DB2 SQLCODE -964 錯誤：日誌檔案區填滿的根因與三大解決策略

錯誤現象速覽

應用程式拋出 SQLState: 57011、SQLCODE: -964，訊息為「The transaction log for the database is full」（資料庫交易日誌已滿）。此錯誤意味著作用中日誌空間耗盡，資料庫無法再寫入新的交易記錄，導致所有寫入操作（INSERT/UPDATE/DELETE）中斷。

核心成因：日誌空間不足

DB2 採用循環日誌機制，主要日誌檔（Primary Log Files）與次要日誌檔（Secondary Log Files）共同構成日誌空間。當交易量激增、長時間執行的大量交易未提交、或備份/複寫延遲導致日誌無法被循環覆寫時，日誌空間即會耗盡。關鍵配置參數包括：

• LOGFILSIZ：單一檔案大小（單位：4 KB 頁）
• LOGPRIMARY：主要日誌檔數量（預先配置，常駐）
• LOGSECOND：次要日誌檔數量（動態分配，用完釋放）

總日誌空間上限 ≈ (LOGPRIMARY + LOGSECOND) × LOGFILSIZ × 4 KB。

診斷步驟：檢視目前配置

連線資料庫後執行：

db2 "get db cfg for <dbname> | grep -i log"

典型預設輸出範例：

Log file size (4KB)          (LOGFILSIZ) = 1024      (每檔 4 MB)
Number of primary log files  (LOGPRIMARY) = 3
Number of secondary log files (LOGSECOND) = 1

此配置總空間僅 (3+1) × 4 MB = 16 MB，極易滿載。

三大解決策略（可單獨或組合使用）

策略一：調大單一檔案大小 (LOGFILSIZ)

適合：日誌寫入吞吐量高，欲減少檔案切換開銷。

db2 "update db cfg for <dbname> using LOGFILSIZ 4096"

將檔案從 4 MB 增至 16 MB（4096 × 4 KB）。修改後需重新啟動資料庫生效（db2 deactivate db <dbname> → db2 activate db <dbname>）。

策略二：增加主要日誌檔數量 (LOGPRIMARY)

適合：穩定提高基礎日誌容量，避免頻繁動態分配次要檔案的效能抖動。

db2 "update db cfg for <dbname> using LOGPRIMARY 6"

由 3 增至 6，基礎容量倍增。同樣需重啟資料庫生效。

策略三：增加次要日誌檔數量 (LOGSECOND)

適合：應對偶發性交易尖峰，平時不佔用空間，尖峰時動態擴展。

db2 "update db cfg for <dbname> using LOGSECOND 10"

由 1 增至 10，提供彈性緩衝。此參數即時生效，無需重啟資料庫，風險最低、操作最便利。

參數調整決策指引

長期預防措施

1. 啟用自動維護：配置 AUTO_MAINT、AUTO_DB_BACKUP 確保定期備份釋放日誌空間。
2. 監控日誌使用率：定期查詢 MON_GET_TRANSACTION_LOG 或設定告警，於使用率達 70% 時預警。
3. 避免長交易：拆分大量更新為小批次提交，縮短日誌鎖定時間。
4. 檢查複寫/備份延遲：HADR、Q 複寫、TSM 備份滯後會阻礙日誌循環。

緊急處理 SOP

1. 確認錯誤為 -964（而非 -954 等其他日誌錯誤）。
2. 立即執行 db2 "update db cfg for <dbname> using LOGSECOND 20" 緊急擴容（即時生效）。
3. 觀察應用程式是否恢復正常寫入。
4. 排程維護窗口，進一步調整 LOGFILSIZ/LOGPRIMARY 並重啟資料庫固化配置。
5. 事後複盤：分析交易模式、備份策略、應用程式提交頻率，制定長期容量規劃。

掌握日誌三參數的交互關係，並建立監控與預警機制，即可徹底杜絕 -964 錯誤對業務的衝擊。