數據庫恢復

文章目錄

• 數據庫恢復
• 1. 常見問題
• 2. 恢復
• 2.1 冗餘數據
• 3. 中斷的事務
• 3.1 日誌記錄形式
• 3.1.1 Undo 日誌的恢復
• 3.1.2 Redo 日誌的恢復
• 3.2 Undo|Redo日誌恢復
• 4. 檢查點技術
• 4.1 非靜止檢查點
• 4.1.1 undo
• 4.1.2 redo

數據庫恢復

查詢和更新數據庫時，由於某些問題( ( 故障) ) 發生可能會導致數據庫被破壞或影響數據庫中數據的一致性。

數據庫恢復技術將數據庫從錯誤狀態恢復到某個一致狀態，它是數據庫可靠性的保證。

---

1. 常見問題

1. 事務故障（內部原因）

• 錯誤輸入，運算溢出等

2. 介質故障（物理原因）

• 局部故障，磁盤扇區的奇偶校驗法可檢測
• 嚴重故障（磁盤無法訪問），RAID模式，備份、冗餘分佈
• 磁盤中的數據丟失

3. 系統故障（其他原因）

• OS錯誤、斷電等（外部原因）
• 日誌記錄（分離的、非易失的日誌中記錄數據庫更新，必要時候恢復）
• -主存中的臨時數據丟失

---

2. 恢復

存在系統其他位置的冗餘數據進行恢復

---

2.1 冗餘數據

1. 日誌
2. 數據備份

---

3. 中斷的事務

在數據庫恢復時候，對故障發生時候對已提交的事務進行重做Redo，對未提交的事務進行撤銷Undo，保證所有事物的原子性。
所以，恢復處理中第一個任務就是將所有的事物劃分爲已提交事務和未提交事務。

事務具有ACID四個性質，其中原子性。
日誌是一個日誌記錄的序列，每個日誌記錄會記錄事務的操作（開始、更新、提交和中止等），所以日誌的體量很大。

---

3.1 日誌記錄形式

事務開始
事務提交
事務撤銷
事務撤銷
undo日誌中的更新：<T, Y, OldV>
redo日誌中的更新：<T, Y, NewV>
T：表示事務 ，X：數據元素

---

3.1.1 Undo 日誌的恢復

做完事務T之前沒做完的操作（事務T在commit或Abort之前的操作），然後進行事務撤銷。

如果事務T 的Commit 日誌記錄已到達磁盤，該事務一定已經完成

1. 對每一個更新操作都生成一條undo 日誌記錄
2. 如果事務改變了數據庫元素x ， 那麼日誌記錄必須在x 的新值寫回磁盤之前寫到磁盤 (write ahead logging, WAL) ；
3. 如果事務提交，則其Commit 日誌記錄必須在事務改變的所有數據庫元素已寫到磁盤後再寫磁盤。

---

Redo操作：

1. 反向掃描日誌文件 ，確認未完成的事務集合S ，即有<Ti, start> ，但沒有<Ti, commit> ( 或<Ti, abort>)
   日誌記錄的事務集合
2. 在掃描過程中，對每一條日誌記錄<Ti, X, v> 做:
   (1) 如果Ti $\in$∈ S ，則 write (X, v) output (X) ;
3. 對每一個事務Ti $\in$∈ S ，增加<Ti, abort> 日誌記錄
4. 刷新日誌，即Flush Log

Flush Log

• 任務：讓緩衝區管理器 強制 將發生了修改的日誌記錄 寫到磁盤

---

3.1.2 Redo 日誌的恢復

只要日誌中沒有<commit, T> 記錄，那麼事務T 對數據庫所做的更新就都沒有寫到磁盤上。

Redo日誌規則：

1. 對每個事務中的更新操組都產生一條redo 日誌記錄( 包含新值，形如<Ti, X, newvalue> )
2. 在修改磁盤上的任何數據庫元素x 之前，要保證所有與x 的這一修改相關的日誌記錄，包括 記錄，都必須先寫到磁盤。
3. 提交時同時刷新日誌，即Flush Log 。
4. 在數據庫被刷新後，增加一條<Ti, end>

---

Redo操作：

1. 正向掃描日誌文件 ，確認已提交的事務集合S ，即在日誌中有<Ti, commit> ( 但沒有<Ti, end>) 日誌記錄的事務集合
2. 在掃描過程中，對每一條日誌記錄<Ti, X, v> 做:
   (1) 如果Ti $\in$∈ S 則 Write(X, v), Output(X)
3. 對每個Ti $\in$∈ S, 增加日誌記錄<Ti, end>
4. 刷新日誌，即Flush Log

---

3.2 Undo|Redo日誌恢復

• 正向掃描日誌，確定已提交事務集合 和 未提交事務集合；
• 反向掃描日誌，Undo所有未提交事務；
• 正向掃描日誌，Redo所有已提交的事務。

---

4. 檢查點技術

每次恢復都檢查整個日誌好浪費時間哦，又不是所有的事務都需要重新處理，事務只要在日誌上有commit的記錄，那就不需要處理它了嘛。

怎麼搞？？？

週期性的在日誌上做標記（檢查點），檢查點之前的日誌記錄在恢復的時候就不用管了嘛！！！

• 所有在檢查點之前執行的事務都已經完成，並寫回磁盤。恢復時不需要撤銷。
• 在恢復中，確定所有未完成事務的處理，只需反向掃描日誌至發現 記錄時止。

---

4.1 非靜止檢查點

簡單的檢查點技術在效果上相當於在進行檢查點是必須關閉系統。由於活躍的事務可能需要較長的時間來
提交或中止，在用戶看來系統似乎停止了。

特點：

• 讓系統處於檢查點時仍允許新的事務進入；
• 唯一的代價是恢復時非靜止檢查點前的某些日誌記錄可能需要檢查。

---

4.1.1 undo

步驟：

• 寫入日誌記錄<Start CKPT(T1,…,Tk)> ，其中T1,…,Tk 爲所有活躍事務的標識。
• 等待T1,…,Tk 中的每一個提交或中止，但允許其他事務開始。
• 當T1,…,Tk 都完成時，寫入日誌記錄<END CKPT> 並刷新日誌

---

4.1.2 redo

特有問題：Redo 日誌中被修改的數據寫到磁盤的時間可能比事務提交的時間晚得多。

定期進行數據備份