| 檢 查 點 概述 | ■l當(dāng)修改數(shù)據(jù)時，需要首先將數(shù)據(jù)讀入內(nèi)存中（Buffer Cache），修改數(shù)據(jù)的同時，Oracle會記錄重做信息（Redo）用于恢復(fù)。因? ? ?為有了重做信息的存在，Oracle不需要在提交時立即將變化的數(shù)據(jù)寫回磁盤（立即寫的效率會很低），重做（Redo）的存在也? ? ? ?正是為了在數(shù)據(jù)庫崩潰之 后，數(shù)據(jù)就可以恢復(fù)。 ■l最常見的情況，數(shù)據(jù)庫可以因為斷電而Crash，那么內(nèi)存中修改過的、尚未寫入文件的數(shù)據(jù)將會丟失。在下一次數(shù)據(jù)庫啟動之? ? ? ? ?后，Oracle可以通過重做日志（Redo）進(jìn)行事務(wù)重演，也就是進(jìn)行前滾，將數(shù)據(jù)庫恢復(fù)到崩潰之前的狀態(tài)，然后數(shù)據(jù)庫可以打? ? ? ?開提供使用，之后Oracle可以將 ?未提交的數(shù)據(jù)進(jìn)行回滾。 ■在這個過程中，通常大家最關(guān)心的是數(shù)據(jù)庫要經(jīng)歷多久才能打開。也就是需要讀取多少重做日志才能完成前滾。當(dāng)然用戶希望這? ? ?個時間越短越好，Oracle也正是通過各種手段在不斷優(yōu)化這個過程，縮短恢復(fù)時間。 檢查點的存在就是為了縮短這個恢復(fù)時間。 checkpoint是數(shù)據(jù)庫的一個內(nèi)部事件，它存在的根本意義在于減少崩潰恢復(fù)（Crash Recovery）時間。 |
| 發(fā)展 | ■在Oracle8之前，Oracle的檢查點通常被稱為常規(guī)檢查點（Conventional Checkpoint）,這類檢查點按一定的條件觸發(fā)（log_checkpoint_interval、log_checkpoint_timeout參數(shù)設(shè)置及l(fā)og switch等條件出發(fā)）。 ■從Oracle 8開始，Oracle引入了增量檢查點（Inctrmental Checkpoint）的概念。 ? ?和以前的版本相比，在新版本中，Oracle主要引入了檢查點隊列（Checkpoinnt Queue）機制，增量檢查點的主要宗旨就是定期? ? ?的刷新一部分臟塊。將臟塊一次刷新完是不合理的，因為臟塊不斷產(chǎn)生，沒有窮盡。像完全檢查點那樣停止用戶所有的修改操? ? ? ? ?作，將臟塊刷新完再繼續(xù)，這絕對會極大的影響性能。 ■所有增量檢查點的一次刷新部分塊是臟塊問題的最好解決辦法。 ■增量檢查點就是根據(jù)塊變臟的順序，每次刷新那些最早臟的塊，這種方式最為合理。 |
| 原理 | 當(dāng)檢查點發(fā)生時（此時的SCN被稱為CheckPoint SCN），Oracle會通知DBWR進(jìn)程，將數(shù)據(jù)緩沖區(qū)里的臟數(shù)據(jù)塊，也就是Checkpoint SCN之前的臟數(shù)據(jù)（Dirty Data）從Buffer Cache寫入磁盤，當(dāng)寫入完成之后，CKPT進(jìn)程更新控制文件和數(shù)據(jù)文件頭，記錄檢查點信息，標(biāo)識變更。 |
| 作用 | | 保證數(shù)據(jù)庫的一致性 | 這是指將臟數(shù)據(jù)寫出到硬盤，保證內(nèi)存和硬盤上的數(shù)據(jù)是一樣的 | | 縮短實例恢復(fù)的時間 | ■實例恢復(fù)要把實例異常關(guān)閉前沒有寫到硬盤的臟數(shù)據(jù)通過日志進(jìn)行恢復(fù)。 ■如果臟塊過多，實例恢復(fù)的時間也會過長，檢查點的發(fā)生可以減少臟塊的數(shù)量，從而減少實例 恢復(fù)的時間。 ■通過LRBA（LOW REDO BUFFER ADRESS），HRBA（HIGH REDO BUFFER ADRESS）， HRBA是沒有任何意義的，但是LRBA非常有意義了，CKPT會將最早臟塊在redo記錄里面位置 即LRBA寫到控制文件里面去，下次實例恢復(fù)讀取控制文件就知道從redo記錄的哪個位置開始恢復(fù)數(shù)據(jù)塊 |
|
| 檢查點 相關(guān) | | rba | ■rba就是重做塊地址,比如說,用戶發(fā)出了一條update命令,更新了塊A,塊A現(xiàn)在變成了臟塊,oracle會為他
生成一條重做記錄.這條重做記錄在重做日志文件中的位置就是rba(redo block address).過了一會兒,假
如:塊A依然還是臟塊,此時.用戶又發(fā)出一條更新塊A的命令,這又會生成一條重做記錄.第一條更新命令對
應(yīng)的重做記錄的rba被稱為塊A的lrba(low rba),第二條更新命令對應(yīng)的rba,被稱為hrba(high rba). | | 檢查點隊列 | ? ? ■被修改過的塊，在oracle中都被統(tǒng)稱為臟塊.所有的臟塊被一個鏈表串起來,稱做檢查點隊列.在buffercache中,每一個塊都有一個buffer header 簡稱BH,在BH中有一個ckptq項。 ? ? ■buffer header記錄對應(yīng)塊在Buffer cache中的地址，臟塊對應(yīng) ? 的重做記錄在日志文件中的位置，另外還有前一個節(jié)點、后一個節(jié)點的地址。 ? ? ■ckptq項此項目中記錄了指向檢查點隊列上一個塊和下一個塊的指針.如果某一個塊不在檢查點隊列中,他的ckptq項為空.通過ckptq項oracle將所有的臟塊串成了一個雙向鏈表.這個雙向鏈表就是檢查點隊列。 ? ? ■只有臟塊才會在檢查點隊列中,非臟塊的ckptq為空。 ? ? ■?每個塊在它變臟時，會被鏈接到檢查點隊列的末尾。就好像排隊一樣，9:00來的人站在第一位，9:05來的人排第二位，以后每來一個人都站在 ? 隊伍的末尾，這個隊伍就是按來到的時間順序排列的一個隊列。檢查點隊列就是這樣，塊在變臟時會被按照Low RBA的順序（第一次對比數(shù)據(jù) ? 塊修改對應(yīng)的Redo Byte Address）鏈到末尾。 ? ? ■?當(dāng)塊首次被更改時,塊會立即被加進(jìn)檢查點隊列.如果檢查點隊列中的臟塊再次被修改,并不會改變其在
檢查點隊列中的位置。因此檢查點隊列是按塊變臟的時間順序，將塊排成了一個隊列。 ? ? ■檢查點隊列就是這樣，塊在變臟時會被按照Low RBA的順序（第一次對比數(shù)據(jù) ? 塊修改對應(yīng)的Redo Byte Address）鏈到末尾。其實,按照lrba來排列,就是按照塊首次被修改的順序來排列. | | 檢查點位置 | ■檢查點隊列的頭，又被稱為檢查點位置，Checkpoint postion。總之，檢查點位置就是檢查點隊列頭。檢查點隊列頭節(jié)點（也就是檢查點位置）的信息，Oracle會頻繁的將它記錄到控制文件中，而且會很頻繁的記錄。一般是每隔三秒，有一個專門的進(jìn)程CKPT，會將檢查點位置記錄進(jìn)控制文件。 ■檢查點位置對應(yīng)的日志地址（RBA）又總是被記錄在控制文件中。如果發(fā)生系統(tǒng)崩潰，這個最后的檢查點位置就是實例恢復(fù)運用日志的起點 | | DBWR寫臟塊 | Oracle會定期喚醒DBWn從檢查點隊列頭開始，沿著檢查點隊列的順序，刷新臟塊（數(shù)據(jù)緩沖區(qū)里的臟數(shù)據(jù)塊），CKPT進(jìn)程使用非常輕量級的控制文件更新協(xié)議，將當(dāng)前的最低RBA寫入控制文件。在刷新臟塊的同時，仍可以不斷的有新的臟塊被鏈接到檢查點隊列的尾部。 定期喚醒DBWn刷新臟塊的操作，Oracle就稱為增量檢查點。因為增量檢查點可以連續(xù)地進(jìn)行，因此檢查點RBA可以比常規(guī)檢查點更接近數(shù)據(jù)庫的最后狀態(tài)，從而在數(shù)據(jù)庫的實例恢復(fù)中可以極大地減少恢復(fù)時間。 |
|
| 分類 | | 完全 檢查 點 | 完全檢查點發(fā)生時,將不能有新的臟塊產(chǎn)生,直到完全檢查點完成 1.記下當(dāng)前的scn, 將此scn之前所有的臟塊一次性寫完 2.將該scn號同步更新控制文件和數(shù)據(jù)文件頭。 3.把新的連機重做日志的第一重做記錄的RBA寫進(jìn)數(shù)據(jù)文件頭 可以引起完全檢查點的四個動作 ?
a)正常關(guān)閉數(shù)據(jù)庫:shutdown immediate
b)手動檢查點切換:alter system checkpoint;?
c)日志切換：alter system switch logfile;
d)數(shù)據(jù)庫熱備模式：alter database begin backup;? | ■當(dāng)發(fā)生日志切換時,也會觸發(fā)檢查點.在數(shù)據(jù)庫并不繁忙的情況下，日志切換的檢查點并不急于完成.之所以在日志切換的時候觸發(fā)一次檢查點,是為了保證重做日志文件所對應(yīng)的臟塊都被寫進(jìn)磁盤文件。 ■如果寫臟塊的速度比較慢,日志文件循環(huán)一圈后,又該覆蓋此日志文件時,而此日志文件的檢查點還沒有完成,那么覆蓋操作將等待.等待事件名:log file switch(checkpoint incomplete).如果出現(xiàn)該等待事件,解決方法: ? ? 1,可以增加日志文件組的數(shù)量。 ? ? 2,觀察下增量檢查點的間隔時間.如果是因為增量檢查點間隔時間太長,導(dǎo)致積攢的臟塊過多。 ? ? ? ?可以把增量檢查點參數(shù)設(shè)置的頻繁點.
日志切換檢查點除了會觸發(fā)DBWR寫臟塊外，CKPT進(jìn)程還要將切換時的SCN寫進(jìn)數(shù)據(jù)文件頭和控制文件中的數(shù)據(jù)庫信息節(jié),還有數(shù)據(jù)文件節(jié).另外還要將新的連機重做日志文件中第一條重做記錄的RBA寫進(jìn)數(shù)據(jù)文件頭. |
| | 增量 檢查點 | 1）增量檢查點使檢查點位置前移。進(jìn)而縮短實例恢復(fù)需要的日志起點和終點之間的距離，觸發(fā)增量檢查點越頻繁，實例恢復(fù)的時間越短，但數(shù)據(jù)庫性能受到頻繁IO影響會降低。? 2）增量檢查點并不會去更新數(shù)據(jù)文件頭，以及控制文件中數(shù)據(jù)庫SCN以及數(shù)據(jù)文件條目的SCN信息，而只是每3秒由CKPT進(jìn)程去更新控制文件中的lowcache?rba信息，?也就是檢查點的位置。 3）如果發(fā)生了實例崩潰，只需要在日志文件中找到檢查點位置(low?cache?rba),從此處開始應(yīng)用所有的重做日志文件，就完成了前滾操作。實例崩潰后，再次啟動數(shù)據(jù)庫，oracle會到控制文件中讀取low?cache?rba，?這就是檢查點位置。從此處開始應(yīng)用重做日志，應(yīng)用到on?disk?rba的位置。on?diskrba是磁盤中重做日志文件的最后一條重做記錄的rba. | 查 看 | select CPDRT,CPLRBA_SEQ||'.'||CPLRBA_BNO||'.'||CPLRBA_BOF "LowRBA",CPODR_SEQ||'.'||CPODR_BNO||'.'||
CPODR_BOF "0n?disk?RBA",CPODS,CPODT,CPHBT from x$kcccp;CPDRT Low RBA? ?? ?? ?On disk RBA? ???CPODS? ?? ?? ?? ?CPODT? ?? ?? ?? ?? ?? ?? ?CPHBT
---------- --------------- --------------- ---------------- -------------------- ----------35 686.124.0? ?? ? 686.220.0? ?? ? 2325376? ?? ?? ? 03/02/2008 15:18:54? ?648319278CPDRT列是檢查點隊列中的臟塊數(shù)目.
CPODS列是on disk rba的scn??
on disk rba是磁盤中重做日志文件的最后一條重做記錄的rba.??如果某條命令的重做記錄的rba高于on disk rba，那說明此重做記錄還沒有被寫進(jìn)日志文件中，崩潰發(fā)生時，他是不可能被恢復(fù)的.
on disk rba是oracle前滾操作的終點.
on disk 顧名思義 就是'在磁盤上'的意思.比這個更高的rba,都在log buffer中,還沒有來的急被寫進(jìn)磁盤中的日志文件.所以是不能被用于恢復(fù)的.
CPODT列是on disk rba的時間戳
CPHBT列是心跳 ? | | 參 數(shù) | 在10g中把 log_checkpoint_to_alert設(shè)置為真,可以在告警日志中觀察到增量檢查點的觸發(fā).在9I中看不到增量檢查點,可以看到其他檢查點的觸發(fā)信息。 SQL> alter system set log_checkpoints_to_alert=true;
系統(tǒng)已更改。
步驟2:將增量檢查點的切換頻率定為300秒.log_checkpoint_timeout
該參數(shù)用于表示檢查點位置和重做日志尾之間的時間間隔,以秒為單位,
默認(rèn)情況下是1800秒,
這個參數(shù)實際上表示了臟塊保持臟狀態(tài)的最長時間。
如果它被定為1800秒,沒有臟塊保持1800秒后,還是為臟
LOG_CHECKPOINT_INSTERVAL
該參數(shù)是表示檢查點位置和重做日志末尾的塊的數(shù)量.以O(shè)S表示.LOG_CHECKPOINT_TIMEROUT及LOG_CHECKPOINT_INSTERVAL參數(shù)，
根據(jù)這個參數(shù)，Oracle計算出在內(nèi)存中累積的dirty buffer所需
的日志恢復(fù)時間，如果到達(dá)該參數(shù)指定的時間，則增量檢查點進(jìn)程
被觸發(fā)。該參數(shù)如果為0，ORACLE則會根據(jù)，Oracle將根據(jù)產(chǎn)生臟
塊的速度、存貯硬件的性能自動調(diào)節(jié)檢查點的頻率，讓DBWN進(jìn)程自
身盡量減少寫入量，這樣雖然實現(xiàn)了性能最大化，但實例恢復(fù)時間
可能會比較長
SQL> alter system set log_checkpoint_timeout=300;[單位是秒]
系統(tǒng)已更改。
? |
| | 局部檢查點 | 觸發(fā)命令： SQL>alter system checkpoint local;?這條命令顯示的觸發(fā)一個局部檢查點。 對于某些操作，局部檢查點是必須的，并會自動執(zhí)行。 比如：表空間offline,數(shù)據(jù)文件offline,刪除extent,表truncate,begin backup(將表空間置于備份模式）等。Oracle會根據(jù)需要自動執(zhí)行 |
|
| 處理步驟 | | 獲取實例狀態(tài)隊列 | 實例狀態(tài)隊列是在實例狀態(tài)轉(zhuǎn)變時獲得，ORACLE獲得此隊列以保證CHECKPIONT執(zhí)行期間，數(shù)據(jù)庫處于打開狀態(tài)； | | 獲取當(dāng)前CHECKPIONT信息 | 獲取CHECKPIONT記錄信息的結(jié)構(gòu)，此結(jié)構(gòu)包括當(dāng)前CHECKPIONT時間、活動線程、進(jìn)行CHECKPIONT處理的當(dāng)前線程、日志文件中恢復(fù)截止點的地址信息 | | 緩存區(qū)標(biāo)識 | 標(biāo)識所有臟緩存區(qū)，當(dāng)CHECKPIONT找到一個臟緩存區(qū)就將其標(biāo)識為需要進(jìn)行刷新，標(biāo)識的臟緩存區(qū)由系統(tǒng)進(jìn)程DBWR進(jìn)行寫操作，將臟緩存區(qū)的內(nèi)容寫入數(shù)據(jù)文件 | | 臟緩存區(qū)刷新 | DBWR進(jìn)程將所有臟緩存區(qū)寫入磁盤后，設(shè)置一標(biāo)志，標(biāo)識已完成臟緩存區(qū)至磁盤的寫入操作。系統(tǒng)進(jìn)程LGWR與CKPT進(jìn)程將繼續(xù)進(jìn)行檢查，直至DBWR進(jìn)程結(jié)束為止 | | 更新控制文件與數(shù)據(jù)文件 | 控制文件與數(shù)據(jù)文件頭包含CHECKPIONT結(jié)構(gòu)信息 |
|
| 用戶修改塊 | 1．如果塊不在Buffer cache，將塊讀入Buffer cache 2．先生成重做記錄，并記入日志緩存，在用戶提交時寫到日志文件中 3．在Buffer cache中修改塊 4．在Buffer cache中設(shè)置塊的臟標(biāo)志位，標(biāo)志塊變成臟塊，同時在檢查點隊列末尾增加一個新節(jié)點，記錄這個新臟塊的信息，信息包括：臟塊在Buffer cache中的位置，在步驟2時生成的與此臟塊對應(yīng)的重做記錄位置。 5．用戶提交后，將相應(yīng)的重做記錄從重做緩存寫入日志文件 |
| ? | ? |
| C K P T | 數(shù)據(jù)庫中有個CKPT進(jìn)程，這個是個可選進(jìn)程，但是真正執(zhí)行檢查點的任務(wù)并不是有ckpt來完成的，而是ckpt在更新控制文件和數(shù)據(jù)文件頭的有關(guān)信息后，通知DBWn進(jìn)程，產(chǎn)生一個檢查點，在產(chǎn)生檢查點的時候，DBWn進(jìn)程會將buffer cache中的臟數(shù)據(jù)(當(dāng)前online redo log對應(yīng)的臟數(shù)據(jù))，寫入我們的數(shù)據(jù)文件當(dāng)中。那么這個時候如果數(shù)據(jù)庫此時崩潰（比如我們做個shutdown abort），那么在進(jìn)行實例恢復(fù)的時候就可以不需要當(dāng)前online redo log的內(nèi)容了，會很快就做完。 | 任務(wù) | ■監(jiān)控著檢查點隊列的長度,當(dāng)檢查點隊列的長度達(dá)到一定限制時,CKPT會通知DBWR寫臟塊.CKPT會根據(jù)參數(shù)的設(shè)置和I/O的速度以及繁忙程度,計算出來一個Target rba(目標(biāo)rba),DBWR會沿著檢查點隊列,將所有Target rba之前的臟塊刷新到磁盤.當(dāng)CKPT通知完DBWR Target rba后,CKPT的任務(wù)就結(jié)束了 | | 每3秒,檢測一次DBWR的寫進(jìn)度.檢查點隊列最前面的塊被稱為檢查點位置.DBWR是沿著檢查點隊列寫臟塊的,CKPT每3秒鐘查看一下DBWR沿檢查點隊列寫到了哪里,并且將這個位置設(shè)置為檢查點位置.也就是說檢查點位置之前的塊,都是已被DBWR刷新到磁盤上的塊.這個3秒一次檢查DBWR進(jìn)度的工作,也是CKPT的一個重要的任務(wù) | | CKPT每3秒一次將檢查點位置記錄進(jìn)控制文件,當(dāng)然同時被記錄進(jìn)控制文件的還有'心跳'等其他信息. CKPT每3秒一次的工作和CKPT定期觸發(fā)DBWR，這兩項操作合一起被稱為--增量檢查點. |
? ?因此ckpt進(jìn)程只是個輔助進(jìn)程，他的任務(wù)更多的是用來在系統(tǒng)做checkpoint的時候更新控制文件和數(shù)據(jù)文件頭中的信息。其實在oracle 8i的時候呢，ckpt的任務(wù)一般都是由lgwr進(jìn)程來完成，到了8i以后，隨著CKPT進(jìn)程的引入，lgwr的工作負(fù)擔(dān)就減輕了很多(commit的速度加快了) |
| 檢查點 不做更新 | 在兩種情況下，文件頭中的檢查點信息（獲取當(dāng)前檢查點信息時）將不做更新： 1）數(shù)據(jù)文件不處于熱備份方式，此時ORACLE將不知道操作系統(tǒng)將何時讀文件頭，而備份拷貝在拷貝開始時必須具有檢查點SCN；ORACLE在數(shù)據(jù)文件頭中保留一個檢查點的記數(shù)器，在正常操作中保證使用數(shù)據(jù)文件的當(dāng)前版本，在恢復(fù)時防止恢復(fù)數(shù)據(jù)文件的錯誤版本；即使在熱備份方式下，計數(shù)器依然是遞增的；每個數(shù)據(jù)文件的檢查點計數(shù)器，也保留在控制文件相對應(yīng)數(shù)據(jù)文件項中。 2）檢查SCN小于文件頭中的檢查點SCN的時候，這表明由檢查點產(chǎn)生的改動已經(jīng)寫到磁盤上，在執(zhí)行全局檢查點的處理過程中，如果一個熱備份快速檢查點在更新文件頭時，則可能發(fā)生此種情況。應(yīng)該注意的是，ORACLE是在實際進(jìn)行檢查點處理的大量工作之前捕獲檢查SCN的，并且很有可能被一條象熱備份命令 alter tablespace USERS begin backup進(jìn)行快速檢查點處理時的命令打斷。 ? ORACLE在進(jìn)行數(shù)據(jù)文件更新之前，將驗證其數(shù)據(jù)一致性，當(dāng)驗證完成，即更新數(shù)據(jù)文件頭以反映當(dāng)前檢查點的情況；未經(jīng)驗證的數(shù)據(jù)文件與寫入時出現(xiàn)錯誤的數(shù)據(jù)文件都被忽略；如果日志文件被覆蓋，則這個文件可能需要進(jìn)行介質(zhì)恢復(fù)，在這種情況下，ORACLE系統(tǒng)進(jìn)程DBWR將此數(shù)據(jù)文件脫機 |
| ? | 如果FAST_START_MTTR_TARGET<>0，v$log視圖中的active狀態(tài)幾分鐘后會變成inactive狀態(tài)，然后更新了控制文件和日志文件頭部的SCN |
| 與提交區(qū)別 | 事務(wù)在沒有提交或者回滾之前對于其他的用戶會話是看不到的，即數(shù)據(jù)修改了但是對于其他人是不可見的，因為沒有提交。提交了的數(shù)據(jù)還是可能在內(nèi)存，未提交的數(shù)據(jù)也可能在磁盤。在未提交之前發(fā)出alter system checkpoint，那么所有修改了的數(shù)據(jù)塊都寫到磁盤上面了，雖然未提交，但是數(shù)據(jù)還是寫到磁盤上面了，因為未提交，其他會話依舊看不到數(shù)據(jù)修改的變化。 對于一個事務(wù)的提交與否和在磁盤，內(nèi)存沒有任何關(guān)系。對于commit來說是來保證數(shù)據(jù)的永久的改變，這些改變在磁盤還是在內(nèi)存改變都不重要，總之就是改變了。 ? Checkpoint就是將內(nèi)存凡是修改過的數(shù)據(jù)塊就寫到磁盤上面，修改的數(shù)據(jù)塊有兩種情況，一種是修改完提交，一種是修改完未提交。所以checkpoint只管將修改了的數(shù)據(jù)塊寫到磁盤上面。 ? 事務(wù)發(fā)出一個commit之后，這個時候Oracle就認(rèn)為將這個數(shù)據(jù)塊永久的改變了。commit表示事務(wù)的結(jié)束，事務(wù)的結(jié)束就意味著別人對操數(shù)據(jù)的結(jié)果可見。哪怕修改了100W條記錄沒有commit，對于其他的用戶依然查看不到修改了的數(shù)據(jù)。commit標(biāo)識事務(wù)的結(jié)束，標(biāo)識修改數(shù)據(jù)的生效，生效是在內(nèi)存生效還是磁盤生效都不重要。 ? 總結(jié)：commit就是讓事務(wù)提交，讓事務(wù)生效，讓修改過后的數(shù)據(jù)對于其他用戶可見。如果生效的數(shù)據(jù)在磁盤上面，別的用戶查的時候就去磁盤上讀取出來，如果生效的數(shù)據(jù)在內(nèi)存里面，那么在內(nèi)存里面就是可以看到的。 ? commit之后不是將修改過后的臟數(shù)據(jù)塊寫到磁盤上面，redo log開始是放在內(nèi)存里面的，commit之后會強迫log buffer里面的redo log無條件的必須寫到磁盤上面。只有磁盤寫成功了commit才會返回給客戶端提交完成的信息。在Oracle里面數(shù)據(jù)是由redo來保護的，為什么不將修改了的數(shù)據(jù)直接寫到磁盤上面，為什么還要讓redo去寫。因為寫redo速度快，redo是順序?qū)懙?#xff0c;是從一個文件從頭寫到尾。而要將數(shù)據(jù)塊寫到磁盤上面，先要去磁盤上面找數(shù)據(jù)塊的位置，然后再寫入，這樣非常耗時。一旦redo信息寫到磁盤上面就沒有問題了，即使數(shù)據(jù)塊丟失了，也可以通過redo找回來。 ? redo一寫到磁盤上，這個數(shù)據(jù)就安全了，既然安全了為什么還要checkpoint呢？ 第一：就是給別人讓位置，臟數(shù)據(jù)會越來越多的，最后內(nèi)存會放不下，所以臟數(shù)據(jù)最后還是得刷到磁盤上面給其他新產(chǎn)生的臟數(shù)據(jù)讓出位置。 第二：在恢復(fù)的時候減少時間，redo是可以將數(shù)據(jù)保護起來，如果有大量的數(shù)據(jù)都在內(nèi)存里面，比如說有好幾個G的數(shù)據(jù)在內(nèi)存里面沒有刷到磁盤上面，數(shù)據(jù)庫壞了恢復(fù)的時候因為大量數(shù)據(jù)的丟失到導(dǎo)致恢復(fù)的時候需要很長時間。所以checkpoint就是將一些數(shù)據(jù)及時的寫到磁盤上面，一旦寫到磁盤上面就不需要恢復(fù)了。 那么是否要通過checkpoint經(jīng)常來將臟數(shù)據(jù)寫到磁盤上面呢？效率的問題，因為頻繁的寫到磁盤上面是隨機寫I/O，效率低。 |
| 算法 | 臟緩存區(qū)用一個新隊列鏈接，稱為檢查點隊列。對緩存區(qū)的每一個改動，都有一個與其相關(guān)的重做值。檢查點隊列包含臟的日志緩存區(qū)，這些緩存區(qū)按照它們在日志文件中的位置排序，即在檢查點隊列中，緩存區(qū)按照它們的低重做值進(jìn)行排序。需要注意的是，由于緩存區(qū)是依照第一次變臟的次序鏈接到隊列中的，所以，如果在緩存區(qū)寫出之前對它有另外的改動，鏈接不能進(jìn)行相應(yīng)變更，緩存區(qū)一旦被鏈接到檢查點隊列，它就停留在此位置，直到將它被寫出為止。 ? ORACLE系統(tǒng)進(jìn)程DBWR在響應(yīng)檢查點請求時，按照這個隊列的低重做值的升序?qū)懗鼍彺鎱^(qū)。每個檢查點請求指定一個重做值，一旦DBWR寫出的緩存區(qū)重做值等于或大于檢查點的重做值，檢查點處理即完成，并將記錄到控制文件與數(shù)據(jù)文件。 ? 由于檢查點隊列上的緩存區(qū)按照低重做值進(jìn)行排序，而DBWR也按照低重做值順序?qū)懗鰴z查點緩存區(qū)，故可能有多個檢查點請求處于活動狀態(tài)，當(dāng)DBWR寫出緩存區(qū)時，檢查位于檢查點隊列前端的緩存區(qū)重做值與檢查點重做值的一致性，如果重做值小于檢查點隊列前緩存區(qū)的低重做值的所有檢查點請求，即可表示處理完成。當(dāng)存在未完成的活動檢查點請求時，DBWR繼續(xù)寫出檢查點緩存區(qū)。 ? 算法特點： 1）DBWR能確切的知道為滿足檢查點請求需要寫那些緩存區(qū)； 2）在每次進(jìn)行檢查點寫時保證指向完成最早的（具有最低重做值的）檢查點； 3）根據(jù)檢查點重做值可以區(qū)別多個檢查點請求，然后按照它們的順序完成處理 |
| 參數(shù)與命令 | 在數(shù)據(jù)庫中，增量檢查點是通過Fast-Start Checkpointing特性來實現(xiàn)的，從Oracle 8i開始，這一特性包含了Oracle企業(yè)版的Fast-Start Fault Recovery組件之中 select * from V$option where Parameter='Fast-Start Fault Recovery'; | 該組件包含3個主要特性，可以加快系統(tǒng)在故障后的恢復(fù)，提高系統(tǒng)的可用性。 Fast-Start Checkpointing 特性在Oracle 8i中主要通過參數(shù)FAST_START_IO_TARGET來實現(xiàn) | | Fast-Start Checkpointing | Fast-Start On-Demand Rollback | Fast-Start Parallel Rollback | | fast_start_io_target
該參數(shù)用于表示數(shù)據(jù)庫發(fā)生Instance Recovery 的時候需要產(chǎn)生的IO總數(shù),他通過v$filestat的AVGIOTIM來估算的.比如我們一個數(shù)據(jù)庫發(fā)生Instance Crash后需要在10分鐘內(nèi)恢復(fù)完畢,假定OS的IO每秒為500個,那么這個數(shù)據(jù)庫發(fā)生Instance Recovery的時候大概產(chǎn)生500*10*60=30,000次IO,也就是我們將可以把fast_start_io_target設(shè)置為30000 ? 在9i之前DBA主要靠fast_start_io_target間隔時間等方式來設(shè)置增量檢查點的頻率，比如可以讓Oracle每10分鐘發(fā)生一次增量檢查點。如果這個數(shù)字設(shè)置不合適，對數(shù)據(jù)庫性能的影響是很大的。而且有可能造成實例恢復(fù)時間過長 | | 在Oracle 9i中，Fast-Start Checkpointing主要通過參數(shù)FAST_START_MTTR_TARGET來實現(xiàn)。 mttr是mean time to recovery的簡寫，該參數(shù)定義數(shù)據(jù)庫進(jìn)行Crash恢復(fù)的時間，單位是秒，取值范圍是在0~3600秒之間。 在9i之后，特別是到了10g中，檢查點已經(jīng)相當(dāng)?shù)闹悄芑?#xff0c;很少會成為I/O問題的原兇。9i中設(shè)置fast_start_mttr_target參數(shù)為你所期望的實例恢復(fù)時間，系統(tǒng)將自動控制增量檢查點的頻率。比如，你希望實例恢復(fù)可以在5分鐘內(nèi)完成，你可以將此參數(shù)設(shè)置為300，也就是300 當(dāng)設(shè)置了fast_start_mttr_target后,fast_start_io_target這個參數(shù)將不再生效,從9I后fast_start_io_target這個參數(shù)被oracle廢除了 |
| Oracle 10g自動檢查點調(diào)整 從Oracle 10g開始，數(shù)據(jù)庫可以實現(xiàn)自動調(diào)整的檢查點，使用自動調(diào)整的檢查點，Oracle數(shù)據(jù)庫可以利用系統(tǒng)的低I/O負(fù)載時段寫出內(nèi)存中的臟數(shù)據(jù)，從而提高數(shù)據(jù)庫的效率。因此，及時數(shù)據(jù)庫管理員設(shè)置了不合理的檢查點相關(guān)參數(shù)，Oracle仍然能夠通過自動調(diào)整將數(shù)據(jù)庫的Crash Recovery時間控制在合理的范圍之內(nèi)。 當(dāng)FAST_START_MTTR_TARGET參數(shù)未設(shè)置，自動檢查點調(diào)整生效。 通常，如果必須嚴(yán)格控制實例或節(jié)點恢復(fù)時間，那么可以設(shè)置FAST_START_MTTR_TARGET為期望時間值；如果恢復(fù)時間不嚴(yán)格控制，那么可以不設(shè)置FAST_START_MTTR_TARGET參數(shù)，從而啟用Oracle 10g的自動調(diào)整特性 | | FAST_START_MTTR_TARGET ? | ■如果此參數(shù)設(shè)置的值超出了硬件實際的限制，比如你將它設(shè)置為60，你期望無論在任何情況下，數(shù)據(jù)庫都可以在1分鐘內(nèi)完成實例恢復(fù)，但根據(jù)數(shù)據(jù)庫的臟塊生成速度、存儲設(shè)備的寫性能，1分鐘內(nèi)根本無法完成實例恢復(fù)。這時候Oracle會自動設(shè)置合適的fast_start_mttr_target參數(shù)值，我們可以在參數(shù)文件中看到修正后的參數(shù)值，也可以在V$instance_recovery視圖中的Target_mttr列中看到實際的值 ■如果設(shè)置了FAST_START_MTTR_TARGET參數(shù)，就不要用早期的一些參數(shù)，容易引起沖突。 ■注意點：如果將fast_start_mttr_target設(shè)置為非0 ? ? 1）將啟用檢查點自動調(diào)整機制。 ? ? 2）log_checkpoint_interval參數(shù)將被覆蓋掉。 ? ? 3）90% OF SMALLEST REDO LOG(Oarcle 內(nèi)部機制)，從上次切換后算起，累計日志為? ? ? ? ? ? ?一個日志組大小的90%時，做一次檢查點切換。 ? ? ?4）每3s查看checkpoint隊列臟塊的寫出進(jìn)度，這個3秒是Oracle強調(diào)的增量檢查點特性之? ? ? ? ? ? ? 一。注意，3s并不觸發(fā)檢查點，它只是記錄當(dāng)時的檢查點位置，并將相關(guān)信息寫入到? ? ? ? ? ? ? controlfile。 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中，FAST_START_IO_TARGET和LOG_CHECKPOINT_INTERVAL參數(shù)已經(jīng)被設(shè)置為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------------------------ ------------- ----------- ----------------- ----------------------- ----------------- ----------------------- -------------- -------------------- 該視圖評估在不同F(xiàn)AST_START_MATTR_TARGET設(shè)置下，系統(tǒng)需要執(zhí)行的I/O次數(shù)等操作。用戶可以根據(jù)數(shù)據(jù)庫的建議，對FAST_START_MTTR_TARGET進(jìn)行相應(yīng)調(diào)整。 這個建議信息的收到Oracle 9i新引入的初始化參數(shù)statistics_level的控制，當(dāng)該參數(shù)設(shè)置為Typical或ALL時，MTTR建議信息被收集： SQL> show parameter statistics_levelNAME TYPE VALUE------------------------------------ ----------- ------------------------------statistics_level string TYPICAL 也可以通過v$statistics_level視圖來查詢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 ? ? | | 90% OF SMALLEST REDO LOG | ?oracle內(nèi)部事實上還將重做日志末尾前面90%的位置設(shè)為檢查點位置,這不是一個參數(shù),這是oracle內(nèi)部
規(guī)定的一個觸發(fā)增量檢查點的事件 | | ? | ? | | ? | ? | | fast_start_mttr_target,log_checkpoint_timeout,log_checkpoint_interval和90% OF SMALLEST REDOLOG 可以同時使用.考慮這樣一種情況,如果上面的這些觸發(fā)增量檢查點的參數(shù)都被設(shè)置,并且在某一時刻,這幾個參數(shù)一起被觸發(fā),但他們指定的Target RBA位置可能不盡相同,oracle將離日志末尾最近的那個位置認(rèn)為檢查點位置 |
Checkpoint SCN可以從數(shù)據(jù)庫中查詢得到： select file#,CHECKPOINT_CHANGE#,to_char(CHECKPOINT_TIME,'yyyy-mm-dd hh24:mi:ss') cpt from v$datafile; select dbid,CHECKPOINT_CHANGE# from v$database; 數(shù)據(jù)庫當(dāng)前的實例恢復(fù)狀態(tài)可以通過視圖v$instance_recovery查詢得到： SQL>select recovery_estimated_ios,actual_redo_blks,target_redo_blks,target_mttr,estimated_mttr from ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? v$instance_recovery;RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR
---------------------- ---------------- ---------------- ----------- --------------72 ??????????????333 ???????????3700 ?????????33 ????????????12系統(tǒng)計算出來的target_mttr為33秒,當(dāng)前估算的恢復(fù)時間是12秒。
ESTIMATED_MTTR的估算值是基于Dirty Buffer 的數(shù)據(jù)量和日志塊數(shù)量得出的，這個參數(shù)值告訴我們，如果此時數(shù)據(jù)庫本虧，那么進(jìn)行實例恢復(fù)將會需要的時間。
TARGET_MTTR 代表的是期望的恢復(fù)時間，通常改參數(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接近或超過FAST_START_MTTR_TARGET參數(shù)設(shè)置
（v$instance_recovery TARGET_MTTR）時，系統(tǒng)就會促發(fā)檢查點，
執(zhí)行寫出之后，系統(tǒng)恢復(fù)信息將會重新計算
在繁忙的系統(tǒng)中，可能會觀察到ESTIMATED_MTTR>TARGET_MTTR，這可能是因為DBWR正忙于寫出，甚或出現(xiàn)Checkpoint不能及時完成的情況WRITES_AUTOTUNE字段數(shù)據(jù)就是指由于自動調(diào)整檢查點執(zhí)行的寫出次數(shù)，而CK_BLOCK_WRITES指的則是由于檢查點寫出的Block的數(shù)量。 ? ? ? ? ? ? |
| 其他 | 當(dāng)運行alter tablespace ,datafile offline的時候; 運行alter tablespace、datafile offline的時候，它們存在著一定的區(qū)別： alter datafile offline： 在offline、online的時候，系統(tǒng)將不會修改所有datafile的scn alter tablespace offline： offline的事件，就會修改scn號；在online的時候，系統(tǒng)也將修改該ts下的所有datafile的scn |
