您好,登錄后才能下訂單哦!
檢查點是一個數據庫事件,它把修改數據從高速緩存寫入磁盤,并更新控制文件和數據文件。
檢查點分為三類:
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]"。
檢查點是一個數據庫事件,它把修改數據從高速緩存寫入磁盤,并更新控制文件和數據文件,總結起來如下:
檢查點分為三類:
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繼續寫出檢查點緩存區。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。