增量檢查點（incremental checkpoint）的解疑

原文：oracle8以後Oracle推出了incremental checkpoint的機制，在以前的版本里每次常規checkpoint時都會做一個full thread checkpoint,這樣的話所有髒資料會被寫到磁碟，巨大的i/o對系統效能帶來很大影響。為了解決這個問題，oracle引入了checkpoint queue機制，每一個髒塊會被移到檢查點佇列裡面去，按照low rdb（第一次對此塊修改對應的redo block address）來排列，靠近檢查點佇列尾端的資料塊的low rba值是最小的，而且如果這些贓塊被再次修改後它在檢查點佇列裡的順序也不會改變，這樣就保證了越早修改的塊越早寫入磁碟。每隔3秒鐘ckpt會去更新控制檔案中的checkpoint progress recored區域，記錄checkpoint執行的情況。
注意：增量檢查點並不去更新資料檔案頭，只是在控制檔案中記錄了checkpoint progress record這個區域，記下low rba,on-disk rba等資訊。這些資訊就可以用來快速恢復。

每隔3秒鐘ckpt會去更新控制檔案中的checkpoint progress recored區域，記錄checkpoint執行的情況。

解疑:這裡應該是只更新控制檔案，每3秒不是更新資料檔案頭，而是在控制檔案中記錄checkpoint的執行情況，基於增量檢查點和checkpoint  queue的原理，在發生檢查點的時候，ckpt 程式每次只是告訴dbwr，寫dirty  buffe要一直寫到最新這個位置(發生檢查點：也就是alter system checkpoint)，這樣做呢，僅僅是告訴dbwr一個checkpoint queue中的結束點，ckpt絕對不會等到dbwr寫完所有髒資料在更新控制檔案和資料檔案頭，而是每3秒鐘，在控制檔案中的checkpoint progress recored區域中報告一下dbwr最新寫入的位置(也就是dbwr的寫狀態的scn)。這樣使得，比如資料庫要做恢復的時候（instance  recovery）可以從這個最新報告的scn位置開始做恢復，而不是從資料檔案中的checkpoint  scn開始做恢復，這樣將縮短恢復時間，尤其是instance  crash的情況下啟動更快。另外要注意的是，檢查點發生的時候，ckpt 去更新資料檔案頭和控制檔案，並不是把當前檢查點發生時候的scn 更新進去，而是把上一次dbwr寫入已經完成的檢查點發生時候的  scn 更新進去，也就是說，更新控制檔案和資料檔案頭是滯後於檢查點的發生的，這個從恢復的原理也很容易理解，因為檢查點發生的時候dirty buffer還沒有寫入，自然不能立即更新成當前的scn了。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/9390331/viewspace-694961/，如需轉載，請註明出處，否則將追究法律責任。