|
檢查點(diǎn)是一個(gè)數(shù)據(jù)庫(kù)事件，它把修改數(shù)據(jù)從高速緩存寫(xiě)入磁盤，并更新控制文件和數(shù)據(jù)文件。
1.檢查點(diǎn)（Checkpoint）的本質(zhì)
許多文檔把Checkpint描述得非常復(fù)雜，為我們正確理解檢查點(diǎn)帶來(lái)了障礙，結(jié)果現(xiàn)在檢查點(diǎn)變成了一個(gè)非常復(fù)雜的問(wèn)題。實(shí)際上，檢查點(diǎn)只是一個(gè)數(shù)據(jù)庫(kù)事件，它存在的根本意義在于減少崩潰恢復(fù)（Crash Recovery）時(shí)間。 當(dāng)修改數(shù)據(jù)時(shí)，需要首先將數(shù)據(jù)讀入內(nèi)存中（Buffer Cache），修改數(shù)據(jù)的同時(shí)，Oracle會(huì)記錄重做信息（Redo）用于恢復(fù)。因?yàn)橛辛酥刈鲂畔⒌拇嬖冢琌racle不需要在提交時(shí)立即將變化的數(shù)據(jù)寫(xiě)回磁盤（立即寫(xiě)的效率會(huì)很低），重做（Redo）的存在也正是為了在數(shù)據(jù)庫(kù)崩潰之后，數(shù)據(jù)就可以恢復(fù)。 最常見(jiàn)的情況，數(shù)據(jù)庫(kù)可以因?yàn)閿嚯姸鳦rash，那么內(nèi)存中修改過(guò)的、尚未寫(xiě)入文件的數(shù)據(jù)將會(huì)丟失。在下一次數(shù)據(jù)庫(kù)啟動(dòng)之后，Oracle可以通過(guò)重做日志（Redo）進(jìn)行事務(wù)重演，也就是進(jìn)行前滾，將數(shù)據(jù)庫(kù)恢復(fù)到崩潰之前的狀態(tài)，然后數(shù)據(jù)庫(kù)可以打開(kāi)提供使用，之后Oracle可以將未提交的數(shù)據(jù)進(jìn)行回滾。 在這個(gè)過(guò)程中，通常大家最關(guān)心的是數(shù)據(jù)庫(kù)要經(jīng)歷多久才能打開(kāi)。也就是需要讀取多少重做日志才能完成前滾。當(dāng)然用戶希望這個(gè)時(shí)間越短越好，Oracle也正是通過(guò)各種手段在不斷優(yōu)化這個(gè)過(guò)程，縮短恢復(fù)時(shí)間。 檢查點(diǎn)的存在就是為了縮短這個(gè)恢復(fù)時(shí)間。 當(dāng)檢查點(diǎn)發(fā)生時(shí)（此時(shí)的SCN被稱為CheckPoint SCN），Oracle會(huì)通知DBWR進(jìn)程，把修改過(guò)的數(shù)據(jù)，也就是Checkpoint SCN之前的臟數(shù)據(jù)（Dirty Data）從Buffer Cache寫(xiě)入磁盤，當(dāng)寫(xiě)入完成之后，CKPT進(jìn)程更新控制文件和數(shù)據(jù)文件頭，記錄檢查點(diǎn)信息，標(biāo)識(shí)變更。 Oracle SCN的相關(guān)知識(shí)可以參考我的另外一篇文章：DBA入門之認(rèn)識(shí)Oracle SCN（System Change Number） Checkpoint SCN可以從數(shù)據(jù)庫(kù)中查詢得到：
 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
在檢查點(diǎn)完成之后，此檢查點(diǎn)之前修改過(guò)的數(shù)據(jù)都已經(jīng)寫(xiě)回磁盤，重做日志文件中的相應(yīng)重做記錄對(duì)于崩潰/實(shí)例恢復(fù)不再有用。 下圖標(biāo)記了3個(gè)日志組，假定在T1時(shí)間點(diǎn)，數(shù)據(jù)庫(kù)完成并記錄了最后一次檢查點(diǎn)，在T2時(shí)刻數(shù)據(jù)庫(kù)Crash。那么在下次數(shù)據(jù)庫(kù)啟動(dòng)時(shí)，T1時(shí)間點(diǎn)之前的Redo不再需要進(jìn)行恢復(fù)，Oracle需要重新應(yīng)用的就是時(shí)間點(diǎn)T1至T2之間數(shù)據(jù)庫(kù)生成的重做日志（Redo）。
上圖可以很輕易地看出來(lái)，檢查點(diǎn)的頻率對(duì)于數(shù)據(jù)庫(kù)的恢復(fù)時(shí)間具有極大的影響，如果檢查點(diǎn)的頻率高，那么恢復(fù)時(shí)需要應(yīng)用的重做日志就相對(duì)得少，檢查時(shí)間就可以縮短。然而，需要注意的是，數(shù)據(jù)庫(kù)內(nèi)部操作的相對(duì)性極強(qiáng)，國(guó)語(yǔ)平凡的檢查點(diǎn)同樣會(huì)帶來(lái)性能問(wèn)題，尤其是更新頻繁的數(shù)據(jù)庫(kù)。所以數(shù)據(jù)庫(kù)的優(yōu)化是一個(gè)系統(tǒng)工程，不能草率。 更進(jìn)一步可以知道，如果Oracle可以在性能允許的情況下，使得檢查點(diǎn)的SCN主鍵逼近Redo的最新更新，那么最終可以獲得一個(gè)最佳平衡點(diǎn)，使得Oracle可以最大化地減少恢復(fù)時(shí)間。 為了實(shí)現(xiàn)這個(gè)目標(biāo)，Oracle在不同版本中一直在改進(jìn)檢查點(diǎn)的算法。
2.常規(guī)檢查點(diǎn)與增量檢查點(diǎn) 為了區(qū)分，在Oracle8之前，Oracle實(shí)時(shí)的檢查點(diǎn)通常被稱為常規(guī)檢查點(diǎn)（Conventional Checkpoint）,這類檢查點(diǎn)按一定的條件出發(fā)（log_checkpoint_interval、log_checkpoint_timeout參數(shù)設(shè)置及l(fā)og switch等條件出發(fā)）。 從Oracle 8開(kāi)始，Oracle引入了增量檢查點(diǎn)（Inctrmental Checkpoint）的概念。 和以前的版本相比，在新版本中，Oracle主要引入了檢查點(diǎn)隊(duì)列（Checkpoinnt Queue）機(jī)制，在數(shù)據(jù)庫(kù)內(nèi)部，每一個(gè)臟數(shù)據(jù)塊都會(huì)被移動(dòng)到檢查點(diǎn)隊(duì)列，按照Low RBA的順序（第一次對(duì)比數(shù)據(jù)塊修改對(duì)應(yīng)的Redo Byte Address）來(lái)排列，如果一個(gè)數(shù)據(jù)塊進(jìn)行過(guò)多次修改，該數(shù)據(jù)庫(kù)在檢查點(diǎn)隊(duì)列上的順序并不會(huì)發(fā)生變化。 當(dāng)執(zhí)行檢查點(diǎn)時(shí)，DBWR從檢查點(diǎn)隊(duì)列按照Low RBA的順序?qū)懗觯瑢?shí)例檢查點(diǎn)因此可以不斷增進(jìn)、階段性的，CKPT進(jìn)程使用非常輕量級(jí)的控制文件更新協(xié)議，將當(dāng)前的最低RBA寫(xiě)入控制文件。 因?yàn)樵隽繖z查點(diǎn)可以連續(xù)地進(jìn)行，因此檢查點(diǎn)RBA可以比常規(guī)檢查點(diǎn)更接近數(shù)據(jù)庫(kù)的最后狀態(tài)，從而在數(shù)據(jù)庫(kù)的實(shí)例恢復(fù)中可以極大地減少恢復(fù)時(shí)間。 而且，通過(guò)增量檢查點(diǎn)，DBWR可以持續(xù)進(jìn)行寫(xiě)出，從而避免了常規(guī)檢查點(diǎn)出發(fā)的峰值寫(xiě)入對(duì)于I/O的國(guó)度征用，通過(guò)下圖可以清楚地看到這一改進(jìn)的意義。
在數(shù)據(jù)庫(kù)中，增量檢查點(diǎn)是通過(guò)Fast-Start Checkpointing特性來(lái)實(shí)現(xiàn)的，從Oracle 8i開(kāi)始，這一特性包含了Oracle企業(yè)版的Fast-Start Fault Recovery組件之中，通過(guò)查詢v$option視圖，了解這一特性：
SQL> select * from v$version where rownum2; 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個(gè)主要特性，可以加快系統(tǒng)在故障后的恢復(fù)，提高系統(tǒng)的可用性。
Fast-Start Checkpointing; Fast-Start On-Demand Rollback; Fast-Start Parallel Rollback;
Fast-Start Checkpointing 特性在Oracle 8i中主要通過(guò)參數(shù)FAST_START_IO_TARGET來(lái)實(shí)現(xiàn)，在Oracle 9i中，F(xiàn)ast-Start Checkpointing主要通過(guò)參數(shù)FAST_START_MTTR_TARGET來(lái)實(shí)現(xiàn)。
3.FAST_START_MTTR_TARGET FAST_START_MTTR_TARGET參數(shù)從Oracle 9i開(kāi)始被引入，該參數(shù)定義數(shù)據(jù)庫(kù)進(jìn)行Crash恢復(fù)的時(shí)間，單位是秒，取值范圍是在0~3600秒之間。 在Oracle 9i中，Oracle推薦設(shè)置這個(gè)參數(shù)代替FAST_START_IO_TARGE、LOG_CHECKPOINT_TIMEROUT及LOG_CHECKPOINT_INSTERVAL參數(shù)。 缺省情況下，在Oracle 9i中，F(xiàn)AST_START_IO_TARGET和LOG_CHECKPOINT_INTERVAL參數(shù)已經(jīng)被設(shè)置為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開(kāi)始，Oracle引入了一個(gè)新的視圖提供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 ------------------------ ------------- ----------- ----------------- ----------------------- ----------------- ----------------------- -------------- --------------------
該視圖評(píng)估在不同F(xiàn)AST_START_MATTR_TARGET設(shè)置下，系統(tǒng)需要執(zhí)行的I/O次數(shù)等操作。用戶可以根據(jù)數(shù)據(jù)庫(kù)的建議，對(duì)FAST_START_MTTR_TARGET進(jìn)行相應(yīng)調(diào)整。 這個(gè)建議信息的手機(jī)收到Oracle 9i新引入的初始化參數(shù)statistics_level的控制，當(dāng)該參數(shù)設(shè)置為Typical或ALL時(shí)，MTTR建議信息被手機(jī)：
SQL> show parameter statistics_level NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ statistics_level string TYPICAL
也可以通過(guò)v$statistics_level視圖來(lái)查詢MTTR_Advice的當(dāng)前設(shè)置：
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
數(shù)據(jù)庫(kù)當(dāng)前的實(shí)例恢復(fù)狀態(tài)可以通過(guò)視圖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視圖，可以看到當(dāng)前數(shù)據(jù)庫(kù)估計(jì)的平均恢復(fù)時(shí)間（MTTR）參數(shù)：ESTIMATED_MTTR。 ESTIMATED_MTTR的估算值是基于Dirty Buffer 的數(shù)據(jù)量和日志塊數(shù)量得出的，這個(gè)參數(shù)值告訴我們，如果此時(shí)數(shù)據(jù)庫(kù)本虧，那么進(jìn)行實(shí)例恢復(fù)將會(huì)需要的時(shí)間。 在V$instance_revovery視圖中，TARGET_MTTR代表的是期望的恢復(fù)時(shí)間，通常改參數(shù)應(yīng)該等于FAST_START_MTTR_TARGET參數(shù)設(shè)置值（但是如果FAST_START_MTTR_TARGET參數(shù)定義的值極大或極小，TARGET_MEER可能不等于FAST_START_MTTR_TARGET的設(shè)置）。 當(dāng)ESTIMATED_MTTR接近或超過(guò)FAST_START_MTTR_TARGET參數(shù)設(shè)置（v$instance_recovery TARGET_MTTR）時(shí)，系統(tǒng)就會(huì)促發(fā)檢查點(diǎn)，執(zhí)行寫(xiě)出之后，系統(tǒng)恢復(fù)信息將會(huì)重新計(jì)算：
View Code 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
在繁忙的系統(tǒng)中，可能會(huì)觀察到ESTIMATED_MTTR>TARGET_MTTR，這可能是因?yàn)镈BWR正忙于寫(xiě)出，甚或出現(xiàn)Checkpoint不能及時(shí)完成的情況。
4. Oracle 10g自動(dòng)檢查點(diǎn)調(diào)整 從Oracle 10g開(kāi)始，數(shù)據(jù)庫(kù)可以實(shí)現(xiàn)自動(dòng)調(diào)整的檢查點(diǎn)，使用自動(dòng)調(diào)整的檢查點(diǎn)，Oracle數(shù)據(jù)庫(kù)可以利用系統(tǒng)的低I/O負(fù)載時(shí)段寫(xiě)出內(nèi)存中的臟數(shù)據(jù)，從而提高數(shù)據(jù)庫(kù)的效率。因此，及時(shí)數(shù)據(jù)庫(kù)管理員設(shè)置了不合理的檢查點(diǎn)相關(guān)參數(shù)，Oracle仍然能夠通過(guò)自動(dòng)調(diào)整將數(shù)據(jù)庫(kù)的Crash Recovery時(shí)間控制在合理的范圍之內(nèi)。 當(dāng)FAST_START_MTTR_TARGET參數(shù)未設(shè)置，自動(dòng)檢查點(diǎn)調(diào)整生效。 通常，如果必須嚴(yán)格控制實(shí)例或節(jié)點(diǎn)恢復(fù)時(shí)間，那么可以設(shè)置FAST_START_MTTR_TARGET為期望時(shí)間值；如果恢復(fù)時(shí)間不嚴(yán)格控制，那么可以不設(shè)置FAST_START_MTTR_TARGET參數(shù)，從而啟用Oracle 10g的自動(dòng)調(diào)整特性。 當(dāng)取消FAST_START_MTTR_TARGET參數(shù)設(shè)置之后：
View Code SQL> show parameter fast_start_mttr NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ fast_start_mttr_target integer 0 在啟動(dòng)數(shù)據(jù)庫(kù)的時(shí)候，可以從alter文件中看到如下信息： View Code Thu Nov 17 20:27:23 2011 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set 檢查v$instance_recovery視圖，可以發(fā)現(xiàn)Oracle 10g的改變： View Code 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字段數(shù)據(jù)就是指由于自動(dòng)調(diào)整檢查點(diǎn)執(zhí)行的寫(xiě)出次數(shù)，而CK_BLOCK_WRITES指的則是由于檢查點(diǎn)寫(xiě)出的Block的數(shù)量。 關(guān)于檢查點(diǎn)的機(jī)制問(wèn)題，我們側(cè)重介紹了原理，至于具體的算法實(shí)現(xiàn)，不需要去追究過(guò)多，只要明白了這個(gè)原理性的規(guī)則，理解Oracle就會(huì)變成輕松的事情。 Oracle的算法改進(jìn)是一種優(yōu)化，對(duì)于數(shù)據(jù)庫(kù)的調(diào)整優(yōu)化也不外如此，借鑒Oracle的優(yōu)化對(duì)于理解和優(yōu)化Oracle數(shù)據(jù)庫(kù)都具有極大的好處。 5.從控制文件獲取檢查點(diǎn)信息 在控制文件的轉(zhuǎn)儲(chǔ)中，可以看到關(guān)于檢查點(diǎn)進(jìn)程進(jìn)度的記錄：
View Code *************************************************************************** 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地址，在實(shí)例恢復(fù)或者崩潰恢復(fù)中，需要從這里開(kāi)始恢復(fù)。 On disk dba是磁盤上的最高的重做值，在進(jìn)行恢復(fù)時(shí)應(yīng)用重做至少要達(dá)到這個(gè)值。 除了檢查點(diǎn)隊(duì)列（CKPTQ）之外，數(shù)據(jù)庫(kù)中還存在另外一個(gè)隊(duì)列和檢查點(diǎn)有關(guān)，這就是文件檢查點(diǎn)隊(duì)列（FILE QUEUE），通常稱為FILEQ，文件檢查點(diǎn)的引入提供了表空間相關(guān)的檢查點(diǎn)的性能。每個(gè)Dirty Buffer同時(shí)鏈接到這兩個(gè)隊(duì)列，CKPTQ包含實(shí)例所有需要執(zhí)行檢查點(diǎn)的Buffer，F(xiàn)ILEQ包含屬于特定文件需要執(zhí)行的檢查點(diǎn)Buffer，每個(gè)文件都包含一個(gè)文件隊(duì)列，在執(zhí)行表空間檢查點(diǎn)請(qǐng)求時(shí)需要使用FILEQ，通常當(dāng)對(duì)表空間執(zhí)行Offline等操作時(shí)會(huì)觸發(fā)表空間檢查點(diǎn)。CKPTQ和FILEQ都是雙向鏈表，每個(gè)隊(duì)列中都記錄了兩個(gè)地址信息，分別是前一塊和下一塊Buffer的地址信息。注意只有Dirty Buffer才會(huì)包含CKPTQ信息，否則為NULL，信息類似'ckptq:[NULL]fileq:[NULL]'。 檢查點(diǎn)（checkpoint）的工作機(jī)制檢查點(diǎn)是一個(gè)數(shù)據(jù)庫(kù)事件，它把修改數(shù)據(jù)從高速緩存寫(xiě)入磁盤，并更新控制文件和數(shù)據(jù)文件，總結(jié)起來(lái)如下： 檢查點(diǎn)分為三類： 1）局部檢查點(diǎn)：?jiǎn)蝹€(gè)實(shí)例執(zhí)行數(shù)據(jù)庫(kù)所有數(shù)據(jù)文件的一個(gè)檢查點(diǎn)操作，屬于此實(shí)例的全部臟緩存區(qū)寫(xiě)入數(shù)據(jù)文件。 觸發(fā)命令： svmrgrl>alter system checkpoint local; 這條命令顯示的觸發(fā)一個(gè)局部檢查點(diǎn)。 2）全局檢查點(diǎn)：所有實(shí)例（對(duì)應(yīng)并行數(shù)據(jù)服務(wù)器）執(zhí)行數(shù)據(jù)庫(kù)所有所有數(shù)據(jù)文件的一個(gè)檢查點(diǎn)操作，屬于此實(shí)例的全部臟緩存區(qū)寫(xiě)入數(shù)據(jù)文件。 觸發(fā)命令 svrmgrl>alter system checkpoint global; 這條命令顯示的觸發(fā)一個(gè)全局檢查點(diǎn)。 3）文件檢查點(diǎn)：所有實(shí)例需要執(zhí)行數(shù)據(jù)文件集的一個(gè)檢查點(diǎn)操作，如使用熱備份命令alter tablespace USERS begin backup，或表空間脫機(jī)命令alter tablespace USERS offline，將執(zhí)行屬于USERS表空間的所有數(shù)據(jù)文件的一個(gè)檢查點(diǎn)操作。 檢查點(diǎn)處理步驟： 1）獲取實(shí)例狀態(tài)隊(duì)列：實(shí)例狀態(tài)隊(duì)列是在實(shí)例狀態(tài)轉(zhuǎn)變時(shí)獲得，ORACLE獲得此隊(duì)列以保證檢查點(diǎn)執(zhí)行期間，數(shù)據(jù)庫(kù)處于打開(kāi)狀態(tài)； 2）獲取當(dāng)前檢查點(diǎn)信息：獲取檢查點(diǎn)記錄信息的結(jié)構(gòu)，此結(jié)構(gòu)包括當(dāng)前檢查點(diǎn)時(shí)間、活動(dòng)線程、進(jìn)行檢查點(diǎn)處理的當(dāng)前線程、日志文件中恢復(fù)截止點(diǎn)的地址信息； 3）緩存區(qū)標(biāo)識(shí)：當(dāng)數(shù)據(jù)在buffer cache中做了修改之后會(huì)自動(dòng)被為臟緩沖區(qū)，加入到Checkpoint Queue的臟緩沖區(qū)隊(duì)列。 4）臟緩存區(qū)刷新：當(dāng)檢查點(diǎn)發(fā)生時(shí)，會(huì)到CKPTQ中的臟緩沖區(qū)隊(duì)列找到到目前為止最大的LRBA，并通知DBWR進(jìn)程將所有臟緩存區(qū)寫(xiě)入磁盤，完成之后設(shè)置一標(biāo)志，標(biāo)識(shí)已完成臟緩存區(qū)至磁盤的寫(xiě)入操作，以便刷新臟緩沖隊(duì)列（此時(shí)DML可以繼續(xù)進(jìn)行）。系統(tǒng)進(jìn)程LGWR與CKPT進(jìn)程將繼續(xù)進(jìn)行檢查，直至DBWR進(jìn)程結(jié)束為止； 5）更新控制文件與數(shù)據(jù)文件。 注：控制文件與數(shù)據(jù)文件頭包含檢查點(diǎn)結(jié)構(gòu)信息。 在兩種情況下，文件頭中的檢查點(diǎn)信息（獲取當(dāng)前檢查點(diǎn)信息時(shí)）將不做更新： 1）數(shù)據(jù)文件不處于熱備份方式，此時(shí)ORACLE將不知道操作系統(tǒng)將何時(shí)讀文件頭，而備份拷貝在拷貝開(kāi)始時(shí)必須具有檢查點(diǎn)SCN； ORACLE在數(shù)據(jù)文件頭中保留一個(gè)檢查點(diǎn)的記數(shù)器，在正常操作中保證使用數(shù)據(jù)文件的當(dāng)前版本，在恢復(fù)時(shí)防止恢復(fù)數(shù)據(jù)文件的錯(cuò)誤版本；即使在熱備份方式下，計(jì)數(shù)器依然是遞增的；每個(gè)數(shù)據(jù)文件的檢查點(diǎn)計(jì)數(shù)器，也保留在控制文件相對(duì)應(yīng)數(shù)據(jù)文件項(xiàng)中。 2）檢查SCN小于文件頭中的檢查點(diǎn)SCN的時(shí)候，這表明由檢查點(diǎn)產(chǎn)生的改動(dòng)已經(jīng)寫(xiě)到磁盤上，在執(zhí)行全局檢查點(diǎn)的處理過(guò)程中，如果一個(gè)熱備份快速檢查點(diǎn)在更新文件頭時(shí)，則可能發(fā)生此種情況。應(yīng)該注意的是，ORACLE是在實(shí)際進(jìn)行檢查點(diǎn)處理的大量工作之前捕獲檢查SCN的，并且很有可能被一條象熱備份命令 alter tablespace USERS begin backup進(jìn)行快速檢查點(diǎn)處理時(shí)的命令打斷。 ORACLE在進(jìn)行數(shù)據(jù)文件更新之前，將驗(yàn)證其數(shù)據(jù)一致性，當(dāng)驗(yàn)證完成，即更新數(shù)據(jù)文件頭以反映當(dāng)前檢查點(diǎn)的情況；未經(jīng)驗(yàn)證的數(shù)據(jù)文件與寫(xiě)入時(shí)出現(xiàn)錯(cuò)誤的數(shù)據(jù)文件都被忽略；如果日志文件被覆蓋，則這個(gè)文件可能需要進(jìn)行介質(zhì)恢復(fù)，在這種情況下，ORACLE系統(tǒng)進(jìn)程DBWR將此數(shù)據(jù)文件脫機(jī)。 檢查點(diǎn)算法描述： 臟緩存區(qū)用一個(gè)新隊(duì)列鏈接，稱為檢查點(diǎn)隊(duì)列。對(duì)緩存區(qū)的每一個(gè)改動(dòng)，都有一個(gè)與其相關(guān)的重做值。檢查點(diǎn)隊(duì)列包含臟的日志緩存區(qū)，這些緩存區(qū)按照它們?cè)谌罩疚募械奈恢门判?，即在檢查點(diǎn)隊(duì)列中，緩存區(qū)按照它們的LRBA進(jìn)行排序。需要注算法特點(diǎn)： 3）根據(jù)檢查點(diǎn)重做值可以區(qū)別多個(gè)檢查點(diǎn)請(qǐng)求，然后按照它們的順序完成處理。 1）DBWR能確切的知道為滿足檢查點(diǎn)請(qǐng)求需要寫(xiě)那些緩存區(qū)； 2）在每次進(jìn)行檢查點(diǎn)寫(xiě)時(shí)保證指向完成最早的（具有最低重做值的）檢查點(diǎn)；意的是，由于緩存區(qū)是依照第一次變臟的次序鏈接到隊(duì)列中的，所以，如果在緩存區(qū)寫(xiě)出之前對(duì)它有另外的改動(dòng)，鏈接不能進(jìn)行相應(yīng)變更，緩存區(qū)一旦被鏈接到檢查點(diǎn)隊(duì)列，它就停留在此位置，直到將它被寫(xiě)出為止。 ORACLE系統(tǒng)進(jìn)程DBWR在響應(yīng)檢查點(diǎn)請(qǐng)求時(shí)，按照這個(gè)隊(duì)列的LRBA的升序?qū)懗鼍彺鎱^(qū)。每個(gè)檢查點(diǎn)請(qǐng)求指定一個(gè)重做值，一旦DBWR寫(xiě)出的緩存區(qū)重做值等于或大雨檢查點(diǎn)的重做值，檢查點(diǎn)處理即完成，并將記錄到控制文件與數(shù)據(jù)文件。 由于檢查點(diǎn)隊(duì)列上的緩存區(qū)按照低重做值進(jìn)行排序，而DBWR也按照低重做值順序?qū)懗鰴z查點(diǎn)緩存區(qū)，故可能有多個(gè)檢查點(diǎn)請(qǐng)求處于活動(dòng)狀態(tài)，當(dāng)DBWR寫(xiě)出緩存區(qū)時(shí)，檢查位于檢查點(diǎn)隊(duì)列前端的緩存區(qū)重做值與檢查點(diǎn)重做值的一致性，如果重做值小于檢查點(diǎn)隊(duì)列前緩存區(qū)的低重做值的所有檢查點(diǎn)請(qǐng)求，即可表示處理完成。當(dāng)存在未完成的活動(dòng)檢查點(diǎn)請(qǐng)求時(shí)，DBWR繼續(xù)寫(xiě)出檢查點(diǎn)緩存區(qū)。
|
|
|
來(lái)自： 昵稱25533110 > 《待分類1》
