對引數FAST_START_MTTR_TARGET = 0 的誤解及設定

beatony發表於2011-07-29
 

對引數FAST_START_MTTR_TARGET = 0 的誤解及設定

分類: Oracle 故障處理 2706人閱讀 評論(0) 舉報

--===============================================

--對引數FAST_START_MTTR_TARGET = 0 的誤解及設定

--===============================================

 

        筆者Google了一下關於描述了FAST_START_MTTR_TARGET引數,看到很多文章將該引數置為0時為啟用自動調整的檢查點功能

    如:  

        對其中FAST_START_MTTR_TARGET=0為啟用自動調整的檢查點的這個觀點筆者著是不敢苟同。

   

一、關於FAST_START_MTTR_TARGET引數

 

        是一個加快例項恢復的引數,我們可以根據服務級別來定義一個合理的、可接受的值,該值的單位為秒。比如設定為60s,即2分鐘。

    假定該值處於合理的情況之下,則一旦例項崩潰,在60s以內例項應當能夠被恢復。合理即是該值不能太大,也不能太小。太大則例項恢

    復所需的時間較長,太小則導致大量資料的及時寫入,增加了系統的I/O

   

        影響例項恢復時間長短的主要因素即是從最近檢查點位置到聯機重做日誌尾部之間的距離。距離越長則所需要的cache recovery undo

    redo的時間越長。所以如何有效的縮短最近檢查點位置與聯機重做日誌尾部之間的距離,這正是FAST_START_MTTR_TARGET的目的。

   

        關於檢查點的觸發條件有很多,比如日誌切換、資料庫shutdown、開始結束備份表空間等。檢查點的分類也很多,比如完全檢查點、部

    分檢查點、增量檢查點等。

   

        FAST_START_MTTR_TARGET的值實際上也是觸發檢查點的一個觸發條件。當記憶體中產生的dirty buffer所需的恢復時間(estimated_mttr)

    如果到達FAST_START_MTTR_TARGET的指定時間,則檢查點程式被觸發。檢查點程式一旦被觸發,將通知DBWn程式將按檢查點佇列順序將髒數

    據寫入到資料檔案,從而縮短了最後檢查點位置與聯機重做日誌間的距離,減少了例項恢復所需的時間。

   

        關於例項的恢復以及檢查的具體分類描述等,請參考:

            Oracle 例項恢復

            Oracle例項和Oracle資料庫(Oracle體系結構)           

 

二、FAST_START_MTTR_TARGET = 0的質疑

   

        很多文章描述了FAST_START_MTTR_TARGET = 0,即為未設定,表示啟用自動檢查點功能,下面是來自Oracle的官方文件中的一段,

    原文的連結為:

   

        Fast-start checkpointing refers to the periodic writes by the database writer (DBWn) processes for the purpose of writing changed data blocks from the Oracle buffer cache to disk and advancing the thread-checkpoint. Setting the database parameter FAST_START_MTTR_TARGET to a value greater than zero enables the fast-start checkpointing feature. Fast-start checkpointing should always be enabled for the following reasons:

 

        It reduces the time required for cache recovery, and makes instance recovery time-bounded and predictable. This is accomplished by limiting the number of dirty buffers (data blocks which have changes in memory that still need to be written to disk) and the number of redo records (changes in the database) generated between the most recent redo record and the last checkpoint.

   

        Fast-Start checkpointing eliminates bulk writes and corresponding I/O spikes that occur traditionally with interval- based checkpoints, providing a smoother, more consistent I/O pattern that is more predictable and easier to manage. If the system is not  already near or at its maximum I/O capacity, fast-start checkpointing will have a negligible impact on performance. Although  fast-start checkpointing results in increased write activity, there is little reduction in database throughout, provided the system  has sufficient I/O capacity.

 

        從第一段中粗體標記的描述來看,當設定一個大於0的值給FAST_START_MTTR_TARGET,則自動調整檢查點功能別啟用。即fast-start

    checkpointing,更準確的說應該是快速啟動檢查點功能

   

        再看下面的這段描述,這段來自Oracle 10g OCP workshop I 14-17 英文版教程(Edition 3.1 December 2008)

   

        Explicit setting of the FAST_START_MTTR_TARGET parameter to 0 disables automatic checkpoint tuning.Explicit setting of the FAST_START_MTTR_TARGET parameter to a value other than 0 also enables the Redo Log Advisor.

   

        從上面的描述可以看出,如果將FAST_START_MTTR_TARGET設定為將關閉檢查點自動調整功能。

       

三、設定FAST_START_MTTR_TARGET

        根據實際需要來設定FAST_START_MTTR_TARGET的值,這個值的設定需要考慮到可接受的例項的恢復時間、可承受的I/O吞吐量等等。

        假定我們將該值設定為

            SQL> alter system set fast_start_mttr_target = 30 ;

        在事務頻繁的時間段來考察檢視v$instacne_recovery提供的值

       

        SQL> desc v$instance_recovery;   --檢視v$instance_recovery檢視的結構

         Name                                      Null?    Type

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

         RECOVERY_ESTIMATED_IOS                             NUMBER

         ACTUAL_REDO_BLKS                                   NUMBER

         TARGET_REDO_BLKS                                   NUMBER

         LOG_FILE_SIZE_REDO_BLKS                            NUMBER

         LOG_CHKPT_TIMEOUT_REDO_BLKS                        NUMBER

         LOG_CHKPT_INTERVAL_REDO_BLKS                       NUMBER

         FAST_START_IO_TARGET_REDO_BLKS                     NUMBER

         TARGET_MTTR                                        NUMBER

         ESTIMATED_MTTR                                     NUMBER

         CKPT_BLOCK_WRITES                                  NUMBER

         OPTIMAL_LOGFILE_SIZE                               NUMBER

         ESTD_CLUSTER_AVAILABLE_TIME                        NUMBER

         WRITES_MTTR                                        NUMBER

         WRITES_LOGFILE_SIZE                                NUMBER

         WRITES_LOG_CHECKPOINT_SETTINGS                     NUMBER

         WRITES_OTHER_SETTINGS                              NUMBER

         WRITES_AUTOTUNE                                    NUMBER

         WRITES_FULL_THREAD_CKPT                            NUMBER

 

        兩個欄位:

            TARGET_MTTR         --&gt參照fast_start_mttr_target引數中設定的值計算出來的一個值

            ESTIMATED_MTTR      --&gt系統根據dirty buffer 中計算出來的值

        可能出現的情況

            1.TARGET_MTTR > ESTIMATED_MTTR  --大量的事務將導致這種情況的出現

            2.TARGET_MTTR < ESTIMATED_MTTR  --資料庫剛剛啟動時,幾乎沒有事務時會出現這種情況

 

SQL> select recovery_estimated_ios,actual_redo_blks ,target_redo_blks ,

  2  target_mttr,estimated_mttr

  3  from v$instance_recovery;

 

RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR

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

                    55              147              707          33             27

 

        可以在負載的情況下根據TARGET_MTTR來值透過v$mttr_target_advice調整該引數

 

四、啟用MTTR Advisory

        需要設定兩個引數

            STATISTICS_LEVEL         --&gt置為typical 或者all

            FAST_START_MTTR_TARGET   --&gt置為非零值

 

        SQL> show parameter mttr;    --目標mttr_time設定為30 s

 

        NAME                                 TYPE        VALUE

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

 

        fast_start_mttr_target               integer     30

 

        SQL> select  target_mttr,estimated_mttr from v$instance_recovery;   --系統計算出來的mttr33

 

        TARGET_MTTR ESTIMATED_MTTR

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

                 33             27     

 

        SQL> select mttr_target_for_estimate tar_est,dirty_limit,estd_cache_writes est_c_w,

          2  estd_cache_write_factor est_c_w_f,estd_total_writes est_t_w,estd_total_write_factor est_t_w_f

          3  from v$mttr_target_advice;

 

           TAR_EST DIRTY_LIMIT    EST_C_W  EST_C_W_F    EST_T_W  EST_T_W_F

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

                60        5028       3762      .7376       3762      .7376

                34        1000       5100          1       5100          1

                68        6248       3762      .7376       3762      .7376

                52        3808       3762      .7376       3762      .7376

                45        2735       3845      .7539       3845      .7539

   

        --mttr_target_for_estimate有一個值為的最接近設定的目標時間30,以及由系統計算出的的target_mttr時間33

        --同時也給出了幾組不同的mttr_target值及dirty_limit,cache_write,io 等來供DBA來選擇設定合適的mttr

 

五、兩個重要的檢視

        v$instacne_recovery

        v$mttr_target_advice

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

相關文章