Oracle UNDO LOG 日誌回放機制深度解析：從原理到 Checkpoint 實作

問題背景

資料庫崩潰重啟時，必須確保「已提交交易持久化」、「未提交交易回滾」。UNDO LOG 記錄了資料修改前的舊值，回放過程需從後向前掃描，直到找到 COMMIT 點。但多併發交易環境下，COMMIT 點不止一個，如何定義回放邊界？

可行方案對比

方法一：全量掃描回放

• 從日誌尾部向前掃描，對每個未提交交易執行回滾。
• 缺點： 必須掃描所有歷史日誌，恢復時間不可控，生產環境不可接受。

方法二：Checkpoint（檢查點）機制 —— 生產環境標準做法

Checkpoint 如同一道「大柵欄」，將恢復邊界固化：

1. CREATE_CKPT(T1,T2,...,Tn)：記錄目前所有進行中（未提交）的交易 ID。
2. 等待 T1~Tn 全部完成（提交或回滾）。此期間新交易繼續寫日誌，不納入本 Checkpoint。
3. END_CKPT：標記「柵欄建立前的所有狀態已一致」。

日誌回放演算法（採用 Checkpoint）

從日誌尾部向前掃描：
  IF 先遇到 END_CKPT：
     -- 代表 CREATE_CKPT 中記錄的交易已全部完成
     僅需回放至 CREATE_CKPT 處，之前日誌可丟棄
  ELSE IF 先遇到 CREATE_CKPT：
     -- 代表記錄中的交易可能尚未完成
     為保證 Global Serializability，
     回滾至 T1~Tn 中最早開始的那筆交易之前
     （因為該交易之前的所有資料已確保 COMMIT）

關鍵優勢

• 恢復時間有界： 僅需回放最近一個 Checkpoint 之後的日誌量。
• 並發友善： 新交易不阻塞 Checkpoint 推進，舊交易自然完成即可。
• 實作簡潔： 只需在日誌中寫入兩條記錄（CREATE/END），無需鎖定整個系統。

Oracle 實際運作補充

• Oracle 採用增量 Checkpoint（DBWn 定期將髒緩衝區寫入資料檔），並配合 LOG_CHECKPOINT_INTERVAL、LOG_CHECKPOINT_TIMEOUT、FAST_START_MTTR_TARGET 參數控制恢復時間目標（MTTR）。
• 檢查點資訊記錄於控制檔與線上重做日誌標頭，啟動時由 SMON 讀取決定恢復起點。

結語

UNDO LOG 回放的核心難題在於「如何在併發環境下劃定一致性邊界」。Checkpoint 機制以極低成本解決此問題，是現代關聯式資料庫實現快速崩潰恢復的基石。理解其原理，有助於 DBA 調整 Checkpoint 相關參數，平衡「正常運作效能」與「故障恢復速度」。