圓滿事務：日誌中記錄了事務的開始和commit提交事務，這說明日誌已經完整地記錄了事務的所有更新活動。
中止事務：日誌中記錄了事務的開始記錄，但沒有日誌的提交記錄，這說明日誌記錄的事務沒有最後提交。
資料庫的故障及恢復機制都離不開日誌檔案。每次恢復過程都需要從頭到尾掃瞄日誌檔案以確定哪些事務是圓滿事務，哪些事務是中止事務，才能分別進行redo或undo操作。
設想一下，如果日誌檔案的內容很大，這樣的掃瞄和恢復操作將耗費大量的資源。而且儘管一些圓滿事務的結果已經寫入資料庫（不需要redo），但從頭到尾的掃瞄仍然會redo這些事務，儘管這樣的操作並不會導致資料庫一致性的改變，但無謂的redo操作仍然顯得多餘。
有沒有儘量減少在恢復時必須前滾的修改量的機制呢？這就是檢查點機制。目前的主流資料庫產品都支援日誌的檢查點機制。
sql server 系統按照設定在日誌檔案中設定乙個乙個的檢查點（checkpoint），這裡的檢查點就好比是日誌檔案的乙個乙個驛站。檢查點從當前資料庫的記憶體的緩衝區中重新整理髒資料和日誌頁面，以儘量減少在恢復時必須重做（redo）的修改量。
sql server 生成檢查點的過程如下：
①將標記檢查點起點的日誌記錄寫入日誌檔案。
②將為檢查點記錄的資訊儲存在檢查點日誌記錄鏈中，鏈起點的lsn將寫入資料庫根頁面中。
③將最小恢復lsn（minlsn）儲存在檢查點記錄中。
④在檢查點記錄中記錄所有的未完成的活動事務。
⑤如果資料庫工作在【簡單恢復模式】，刪除新的minlsn之前的所有日誌記錄。
⑥將所有修改後的日誌寫入磁碟。
⑦將所有修改後的資料寫入磁碟。
⑧將標記檢查點記錄末端的記錄寫入日誌檔案。
在日誌檔案中設定了檢查點之後，為什麼基於日誌的恢復機制就可以提高效率了呢？如圖所示為檢查點發生時可能的事務的狀態。
① 事務1
其start和commit日誌記錄都發生在檢查點之前，這樣的事務其結果已經反映到物理介質上去了（因為檢查點會保證wal協議，確保資料被寫入），所以在恢復時無須對該事務做redo操作。
② 事務2
其start日誌記錄在檢查點之前發生，其commit記錄在故障點之前發生，說明日誌中事務已經完美提交，但資料不一定已經寫入，所以屬於圓滿事務，需要redo操作。
③ 事務3
其start日誌記錄在檢查點之後發生，其commit記錄在故障點之前發生，說明日誌中事務已經完美提交，但資料不一定已經寫入，所以屬於圓滿事務，需要redo操作。
④ 事務4
其start日誌記錄在檢查點之後發生，其commit記錄在故障點之前尚未發生，說明日誌中事務為中止事務，需要undo操作。
⑤ 事務5
其start日誌記錄在檢查點之前發生，其commit記錄在故障點之前尚未發生，說明日誌中事務為中止事務，需要undo操作。
由於在檢查點完成之前的所有事務不需要再執行redo操作，所以可以大大提高資料庫系統恢復的效率。
minlsn實際上代表了資料庫從檢查點恢復時，具體從哪個lsn號開始掃瞄並進行恢復。所以minlsn的選擇是檢查點時的lsn和最早的活動事務起點lsn兩者比較的最小值。
如圖，事務2為檢查點時的唯一活動事務，其起點的lsn1小於檢查點發生時的lsn2，所以minlsn取lsn1就可以。
資料儲存必知必會
在作業系統出現之後，隨著計算機應用範圍的擴大 需要處理的資料迅速膨脹。最初，資料與程式一樣，以簡單的檔案作為主要儲存形式。以這種方式組織的資料在邏輯上更簡單，但可擴充套件性差，訪問這種資料的程式需要了解資料的具體組織格式。當系統資料量大或者使用者訪問量大時，應用程式還需要解決資料的完整性 一致性以及...
mysql必知必會 mysql必知必會（四）
十四 理解子查詢 1 通過子查詢過濾 這本書在所有的章節都關連到了資料庫表，訂單資料是儲存在兩個表中，orders表儲存著 訂單號碼 顧客id和訂單日期。個人的訂單列表關連著orderitems表，訂單表沒有儲存顧客資訊，它只是儲存著顧客id，這實際的顧客資訊是儲存在customers表中。現在假設...
mysql的必知必會 mysql 必知必會 筆記
好久沒有寫了。1 show columns from table 等同於describe table顯示的是表的結構。而select from table 則顯示的是整個表中插入的資料。2 select distinct c1,c2 from table除非列不相同，否則所有行將被檢索出來，即不能對...