FAST_START_MTTR_TARGET引數

xiexingzhi發表於2012-09-11
AST

1        什麼是FAST_START_MTTR_TARGET

首先，什麼是FAST_START_MTTR_TARGET。引數FAST_START_MTTR_TARGET是指允許DBA指定資料庫進行崩潰恢復需要的秒數。MTTR（mean time to restoration）指平均恢復時間。

恢復時間取決於讀取log files的時間和處理需要恢復的資料塊的時間。引數log_checkpoint_interval設定了恢復過程中將要被讀的重做記錄的數目。 fast_start_io_target控制了需要被恢復的資料塊數目。然而，DBA可以通過單獨設定引數來設定基於秒級的恢復時間限制。 LOG_CHECKPOINT_TIMEOUT限制了上一檢查點和最近的重做記錄之間的秒數。但他對於設定恢復時間限制來說都是不夠精確的！

所以Oracle10r2後有了FAST_START_MTTR_TARGET，實際上這個引數被轉化為設定引數FAST_START_IO_TARGET,LOG_CHECKPOINT_INTERVAL兩個引數。這個特性大大簡化了限定資料庫恢復時間，並增加了準確性。fast_start_mttr_target是一個動態引數，可以線上修改。例如： alter system set fast_start_mttr_target =60;

資料庫的恢復有兩個步驟，Cache Recovery和Transaction Recovery。首先進行Cache Recovery，相當於一個Rolling Forward的過程。即oracle會應用redo log檔案中所有已經提交或在當機時還未提交的變化(因為所有變化在寫入資料檔案前都會先記錄到redo log檔案中)。然後進行Transaction Recovery，相當於一個Rolling Back的過程。即為了使資料庫達到一致性要求，Oracle會回退undo tablespace（Oracle10g中取消了rollback segments，因為回滾段管理起來太複雜）中的所有未提交事務。

Oracle會週期性的記錄檢查點（checkpoint）。關於checkpoint：

“A checkpoint is the highest system change number (SCN) such that all data blocks less than or equal to that SCN are known to be written out to the data files. If a failure occurs, then only the redo records containing changes at SCNs higher than the checkpoint need to be applied during recovery. 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.”

因為checkpoint會促使後臺程式DBWn將髒資料寫入資料檔案，所以頻繁的checkpointing writes有利於大大縮短資料庫的恢復時間。但如此頻繁的寫入操作也會降低資料庫的執行效能。如上面所說，這個頻度由引數FAST_START_MTTR_TARGET決定。當FAST_START_MTTR_TARGET >0時，將會啟用Fast-Start Fault Recovery 功能。關於Fast-Start Fault Recovery：

“The foundation of Fast-Start Fault Recovery is the Fast-Start checkpointing architecture. Instead of conventional event-driven (that is, log switching) checkpointing, which does bulk writes, fast-start checkpointing occurs incrementally. Each DBWn process periodically writes buffers to disk to advance the checkpoint position. The oldest modified blocks are written first to ensure that every write lets the checkpoint advance. Fast-Start checkpointing eliminates bulk writes and the resultant I/O spikes that occur with conventional checkpointing.”

一旦FAST_START_MTTR_TARGET被設定成實際可行的值時，那麼你的資料庫的平均恢復時間會盡量達到該值設定的大小。但有幾點需要注意：

  1. 當你設定FAST_START_MTTR_TARGET時必須禁用或者刪除FAST_START_IO_TARGET, LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT這三個引數。因為這三個引數將會和FAST_START_MTTR_TARGET互相干擾。
  2. FAST_START_MTTR_TARGET的最大值是3600秒，當你設定的值超過3600秒，Oracle會按照3600秒來執行。
  3. 請為FAST_START_MTTR_TARGET設定一個實際可行的值。原則上FAST_START_MTTR_TARGET的最小值是1秒（先不討論0的情況），但是把數值設的很低並不意味著你可以達成這個目標，因為最低的MTTR TARGET是有限制的，它依賴於你資料庫的啟動時間等因素。你資料庫實際能達到的MTTR TARGET稱為effective MTTR target。你可以通過查詢V$INSTANCE_RECOVERY檢視的TARGET_MTTR列來檢視該值。所以假如你將FAST_START_MTTR_TARGET設定過低不僅沒有什麼作用，反而還會因為頻繁的checkpointing writes操作降低了資料庫的效能。同樣假如你將FAST_START_MTTR_TARGET設定過高，他也不會比在你資料庫最遭情況下（整個快取中都是髒資料）花的時間更長。（原文：If you set FAST_START_MTTR_TARGET to a time longer than the practical range, the MTTR target will be no better than the worst-case situation.）

2        如何調整FAST_START_MTTR_TARGET

在初步認識了FAST_START_MTTR_TARGET引數之後，將對他的用法進一步的學習。

首先，為了有效調節FAST_START_MTTR_TARGET引數，必須確保你的系統在標準工作量（typical workload）上執行了足夠長的時間，同時，執行過一些例項恢復操作，從而保證了在恢復期間所記錄的讀取redo塊和讀寫資料塊的時間是準確的。

接著，開始決定FAST_START_MTTR_TARGET的實際可行範圍。

第一步，確定FAST_START_MTTR_TARGET的下邊界。將FAST_START_MTTR_TARGET設定為1，啟動你的資料庫。之後查詢V$INSTANCE_RECOVERY檢視中的TARGET_MTTR引數，此時的TARGET_MTTR就是FAST_START_MTTR_TARGET的最小值。

1TARGET_MTTR ESTIMATED_MTTR
2 
3----------- --------------
4 
538             22

可以發現，雖然FAST_START_MTTR_TARGET設定為1，但它的啟動仍需38秒。由此可見，對於下邊界的設定，資料庫的啟動時間比快取恢復時間更能起到決定作用。

同時也有個疑問，為什麼它的ESTIMATED_MTTR會比TARGET_MTTR——即最小值還小呢？這是因為ESTIMATED_MTTR是平均恢復時間的預期值，依賴於當前正在執行的資料庫。而此時的資料庫因為是剛剛啟動，在它的快取中只有非常少的髒資料，所以才會出現低於最小值的情況。ESTIMATED_MTTR的值會在短期內受到最近資料庫活動的影響。只要做一個簡單的測試就可以驗證。比如對資料庫進行頻繁的更新操作。

1declare
2 
3k number:=20000;
4 
5begin
6 
7while(k<50000)loop
8 
9update sta_finance set  sta_salary=k where sta_id=201000014;
10 
11k := k + 1;
12 
13end loop;
14 
15end;

此時再查詢V$INSTANCE_RECOVERY檢視會發現

1TARGET_MTTR ESTIMATED_MTTR
2 
3----------- --------------
4 
538             41

ESTIMATED_MTTR的值大於了TARGET_MTTR值。我們再等上一會兒，等待ckpt程式發出檢查點，促使後臺程式DBWn將髒資料寫入資料檔案。然後再次查詢V$INSTANCE_RECOVERY檢視，此時

檢視原始碼
<embed>
列印幫助
1TARGET_MTTR ESTIMATED_MTTR
2 
3----------- --------------
4 
538             39

ESTIMATED_MTTR數值降下來了，這是因為一些髒資料被寫到資料檔案中了。

第二步，確定FAST_START_MTTR_TARGET的上邊界。為了確定FAST_START_MTTR_TARGET的上邊界，需要先將FAST_START_MTTR_TARGET設定為它的最大值3600，然後操縱你的資料庫在標準工作量下跑一會兒。此時再檢視V$INSTANCE_RECOVERY檢視，它的TARGET_MTTR所顯示的值就是一個很好的上邊界值。

通過一、二兩步大體上可以確定FAST_START_MTTR_TARGET的實際範圍。

接著第三步，確定一個初步可行的FAST_START_MTTR_TARGET值。這就看不同人對資料庫的要求了。假如更關心資料庫的效能，那麼在範圍內選擇一個較大的值。假如希望更短的恢復時間，那麼就選一個較小的數值。範圍越小，選擇就越容易。

最後，為了得到一個理想的值，就需要用到MTTR Advisor了。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/22531473/viewspace-743133/，如需轉載，請註明出處，否則將追究法律責任。

相關文章