oracle之檢查點（Checkpoint）

標籤：

檢查點是一個資料庫事件，它把修改資料從快取寫入磁碟，並更新控制檔案和資料檔案。
檢查點分為三類：
1）局部檢查點：單個執行個體執行資料庫所有資料檔案的一個檢查點操作，屬於此執行個體的全部髒緩衝區寫入資料檔案。
觸發命令：
svmrgrl>alter system checkpoint local;
這條命令顯示的觸發一個局部檢查點。
2）全域檢查點：所有執行個體（對應並行資料服務器）執行資料庫所有所有資料檔案的一個檢查點操作，屬於此執行個體的全部髒緩衝區寫入資料檔案。
觸發命令
svrmgrl>alter system checkpoint global;
這條命令顯示的觸發一個全域檢查點。
3）檔案檢查點：所有執行個體需要執行資料檔案集的一個檢查點操作，如使用熱備份命令alter tablespace USERS begin backup，或資料表空間離線命令alter tablespace USERS offline，將執行屬於USERS資料表空間的所有資料檔案的一個檢查點操作。

檢查點處理步驟：
1）擷取執行個體狀態隊列：執行個體狀態隊列是在執行個體狀態轉變時獲得，ORACLE獲得此隊列以保證檢查點執行期間，資料庫處於開啟狀態；
2）擷取當前檢查點資訊：擷取檢查點記錄資訊的結構，此結構包括當前檢查點時間、活動線程、進行檢查點處理的當前線程、記錄檔中恢複截止點的地址資訊；
3）緩衝區標識：標識所有髒緩衝區，當檢查點找到一個髒緩衝區就將其標識為需進行重新整理，標識的髒緩衝區由系統進程DBWR進行寫操作，將髒緩衝區的內容寫入資料檔案；
4）髒緩衝區重新整理：DBWR進程將所有髒緩衝區寫入磁碟後，設定一標誌，標識已完成髒緩衝區至磁碟的寫入操作。系統進程LGWR與CKPT進程將繼續進行檢查，直至DBWR進程結束為止；
5）更新控制檔案與資料檔案。
註：控制檔案與資料檔案頭包含檢查點結構資訊。
在兩種情況下，檔案頭中的檢查點資訊（擷取當前檢查點資訊時）將不做更新：
1）資料檔案不處於熱備份方式，此時ORACLE將不知道作業系統將何時讀檔案頭，而備份拷貝在拷貝開始時必須具有檢查點SCN；
ORACLE在資料檔案頭中保留一個檢查點的記數器，在正常操作中保證使用資料檔案的目前的版本，在恢複時防止恢複資料檔案的錯誤版本；即使在熱備份方式下，計數器依然是遞增的；每個資料檔案的檢查點計數器，也保留在控制檔案相對應資料檔案項中。
2）檢查SCN小於檔案頭中的檢查點SCN的時候，這表明由檢查點產生的改動已經寫到磁碟上，在執行全域檢查點的處理過程中，如果一個熱備份快速檢查點在更新檔案頭時，則可能發生此種情況。應該注意的是，ORACLE是在實際進行檢查點處理的大量工作之前捕獲檢查SCN的，並且很有可能被一條象熱備份命令alter tablespace USERS begin backup進行快速檢查點處理時的命令打斷。
ORACLE在進行資料檔案更新之前，將驗證其資料一致性，當驗證完成，即更新資料檔案頭以反映當前檢查點的情況；未經驗證的資料檔案與寫入時出現錯誤的資料檔案都被忽略；如果記錄檔被覆蓋，則這個檔案可能需要進行介質恢複，在這種情況下，ORACLE系統進程DBWR將此資料檔案離線。
檢 查點演算法描述：
髒緩衝區用一個新隊列連結，稱為檢查點隊列。對緩衝區的每一個改動，都有一個與其相關的重做值。檢查點隊列包含髒的日誌緩衝區，這些緩衝區按照它們在記錄檔中的位置排序，即在檢查點隊列中，緩衝區按照它們的低重做值進行排序。需要注意的是，由於緩衝區是依照第一次變髒的次序連結到隊列中的，所以，如果在緩衝區寫出之前對它有另外的改動，連結不能進行相應變更，緩衝區一旦被連結到檢查點隊列，它就停留在此位置，直到將它被寫出為止。
ORACLE系統進程DBWR在響應檢查點請求時，按照這個隊列的低重做值的升序寫出緩衝區。每個檢查點請求指定一個重做值，一旦DBWR寫出的緩衝區重做值等於或大雨檢查點的重做值，檢查點處理即完成，並將記錄到控制檔案與資料檔案。
由於檢查點隊列上的緩衝區按照低重做值進行排序，而DBWR也按照低重做值順序寫出檢查點緩衝區，故可能有多個檢查點請求處於活動狀態，當DBWR寫出緩衝區時，檢查位於檢查點隊列前端的緩衝區重做值與檢查點重做值的一致性，如果重做值小於檢查點隊列前緩衝區的低重做值的所有檢查點請求，即可表示處理完成。當存在未完成的活動檢查點請求時，DBWR繼續寫出檢查點緩衝區。
演算法特點：
1）DBWR能確切的知道為滿足檢查點請求需要寫那些緩衝區；
2）在每次進行檢查點寫時保證指向完成最早的（具有最低重做值的）檢查點；
3）根據檢查點重做值可以區別多個檢查點請求，然後按照它們的順序完成處理。

1.檢查點（Checkpoint）的本質

 

許多文檔把Checkpint描述得非常複雜，為我們正確理解檢查點帶來了障礙，結果現在檢查點變成了一個非常複雜的問題。實際上，檢查點只是一個資料庫事件，它存在的根本意義在於減少崩潰恢複（Crash Recovery）時間。

當修改資料時，需要首先將資料讀入記憶體中（Buffer Cache），修改資料的同時，Oracle會記錄重做資訊（Redo）用於恢複。因為有了重做資訊的存在，Oracle不需要在提交時立即將變化的資料寫回磁碟（立即寫的效率會很低），重做（Redo）的存在也正是為了在資料庫崩潰之後，資料就可以恢複。

最常見的情況，資料庫可以因為斷電而Crash，那麼記憶體中修改過的、尚未寫入檔案的資料將會丟失。在下一次資料庫啟動之後，Oracle可以通過重做日誌（Redo）進行事務重演，也就是進行前滾，將資料庫恢複到崩潰之前的狀態，然後資料庫可以開啟提供使用，之後Oracle可以將未提交的資料進行復原。

在這個過程中，通常大家最關心的是資料庫要經曆多久才能開啟。也就是需要讀取多少重做日誌才能完成前滾。當然使用者希望這個時間越短越好，Oracle也正是通過各種手段在不斷最佳化這個過程，縮短恢復。

檢查點的存在就是為了縮短這個恢復。

當檢查點發生時（此時的SCN被稱為CheckPoint SCN），Oracle會通知DBWR進程，把修改過的資料，也就是Checkpoint SCN之前的髒資料（Dirty Data）從Buffer Cache寫入磁碟，當寫入完成之後，CKPT進程更新控制檔案和資料檔案頭，記錄檢查點資訊，標識變更。

Oracle SCN的相關知識可以參考我的另外一篇文章：DBA入門之認識Oracle SCN（System Change Number）

Checkpoint SCN可以從資料庫中查詢得到：

 

SQL> select file#,CHECKPOINT_CHANGE#,to_char(CHECKPOINT_TIME,‘yyyy-mm-dd hh24:mi:ss‘) cpt from v$datafile;

FILE# CHECKPOINT_CHANGE# CPT

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

1 913306 2011-11-16 16:06:06

2 913306 2011-11-16 16:06:06

3 913306 2011-11-16 16:06:06

4 913306 2011-11-16 16:06:06

SQL> select dbid,CHECKPOINT_CHANGE# from v$database;

DBID CHECKPOINT_CHANGE#

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

1294662348 913306

 

 

 

在檢查點完成之後，此檢查點之前修改過的資料都已經寫回磁碟，重做記錄檔中的相應重做記錄對於崩潰/執行個體恢複不再有用。

標記了3個日誌組，假定在T1時間點，資料庫完成並記錄了最後一次檢查點，在T2時刻資料庫Crash。那麼在下次資料庫啟動時，T1時間點之前的Redo不再需要進行恢複，Oracle需要重新應用的就是時間點T1至T2之間資料庫產生的重做日誌（Redo）。

 

 

可以很輕易地看出來，檢查點的頻率對於資料庫的恢復具有極大的影響，如果檢查點的頻率高，那麼恢複時需要應用的重做日誌就相對得少，檢查時間就可以縮短。然而，需要注意的是，資料庫內部操作的相對性極強，國語平凡的檢查點同樣會帶來效能問題，尤其是更新頻繁的資料庫。所以資料庫的最佳化是一個系統工程，不能草率。

更進一步可以知道，如果Oracle可以在效能允許的情況下，使得檢查點的SCN主鍵逼近Redo的最新更新，那麼最終可以獲得一個最佳平衡點，使得Oracle可以最大化地減少恢復。

為了實現這個目標，Oracle在不同版本中一直在改進檢查點的演算法。

 

2.常規檢查點與增量檢查點

為了區分，在Oracle8之前，Oracle即時的檢查點通常被稱為常規檢查點（Conventional Checkpoint）,這類檢查點按一定的條件出發（log_checkpoint_interval、log_checkpoint_timeout參數設定及log switch等條件出發）。

從Oracle 8開始，Oracle引入了增量檢查點（Inctrmental Checkpoint）的概念。

和以前的版本相比，在新版本中，Oracle主要引入了檢查點隊列（Checkpoinnt Queue）機制，在資料庫內部，每一個髒資料區塊都會被移動到檢查點隊列，按照Low RBA的順序（第一次對比資料區塊修改對應的Redo Byte Address）來排列，如果一個資料區塊進行過多次修改，該資料庫在檢查點隊列上的順序並不會發生變化。

當執行檢查點時，DBWR從檢查點隊列按照Low RBA的順序寫出，執行個體檢查點因此可以不斷增進、階段性的，CKPT進程使用非常輕量級的控制檔案更新協議，將當前的最低RBA寫入控制檔案。

因為增量檢查點可以連續地進行，因此檢查點RBA可以比常規檢查點更接近資料庫的最後狀態，從而在資料庫的執行個體恢複中可以極大地減少恢復。

而且，通過增量檢查點，DBWR可以持續進行寫出，從而避免了常規檢查點出發的峰值寫入對於I/O的國度徵用，通過可以清楚地看到這一改進的意義。

 

 

在資料庫中，增量檢查點是通過Fast-Start Checkpointing特性來實現的，從Oracle 8i開始，這一特性包含了Oracle企業版的Fast-Start Fault Recovery組件之中，通過查詢v$option視圖，瞭解這一特性：

 

 

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

BANNER

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

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – Prod

SQL> col parameter for a30

SQL> col value for a20

SQL> select * from V$option where Parameter=‘Fast-Start Fault Recovery‘;

PARAMETER VALUE

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

Fast-Start Fault Recovery TRUE

 

 

該組件包含3個主要特性，可以加快系統在故障後的恢複，提高系統的可用性。

 

Fast-Start Checkpointing;

Fast-Start On-Demand Rollback;

Fast-Start Parallel Rollback;

 

 

Fast-Start Checkpointing 特性在Oracle 8i中主要通過參數FAST_START_IO_TARGET來實現，在Oracle 9i中，Fast-Start Checkpointing主要通過參數FAST_START_MTTR_TARGET來實現。

 

3.FAST_START_MTTR_TARGET

FAST_START_MTTR_TARGET參數從Oracle 9i開始被引入，該參數定義資料庫進行Crash恢複的時間，單位是秒，取值範圍是在0~3600秒之間。

在Oracle 9i中，Oracle推薦設定這個參數代替FAST_START_IO_TARGE、LOG_CHECKPOINT_TIMEROUT及LOG_CHECKPOINT_INSTERVAL參數。

預設情況下，在Oracle 9i中，FAST_START_IO_TARGET和LOG_CHECKPOINT_INTERVAL參數已經被設定為0.

 

 

SQL> show parameter fast_start_io

NAME TYPE VALUE

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

fast_start_io_target integer 0

SQL> show parameter interval

NAME TYPE VALUE

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

log_checkpoint_interval integer 0

 

在Oracle 9i R2開始，Oracle引入了一個新的視圖提供MTTR建議：

 

SQL> select * from v$mttr_target_advice;

MTTR_TARGET_FOR_ESTIMATE ADVICE_STATUS DIRTY_LIMIT ESTD_CACHE_WRITES ESTD_CACHE_WRITE_FACTOR ESTD_TOTAL_WRITES ESTD_TOTAL_WRITE_FACTOR ESTD_TOTAL_IOS ESTD_TOTAL_IO_FACTOR

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

 

 

該視圖評估在不同FAST_START_MATTR_TARGET設定下，系統需要執行的I/O次數等操作。使用者可以根據資料庫的建議，對FAST_START_MTTR_TARGET進行相應調整。

這個建議資訊的手機收到Oracle 9i新引入的初始化參數statistics_level的控制，當該參數設定為Typical或ALL時，MTTR建議資訊被手機：

 

SQL> show parameter statistics_level

NAME TYPE VALUE

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

statistics_level string TYPICAL

 

也可以通過v$statistics_level視圖來查詢MTTR_Advice的當前設定：

 

SQL> select * from v$statistics_level where STATISTICS_NAME=‘MTTR Advice‘;

STATISTICS_NAME DESCRIPTION SESSION_STATUS SYSTEM_STATUS ACTIVATION_LEVEL STATISTICS_VIEW_NAME SESSION_SETTABLE

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

MTTR Advice Predicts the impact of different MTTR settings on number of physical I/Os ENABLED ENABLED TYPICAL V$MTTR_TARGET_ADVICE NO

 

 

資料庫當前的執行個體恢複狀態可以通過視圖v$instance_recovery查詢得到：

 

SQL> select * from v$instance_recovery;

RECOVERY_ESTIMATED_IOS 53

ACTUAL_REDO_BLKS 376

TARGET_REDO_BLKS 184320

LOG_FILE_SIZE_REDO_BLKS 184320

LOG_CHKPT_TIMEOUT_REDO_BLKS

LOG_CHKPT_INTERVAL_REDO_BLKS

FAST_START_IO_TARGET_REDO_BLKS

TARGET_MTTR 0

ESTIMATED_MTTR 18

CKPT_BLOCK_WRITES 27

OPTIMAL_LOGFILE_SIZE

ESTD_CLUSTER_AVAILABLE_TIME

WRITES_MTTR 0

WRITES_LOGFILE_SIZE 0

WRITES_LOG_CHECKPOINT_SETTINGS 0

WRITES_OTHER_SETTINGS 0

WRITES_AUTOTUNE 104

WRITES_FULL_THREAD_CKPT 0

 

 

從v$instance_recovery視圖，可以看到當前資料庫估計的平均恢復（MTTR）參數：ESTIMATED_MTTR。

ESTIMATED_MTTR的估算值是基於Dirty Buffer 的資料量和日誌塊數量得出的，這個參數值告訴我們，如果此時資料庫本虧，那麼進行執行個體恢複將會需要的時間。

在V$instance_revovery視圖中，TARGET_MTTR代表的是期望的恢復，通常改參數應該等於FAST_START_MTTR_TARGET參數設定值（但是如果FAST_START_MTTR_TARGET參數定義的值極大或極小，TARGET_MEER可能不等於FAST_START_MTTR_TARGET的設定）。

當ESTIMATED_MTTR接近或超過FAST_START_MTTR_TARGET參數設定（v$instance_recovery TARGET_MTTR）時，系統就會促發檢查點，執行寫出之後，系統復原資訊將會重新計算：

 

View Code

 

在繁忙的系統中，可能會觀察到ESTIMATED_MTTR>TARGET_MTTR，這可能是因為DBWR正忙於寫出，甚或出現Checkpoint不能及時完成的情況。

 

4. Oracle 10g自動檢查點調整

從Oracle 10g開始，資料庫可以實現自動調整的檢查點，使用自動調整的檢查點，Oracle資料庫可以利用系統的低I/O負載時段寫出記憶體中的髒資料，從而提高資料庫的效率。因此，及時資料庫管理員設定了不合理的檢查點相關參數，Oracle仍然能夠通過自動調整將資料庫的Crash Recovery時間控制在合理的範圍之內。

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

通常，如果必須嚴格控制執行個體或節點恢復，那麼可以設定FAST_START_MTTR_TARGET為期望時間值；如果恢復不嚴格控制，那麼可以不設定FAST_START_MTTR_TARGET參數，從而啟用Oracle 10g的自動調整特性。

當取消FAST_START_MTTR_TARGET參數設定之後：

 

View Code

在啟動資料庫的時候，可以從alter檔案中看到如下資訊：

View Code

檢查v$instance_recovery視圖，可以發現Oracle 10g的改變：

View Code

 

在以上視圖中，WRITES_AUTOTUNE欄位資料就是指由於自動調整檢查點執行的寫出次數，而CK_BLOCK_WRITES指的則是由於檢查點寫出的Block的數量。

關於檢查點的機制問題，我們側重介紹了原理，至於具體的演算法實現，不需要去追究過多，只要明白了這個原理性的規則，理解Oracle就會變成輕鬆的事情。

Oracle的演算法改進是一種最佳化，對於資料庫的調整最佳化也不外如此，借鑒Oracle的最佳化對於理解和最佳化Oracle資料庫都具有極大的好處。

5.從控制檔案擷取檢查點資訊

在控制檔案的轉儲中，可以看到關於檢查點進程進度的記錄：

 

View Code

 

這裡的low cache rba（Revovery block address）指在Cache中，最低的RBA地址，在執行個體恢複或者崩潰恢複中，需要從這裡開始恢複。

On disk dba是磁碟上的最高的重做值，在進行恢複時應用重做至少要達到這個值。

 

除了檢查點隊列（CKPTQ）之外，資料庫中還存在另外一個隊列和檢查點有關，這就是檔案檢查點隊列（FILE QUEUE），通常稱為FILEQ，檔案檢查點的引入提供了資料表空間相關的檢查點的效能。每個Dirty  Buffer同時連結到這兩個隊列，CKPTQ包含執行個體所有需要執行檢查點的Buffer，FILEQ包含屬於特定檔案需要執行的檢查點Buffer，每個檔案都包含一個檔案隊列，在執行資料表空間檢查點請求時需要使用FILEQ，通常當對錶空間執行Offline等操作時會觸發資料表空間檢查點。CKPTQ和FILEQ都是雙向鏈表，每個隊列中都記錄了兩個地址資訊，分別是前一塊和下一塊Buffer的地址資訊。注意只有Dirty Buffer才會包含CKPTQ資訊，否則為NULL，資訊類似"ckptq:[NULL]fileq:[NULL]"。

 

檢查點（checkpoint）的工作機制

 

檢查點是一個資料庫事件，它把修改資料從快取寫入磁碟，並更新控制檔案和資料檔案，總結起來如下：

檢查點分為三類：
1）局部檢查點：單個執行個體執行資料庫所有資料檔案的一個檢查點操作，屬於此執行個體的全部髒緩衝區寫入資料檔案。
觸發命令：
svmrgrl>alter  system checkpoint local;
這條命令顯示的觸發一個局部檢查點。
2）全域檢查點：所有執行個體（對應並行資料 伺服器）執行資料庫所有所有資料檔案的一個檢查點操作，屬於此執行個體的全部髒緩衝區寫入資料檔案。
觸發命令
svrmgrl>alter system checkpoint global;
這條命令顯示的觸發一個全域檢查點。
3）檔案檢查點：所有執行個體需要執行資料檔案集的一個檢查點操作，如使用熱 備份命令alter   tablespace USERS begin backup，或資料表空間離線命令alter tablespace USERS offline，將執行屬於USERS資料表空間的所有資料檔案的一個檢查點操作。

檢查點處理步驟：
1）擷取執行個體狀態隊列：執行個體狀態隊列是在執行個體狀態轉變時獲得，ORACLE獲得此隊列以保證檢查點執行期間，資料庫處於開啟狀態；
2）擷取當前檢查點資訊：擷取檢查點記錄資訊的結構，此結構包括當前檢查點時間、活動線程、進行檢查點處理的當前線程、記錄檔中恢複截止點的地址資訊；
3）緩衝區標識：當資料在buffer cache中做了修改之後會自動被為髒緩衝區，加入到Checkpoint Queue的髒緩衝區隊列。

 

4）髒緩衝區重新整理：當檢查點發生時，會到CKPTQ中的髒緩衝區隊列找到到目前為止最大的LRBA，並通知DBWR進程將所有髒緩衝區寫入磁碟，完成之後設定一標誌，標識已完成髒緩衝區至磁碟的寫入操作，以便重新整理髒緩衝隊列（此時DML可以繼續進行）。系統進程LGWR與CKPT進程將繼續進行檢查，直至DBWR進程結束為止；

 

5）更新控制檔案與資料檔案。
註：控制檔案與資料檔案頭包含檢查點結構資訊。
在兩種情況下，檔案頭中的檢查點資訊（擷取當前檢查點資訊時）將不做更新：
1）資料檔案不處於熱備份方式，此時ORACLE將不知道作業系統將何時讀檔案頭，而備份拷貝在拷貝開始時必須具有檢查點SCN；
ORACLE在資料檔案頭中保留一個檢查點的記數器，在正常操作中保證使用資料檔案的目前的版本，在恢複時防止恢複資料檔案的錯誤版本；即使在熱備份方式下，計數器依然是遞增的；每個資料檔案的檢查點計數器，也保留在控制檔案相對應資料檔案項中。
2）檢查SCN小於檔案頭中的檢查點SCN的時候，這表明由檢查點產生的改動已經寫到磁碟上，在執行全域檢查點的處理過程中，如果一個熱備份快速檢查點在更新檔案頭時，則可能發生此種情況。應該注意的是，ORACLE是在實際進行檢查點處理的大量工作之前捕獲檢查SCN的，並且很有可能被一條象熱備份命令 
alter tablespace USERS begin backup進行快速檢查點處理時的命令打斷。
ORACLE在進行資料檔案更新之前，將驗證其資料一致性，當驗證完成，即更新資料檔案頭以反映當前檢查點的情況；未經驗證的資料檔案與寫入時出現錯誤的資料檔案都被忽略；如果記錄檔被覆蓋，則這個檔案可能需要進行介質恢複，在這種情況下，ORACLE系統進程DBWR將此資料檔案離線。

檢查點演算法描述：
髒緩衝區用一個新隊列連結，稱為檢查點隊列。對緩衝區的每一個改動，都有一個與其相關的重做值。檢查點隊列包含髒的日誌緩衝區，這些緩衝區按照它們在記錄檔中的位置排序，即在檢查點隊列中，緩衝區按照它們的LRBA進行排序。需要注演算法特點：
3）根據檢查點重做值可以區別多個檢查點請求，然後按照它們的順序完成處理。
1）DBWR能確切的知道為滿足檢查點請求需要寫那些緩衝區；
2）在每次進行檢查點寫時保證指向完成最早的（具有最低重做值的）檢查點；意的是，由於緩衝區是依照第一次變髒的次序連結到隊列中的，所以，如果在緩衝區寫出之前對它有另外的改動，連結不能進行相應變更，緩衝區一旦被連結到檢查點隊列，它就停留在此位置，直到將它被寫出為止。

ORACLE系統進程DBWR在響應檢查點請求時，按照這個隊列的LRBA的升序寫出緩衝區。每個檢查點請求指定一個重做值，一旦DBWR寫出的緩衝區重做值等於或大雨檢查點的重做值，檢查點處理即完成，並將記錄到控制檔案與資料檔案。
由於檢查點隊列上的緩衝區按照低重做值進行排序，而DBWR也按照低重做值順序寫出檢查點緩衝區，故可能有多個檢查點請求處於活動狀態，當DBWR寫出緩衝區時，檢查位於檢查點隊列前端的緩衝區重做值與檢查點重做值的一致性，如果重做值小於檢查點隊列前緩衝區的低重做值的所有檢查點請求，即可表示處理完成。當存在未完成的活動檢查點請求時，DBWR繼續寫出檢查點緩衝區。轉：http://www.cnblogs.com/Ronger/archive/2011/12/09/2281650.html

oracle之檢查點（Checkpoint）