數據庫恢復技術

事務的基本概念

①事務

• 事務的概念：
  - 事務是對數據庫的一個操作序列

  • 一個不可分割的工作單位
  • 恢復和並發控制的基本單位

• 事務的定義方式

  • 顯式定義

  

  • 隱式定義

  按照某種規則自動划分

• 事務和程序比較

  • 在關系數據庫中，一個事務可以是一條或多條SQL語句,也可以包含一個或多個程序。
  • 一個程序通常包含多個事務

事務的ACID特性

原子性

　　事務是數據庫的邏輯工作單元，事務中包括的諸操作要么全執行，要么全不執行。

一致性

　　事務執行的結果必須是使數據庫從一個一致性變到另一個一致性狀態。因此當數據庫只包含成功事務提交的結果時，就說數據庫處於一致性狀態。如果數據庫系統運行中發生故障，有些事務尚未完成就被迫中斷，這些未完成事務對數據庫所做的修改有一部分已寫入數據庫中，這時數據庫就處於一種不正確的狀態。

（可以看出，一致性需要由原子性保障）

隔離性

一個事務的執行不能被其他事務干擾。即一個事務的內部操作以及使用的數據對其他並發事務是隔離的，並發執行的各個事務之間不能互相干擾。

持續性

　　持續性也稱永久性，指一個事務一旦提交，它對數據庫中數據的改變就應該是永久性的。接下來的其他操作或故障不應該對其執行結果有任何影響。（例如銀行存錢，存進去就不能變了）

數據庫恢復概述

故障的種類

故障是不可避免的

• 系統故障：計算機軟、硬件故障
• 人為故障：操作員的失誤、惡意的破壞等

事務內部的故障

　　事務內部的故障有的是可以通過事務本身發現的(比如取錢時發現余額不足，事務無法進行)，有的是非預期的（比如事務程序運行過程中的內存滿了，報錯），不能由事務程序處理。
事務故障意味着事務沒有達到預期的終點，因此，數據庫可能處於不正確狀態。恢復程序要在不影響其他事務運行的情況下，強行回滾該事務，即撤銷該事務已經做出的任何對數據庫的修改，使得該事務好像根本沒有啟動一樣。這類恢復操作稱為事務撤銷。

系統故障

　　系統故障是指造成系統停止運轉的任何事件，使得系統要重新啟動。例如，特定類型的硬件錯誤，操作系統故障，DBMS代碼錯誤，系統斷電等。這類故障影響正在運行的所有事務，但不破壞數據庫。
恢復子系統必須在系統重新啟動時讓所有非正常終止的事務回滾，強行撤銷所有未完成事務。有些已完成事務可能有一部分甚至全部留在緩沖區，尚未寫回到磁盤上的物理數據庫中，系統故障使得這些事務對數據庫的修改部分丟失或者全部丟失，這也會使數據庫處於不一致狀態，因此應將這些事務已提交的結果重新寫入數據庫。

恢復方法：

√發生系統故障時，事務未提交。

​ ·恢復策略：強行撤消（UNDO）所有未完成事務

√發生系統故障時，事務已提交，但緩沖區中的信息尚未完全寫回到磁盤上：

​ ·恢復策略：重做（REDO）所有已提交的事務

介質故障

　　系統故障稱為軟故障，介質故障稱為硬故障。硬故障指外存故障，如磁盤損壞、磁頭碰撞、瞬時強磁場干擾等。這類故障將破壞數據庫或部分數據庫，並影響正在存取這部分數據的所有事務。

√裝入數據庫發生介質故障前某個時刻的數據副本

√重做自此時始的所有成功事務，將這些事務已提交的結果重新記入數據庫

計算機病毒

　　總結各類故障，對數據庫的影響有兩種可能性。一是數據庫本身被破壞。二是數據庫沒有被破壞，但數據可能不正確，這時由於事務的運行被非正常終止造成的。

恢復的實現技術

恢復操作的基本原理：冗余

恢復機制涉及兩個關鍵問題：

1.如何建立冗余數據；

2.如何利用這些冗余數據實施數據庫恢復。

建立冗余數據最常用的技術是數據轉儲和登陸日志文件。通常在一個數據庫系統中，這兩種方法是一起使用的。

數據轉儲

數據轉儲是數據庫恢復中采用的基本技術。所謂轉儲即DBA定期將整個數據庫復制到磁帶或另一個磁盤上保存起來的過程。這些備用的數據成為后備副本或后援副本（backup）。

轉儲可以分為靜態轉儲和動態轉儲。

靜態轉儲

在系統中無運行事務時進行的轉儲操作

• 轉儲開始時數據庫處於一致性狀態

• 轉儲期間不允許對數據庫的任何存取、修改活動

• 得到的一定是一個數據一致性的副本

√優點：實現簡單

√缺點：降低了數據庫的可用性

·轉儲必須等待正運行的用戶事務結束

·新的事務必須等轉儲結束

動態轉儲

√轉儲操作與用戶事務並發進行轉儲期間允許對數據庫進行存取或修改

√優點

• 不用等待正在運行的用戶事務結束

• 不會影響新事務的運行

√缺點：不能保證副本中的數據正確有效

√利用動態轉儲得到的副本進行故障恢復

• ·需要把動態轉儲期間各事務對數據庫的修改活動登記下來，建立日志文件

• ·后備副本加上日志文件才能把數據庫恢復到某一時刻的正確狀態

動態轉儲又分為兩類：

• [x] 海量轉儲: 每次轉儲全部數據庫

• [x] 增量轉儲: 只轉儲上次轉儲后更新過的數據

√海量轉儲與增量轉儲比較

·從恢復角度看，使用海量轉儲得到的后備副本進行恢復往往更方便

·但如果數據庫很大，事務處理又十分頻繁，則增量轉儲方式更實用更有效

登記日志文件

日志文件是用來記錄事務對數據庫的更新操作的文件。

日志文件主要有兩種格式：

1. 以記錄為單位的日志文件
2. 以數據塊為單位的日志文件。

√以記錄為單位的日志文件內容

• [x] ·各個事務的開始標記(BEGIN TRANSACTION)

• [x] ·各個事務的結束標記(COMMIT或ROLLBACK)

• [x] ·各個事務的所有更新操作

  √每個日志記錄的內容包括

  • [x] ·事務標識（標明是哪個事務）
  • [x] ·操作類型（插入、刪除或修改）
  • [x]   ·操作對象（記錄內部標識）
  • [x] ·更新前數據的舊值（對插入操作而言，此項為空值）
  • [x]   ·更新后數據的新值（對刪除操作而言, 此項為空值）

√以數據塊為單位的日志文件，每條日志記錄的內容

• [x]          ·事務標識（標明是那個事務）

• [x]          ·被更新的數據塊

日志文件的作用

1. 進行事務故障恢復
2. 進行系統故障恢復
3. 協助后備副本進行介質故障恢復

利用靜態轉儲副本和日志文件進行恢復 ：

基本原則

①登記的次序嚴格按事務執行的時間次序

②必須先寫日志文件，后寫數據庫（很重要）

​ ·寫日志文件操作：把表示這個修改的日志記錄寫到日志文件

​ ·寫數據庫操作：把對數據的修改寫到數據庫中

為什么要先寫日志文件?

·寫數據庫和寫日志文件是兩個不同的操作在這兩個操作之間可能發生故障（就是說日志記錄和羅盤不是原子性的）

·如果先寫了數據庫修改，而在日志文件中沒有登記下這個修改，則以后就無法恢復這個修改了

·如果先寫日志，但沒有修改數據庫，按日志文件恢復時只不過是多執行一次不必要的UNDO操作，並不會影響數據庫的正確性

恢復策略

①事務故障的恢復

√事務故障：事務在運行至正常終止點前被終止

√恢復方法：

·由恢復子系統應利用日志文件撤消（UNDO）此事務已對數據庫進行的修改

·事務故障的恢復由系統自動完成，對用戶是透明的，不需要用戶干預。

1）反向掃描文件日志（即從最后向前掃描日志文件），查找該事務的更新操作（讀操作不需要，因為不影響db內容）

2）對該事務的更新操作執行逆操作。即將日志記錄中“更新前的值” 寫入數據庫

插入操作: “更新前的值”為空，則相當於做刪除操作

刪除操作:“更新后的值”為空，則相當於做插入操作

修改操作：則相當於用修改前值代替修改后值

3）繼續反向掃描日志文件，查找該事務的其他更新操作，並做同樣處理

4）如此處理下去，直至讀到此事務的開始標記，事務故障恢復就完成了。

②系統故障的恢復

√系統故障造成數據庫不一致狀態的原因：

·未完成事務對數據庫的更新已寫入數據庫

·已提交事務對數據庫的更新還留在緩沖區沒來得及寫入數據庫

√系統故障的恢復由系統在重新啟動時自動完成，不需要用戶干預

√恢復方法：

·UNDO故障發生時未完成的事務（撤銷）

·REDO已完成的事務（重做）

1）正向掃描日志文件（即從頭掃描日志文件）

·重做(REDO) 隊列: 在故障發生前已經提交的事務（既有BEGIN TRANSACTION記錄，也有COMMIT記錄）

·撤銷 (Undo)隊列:故障發生時尚未完成的事務（只有BEGIN TRANSACTION記錄）

2)對撤銷(Undo)隊列事務進行撤銷(UNDO)處理

·反向掃描日志文件，對每個UNDO事務的更新操作執行逆操作（即將日志記錄中“更新前的值”寫入數據庫）

3)對重做(Redo)隊列事務進行重做(REDO)處理

·正向掃描日志文件，對每個REDO事務重新執行登記的操作（即將日志記錄中“更新后的值”寫入數據庫）
這兩個一個反向，一個正向，要注意。

③介質故障的恢復

√恢復方法：重裝數據庫，然后重做已完成的事務。

這個故行是比較嚴重的，需要重裝DB

√恢復步驟：

1）裝入最新的后備數據庫副本(離故障發生時刻最近的轉儲副本) ，使數據庫恢復到最近一次轉儲時的一致性狀態。

·對於靜態轉儲的數據庫副本，裝入后數據庫即處於一致性狀態

·對於動態轉儲的數據庫副本，還須同時裝入轉儲時刻的日志文件副本，利用與恢復系統故障的方法（即REDO+UNDO），才能將數據庫恢復到一致性狀態

2）裝入有關的日志文件副本 (轉儲結束時刻的日志文件副本) ，重做已完成的事務。

·首先掃描日志文件，找出故障發生時已提交的事務的標識，將其記入重做隊列。

·然后正向掃描日志文件，對重做隊列中的所有事務進行重做處理。即將日志記錄中“更新后的值”寫入數據庫

√介質故障的恢復需要DBA介入（重裝最近轉儲的數據庫副本和有關的各日志文件副本，執行系統提供的恢復命令）

√具體的恢復操作仍由DBMS完成

具有檢查點的恢復技術

√兩個問題：

·搜索整個日志將耗費大量的時間

·REDO處理：重新執行，浪費了大量時間

√具有檢查點（checkpoint）的恢復技術

·在日志文件中增加檢查點記錄（checkpoint）

·增加重新開始文件

·恢復子系統在登錄日志文件期間動態地維護日志

√檢查點記錄的內容：

              1. 建立檢查點時刻所有正在執行的事務清單

              2. 這些事務**最近一個日志記錄的地址**

√重新開始文件的內容: 記錄各個檢查點記錄在日志文件中的地址

√使用檢查點方法可以改善恢復效率：如果一個事務在檢查點之前提交，則數據庫恢復的時候，就沒必要對這個事務進行REDO操作。

√動態維護日志文件的方法：周期性地執行如下操作：建立檢查點，保存數據庫狀態

√具體步驟：

1）將當前日志緩沖區中的所有日志記錄寫入磁盤的日志文件上

2）在日志文件中寫入一個檢查點記錄

3）將當前數據緩沖區的所有數據記錄寫入磁盤的數據庫中

4）把檢查點記錄在日志文件中的地址寫入一個重新開始文件

√建立檢查點：恢復子系統可以定期或不定期地建立檢查點,保存數據庫狀態

√系統出現故障時，恢復子系統將根據事務的不同狀態采取不同的恢復策略

步驟：

1）從重新開始文件中找到最后一個檢查點記錄在日志文件中的地址，由該地址在日志文件中找到最后一個檢查點記錄.

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（重做）操作

數據庫鏡像

√介質故障是對系統影響最為嚴重的一種故障，嚴重影響數據庫的可用性

·介質故障恢復比較費時

·為預防介質故障，DBA必須周期性地轉儲數據庫

√提高數據庫可用性的解決方案：數據庫鏡像（Mirror）

√數據庫鏡像：

·DBMS自動把整個數據庫或其中的關鍵數據復制到另一個磁盤上

·DBMS自動保證鏡像數據與主數據庫的一致性 , 每當主數據庫

更新時，DBMS自動把更新后的數據復制過去

·沒有出現故障時，數據庫鏡像可用於並發操作，一個用戶對數據加排他鎖修改數據，其他用戶可以讀鏡像數據庫上的數據，而不必等待該用戶釋放鎖

·出現介質故障時，可由鏡像磁盤繼續提供使用，同時DBMS自動利用鏡像磁盤數據進行數據庫的恢復，不需要關閉系統和重裝數據庫副本。

√頻繁地復制數據自然會降低系統運行效率：在實際應用中用戶往往只選擇對關鍵數據和日志文件鏡像，而不是對整個數據庫進行鏡像