轉載地址：http://www.cnblogs.com/Ronger/archive/2011/12/09/2281650.html
檢查點是一個數據庫事件，它把修改數據從高速緩存寫入磁盤，並更新控制文件和數據文件。
檢查點分爲三類：
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可以從數據庫中查詢得到：
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視圖，瞭解這一特性：
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 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.
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建議：
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建議信息被手機：
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
statistics_level string TYPICAL
也可以通過v$statistics_level視圖來查詢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查詢得到：
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是磁盤上的最高的重做值，在進行恢復時應用重做至少要達到這個值。
檢查點（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的髒緩衝區隊列。
注：控制文件與數據文件頭包含檢查點結構信息。
在兩種情況下，文件頭中的檢查點信息（獲取當前檢查點信息時）將不做更新：
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繼續寫出檢查點緩存區。