DBMS - 資料恢復

崩潰恢復

DBMS是一個高度複雜的系統，每秒執行數百個事務。DBMS的永續性和健壯性取決於其複雜的架構及其底層的硬體和系統軟體。如果它在事務處理過程中出現故障或崩潰，則預計系統會遵循某種演算法或技術來恢復丟失的資料。

故障分類

為了檢視問題發生的位置，我們將故障概括為以下幾類：

事務失敗

當事務無法執行或到達無法繼續執行的點時，它必須中止。這稱為事務失敗，其中只有少數事務或程序受到影響。

事務失敗的原因可能包括：

• 邏輯錯誤 - 事務由於程式碼錯誤或任何內部錯誤條件而無法完成。

• 系統錯誤 - 資料庫系統本身終止活動事務，因為 DBMS 無法執行它，或者由於某些系統條件而必須停止。例如，在死鎖或資源不可用情況下，系統會中止活動事務。

系統崩潰

有一些外部問題可能導致系統突然停止並導致系統崩潰。例如，電源中斷可能導致底層硬體或軟體故障。

示例可能包括作業系統錯誤。

磁碟故障

在技術發展早期，硬碟驅動器或儲存驅動器頻繁出現故障是一個常見問題。

磁碟故障包括壞扇區形成、磁碟不可訪問、磁碟磁頭損壞或任何其他故障，這些故障會破壞所有或部分磁碟儲存。

儲存結構

我們已經描述了儲存系統。簡而言之，儲存結構可以分為兩類：

• 易失性儲存 - 顧名思義，易失性儲存無法在系統崩潰後倖存。易失性儲存裝置放置在非常靠近 CPU 的位置；通常它們嵌入到晶片組本身。例如，主記憶體和快取記憶體是易失性儲存的示例。它們速度快，但只能儲存少量資訊。

• 非易失性儲存 - 這些記憶體能夠在系統崩潰後倖存。它們的資料儲存容量很大，但訪問速度較慢。示例可能包括硬碟、磁帶、快閃記憶體和非易失性（電池備份）RAM。

恢復和原子性

當系統崩潰時，它可能有多個事務正在執行，並且為它們打開了各種檔案以修改資料項。事務由各種操作組成，這些操作本質上是原子的。但根據 DBMS 的 ACID 屬性，必須維護事務整體的原子性，即要麼所有操作都執行，要麼都不執行。

當 DBMS 從崩潰中恢復時，它應該維護以下內容：

• 它應該檢查所有正在執行的事務的狀態。

• 事務可能處於某個操作的中間；在這種情況下，DBMS 必須確保事務的原子性。

• 它應該檢查事務現在是否可以完成，或者是否需要回滾。

• 不允許任何事務使 DBMS 處於不一致狀態。

有兩種技術可以幫助 DBMS 恢復並維護事務的原子性：

• 維護每個事務的日誌，並在實際修改資料庫之前將它們寫入某個穩定儲存。

• 維護影子分頁，其中更改在易失性記憶體中完成，稍後更新實際資料庫。

基於日誌的恢復

日誌是記錄的序列，它維護事務執行的操作記錄。重要的是，日誌應在實際修改之前寫入並存儲在安全可靠的穩定儲存介質上。

基於日誌的恢復的工作方式如下：

• 日誌檔案儲存在穩定的儲存介質上。

• 當事務進入系統並開始執行時，它會寫入有關它的日誌。

<Tn, Start>

• 當事務修改項 X 時，它會寫入如下日誌：

<Tn, X, V1, V2>

它讀取 T_n 已將 X 的值從 V₁ 更改為 V₂。

• 當事務完成時，它會記錄：

<Tn, commit>

可以使用兩種方法修改資料庫：

• 延遲資料庫修改 - 所有日誌都寫入穩定儲存，並在事務提交時更新資料庫。

• 立即資料庫修改 - 每個日誌都跟隨實際的資料庫修改。也就是說，資料庫在每次操作後立即修改。

併發事務恢復

當多個事務並行執行時，日誌會交錯。在恢復時，恢復系統很難回溯所有日誌，然後開始恢復。為了簡化這種情況，大多數現代 DBMS 使用“檢查點”的概念。

檢查點

即時和真實環境中儲存和維護日誌可能會耗盡系統中所有可用的記憶體空間。隨著時間的推移，日誌檔案可能會變得太大而無法處理。檢查點是一種機制，其中所有以前的日誌都從系統中刪除並永久儲存在儲存磁碟中。檢查點宣告一個 DBMS 處於一致狀態之前的點，並且所有事務都已提交。

恢復

當具有併發事務的系統崩潰並恢復時，它的行為如下：

• 恢復系統從末尾反向讀取日誌到最後一個檢查點。

• 它維護兩個列表，一個撤銷列表和一個重做列表。

• 如果恢復系統看到帶有 <T_n, Start> 和 <T_n, Commit> 或僅 <T_n, Commit> 的日誌，它會將事務放入重做列表。

• 如果恢復系統看到帶有 <T_n, Start> 但未找到提交或中止日誌的日誌，它會將事務放入撤銷列表。

然後撤消撤銷列表中的所有事務並刪除它們的日誌。重做列表中的所有事務及其之前的日誌都會被刪除，然後在儲存其日誌之前重做。