關于FAST_START_IO_START、LOG_CHECKPOINT_INTERVAL、LOG_CHECKPOINT_TIMEOUT這三者的區別,

首先明確幾個概念：

1．Data block 是包含幾個os block，也就是一對多的關系。

2．Data files 中的是 data block

Redo log files 中的 redo block 是os block

3．Data block 中記錄的是完整的信息

Redo block 中記錄的是最簡單的信息

在8i 以前的版本，只有兩個參數用來影響recovery，那就是log_checkpoint_interval和log_checkpoint_time。以log_checkpoint_interval=10000舉例。意思很簡單，就是經過10000個redo block后就引發checkpoint,這樣恢復時，就絕對是在這10000個redo block中。

但是這樣做有個缺點，就是因為redo block(os block)不等于data block。假如datablock中的數據很小，比如1，修改成2，那么10000個redo block中包含的信息卻可以是遠遠大于10000個data block，假如data block中的數據很大，比如123456789，修改成987654321，那么10000個redo block中包含的信息卻可以是遠遠小于10000個data block。

這樣，在恢復時，盡管是讀10000個redo blcok，但是這個10000個redo block中所包含的data block有可能是很少，也有可能是很多，很難把握恢復的時間。

于是，在8i中就引進了fast_start_io_tBarget這個參數來彌補這個不足。計算機自動計算redo block中所包含的data block的多少。例如fast_start_io_target=10000，t1(第一次checkpoint)，在t1后有5000個redo block記錄了，但是這個5000個redo block中只包含了7000個data block，那么redo block繼續記錄，到了redo block到8000個時，計算機發現這8000個redo block中包含了10000個data block，那么就引起t2(第二次checkpoint)，凡是在t1和t2之間的任何crash，都可以保證recovery的時間肯定在這 10000個data block的讀寫時間之內(因為1個data block的I/O 是可以估算的)

所以說，設置fast_start_io_target比設置log_checkpoint_interval，log_checkpoint_time這個兩個參數更為準確。假如3個參數一起設置，那么只要達到任一參數值時，就引發checkpoint。

例如：fast_start_io_target=10000，log_checkpoint_interval=10000，log_checkpoint_time=1800。

在redo block=10000時，所包含的data block卻只有8000，就觸發log_checkpoint_interval

在redo block=8000時，所包含的data block 卻有10000，就觸發fast_start_io_target

#########################################################################

他這里說說的log_checkpoint_time估計就是log_checkpoint_timeout，因為我在文檔里也查不到log_checkpoint_time了，呵呵。

而現在一般都推薦使用FAST_START_MTTR_TARGET參數，直接將ORACLE在恢復的過程中花費的時間限定在一個特定的時間段內。

然而我在查看我數據庫中此參數的時候又產生了新的疑惑

SQL> show parameter mttr

NAME???????????????????????????????? TYPE??????? VALUE

------------------------------------ ----------- ------------------------------

fast_start_mttr_target?????????????? integer???? 0

SQL>

為什么我的fast_start_mttr_target 會是0呢？如果是0的話，那么我數據庫啟動時進行恢復的時間又是被哪種機制來控制的呢？總不能無限期長時間恢復吧？上網搜到EYGLE寫過的一篇文章，這里涉及到一個新的概念：自動調整的檢查點

下面摘取文章中部分內容看看

#########################################################################

從Oracle10gR2開始，數據庫可以實現自動調整的檢查點.

使用自動調整的檢查點，Oracle數據庫可以利用系統的低I/O負載時段寫出內存中的臟數據，從而提高數據庫的效率。

因此，即使數據庫管理員設置了不合理的檢查點相關參數，Oracle仍然能夠通過自動調整將數據庫的Crash Recovery時間控制在合理的范圍之內。

當FAST_START_MTTR_TARGET參數未設置時，自動檢查點調整生效。

通常，如果我們必須嚴格控制實例或節點恢復時間，那么我們可以設置FAST_START_MTTR_TARGET為期望時間值；如果恢復時間不需要嚴格控制，那么我們可以不設置FAST_START_MTTR_TARGET參數，從而啟用Oracle10g的自動檢查點調整特性。

當取消FAST_START_MTTR_TARGET參數設置之后：

SQL> show parameter fast_start_mttr

NAME???????????????????????????????? TYPE??????? VALUE

------------------------------------ ----------- ------------------------fast_start_mttr_target?????????????? integer???? 0

在啟動數據庫的時候，我們可以從alert文件中看到如下信息：

Wed Jan 11 16:28:12 2006

MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

檢查v$instance_recovery視圖，我們可以發現Oracle10g中的改變：

SQL> select RECOVERY_ESTIMATED_IOS REIOS,TARGET_MTTR TMTTR,

2? ESTIMATED_MTTR EMTTR,WRITES_MTTR WMTTR,WRITES_OTHER_SETTINGS WOSET,

3? CKPT_BLOCK_WRITES CKPTBW,WRITES_AUTOTUNE WAUTO,WRITES_FULL_THREAD_CKPT WFTCKPT

4? from v$instance_recovery;

REIOS????? TMTTR????? EMTTR????? WMTTR????? WOSET???? CKPTBW????? WAUTO??? WFTCKPT

---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------

49407????????? 0???????? 68????????? 0????????? 0??? 3649819??? 3506125??? 3130700

在以上視圖中，WRITES_AUTOTUNE字段值就是指由于自動調整檢查點執行的寫出次數，

而CKPT_BLOCK_WRITES指的則是由于檢查點寫出的Block的數量。

#########################################################################

了解了吧，這里雖然我的FAST_START_MTTR_TARGET沒有設置，值為0，可是ORACLE是會通過自動檢查點調整特性來控制啟動時恢復的時間的，使它不會太久。

第一個參數LOG_CHECKPOINTS_TO_ALERT就不說了，我們來看看第二個參數FAST_START_PARALLEL_ROLLBACK。

講到這個參數，就不能不談一下INSTANCE RECOVERY的過程。

Instance and crash recovery occur in two steps: cache recovery followed by transaction recovery.

看一下CACHE RECOVERY都做了些什么

The database can be opened as soon as cache recovery completes, so improving the performance of cache recovery is important for increasing availability.

The duration of cache recovery processing is determined by two factors: the number of data blocks that have changes at SCNs higher than the SCN of the checkpoint, and the number of log blocks that need to be read to find those changes.

Frequent checkpointing writes dirty buffers to the datafiles more often than otherwise, and so reduces cache recovery time in the event of an instance failure. If checkpointing is frequent, then applying the redo records in the redo log between the current checkpoint position and the end of the log involves processing relatively few data blocks. This means that the cache recovery phase of recovery is fairly short.

However, in a high-update system, frequent checkpointing can reduce runtime performance, because checkpointing causes DBWn processes to perform writes.

從這里可以看到，CHECKPOINT也并不是越頻繁越好，當然，也不是間隔越久越好，關鍵是要根據系統的具體情況來把握一個合理的“度”。

Cache Recovery (Rolling Forward)

During the cache recovery step, Oracle applies all committed and uncommitted changes in the redo log files to the affected data blocks. The work required for cache recovery processing is proportional to the rate of change to the database (update transactions each second) and the time between checkpoints.

Transaction Recovery (Rolling Back)

To make the database consistent, the changes that were not committed at the time of the crash must be undone (in other words, rolled back). During the transaction recovery step, Oracle applies the rollback segments to undo the uncommitted changes.

ORACLE在恢復的過程中，首先讀取日志，從最后完成的檢查點開始，應用所有重做記錄，這個過程成為前滾。也就是CACHE RECOVERY過程，完成前滾之后，就可以打開數據庫提供訪問和使用了。

此后進入實例恢復的第二階段，ORACLE回滾未提交的事務，也就是TRANSACTION RECOVERY。ORACLE使用兩個特點來增加這個恢復階段的效率，這兩個特點是FAST-START ON-DEMAND ROLLBACK和FAST-START PARALLEL ROLLBACK(這些特點是FAST-START FAULT RECOVERY的組成部分，僅在oracle 8i之后的企業版中可用)。

使用FAST-START ON-DEMAND ROLLBACK特點，ORACLE自動允許在數據庫打開之后開始新的事務，這通常只需要很短的CACHE RECOVERY時間。如果一個用戶試圖訪問被異常中止進程鎖定的記錄，ORACLE回滾那些新事務請求的記錄，也就是說，因需求而回滾。因而，新事務不需要等待漫長的事務回滾時間。在FAST-START ON-DEMAND ROLLBACK中，后臺進程SMON充當一個調度員，使用多個服務器進程并行回滾一個事務集。

FAST-START PARALLEL ROLLBACK主要對于長時間運行的未提交事務有效，尤其是并行INSERT,UPDATE和DELETE操作。SMON自動決定何時開始并行回滾并且自動在多個進程之間分散工作。

FAST-START PARALLEL ROLLBACK的一個特殊形式是內部事務恢復(INTRA-TRANSACTION RECOVERY)。在內部事務恢復中，一個大的事務可以被拆分，分配給幾個服務器進程并行回滾。這個時候就可以通過我們前面說到的那個FAST_START_PARALLEL_ROLLBACK來控制并行回滾。

前面還涉及到一個概念，FAST-START FAULT RECOVERY，在這里引用網上一個朋友的文章簡單的解釋一下。

######################################################

從Oracle8i開始，Oracle在企業版中引入了Fast-Start Fault Recovery選項。

該選項包含三個主要增強:

1.Fast-Start Checkpointing

2.Fast-Start On-Demand Rollback

3.Fast-Start Parallel Rollback.

這三個選項，都是為了加快系統在故障后的恢復，提高系統的可用性。

從v$option視圖中，我們可以找到這個選項:

SQL> select * from v$version where rownum <2;

BANNER

----------------------------------------------------------------

Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production

SQL> select * from v$option

2?? where Parameter='Fast-Start Fault Recovery';

PARAMETER?????????????????????????????????????????? VALUE

-------------------------------------------------- ---------------

Fast-Start Fault Recovery?????????????????????????? TRUE

######################################################

在使用FAST_START_MTTR_TARGET的時候需要注意的事情

You must disable or remove the FAST_START_IO_TARGET, LOG_CHECKPOINT_INTERVAL, and LOG_CHECKPOINT_TIMEOUT initialization parameters when using FAST_START_MTTR_TARGET. Setting these parameters interferes with the mechanisms used to manage cache recovery time to meet FAST_START_MTTR_TARGET.

Practical Values for FAST_START_MTTR_TARGET

The maximum value for FAST_START_MTTR_TARGET is 3600 seconds (one hour). If you set the value to more than 3600, then Oracle rounds it to 3600.

總結

以上是生活随笔為你收集整理的oracle 入参含多个值,oracle几个检查点参数的含义与区别的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。