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 hh34: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）時，系統就會促發檢查點，執行寫出之后，系統恢復信息將會重新計算：

RECOVERY_ESTIMATED_IOS 24

ACTUAL_REDO_BLKS 43

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 73

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 183

WRITES_FULL_THREAD_CKPT 0

在繁忙的系統中，可能會觀察到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參數設置之后：

SQL> show parameter fast_start_mttr

NAME TYPE VALUE

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

fast_start_mttr_target integer 0

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

Thu Nov 17 20:27:23 2011

MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

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

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

在以上視圖中，WRITES_AUTOTUNE字段數據就是指由于自動調整檢查點執行的寫出次數，而CK_BLOCK_WRITES指的則是由于檢查點寫出的Block的數量。

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

Oracle的算法改進是一種優化，對于數據庫的調整優化也不外如此，借鑒Oracle的優化對于理解和優化Oracle數據庫都具有極大的好處。

5.從控制文件獲取檢查點信息

在控制文件的轉儲中，可以看到關于檢查點進程進度的記錄：

***************************************************************************

CHECKPOINT PROGRESS RECORDS

***************************************************************************

(size = 8180, compat size = 8180, section max = 11, section in-use = 0,

last-recid= 0, old-recno = 0, last-recno = 0)

(extent = 1, blkno = 2, numrecs = 11)

THREAD #1 - status:0x2 flags:0x0 dirty:34

low cache rba:(0x23.19d5.0) on disk rba:(0x23.1a68.0)

on disk scn: 0x0000.000d847d 11/14/2011 15:25:37

resetlogs scn: 0x0000.0006ce7b 11/10/2011 22:40:23

heartbeat: 767211774 mount id: 1294947385

THREAD #2 - status:0x0 flags:0x0 dirty:0

low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)

這里的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繼續寫出檢查點緩存區。