DB2 監視器堆疊使用率飆高至 206%？根因診斷與參數調優實戰

健康中心警報響起：「監視器堆疊使用率」於實例層級突破 95% 閾值，實際值高達 206%。這類告警乍看驚人，實則多源於預設配置與實際負載嚴重不匹配。本文從告警現場還原診斷思路，給出精準調優方案。

告警現場還原

健康指標 `db2.mon_heap_util` 顯示監視器堆疊使用率 206%，遠超 95% 警戒線。監視器堆疊（Monitor Heap）用於儲存快照監控、事件監控等運維數據的中繼資訊，本身不直接影響業務 SQL 執行，但耗盡會導致監控功能失效、甚至實例不穩定。

根因定位：預設值過保守

執行 `GET DBM CFG` 檢視參數 `mon_heap_sz`，發現其值僅為 32 頁（4 KB/頁，約 128 KB）。此為 DB2 預設值，設計初衷是節省記憶體，但在任何啟用監控、擁有中等以上併發的生產環境中，這點空間極易在幾分鐘內耗盡，導致使用率數值「爆表」（超過 100% 代表已觸發動態擴展或截斷）。

調優動作與驗證

-- 線上動態調整至 4096 頁（16 MB），無需重啟實例
UPDATE DBM CFG USING MON_HEAP_SZ 4096 IMMEDIATE;

調整後持續觀察 24 小時，使用率穩定於 15%~35% 區間，告警消失。若後續業務增長再觸發告警，可依步驟再增至 8192 或 16384 頁；上限受 `INSTANCE_MEMORY` 或實體記憶體制約。

延伸建議：建立基準線而非單點調整

1. 啟用歷史收集：`UPDATE DBM CFG USING HEALTH_MON ON`，配合 `db2pd -dbptnmem` 定期導出記憶體佔用趨勢圖。
2. 關聯參數聯動：`MON_HEAP_SZ` 與 `UTIL_HEAP_SZ`、`APPLICATION_MEMORY` 共享實例記憶體池，調大前須確認總額不超限。
3. 區分「使用率」與「實際壓力」：使用率 > 100% 僅表示曾觸發擴展，若無 `ADM6017W` 錯誤日誌，業務通常無感；但長期高位預示配置不足，應主動擴容。

結語：監視器堆疊告警 90% 以上屬於「預設值不符生產實況」的配置缺陷，而非程式錯誤。DBA 應在部署標準化清單中納入 `MON_HEAP_SZ ≥ 4096`，並建立定期巡檢機制，將被動救火轉為主動治理。