「資料庫日誌滿了怎麼辦？」、「誤刪日誌檔導致資料庫掛了怎麼恢復？」這是 DB2 管理員高頻遇到的噩夢。深入理解日誌原理、合理規劃配置、掌握故障排查方法，是保障生產系統穩定的必修課。
DB2 事務日誌核心原理
- 日誌組成： 記錄所有物件與資料變更。總大小 = `(LOGPRIMARY + LOGSECOND) * LOGFILSIZ`。V9.5 前上限 256GB（`LOGFILSIZ` 最大 262144 頁），V9.5 起支援 512GB（`LOGFILSIZ` 524288 頁）。
- 主/輔助日誌： 主日誌於首次連接或 `ACTIVATE DATABASE` 時預分配；輔助日誌於主日誌不足時動態分配。檔案系統大小必須大於主+輔助日誌總和。
- 兩種模式：
- 循環日誌（預設）： 交易提交後日誌重用。支援崩潰恢復與版本恢復，不支援前滾恢復與線上備份。
- 歸檔日誌： 啟用 `LOGARCHMETH1/2` 或 `LOGRETAIN`（V9.5 棄用）。日誌不刪除，支援前滾恢復與線上備份。
關鍵誤區： 歸檔模式下日誌仍受主+輔助日誌總量限制，活動日誌空間耗盡同樣會拋出「日誌滿」錯誤。
日誌滿故障的兩大典型場景與解決方案
場景一：單一超大交易撐爆日誌空間
徵兆： 執行大量 `INSERT`/`DELETE`/`UPDATE` 時拋 `SQL0964C`，全系統寫入操作凍結，直至交易回滾結束。
排查： 用 `db2pd -db -transactions` 找出 `LogSpace` 佔用極大的 `AppHandl`，再用 `db2pd -applications` 獲取 `L-AnchID`/`L-StmtUID`，最後 `db2pd -dynamic` 定位具體 SQL（如呼叫存儲過程 `proc_testlog`）。
解決策略：
- 拆解大交易： 業務允許時拆分為多個小交易提交。
- 不記錄日誌操作： 用 `LOAD` 替代 `INSERT`、臨時表設 `NOT LOGGED`（需評估 HADR/複寫/前滾恢復影響）。
- 限制單交易日誌佔用： 設定 `MAX_LOG`（單交易可用主日誌百分比）+ `DB2_FORCE_APP_ON_MAX_LOG=TRUE`（超限強制斷開回滾，返回 `SQL1224N`）或 `FALSE`（僅當前語句失敗，返回 `SQL0964N`），保留 `(1-MAX_LOG%)*LOGPRIMARY + LOGSECOND` 空間給日常交易。
注意： `MAX_LOG` 不限制 `BACKUP`/`LOAD`/`REORG ONLINE`/`RESTORE`/`ROLLFORWARD`/`ARCHIVE LOG` 等工具命令。
場景二：長期未提交的小交易阻塞日誌重用
徵兆： `db2pd -transactions` 顯示所有交易 `LogSpace` 很小，但 `db2pd -logs` 發現最早的日誌檔（如 `S0000000.LOG`）因一個 `READ` 狀態的舊交易（`FirstLSN` 落在該檔）無法重用，導致後續日誌分配耗盡。
成因： 應用啟動交易後未提交/回滾（如網路中斷、邏輯錯誤），導致日誌檔長期被鎖定。
解決策略：
- 應用層面： 確保所有交易路徑（含異常分支）必有 `COMMIT`/`ROLLBACK`，避免長連接無操作。
- 資料庫層面： 設定 `NUM_LOG_SPAN` 限制單交易跨越日誌檔數，超限自動中斷交易，釋放日誌空間。配合 `MAX_LOG` 雙重保障。
- 無限活動日誌模式（`LOGSECOND=-1`）下： `MAX_LOG`/`NUM_LOG_SPAN` 尤為關鍵，防止長期運行交易導致活動日誌無限增長、崩潰恢復時間暴增。
補充： 系統臨時表資料操作不記日誌，但定義記少量日誌，長期未提交的臨時表定義同樣可能佔用日誌。
日誌使用量評估實戰技巧
用 `db2pd -transactions` 觀察 `LogSpace` 與 `SpaceReserved` 變化，估算單筆 `INSERT` 日誌開銷（例：首筆 ~700 位元組，同交易後續 ~634 位元組/筆）。結合業務峰值交易量，反推所需日誌總量：`總日誌 = 單交易日誌 * 並發大交易數 + 日常交易預留`。
最佳實踐總結
- 預設改用歸檔日誌模式，配置自動歸檔至遠端存儲。
- 依據評估結果設定 `LOGPRIMARY`、`LOGSECOND`、`LOGFILSIZ`，確保檔案系統容量 > 2倍日誌總量。
- 啟用 `MAX_LOG`（建議 80-90）與 `DB2_FORCE_APP_ON_MAX_LOG=TRUE`，防單一交易癱瘓系統。
- 設定 `NUM_LOG_SPAN`（建議 50-100），防長期掛起交易阻塞日誌循環。
- 監控 `db2pd -logs` 確保 `Current Log Number` 穩步推進，無長期卡住的舊日誌檔。
- 定期演練前滾恢復，驗證歸檔日誌完整性與可用性。
掌握日誌原理、預設防護參數、建立監控告警，才能從「被動救火」轉為「主動掌控」，守護核心資料系統穩健運行。
