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