基本原則
登記的次序嚴格按並行事務執行的時間次序
必須先寫日誌檔案，後寫資料庫
寫日誌檔案操作：把表示這個修改的日誌記錄
寫到日誌檔案
寫資料庫操作：把對資料的修改寫到資料庫中
為什麼要先寫日誌檔案 (the write-ahead log)
寫資料庫和寫日誌檔案是兩個不同的操作
在這兩個操作之間可能發生故障
如果先寫了資料庫修改，而在日誌檔案中沒有登記下這個修改，則以後就無法恢復這個修改了
如果先寫日誌，但沒有修改資料庫，按日誌檔案恢復時只不過是多執行一次不必要的undo操作，並不會影響資料庫的正確性
事務故障：事務在執行至正常終止點前被終止
恢復方法
由恢復子系統應利用日誌檔案撤消（undo）此事務已對資料庫進行的修改
事務故障的恢復由系統自動完成，對使用者是透明的，不需要使用者干預
反向掃瞄檔案日誌（即從最後向前掃瞄日誌檔案），查詢該事務的更新操作。
對該事務的更新操作執行逆操作。即將日誌記錄中「更新前的值」 寫入資料庫。
插入操作， 「更新前的值」為空，則相當於做刪除操作
刪除操作，「更新後的值」為空，則相當於做插入操作
若是修改操作，則相當於用修改前值代替修改後值
繼續反向掃瞄日誌檔案，查詢該事務的其他更新操作，並做同樣處理。
如此處理下去，直至讀到此事務的開始標記，事務故障恢復就完成了。
系統故障造成資料庫不一致狀態的原因
未完成事務對資料庫的更新已寫入資料庫
已提交事務對資料庫的更新還留在緩衝區沒來得及寫入資料庫
恢復方法
1. undo 故障發生時未完成的事務
2. redo 已完成的事務
系統故障的恢復由系統在重新啟動時自動完成，不需要使用者干預
1.正向掃瞄日誌檔案（即從頭掃瞄日誌檔案）
重做(redo) 佇列: 在故障發生前已經提交的事務
這些事務既有begin
transaction記錄，也有commit記錄
撤銷 (undo)佇列:故障發生時尚未完成的事務
這些事務只有begin
transaction記錄，無相應的commit記錄
2. 對撤銷(undo)佇列事務進行撤銷(undo)處理
反向掃瞄日誌檔案，對每個undo事務的更新操作執行逆操作
即將日誌記錄中「更新前的值」寫入資料庫
3. 對重做(redo)佇列事務進行重做(redo)處理
正向掃瞄日誌檔案，對每個redo事務重新執行登記的操作
即將日誌記錄中「更新後的值」寫入資料庫
1. 裝入最新的後備資料庫副本(離故障發生時刻最近的轉儲副本) ，使資料庫恢復到最近一次轉儲時的一致性狀態。
對於靜態轉儲的資料庫副本，裝入後資料庫即處於一致性狀態
對於動態轉儲的資料庫副本，還須同時裝入轉儲時刻的日誌檔案副本，利用與恢復系統故障的方法（即redo+undo），才能將資料庫恢復到一致性狀態。
裝入有關的日誌檔案副本(轉儲結束時刻的日誌檔案副本) ，重做已完成的事務，撤銷未完成的事務。
首先掃瞄日誌檔案，找出故障發生時已提交和未完成的事務的標識，分別將其記入重做佇列和撤銷佇列。
然後正向掃瞄日誌檔案，對重做佇列中的所有事務進行redo處理。反向掃瞄日誌檔案，對撤銷佇列中的所有事務進行undo處理。
介質故障的恢復需要dba介入
dba的工作
重灌最近轉儲的資料庫副本和有關的各日誌檔案副本
執行系統提供的恢復命令
具體的恢復操作仍由dbms完成
兩個問題
搜尋整個日誌將耗費大量的時間
redo處理：重新執行，浪費了大量時間
具有檢查點（checkpoint）的恢復技術
在日誌檔案中增加檢查點記錄（checkpoint）
增加重新開始檔案
恢復子系統在登入日誌檔案期間動態地維護日誌
檢查點記錄的內容
1. 建立檢查點時刻所有正在執行的事務清單
2. 這些事務最近乙個日誌記錄的位址
重新開始檔案（oracle控制檔案）的內容
記錄各個檢查點記錄在日誌檔案中的位址
周期性地執行如下操作：建立檢查點，儲存資料庫狀態。
具體步驟是：
1.將當前日誌緩衝區中的所有日誌記錄寫入磁碟的日誌檔案上
2.在日誌檔案中寫入乙個檢查點記錄
3.將當前資料緩衝區的所有資料記錄寫入磁碟的資料庫中
4.把檢查點記錄在日誌檔案中的位址寫入乙個重新開始檔案
恢復子系統可以定期或不定期地建立檢查點,儲存資料庫狀態
定期 按照預定的乙個時間間隔，如每隔一小時建立乙個檢查點
不定期
按照某種規則，如日誌檔案已寫滿一半建立乙個檢查點
使用檢查點方法可以改善恢復效率
當事務t在乙個檢查點之前提交
oracle中，事務t對資料庫所做的修改已寫入日誌檔案，但未必已寫入資料庫
oracle寫入資料庫的時間是在這個檢查點建立之時！
在進行恢復處理時，沒有必要對事務t執行redo操作
t1：在檢查點之前提交
t2：在檢查點之前開始執行，在檢查點之後故障點之前提交
t3：在檢查點之前開始執行，在故障點時還未完成
t4：在檢查點之後開始執行，在故障點之前提交
t5：在檢查點之後開始執行，在故障點時還未完成
恢復策略：
t3和t5在故障發生時還未完成，所以予以撤銷
t2和t4在檢查點之後才提交，它們對資料庫所做的修改在故障發生時可能還在緩衝區中，尚未寫入資料庫，所以要redo
t1在檢查點之前已提交，所以不必執行redo操作
start>
a, 0, 10>
commit>
start>
b, 0, 10>
start>
c, 0, 10>
c, 10, 20>
start>
commit>
a, 10, 20>
start>
d, 0, 10>
commit>
1.從重新開始檔案中（oracle控制檔案）找到最後乙個檢查點記錄在日誌檔案中的位址，由該位址在日誌檔案中找到最後乙個檢查點記錄2.由該檢查點記錄得到檢查點建立時刻所有正在執行的事務清單active-list=
建立兩個事務佇列
undo-list
redo-list
把active-list暫時放入undo-list佇列=，redo佇列暫為空。
3.從檢查點開始正向掃瞄日誌檔案，直到日誌檔案結束
如有新開始的事務ti，把ti暫時放入undo-list佇列=
如有提交的事務tj，把tj從undo-list佇列移到redo-list佇列=
4.對undo-list中的每個事務執行undo操作
對redo-list中的每個事務執行redo操作
dbms自動保證映象資料與主資料庫的一致性
每當主資料庫更新時，dbms自動把更新後的資料複製過去
沒有出現故障時
可用於併發操作
乙個使用者對資料加排他鎖修改資料，其他使用者可以讀映象資料庫上的資料，而不必等待該使用者釋放鎖
頻繁地複製資料自然會降低系統執行效率
在實際應用中使用者往往只選擇對關鍵資料和日誌檔案映象，而不是對整個資料庫進行映象
如果資料庫只包含成功事務提交的結果，就說資料庫處於一致性狀態！保證資料一致性是對資料庫的最基本的要求。
事務是資料庫的邏輯工作單位
dbms保證系統中一切事務的原子性、一致性、隔離性和永續性
dbms必須對事務故障、系統故障和介質故障進行恢復
恢復中最經常使用的技術：資料庫轉儲和登記日誌檔案
恢復的基本原理：利用儲存在後備副本、日誌檔案和資料庫映象中的冗餘資料來重建資料庫
常用恢復技術
事務故障的恢復
undo
系統故障的恢復
undo + redo
介質故障的恢復
重灌備份並恢復到一致性狀態 + redo
提高恢復效率的技術
檢查點技術
可以提高系統故障的恢復效率
可以在一定程度上提高利用動態轉儲備份進行介質故障恢復的效率
映象技術
映象技術可以改善介質故障的恢復效率
資料庫原理 恢復策略
三種不同的資料庫故障，其恢復資料庫的策略也是不同的 1 事務故障的恢復 事務故障 事務執行至正常終點前被終止 恢復方法 利用日誌檔案撤銷此事務對資料庫進行的修改 恢復步驟 特點 事務故障的恢復由系統自動完成，不需要使用者進行干預 2 系統故障的恢復 系統故障造成資料庫不一致性的原因 恢復的方法 恢復...
資料庫備份恢復策略
主要策略 一周一次全量備份，並刪除上週的增量備份，全量備份 每天一次增量備份。全量備份 mysqldump uroot padmin123 quick events flush logs delete master logs single transaction databases fecmall ...
mysql資料庫恢復策略 資料庫系統恢復策略概述
1 前言 儘管計算機系統的可靠性在不斷提高，資料庫系統中也採用了很多措施和方法保證資料庫系統的正確執行，但仍不可避免系統出現這樣或那樣的錯誤，導致資料庫資料丟失或破壞。所以，資料庫系統必須採取相應的恢復措施，把資料庫系統從故障狀態恢復到乙個已知的正確狀態，這就是本文要談的資料庫的故障恢復機制。本文主...