【正文】 ：三個原理v 先寫日志在將更新的數(shù)據(jù)庫對象的修改寫入磁盤之前，先將對應的日志記錄寫入穩(wěn)存v 恢復修改的記錄數(shù)據(jù)在回滾某些事務時，如果出現(xiàn)對數(shù)據(jù)庫的改變，則需要在日志中記錄這些改變，保證在重復進行重新啟動時不需要重復這些操作v 重做時重復歷史在崩潰后進行重新啟動時，重做崩潰前的所有操作，使系統(tǒng)恢復到崩潰時的狀態(tài)，然后回滾崩潰時還在執(zhí)行的事務已完成的操作ARIES算法 ：三個過程v 分析過程決定哪些事務要 undo，哪些頁在崩潰時是臟的，以及 redo應從哪個 LSN開始vRedo過程從分析過程決定的位置開始，執(zhí)行一個 redo，重復歷史，將數(shù)據(jù)庫恢復到發(fā)生崩潰前的狀態(tài)vUndo過程回滾在發(fā)生崩潰時那些不完整的事務ARIES算法 ：系統(tǒng)故障恢復分析重做撤銷 崩潰時活動事務最早的日志記錄分析結束時臟頁中最小的 recLSN最近的檢查點 (包括了臟頁和活動事務的列表，并記錄了事務的 LastLSN)崩潰日志ARIES算法中恢復的三個階段ARIES算法 ： 分析過程v 找到最后完整檢查點日志記錄，并從該記錄開始讀入臟頁表v 將 RedoLSN設置為臟頁表中頁的 RecLSN的最小值，如果沒有臟頁，就將其設置為檢查點日志記錄的LSNv 將要被 undo的事務列表 undolist設置為檢查點日志記錄中的事務列表及這些事務的 LastLSNv 從檢查點繼續(xù)向前掃描，每找到一個不在 undolist中的事務日志記錄，就將其添加到 undolist，每找到一個事務的 end日志記錄，就將其從 undolist中刪除ARIES算法 ： Redo過程v Redo過程通過重演所有沒有在磁盤頁上反映的動作來重復歷史v Redo過程從 RedoLSN開始向前掃描日志，該點之前的日志記錄已經反映在磁盤數(shù)據(jù)庫頁上v 只要 Redo過程找到一個 update日志記錄，它就執(zhí)行如下動作：? 如果該頁不在臟頁表中 (更新已經實施 )，或者該 update日志記錄的 LSN小于臟頁表中該頁的 RecLSN（沒有實施，但之后還有更新）， Redo過程就跳過該日志記錄? 否則 Redo過程就從磁盤調出該頁，如果其 PageLSN小于該日志記錄的 LSN，重做該日志記錄ARIES算法 ： Undo過程v Undo過程反向掃描日志，取消所有 undolist中的事務v 如果找到一個 CLR，它用 UndoNextLSN字段跳過一個已經回滾了的事務日志。否則，它用事務日志的 PrevLSN字段查找下一個要被撤消的事務日志v 每當一個 update日志記錄被用于撤消， Undo過程產生一個包含 undo執(zhí)行動作（必須是物理邏輯的）的 CLR，并將 CLR的 UndoNextLSN設置為update日志記錄的 PreLSN值SQLSERVER恢復技術SQLServer： 最小恢復 LSNvMinLSN是下面這些 LSN中的最小 LSN：? 檢查點起點的 LSN? 最舊的活動事務起點的 LSNLSN141LSN142LSN143LSN144LSN145LSN146LSN147LSN148開始Tran1開始Tran2更新Tran2檢查 點 更新Tran1提交Tran1檢查 點 更新Tran2SQLServer： 生成檢查點v 將標記檢查點起點的記錄寫入日志文件v 將為檢查點記錄的信息存儲在檢查點日志記錄鏈內。將這條鏈起點的 LSN寫入數(shù)據(jù)庫根頁v 將最小恢復 LSN(MinLSN)保存在檢查點記錄中v 將所有未完成的活動事務列表保存在檢查點記錄中v 如果數(shù)據(jù)庫使用的是簡單恢復模式，則刪除新的 MinLSN之前的所有日志記錄v 將所有臟日志和數(shù)據(jù)頁寫入磁盤v 將標記檢查點末端的記錄寫入日志文件SQLServer： 生成檢查點v 檢查點線程遍歷緩沖區(qū)池，按照緩沖區(qū)編號順序掃描頁面，當它發(fā)現(xiàn)臟頁時，它將查看與該頁面物理 (磁盤上 )連續(xù)的其他頁面是否也是臟的，這樣它可以進行大塊寫操作v 如果它看到頁面 5是臟的時，它可能會寫入頁面 2 380、 500等，這些頁面在磁盤上是連續(xù)的，盡管它們在緩沖區(qū)內相去甚遠。這樣，緩沖區(qū)中非連續(xù)的頁面可以被一次聚集寫入 (gatherwrite)磁盤 (它是借助于 Windows NT的 Win32函數(shù) WriteFileGather實現(xiàn)的 )v 以后檢查點會到達頁面 500，為避免將該頁面重復寫入磁盤，檢查點算法會為每個頁面設置標志位，開始時所有的位都相同 (都為 0或 1)。當檢查點檢查到某個頁面時，它將其標志位翻轉。如果檢查點碰到具有相反位的頁面，它就跳過該頁面v 對于在檢查點期間新近引入的頁面，或者已經被檢查點輸出到磁盤但又重新變臟的頁面，都不會被該次檢查點操作寫入SQLServer： 生成檢查點v recovery interval選項設置 SQL Server恢復數(shù)據(jù)庫所需的最大分鐘數(shù)，默認值為 0，表示每個數(shù)據(jù)庫的恢復時間不超過 1分鐘v 據(jù)此 SQL Server將估計在恢復時間間隔期間可以處理多少更新的數(shù)據(jù)，從而決定在每一個數(shù)據(jù)庫中 SQL Server何時生成一次檢查點。實際中， SQL Server根據(jù) 10MB的日志可以在 1分鐘內得到恢復這樣一個估計來確定它的恢復間隔v 一個數(shù)據(jù)庫中，當最近一個檢查點之后數(shù)據(jù)更新操作達到了 SQL Server認為可以在恢復時間間隔更新的數(shù)量時，SQL Server將進行一個檢查點操作SQLServer： 生成檢查點v SQL Server自動生成檢查點的時間間隔基于日志內的記錄數(shù)而非時間。如果數(shù)據(jù)庫只做了很少的修改，自動檢查點的時間間隔就長。如果修改了大量數(shù)據(jù)，自動檢查點將經常發(fā)生v 檢查點間隔取決于 recovery interval配置以及數(shù)據(jù)庫使用的恢復模式v 每當日志記錄數(shù)達到 SQL Server估計在 recovery interval選項所指定的時間內能處理的記錄數(shù)時，就生成自動檢查點v 如果數(shù)據(jù)庫使用的是簡單恢復模式，則當日志的 70%已滿，就生成自動檢查點，以截斷日志并釋放空間。但如果沒有空間可以被釋放，則不生成檢查點SQLServer：事務日志物理構架v 每個物理日志文件分成許多虛擬日志文件v 事務日志是回繞的日志文件。當創(chuàng)建數(shù)據(jù)庫時，邏輯日志從物理日志文件的始端開始。在邏輯日志的末端添加新的日志記錄，邏輯日志就向物理日志末端增長v 當邏輯日志的末端到達物理日志文件的末端時，新的日志記錄繞回物理日志文件的始端。這個循環(huán)不斷重復，只要邏輯日志的末端不到達邏輯日志的始端v 從 MinLSN到日志末端的日志文件部分稱為日志的活動部分。這是進行數(shù)據(jù)庫完全恢復所需的日志部分v 永遠不能截斷活動日志的任何部分。所有的日志截斷都必須從 MinLSN之前的日志部分進行。發(fā)生截斷操作時，刪除MinLSN之前的虛擬日志內的記錄v 截斷并不減小物理日志文件的大小。而是減小邏輯日志文件的大小并釋放磁盤空間以供重新使用。 SQLServer：事務日志物理構架虛擬日志 1 虛擬日志 2 虛擬日志 3 虛擬日志 4 虛擬日志 5被截斷未使用邏輯日志的始端邏輯日志的末端MinLSN最后一個檢查點虛擬日志 1 虛擬日志 2 虛擬日志 3 虛擬日志 4被截斷邏輯日志的始端邏輯日志的末端MinLSN最后一個檢查點倒數(shù)第二個檢查點簡單恢復模式下的日志截斷v 在簡單恢復模式下，日志截斷將自動執(zhí)行。? 檢查點。包括 CHECKPOINT語句產生的顯式檢查點和系統(tǒng)生成的隱式檢查點? 備份日志v 日志截斷可能會延遲，因為虛擬日志文件由于事務長時間運行而保持活動狀態(tài)，或者因為正在執(zhí)行備份。 為防止日志填滿，數(shù)據(jù)庫需要足夠的日志空間來應對日志截斷可能被延遲的情況。v 簡單恢復模式只記錄在系統(tǒng)崩潰或還原數(shù)據(jù)備份后確保數(shù)據(jù)庫一致性所需的最少信息。與其他恢復模式相比，這最大程度地減少了事務日志空間的空間要求完整恢復模式和大容量日志恢復模式下的日志截斷v 在完整恢復模式或大容量日志恢復模式下，必須備份所有日志記錄以維護 “日志鏈 ”，日志鏈是指具有連續(xù)日志序列號 (LSN)的一系列日志記錄。因此，直到日志備份捕獲所有日志記錄，才能截斷日志的不活動部分。? 備份日志v通常，可以使用定期備份日志來定期釋放日志空間以供將來使用。但是，諸如長時間運行的事務等各種因素也可能會暫時阻止截斷日志。思考v 為什么有時候數(shù)據(jù)庫事務日志滿了，實施了日志備份，卻不能截斷日志？? 有應用系統(tǒng)給 SQLServer發(fā)送了一個用戶自定義事務，一直未提交，這個最早活躍事務阻礙系統(tǒng)截斷日志。? 客戶端向 SQLServer發(fā)送了一個修改數(shù)量大的事務，清日志時，該事務還正在執(zhí)行之中，此事務所涉及的日志只能等到事務結束后，才能被截掉。v 如何處理？? 對于第一種情況，只要督促用戶退出應用或者提交事務，系統(tǒng)管理員便可清掉日志。 ? 對于第二種情況，道理也同上。只是在處理它時，需慎重從事。如果這個大事務已運行較長時間，應盡量想法擴大數(shù)據(jù)庫日志空間，保證該事務正常結束。若該事務被強行回滾， SQLServer需要做大量的處理工作，往往是正向執(zhí)行時間的幾倍，系統(tǒng)恢復時間長，可能會影響正常使用的時間?！　?數(shù)據(jù)庫恢復概述2數(shù)據(jù)的存儲結構3故障的種類4恢復的實現(xiàn)技術5恢復策略6具有檢查點的恢復技術7數(shù)據(jù)庫鏡像8高級的恢復技術9ARIES算法10Sqlserver的恢復技術11小結第七章 數(shù)據(jù)庫恢復技術11小結v 如果數(shù)據(jù)庫只包含成功事務提交的結果，就說數(shù)據(jù)庫處于一致性狀態(tài) 。保證數(shù)據(jù)一致性是對數(shù)據(jù)庫的最基本的要求。v 事務是數(shù)據(jù)庫的邏輯工作單位? DBMS保證系統(tǒng)中一切事務的原子性、一致性、隔離性和持續(xù)性小結（續(xù)）v DBMS必須對事務故障、系統(tǒng)故障和介質故障進行恢復v 恢復中最經常使用的技術：數(shù)據(jù)庫轉儲和登記日志文件v 恢復的基本原理：利用存儲在后備副本、日志文件和數(shù)據(jù)庫鏡像中的冗余數(shù)據(jù)來重建數(shù)據(jù)庫小結（續(xù)）v 常用恢復技術l 事務故障的恢復v按照日志文件對發(fā)生故障的事務所作的更新操作做 UNDO。 整個恢復過程由系統(tǒng)自動完成l 系統(tǒng)故障的恢復v按照日志文件，對在系統(tǒng)故障發(fā)生時已經提交的事務作 REDO ；對故障時還沒有提交的事務作 UNDO。 重新啟動計算機后，整個恢復過程由系統(tǒng)自動完成l 介質故障的恢復v重裝備份并恢復到一致性狀態(tài)后按照日志文件對在介質故障發(fā)生時已經提交的事務作 REDO。 此恢復過程中重裝備份等操作需要人工干預，具體的對事務的 Redo操作也由系統(tǒng)自動完成小結（續(xù)） v 提高恢復效率的技術? 檢查點技術v可以提高系統(tǒng)故障的恢復效率v可以在一定程度上提高利用動態(tài)轉儲備份進行介質故障恢復的效率? 鏡像技術v鏡像 技術可以改善介質故障的恢復效率