DB2 事務日誌機制深度解析：從 Write-Ahead Logging 到崩潰恢復的原理與實踐

當遇到 SQL0946C The transaction log for the database is full 錯誤時，理解事務日誌的核心機制至關重要。本文深入剖析 DB2 事務日誌的架構、寫前日誌 (WAL) 協議、緩衝區刷新機制，以及資料庫崩潰後如何利用日誌實現 重做 與 回滾 達到一致性恢復的完整原理。

事務與 ACID 的基石

事務是一個或多個 SQL 操作序列，具備原子性：全做或全不做。事務邊界由隱式啟動（首條 SQL）、COMMIT（永久生效）或 ROLLBACK（撤銷）定義。未提交的修改對其他連接不可見（除非 UR 隔離級）。

事務日誌記錄的生命週期

1. 記憶體階段：日誌緩衝區

• 資料頁修改先在 緩衝池 進行。
• 同步寫入 日誌緩衝區（大小由 LOGBUFSZ 控制），記錄：INSERT 新值、DELETE 舊值、UPDATE 前後值（通常用 XOR 差異）、COMMIT/ROLLBACK 結束標記。
• 每條記錄綁定唯一 事務 ID，支援多事務交織寫入同一日誌檔。

2. 持久化階段：刷新至磁碟日誌檔

觸發條件（任一即刷新）：

• 緩衝池頁面清理器喚醒
• 日誌緩衝區寫滿
• 事務 COMMIT / ROLLBACK（強制刷新，保證持久性）

此為 Write-Ahead Logging (WAL) 核心：修改資料頁落盤前，對應日誌記錄必須已落盤。最大程度減少崩潰時丟失的日誌量。

3. 外部化：日誌檔案管理

• 循環日誌（預設）：固定數量主日誌檔 (LOGPRIMARY) 循環覆寫，不足時動態分配次日誌 (LOGSECOND)。
• 歸檔日誌 (LOGRETAIN=ON/USEREXIT=ON)：主日誌檔寫滿後不覆寫，改由用戶退出程式歸檔至異地，支援時間點恢復 (PITR)。

崩潰恢復：重做與回滾的雙階段機制

資料庫啟動時若發現非正常關閉，自動執行 Crash Recovery：

階段一：重做 - 向前重放

1. 從最後一個檢查點 (Checkpoint) 開始掃描日誌。
2. 對所有已提交事務的日誌記錄，將修改重新應用至資料頁（即使頁面已落盤，也要重放確保一致性）。
3. 對未提交事務的修改暫不處理。

階段二：回滾 - 向後撤銷

1. 識別崩潰時刻仍處於 作用中 的事務（無 COMMIT/ROLLBACK 記錄）。
2. 逆序讀取其日誌記錄，產生補償操作（INSERT→DELETE, UPDATE→反向 UPDATE, DELETE→INSERT）撤銷修改。
3. 釋放這些事務持有的鎖。

完成後，資料庫進入 交易一致 狀態，所有已提交事務持久化，未提交事務痕跡清除。

關鍵配置參數與最佳實踐

無限活動日誌策略

設定 USEREXIT=YES, LOGSECOND=-1。活動事務可跨越主日誌與歸檔日誌，理論上無日誌空間上限。權衡：回滾與崩潰恢復變慢（需從歸檔抓取日誌），適合超大事務、極高可用性要求場景。

理解 WAL 與雙階段恢復，是排查日誌滿、效能抖動、災難恢復失敗的理論基石。建議 DBA 定期演練 db2dart、db2ckbkp 驗證日誌與備份可用性。