DB2 Workload Management 最佳實踐 (下)：閾值管控、高耗查詢治理、並發限制與從 QP/Governor 升級指南

閾值體系：預防性與反應式雙軌制

閾值是 WLM 執行管制的執法者，分兩類：

• 預測性：ESTIMATEDSQLCOST (優化器成本)、ESTIMATEDCARDINALITY，執行前攔截失控查詢。
• 反應式：ACTIVITYTOTALTIME、TEMP_TABLESPACE_USAGE、ROWS_RETURNED、UOWELAPSEDTIME、UOWIDLETIME，執行中動態熔斷。

動作選項：STOP EXECUTION (硬停)、CONTINUE (僅收集診斷資料)、REMAP ACTIVITY (降級至低優先權子類)、FORCE APPLICATION (踢離連線)。

保護系統免於過載：並發佇列閾值

起始建議：

CREATE THRESHOLD QUEUE_LOW_PRIO
FOR SERVICE CLASS LOW_PRIO UNDER POWER
ACTIVITIES ENFORCEMENT DATABASE
WHEN CONCURRENTDBCOORDACTIVITIES > 20
CONTINUE;

視實際負載動態調整。刪除閾值須先 ALTER THRESHOLD ... DISABLE 再 DROP。

治理高耗查詢：成本與時間雙閥門

預測性攔截 (成本閾值)

CREATE THRESHOLD HIGH_COSTS
FOR SERVICE CLASS LOW_PRIO UNDER POWER ACTIVITIES
ENFORCEMENT DATABASE
WHEN ESTIMATEDSQLCOST > 50000000
COLLECT ACTIVITY DATA WITH DETAILS AND VALUES
STOP EXECUTION;

僅針對低優先權類，避免誤傷核心業務。高優先權類可設較寬鬆閾值或僅 CONTINUE 記錄。

反應式熔斷 (執行時間閾值)

CREATE THRESHOLD TOO_LONG
FOR SERVICE CLASS POWER ACTIVITIES
ENFORCEMENT DATABASE
WHEN ACTIVITYTOTALTIME > 60 MINUTES
COLLECT ACTIVITY DATA WITH DETAILS AND VALUES
STOP EXECUTION;

注意：排隊等待時間包含在 ACTIVITYTOTALTIME 內。

限制並發 LOAD 作業：記憶體保護

LOAD 極度消耗記憶體 (UTIL_HEAP_SZ / DATA BUFFER)。建立專屬 Work Class 並在 Database 層級限制並發 = 1：

CREATE WORK CLASS SET LOAD_TYPE (WORK CLASS LOAD_WC WORK TYPE LOAD);
CREATE WORK ACTION SET CONTROL_LOAD FOR DATABASE
USING WORK CLASS SET LOAD_TYPE (
  WORK ACTION LIMIT_LOAD ON WORK CLASS LOAD_WC
  WHEN CONCURRENTDBCOORDACTIVITIES > 1 CONTINUE
);

狀態查詢：WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURRENCES 中 WORKLOAD_OCCURRENCE_STATE 顯示 QUEUED/UOWWAIT/UOWEXEC。

監控高耗查詢：事件監控器 + 歷史分析

建立監控閾值 (不中斷)

CREATE THRESHOLD MONITOREVENT
FOR DATABASE ACTIVITIES ENFORCEMENT DATABASE
WHEN ACTIVITYTOTALTIME > 5 MINUTES
COLLECT ACTIVITY DATA ON ALL WITH DETAILS AND VALUES
CONTINUE;

CREATE THRESHOLD ACTIVCOST
FOR SERVICE CLASS HIGH_PRIO ACTIVITIES ENFORCEMENT DATABASE
WHEN ESTIMATEDSQLCOST > 10000
COLLECT ACTIVITY DATA ON ALL WITH DETAILS AND VALUES
CONTINUE;

同類型多閾值僅觸發一個，避免重複收集。

事件監控器持久化

CREATE EVENT MONITOR WLM_EVENT FOR ACTIVITIES WRITE TO TABLE
  ACTIVITY (TABLE WLM_EVENT IN MONITOR_TS),
  ACTIVITYSTMT (TABLE WLM_EVENT_STMT IN MONITOR_TS),
  ACTIVITYVALS (TABLE WLM_EVENT_VALS IN MONITOR_TS),
  CONTROL (TABLE WLM_EVENT_CONTROL IN MONITOR_TS);

SET EVENT MONITOR WLM_EVENT STATE 1;

常用分析查詢

• Top N 最耗時活動：

  SELECT SUBSTR(APPL_ID,1,26), SUBSTR(CHAR(ACTIVITY_ID),1,10), SUBSTR(APPL_NAME,1,10),
         SUBSTR(ACTIVITY_TYPE,1,10), TIMESTAMPDIFF(2,CHAR(TIME_COMPLETED-TIME_STARTED)) AS TOTALTIME,
         SQLCODE, SUBSTR(SESSION_AUTH_ID,1,8), SUBSTR(SERVICE_SUBCLASS_NAME,1,20)
  FROM WLM_EVENT
  WHERE PARTITION_NUMBER=CURRENT DBPARTITIONNUM
  ORDER BY TOTALTIME DESC FETCH FIRST 10 ROWS ONLY;
  

• 取得完整 SQL 文本：Join WLM_EVENT_STMT 依 APPL_ID, ACTIVITY_ID, UOW_ID。
• 分區級耗時分布：Group by PARTITION_NUMBER 找出資料傾斜分區。

AIX WLM Hard Max 動態調優腳本：緩解剛性限制的副作用

Hard Max 雖保證高優先權 CPU，但低優先權在系統閒置時也被壓制，資源浪費。解法：後台腳本每秒 wlmstat 1 監控高優先權類 CPU 使用率，動態調整低優先權 hardmax：

• 高優先權忙碌 → 低優先權 hardmax=1% (嚴格限制)
• 高優先權閒置 → 低優先權 hardmax=100% (完全釋放)

# auto_tune.sh (root 執行)
wlmstat 1 | gawk -f compute.awk | while read NEWCPUA NEWCPUB; do
  chclass -a inheritance=no -c hardmax=${NEWCPUA} Power.HighPrio
  chclass -a inheritance=no -c hardmax=${NEWCPUB} Power.LowPrio
  wlmcntrl -ud db2workload
done

# compute.awk
BEGIN{prev=0}
/High/{prev=$2; next}
/Low/{
  if (prev=="-" || prev=="0") print "100 100";
  else print "100 1";
  fflush()
}

實測：特殊查詢從 312s 降至 138s (接近獨佔 120s)，低優先權 Q18 僅延遲 100s (1134→1233s)。DPF 環境每節點獨立部署腳本。

附錄：從 Query Patroller (QP) 與 DB2 Governor 升級策略

升級關鍵心法

1. 勿盲目複製 QP 佇列模型：WLM 有服務類優先權、Work Action Set、閾值等更豐富工具，先嘗試資源控制再考慮並發限制。
2. 善用 QP 中繼資料：控制表內的查詢類型、來源、成本分布，是 WLM 初始分類的最佳輸入。
3. 分階段共存：預設用戶服務類 (SYSDEFAULTUSERCLASS) 仍可由 QP 管理，新業務逐步遷移至 WLM 自訂服務類，風險可控。
4. Governor 規則對應：執行時間、回傳行數、閒置時間等反應式規則有 WLM 閾值直接對應；但 Governor 修改即時生效於執行中查詢，WLM 閾值修改僅影響新查詢。

結語

DB2 WLM 以「服務類優先權」為核心，「工作負載/動作集」為分流手段，「閾值」為安全網，「事件監控器」為可觀測基礎，構建完整的工作負載治理體系。配合 AIX WLM Hard Max 動態調優，可在保證核心業務 SLA 前提下最大化資源利用率。升級之路不在工具遷移，而在重新審視業務優先權與資源分配策略。