SQLServer的檢查點、redo和undo

SQLServer的檢查點、redo和undo

檢查點與恢復效率的關係
檢查點將髒資料頁從當前資料庫的緩衝區快取記憶體重新整理到磁碟上。 這最大限度地減少了恢復時必須重做（Redo）的修改量。
為什麼在日誌檔案中設定了檢查點之後，基於日誌的恢復機制就可以提高效率了呢？如圖所示為檢查點發生時可能的事務的狀態。

① 事務1
其start和commit日誌記錄都發生在檢查點之前，這樣的事務其結果已經反映到物理介質上去了（因為檢查點會保證WAL協議，確保資料被寫入），所以在恢復時無須對該事務做Redo操作。
② 事務2
其start日誌記錄在檢查點之前發生，其commit記錄在故障點之前發生，說明日誌中事務已經完美提交，但資料不一定已經寫入，所以屬於圓滿事務，需要Redo操作。
③ 事務3
其start日誌記錄在檢查點之後發生，其commit記錄在故障點之前發生，說明日誌中事務已經完美提交，但資料不一定已經寫入，所以屬於圓滿事務，需要Redo操作。
④ 事務4
其start日誌記錄在檢查點之後發生，其commit記錄在故障點之前尚未發生，說明日誌中事務為中止事務，需要Undo操作。
⑤ 事務5
其start日誌記錄在檢查點之前發生，其commit記錄在故障點之前尚未發生，說明日誌中事務為中止事務，需要Undo操作。

由CheckPoint的機制可以看出，由於記憶體中的資料往往比持久化儲存中的資料更新，而CheckPoint保證了這部分資料能夠被持久化到磁碟，因此CheckPoint之前的資料一定不會再需要被Redo。

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