對於需要持久化資料的軟體或者系統，必須要解決的問題是如何處理意外中斷導致的資料丟失問題。比如乙個交易系統，使用者正在購買商品，突然斷電了，那麼如何恢復使用者的賬戶資訊？該不該扣款？商家的商品到底有沒有賣出？這一些列的問題需要資料庫恢復機制解決。
而恢復機制需要借助日誌系統才能展開。日誌記錄了系統中發生的各個事務。基本的思路就是，把事務提交至資料庫的同時，也在日誌檔案中記錄一下。那麼應該先提交事務，還是先記錄事務的日誌？粗略地講，必然是先提交日誌，因為如果先提交事務，正好提交了一半斷電，這個事務只執行了一半，由於沒有日誌記錄，所以根本無法獲取這個事務的執**況，比如執行了哪些操作，哪些操作還未執行，因此也就無法恢復事務。所以在提交事務之前，必然要先提交日誌。
有了資料庫事務的日誌，然後是兩個必要的操作：
1.redo：就是重做，指的是按照日誌上的操作記錄重做，而不是重做事務，雖然結果一樣，但是日誌上記錄的是cpu計算得到的最終結果，因此效率更高。
2.undo：就是撤銷，或者回滾，指的是把日誌上記錄的操作撤銷，恢復到原本的值。
因此，日誌的一條記錄必然包括操作型別，原始值，更新值這三種資訊。這樣才能進行redo和undo。還有一種是commit點，就是表明某乙個事務已經結束。
恢復技術可以分成兩種型別：
1，延遲更新
事務達到了commit點，被提交，然後先把事務的日誌記錄到資料庫以後，才把事務更新到資料庫。
這種情況下，如果在日誌中沒有看到某乙個事務的commit點，那麼說明該事務的日誌還沒有完全被記錄到資料庫，那麼這個事務的操作也一定沒有更新到資料庫中，因此，這個事務一定沒有被執行。如果有了commit點，這個事務可能被完全執行，可能被執行了一部分，也可能沒有執行。那麼我們只需要重做一次事務的操作即可。認為這個事務已經執行。
2，立即更新
事務不需要到達commit點就可以更新到資料庫，但是操作被更新前必須先記錄日誌。比如事務包含4個操作才是commit，那麼不需要等到commit，第乙個操作就可以執行，但是必須在日誌更新後。
這種情況下，對於日誌中有commit的事務，全部redo，日誌提交了，但是操作可能沒有更新，所以redo。但是對於沒有commit的事務，一定沒有全部執行，可能只執行了一部分，由於日誌不全，也無法做redo，只能undo。即把日誌中該事務的操作全部undo，取消部分更新帶來的影響。
資料庫 日誌系統原理 恢復系統
ref database system concepts 乙個簡單的讀 修改x元素操作的流程如 事務到緩衝中讀取元素x，如果命中，則讀取事務區域性位址空間並返回，如果未命中，則先將相關頁從磁碟讀入緩衝區。事務在它的區域性位址空間中修改元素x，然後寫入緩衝區，再從緩衝區寫入磁碟。當然緩衝區的資料也可能...
恢復系統資料庫
msdb 包含了有關作業 報警及操作員等資訊如果包含系統資料庫的介質變了，那麼必須重建系統資料庫，如果你仍然可以啟動sql server服務，則可以通過restore語句從系統資料庫的備份中恢復資料庫。關於系統資料庫的恢復總結如下 在sql server資料庫中，系統資訊儲存在系統資料庫中，主要的系...
通過日誌恢復資料庫
建立測試資料庫test create database test onprimary name test data.mdf filename d test data.mdf logon name test data.ldf filename d test data.ldf 建立測試表 create ...