DB2 故障診斷與最佳實踐：從錯誤碼分類到實例/資料庫/效能/應用四大維度實戰指南

前言

DB2 故障千變萬化，但解決核心只有一條：**精準分類 → 對症下藥 → 預防復發**。本文建立雙軌分類體系：「有無錯誤碼」 與 「故障域範圍」 (實例/資料庫/效能/應用)，並針對各類別給出標準診斷流程、實戰案例與預防性最佳實踐。

分類體系一：按「錯誤碼」分流

A 類：有明確錯誤碼 (SQLCODE / SQLSTATE / Reason Code)

標準處理流：

1. 記錄完整錯誤訊息 (含 SQLCODE、Reason Code、SQLSTATE)
2. 執行 db2 ? SQLxxxx 查閱官方說明
3. 依 Reason Code 採取對應行動
4. 驗證修復，記錄知識庫

實戰案例：代碼頁不相容 (SQL0332N Reason Code 1)

db2 connect to sample
SQL0332N There is no available conversion for the source code page "1386"
to the target code page "819". Reason Code "1". SQLSTATE=57017

診斷：

db2 ? sql0332
# Reason Code 1: source and target code page combination is not supported by the database manager.

修復： 統一用戶端代碼頁

db2set DB2CODEPAGE=1386
db2 terminate
db2 connect to sample
# 連線成功

B 類：無錯誤碼的「隱性故障」

• 資料庫 Hang 住、無回應
• CPU 持續 100%、記憶體暴增
• 查詢極慢但無報錯
• 應用端超時、連線池耗盡

核心工具鏈： db2pd, db2top, db2mon, db2getsnaps, db2trc, OS 層 top/vmstat/iostat/netstat

診斷心法： 由外而內 (OS → 實例 → 資料庫 → 應用)，抓取快照對比基準線，鎖定熱點資源。

分類體系二：按「故障域」深度解析

一、資料庫實例層故障

1. 啟動失敗並返回錯誤碼 (如 SQL1042C)

排查清單：

• 執行 db2iupdt <inst_name> 更新實例 (修補包安裝後必做)
• 檢查檔案權限：實例目錄不可 全部 777，需符合 DB2 權限矩陣
• 核對 db2nodes.cfg 主機名與 hostname 一致
• 檢查共享記憶體/訊號量核心參數 (ipcs -a)

2. db2start 卡住無回應 (Hang)

原因： 上次未正常關閉，殘留共享記憶體/信號量/進程

標準清理序列：

su - <inst_user>
db2_kill          # 釋放共享記憶體/信號量
ipclean           # 清理 IPC 資源 (AIX/Linux)
# 或手動：ps -ef | grep db2 | grep -v grep | awk '{print $2}' | xargs kill -9
su - root         # 如需清理跨用戶 IPC
db2start

3. 實例崩潰 (Crash/Trap)

• 首查 db2diag.log 末段錯誤堆疊
• 檢查 db2dump/ 下 trap 檔案
• 分類：產品缺陷 (搜尋 IBM Knowledge Center/APAR、套用修補包/Interim Fix) vs 環境/操作因素 (交換空間耗盡、進程被 kill、檔案系統滿、硬體錯誤)
• 嚴重崩潰必開 PMR (Problem Management Record) 尋求 IBM 支援

實例層預防清單

• [ ] 修補包安裝後強制 db2iupdt
• [ ] 監控 Paging Space 使用率 < 70%
• [ ] 禁止對實例目錄執行 chmod -R 777
• [ ] 定期檢查 db2nodes.cfg 與 DNS/hosts 一致性

二、資料庫層故障

1. 連線失敗

2. 資料庫損壞

分級應對：

1. 輕度 (可連線、部分表損壞)： EXPORT 正常表 + db2dart /DDEL 導出損壞表資料 → 重建表 → LOAD 還原
2. 重度 (無法連線/啟動)： 唯一路徑 → 從備份恢復 (RESTORE + ROLLFORWARD)
3. 極度 (無備份)： db2dart /DDEL 導出所有資料 → 重建資料庫 → LOAD 還原 (極高風險，資料可能不全)

鐵律： 無備份 = 無恢復。定期驗證備份可用性 (db2ckbkp) 是 DBA 底線。

三、資料庫效能問題

系統化診斷流程：

1. 確認症狀： 特定 SQL 慢? 整體吞吐下降? 並發擁塞?
2. 收集證據： db2getsnaps (完整快照)、db2top (即時)、db2pd -db <db> -transactions -locks -buffers -tablespaces
3. 定位層次：
   • OS: CPU/IO/記憶體/網路瓶頸
   • 配置: 緩衝池、鎖列表、排序堆疊、日誌緩衝
   • SQL: 慢查詢 Top 10、存取計畫、索引缺失、統計過期
   • 應用: 連線池洩漏、大交易、未提交、N+1 查詢
4. 針對性調優： 統計更新 → 索引重建/新增 → SQL 改寫 → 參數調整 → 架構調整 (分區/MDC/叢集)
5. 驗證與基準化： 變更前後對比關鍵指標 (回應時間、吞吐、資源使用率)

效能調優黃金法則

• 測量優於猜測 — 永遠基於快照/監控數據決策
• 統計資訊是優化器的眼睛 — RUNSTATS 定時自動化
• 索引是雙面刃 — 加速讀、拖慢寫，定期 RUNSTATS + REORGCHK 評估
• 鎖等待時間 > 死鎖次數 — 監控 LOCK_WAIT_TIME 而非單純計數

四、應用開發相關故障

故障處理標準化流程 (建議納入 SOP)

1. 記錄： 時間、症狀、錯誤碼、影響範圍、初步動作
2. 分類： 套用本文雙軌分類，確定故障域
3. 診斷： 依對應域清單執行檢查，保留命令輸出為證據
4. 修復： 最小化變更、可回滾、驗證有效
5. 複盤： 根因分析 (5 Whys)、更新知識庫、改善監控/預警、修訂 SOP

結語

DB2 故障處理不是玄學，而是**結構化思維 + 扎實工具鏈 + 經驗沉澱**的工程實踐。建立「有碼查碼、無碼查資源、按域分層、預防優於治療」的團隊文化，才能在關鍵時刻守住資料庫的穩定與可用。