Oracle CKPT再複習

記憶體資料塊寫入資料檔案,在寫的過程中，一旦發生例項崩潰，就需要例項恢復
要有一套完整的機制能夠保證使用者已經提交的資料不會丟失
而且這套機制要充分考慮IO效率問題
Oracle引入了CKPT和LGWR這兩個後臺程式，這兩個程式與DBWn程式互相合作，
提供了既安全又高效的寫髒資料塊的解決方案。

使用者程式每次修改記憶體資料塊時，都會在日誌緩衝區（log buffer）中構造一個相應的重做條目（redo entry），
該重做條目描述了被修改的資料塊在修改之前和修改之後的值。
而LGWR程式則負責將這些重做條目寫入聯機日誌檔案。
只要重做條目進入了聯機日誌檔案，那麼資料的安全就有保障了，否則這些資料都是有安全隱患的。

使用者提交(commit)時，Oracle是不一定會把提交的資料塊寫入資料檔案的。
那麼例項崩潰時，必然會有一些已經提交但是還沒有被寫入資料檔案的記憶體資料塊隨記憶體斷電消失,就需要恢復
當例項再次啟動時，Oracle需要利用日誌檔案中記錄的重做條目在buffer cache中重新構造出被丟失的資料塊，
從而完成先前滾和後回滾的工作，並將丟失的資料塊找回來。

在恢復的過程中必然要有恢復的起點和終點

終點很好解決.最後commit的點
起點就比較難定位 起點就意味著這之前的資料都已經從記憶體同步到資料檔案中了.其後的就是髒資料
 起點定位時間太長,說明下次恢復週期長,週期長安全隱患大
 起點定位時間太短,說明DBWN程式頻繁的寫,IO就比較緊張
為了確定最佳起點位置oracle採用CKPT程式實現完全檢查點和增量檢查點來分別定位起點
可以說檢查點的引入就是為了加速例項恢復.

oracle為檢查點程式提供了檢查點佇列,該佇列串起來的都是髒資料塊所對應的buffer header.
概括下來其實就是DBWn負責寫檢查點佇列上的髒資料塊，
而CKPT負責記錄當前檢查點佇列的第一個資料塊所對應的的重做條目在日誌檔案中的地址,將其寫到控制檔案中去.

增量檢查點引入的原因 就是加速例項恢復和減緩DBWR一次突發大任務量

完全：所有記憶體中的髒塊+所有的資料檔案+所有的控制檔案
  增量：只更新控制檔案中的LRBA的位置
  延遲：日誌切換，不立即做那個版本,日誌切換就會觸發完全檢查點同時,完全檢查點會更新控制檔案和資料檔案頭.
檢查點佇列隨著時間增長,由CKPT通知DBWR去寫,每次告訴DBWR寫到佇列的什麼地方 與主機的IO效率有關
 也就是CKPT是監工,向DBWR提交任務,DBWR即為勞力
 CKPT除了通知DBWR去寫以外,還會每三秒檢查一次DBWR的工作進度,並將DBWR當前進度記錄到控制檔案
 如果3秒觸發,CKPT只做一件事,就是找出檢查點佇列裡第一個buffer header
 並將該buffer header中所記錄的LRBA（Low Redo Block Address Low表示第一次修改時對應的RBA）
 將LRBA記錄到控制檔案中去。
 如上事件即稱為增量檢查點.目的是例項如果是日誌切換,也換做檢查點,這個檢查點並不立即去做,當日志迴圈切一圈時,第一次切換的日誌要被覆蓋前必須寫盤時會去做
 除了記錄LRBA到控制檔案,還需要記錄到每個資料檔案頭。


 

到了8I版本後,完全檢查點只有在兩種情況下才觸發:
 1. alter system checkpoint;
 2.除了shutdown abort以外的正常關庫命令

 手動執行alter system checkpoint完全檢查點會將所有髒塊寫盤(包括未提交的)
 關閉資料庫時會將為完成的事物回滾.再將髒塊寫盤

 
概括下來其實就是DBWn負責寫檢查點佇列上的髒資料塊，
而CKPT負責記錄當前檢查點佇列的第一個資料塊所對應的的重做條目在日誌檔案中的地址,將其寫到控制檔案中去.

崩潰後,定位恢復的redo起點. 使起點和終點儘可能短,恢復時間就少.