使用 db2look 重建優化器存取計劃（九）：RUNSTATS 並行執行導致的統計不一致與錯誤重現技巧

典型場景：RUNSTATS 允許寫入時的統計時間差

對百萬列資料表執行 RUNSTATS ... ALLOW WRITE ACCESS 並啟用分布統計與索引採樣時，若採樣期間持續有資料寫入，極易產生表統計與索引統計的「時間點不一致」。

具體數值範例

• 開始收集表統計時：表列數 = 1,100,000 → TABLES.CARD = 1,100,000
• 稍後收集主鍵索引統計時：又新增 10,000 列 → 實際列數 = 1,110,000 → INDEXES.FIRSTKEYCARD = 1,110,000

結果：FIRSTKEYCARD (1,110,000) > CARD (1,100,000)，後續在測試環境注入此統計時，UPDATE SYSSTAT.INDEXES 會拋出 SQL1227N rc=8。

修復原則

1. 向下對齊（推薦）：將 FIRSTKEYCARD、FULLKEYCARD、NUMRIDS 降為 1,100,000（等於表 CARD）。
2. 向上對齊：將 TABLES.CARD 提升至 1,110,000（等於索引基數），但需同步調整 NPAGES、FPAGES 等衍生值，風險較高。
3. 原則：索引基數絕不能超過表基數，這是目錄一致性的鐵律。

全面檢查與自動化建議

執行 db2look -m 產出腳本後，務必在測試環境執行前，以腳本或人工檢查所有下列不一致：

• 所有索引的 FIRSTKEYCARD / FULLKEYCARD / NUMRIDS ≤ TABLES.CARD
• 分區表：各分區 CARD 之和 = 表級 CARD
• NLEAF / NLEVELS 與實際索引深度合理
• CLUSTERRATIO / CLUSTERFACTOR 在 [-1, 100] 範圍內
• 各種 AVERAGE_* 欄位非負且邏輯自洽

建議開發「統計一致性預檢工具」，解析 db2look 輸出，自動標記並修正違規行，再寫回乾淨腳本，保證 db2 -tvf db2look.out 零錯誤執行。

進階重現案例：SQL0437W rc=1 警告

現象

生產環境查詢回傳 SQL0437W rc=1（陳述式複雜度超過資源限制），但測試環境不復現。

關鍵檢查點

1. STMTHEAP：測試與生產必須完全一致；若測試較大，優化器可能選擇更複雜計劃而不觸發警告。
2. OPTIMIZATION LEVEL：確認 CURRENT QUERY OPTIMIZATION 設定相同。
3. 其他資源限制參數：MAX_STMT_CONCURRENCY、DB2_OPT_MAX_TEMP_SIZE、DB2_SORT_AFTER_TQ 等登錄變數。

同樣方法可重現 SQL0437W rc=2、SQL0101N、SQL0901N 甚至編譯器/優化器內部斷點（trap/abend）。

利用重現環境進行測試

成功重現問題後，可在不影響生產的前提下：

• 嘗試不同優化等級（SET CURRENT QUERY OPTIMIZATION）
• 開啟/關閉特定登錄變數
• 注入修正後的統計資料觀察計劃變化
• 升級 Fix Pack 驗證是否修復
• 測試索引建議、MQT、MDC 等物理設計變更

結語

db2look 是重現優化器與編譯器問題的終極利器。掌握「收集 → 修正不一致 → 部署 → 驗證 → 實驗」完整流程，能將生產環境的疑難雜症安全轉移至測試環境逐一擊破，極大提升 DBA 調優效率與信心。