數據庫——恢復技術
目錄sql
1、數據庫恢復概述數據庫
1.1故障分類安全
1.1.2系統故障spa
1.1.3介質故障操作系統
2、基於日誌的恢復技術code
2.1日誌對象
2.1.1日誌記錄的格式blog
1、數據庫恢復概述
DBMS的子恢復系統必須確保故障發生後可以把數據庫恢復到某種一致狀態，最大限度地下降損失，並將崩潰後的數據庫不能使用的時間減少到最小
1.1故障分類
1.1.1事務故障
某個事務在運行過程當中因爲種種緣由未能運行到正常終止而夭折
兩種錯誤致使事務執行失敗
- 程序的邏輯錯誤
- 系統錯誤
1.1.2系統故障
因爲某種緣由形成整個系統的正常運行忽然中止，導致全部正在運行的事務都以非正常方式終止
產生緣由
- 操做系統或 DBMS代碼錯誤
- 操做員操做失誤
- 特定類型的硬件錯誤（CPU故障）
- 忽然停電等
1.1.3介質故障
存儲數據庫的存儲設備故障
產生緣由
- 磁盤損壞
- 磁頭碰撞
- 操做系統的某種潛在錯誤
- 瞬時強磁場干擾等
1.2恢復的基本思想
在系統正常運行時創建冗餘數據，保證有足夠的信息可用於故障恢復。故障發生後採起措施，將數據庫內容恢復到某個一致性狀態，保證事務原子性和持久性
數據庫系統主要經過登記日誌和數據轉儲創建冗餘數據
利用冗餘數據進行故障恢復考慮因素
- 存儲器性質
- 事務的更新什麼時候寫入數據庫
- 緩衝
2、基於日誌的恢復技術
2.1日誌
日誌是日誌記錄的序列，記錄了數據庫中全部的更新活動
2.1.1日誌記錄的格式
一條更新日誌記錄了一個事務對數據庫的一次 write操做，包括
- 事務標識符
- 操做類型
- 操做對象
- 舊值
- 新值
<Ti,start> --事務Ti開始 <Ti,Xj,V1,V2> --事務Ti對 Xj的一次更新，其中 V1是舊值，V2是新值。對於插入，V1爲空；對於刪除，V2爲空 <Ti,commit> --事務Ti正常提交 <Ti,abort> --事務Ti異常終止
2.1.2登記日誌的原則
日誌記錄必須嚴格按併發事務執行的時間次序登記
必須先記日誌，後寫數據庫
2.1.3 redo和 undo
redo(Ti) 根據日誌記錄，按登記日誌的次序，將事務 Ti每次更新的數據對象的新值用 write操做從新寫到數據庫（不是從新執行事務 Ti）
undo(Ti) 根據日誌記錄，按登記日誌的相反次序，將事務 Ti每次更新的數據對象的舊值用 write操做寫回數據庫
redo和 undo都是冪等的，執行屢次等價於執行一次
2.2延遲更新技術
延遲更新將事務對數據庫的更新推遲到事務提交以後
遵循規則
- 每一個事務在到達提交點以前不能更新數據庫
- 在一個事務的全部更新操做的日誌記錄寫入穩定存儲器以前，該事務不能到達提交點
2.2.1基於延遲更新技術的事務故障恢復
事務 Ti發生故障時，Ti未到達提交點，所以Ti的更新操做都登記在日誌中，並未輸出到數據庫
當事務 Ti發生故障時，只需清除日誌中事務 Ti的日誌記錄，而無須對數據庫自己作進一步處理。若是故障不是事務Ti自己的邏輯錯誤，則事務Ti能夠在稍後從新啓動
2.2.2基於延遲更新技術的系統故障恢復
一、正向掃描日誌文件，創建兩個事務列表。一個是已提交事務列表，包含全部具備日誌記錄 <Ti,commit>的事務 Ti；另外一個是未提交事務列表，包含全部具備日誌記錄 <Tj,start>但不具備日誌記錄 <Tj,commit>的事務Tj
二、對已提交事務列表的每一個事務 Ti執行 redo(Ti)：正向掃描日誌文件，對於每一個形如 <Ti,Xj,V1,V2>的日誌記錄，若是 Ti在已提交事務列表中，則將 Xj=V2寫到數據庫中
2.3即時更新技術
即時更新技術容許事務在活躍狀態時就將更新輸出到數據庫當中
處於活動狀態的事務直接在數據庫上實施的更新稱爲非提交更新
遵循規則
- 在日誌記錄 <Ti,Xj,V1,V2>安全地輸出到穩定存儲器以前，事務 Ti不能用 Xi=V2更新數據庫
- 在全部 <Ti,Xj,V1,V2>類型日誌記錄安全地輸出到穩定存儲器以前，不容許事務 Ti提交
2.3.1基於即時更新技術的事務故障恢復
事務 Ti發生故障時，它可能已經將某些更新輸出到數據庫，所以必須執行 undo(Ti)
反向掃描日誌文件直到遇到 <Ti,start>，對於每一個形如 <Ti,Xj,V1,V2>的日誌記錄，將 Xj=V1寫到數據庫當中
2.3.2基於即時更新技術的系統故障恢復
一、正向掃描日誌文件，創建兩個事務列表。一個是已提交事務列表，包含全部具備日誌記錄 <Ti,commit>的事務 Ti；另外一個是未提交事務列表，包含全部具備日誌記錄 <Tj,start>但不具備日誌記錄 <Tj,commit>的事務Tj
二、對未提交事務列表的每一個事務 Ti執行 undo(Ti)：反向掃描日誌文件直到遇到未提交事務列表每一個事務 Tk的 <Tk,commit>，對於每一個形如 <Ti,Xj,V1,V2>的日誌記錄，若是 Ti在未提交事務列表中，則將 Xj=V1寫到數據庫中
三、對已提交事務列表的每一個事務 Ti執行 redo(Ti)：正向掃描日誌文件，對於每一個形如 <Ti,Xj,V1,V2>的日誌記錄，若是 Ti在已提交事務列表中，則將 Xj=V2寫到數據庫中
3、基於檢查點的恢復技術
3.1檢查點
提升系統故障恢復效率的基本方法是使用檢查點技術
假設系統在時刻 Tc設立最後一個檢查點，在時刻 Tf發生系統故障，如圖能夠把事務分爲五類
- T1：在檢查點以前提交
- T2：在檢查點以前開始執行，在檢查點以後故障點以前提交
- T3：在檢查點以前開始執行，在故障點時還未完成
- T4：在檢查點以後開始執行，在故障點以前提交
- T5：在檢查點以後開始執行，在故障點時還未完成
3.2基於檢查點的系統故障恢復
當系統故障發生時，首先要從新啓動系統。系統重啓後，恢復子系統自動執行如下步驟
- 獲得最後一個檢查點記錄：找到最後一個檢查點記錄在日誌文件中的地址，取出最後一個檢查點記錄 <checkpoint,L>
- 初始化兩個事務列表 UNDO-LIST（須要執行 undo操做的事務集合）和 REDO-LIST（須要執行 redo操做的事務集合）：將 L中的全部事務都放入 UNDO-LIST，而 REDO-LIST爲空
- 創建兩個事務列表 UNDO-LIST和 REDO-LIST：從最近的檢查點開始，正向掃描日誌文件直到結束，遇到 <Ti,start>就把 Ti加入 UNDO-LIST；遇到 <Ti,commit>就把 Ti從 UNDO-LIST移到 REDO-LIST
- 對 UNDO-LIST中的每一個事務 Ti執行 undo(Ti)：反向掃描日誌文件直到遇到未提交事務列表每一個事務 Tk的 <Tk,commit>，對於每一個形如 <Ti,Xj,V1,V2>的日誌記錄，若是 Ti在未提交事務列表中，則將 Xj=V1寫到數據庫中
- 對 REDO-LIST中的每一個事務 Ti執行 redo(Ti)：正向掃描日誌文件，對於每一個形如 <Ti,Xj,V1,V2>的日誌記錄，若是 Ti在已提交事務列表中，則將 Xj=V2寫到數據庫中
4、介質故障恢復技術
4.1轉儲
將整個或部分數據庫複製到磁帶或另外一個磁盤上，產生數據庫後備副本
後備副本能夠脫機保存，供介質故障恢復時使用
4.1.1靜態轉儲與動態轉儲
從轉儲時是否容許事務運行角度考慮
靜態轉儲是在系統中無運行事務時進行的轉儲；必定獲得一個一致的副本，但下降了數據庫的併發性
動態轉儲容許轉儲操做與用戶事務併發執行，轉儲期間容許事務對數據庫進行存取和更新；不能保證副本中數據的一致性
4.1.2海量存儲與增量存儲
從轉儲時是轉儲整個數據庫仍是部分數據庫角度考慮
海量轉儲製做數據庫的完整副本
增量轉儲只複製上此轉儲後更新過的數據，造成數據庫的增量副本，增量副本不能單獨使用
恢復時，必須使用最後一個完整副本和以後的全部增量副本才能將數據庫恢復到一致狀態
4.2介質故障恢復
當數據庫被破壞時，須要用轉儲的後備副本和日誌進行恢復，這裏只考慮海量轉儲
- 裝入最新的數據庫後備副本，將數據庫恢復到最近一次轉儲時的狀態
- 裝入轉儲後的日誌，redo已完成的事務