檢查點機制

圓滿事務：日志中記錄了事務的開始和commit提交事務，這說明日志已經完整地記錄了事務的所有更新活動。??

??
中止事務：日志中記錄了事務的開始記錄，但沒有日志的提交記錄，這說明日志記錄的事務沒有最后提交。

數據庫的故障及恢復機制都離不開日志文件。每次恢復過程都需要從頭到尾掃描日志文件以確定哪些事務是圓滿事務，哪些事務是中止事務，才能分別進行Redo或Undo操作。

設想一下，如果日志文件的內容很大，這樣的掃描和恢復操作將耗費大量的資源。而且盡管一些圓滿事務的結果已經寫入數據庫（不需要Redo），但從頭到尾的掃描仍然會Redo這些事務，盡管這樣的操作并不會導致數據庫一致性的改變，但無謂的Redo操作仍然顯得多余。

有沒有盡量減少在恢復時必須前滾的修改量的機制呢？這就是檢查點機制。目前的主流數據庫產品都支持日志的檢查點機制。

??? SQL Server 系統按照設置在日志文件中設置一個一個的檢查點（checkpoint），這里的檢查點就好比是日志文件的一個一個驛站。檢查點從當前數據庫的內存的緩沖區中刷新臟數據和日志頁面，以盡量減少在恢復時必須重做（Redo）的修改量。

??? 1.檢查點的操作

??? SQL Server 生成檢查點的過程如下：

???
①將標記檢查點起點的日志記錄寫入日志文件。 ? ?
②將為檢查點記錄的信息存儲在檢查點日志記錄鏈中，鏈起點的LSN將寫入數據庫根頁面中。 ? ?
③將最小恢復LSN（MinLSN）保存在檢查點記錄中。 ? ?
④在檢查點記錄中記錄所有的未完成的活動事務。 ? ?
⑤如果數據庫工作在【簡單恢復模式】，刪除新的MinLSN之前的所有日志記錄。 ? ?
⑥將所有修改后的日志寫入磁盤。 ? ?
⑦將所有修改后的數據寫入磁盤。 ? ?
⑧將標記檢查點記錄末端的記錄寫入日志文件。

??? 2.檢查點與恢復效率的關系

在日志文件中設置了檢查點之后，為什么基于日志的恢復機制就可以提高效率了呢？如圖所示為檢查點發生時可能的事務的狀態。

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

由于在檢查點完成之前的所有事務不需要再執行Redo操作，所以可以大大提高數據庫系統恢復的效率。

3.MinLSN的選擇

MinLSN實際上代表了數據庫從檢查點恢復時，具體從哪個LSN號開始掃描并進行恢復。所以MinLSN的選擇是檢查點時的LSN和最早的活動事務起點LSN兩者比較的最小值。

如圖，事務2為檢查點時的唯一活動事務，其起點的LSN1小于檢查點發生時的LSN2，所以MinLSN取LSN1就可以。

本文轉自UltraSQL51CTO博客，原文鏈接：http://blog.51cto.com/ultrasql/1591632 ，如需轉載請自行聯系原作者

總結

以上是生活随笔為你收集整理的存储引擎之必知必会 -- 检查点机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。