確定在工作負載定義中使用的連接屬性
您可以通過使用 DB2 工作負載管理器表函數確定定義連接到數據庫的每個應用程序的工作負載對象的連接屬性。例如：
SELECT COUNT(*) COUNT, SUBSTR(APPLICATION_NAME, 1, 10) APPLNAME,
SUBSTR(SYSTEM_AUTH_ID,1,10) SYSTEM_USER ,
SUBSTR(SESSION_AUTH_ID,1,10) SESSION_ID ,
SUBSTR(CLIENT_USER,1,10) CLIENT_USER,
SUBSTR(CLIENT_WRKSTNNAME,1,21) CLIENT_WRKSTNNAME ,
SUBSTR(CLIENT_ACCTNG,1,10) CLIENT_ACCTNG,
SUBSTR(CLIENT_APPLNAME,1,10) CLIENT_APPLNAME
FROM TABLE(WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURRENCES('', '', -
2)) A
GROUP BY
APPLICATION_NAME, SYSTEM_AUTH_ID, SESSION_AUTH_ID ,
CLIENT_WRKSTNNAME, CLIENT_ACCTNG, CLIENT_USER, CLIENT_APPLNAME;
這個查詢返回的輸出顯示當前運行的應用程序的數量和以下連接屬性，這些連接屬性可也用於以下 DB2 工作負載定義：APPLNAME （應用程序名）、SYSTEM_USER （系統授權 ID ）、SESSION_ID （會話授權 ID ）、CLIENT_USER （客戶機用戶 ID ）、CLIENT_WRKSTNNAME （客戶機工作站名）、CLIENT_ACCTNG （客戶機帳戶字符串） 和 CLIENT_APPLNAME （客戶機應用程序名）。
COUNT APPLNAME SYSTEM_USER SESSION_ID CLIENT_USER
CLIENT_WRKSTNNAME CLIENT_ACCTNG CLIENT_APPLNAME
----- -------- -------- -------- ----------- ------
--------- --------- ------------
501 db2batch DB2INST3 DB2INST3 - -
- -
1 db2bp DB2INST3 DB2INST3 nela
appl#1.torolab.ibm.c 123-456 boss
2 record(s) selected.
要完成一個特定用戶的連接屬性列表，發送一個如下查詢，該查詢返回用戶 DB2INST3 的 SESSION_USER GROUP （用戶組）和 SESSION_USER ROLE （用戶角色名）。
SELECT GROUP as “SESSION_USER GROUP” FROM TABLE
(SYSPROC.AUTH_LIST_GROUPS_FOR_AUTHID('DB2INST3')) AS T;
SELECT ROLENAME as “SESSION_USER ROLE” FROM
TABLE(SYSPROC.AUTH_LIST_ROLES_FOR_AUTHID ('DB2INST3','U')) AS T;
應用程序可以使用 WLM_SET_CLIENT_INFO 流程設置客戶機信息屬性，以便記錄當前在 DB2 數據服務器上使用該連接的應用程序或最終用戶的身份，如果沒有其他可區分的連接屬性可用，則這個身份是必須的。
例如，以下語句設置此前檢索到的應用程序識別信息：
CALL SYSPROC.WLM_SET_CLIENT_INFO('nela',
'appl#1.torolab.ibm.com', 'boss', '123-456', 'AUTOMATIC');
一旦您已經識別了在您的數據服務器上運行的工作，根據應用程序和用戶的類型和業務優先權將它們劃分為不同的組。在一個數據倉儲環境中，以下示例小組可能適用：
日常報告查詢——通過系統授權 ID 這樣的連接屬性識別。
特殊的或復雜的查詢——通過客戶機用戶 ID 或應用程序名識別。
用於實時數據倉庫的 ETL 作業——通過應用程序名識別。
通過優先權設置獲取一致的響應時間
響應時間的一致性在數據倉庫環境中很關鍵。在服務級別協議生效的地方，響應時間可能是強制性的。
通常，至少有兩個用戶或應用程序組存在於一個數據倉庫環境中，一個“輕型”小組運行擁有較短運行時間並需要較少資源（比如日常報告）的簡單或至多是中度程度開銷的查詢，一個“重型”或高級用戶小組運行需要較多資源的復雜的特殊查詢。有些用戶可能獲准提交其他關鍵查詢，這些查詢（有時稱為“VIP ”或“CEO ”查詢）擁有比其他工作更高的優先權。
一個服務類的優先權需要與其他服務類的優先權相比較，以便確定資源分配。為了確保短期和關鍵查詢擁有一致的響應時間，允許這些查詢在一個具有更高優先權的獨立服務類中執行。將由高級用戶提交的復雜查詢放置到一個具有較低優先權的獨立服務子類中。
首先，創建一個帶有兩個子類的服務類，然後創建兩個識別較重要和較不重要的應用程序或用戶的工作負載。將這些工作負載分配給兩個不同的服務子類：
CREATE SERVICE CLASS POWER;
CREATE SERVICE CLASS LOW_PRIO UNDER POWER;
CREATE SERVICE CLASS HIGH_PRIO UNDER POWER;
CREATE WORKLOAD HIGH_PRIO APPLNAME('db2bp') SYSTEM_USER
('DB2INST3') SERVICE CLASS HIGH_PRIO UNDER POWER;
CREATE WORKLOAD LOW_PRIO APPLNAME('db2batch') SERVICE CLASS
LOW_PRIO UNDER POWER;
GRANT USAGE ON WORKLOAD HIGH_PRIO TO PUBLIC;
GRANT USAGE ON WORKLOAD LOW_PRIO TO PUBLIC;
在每個語句後提交或使用自動提交命令。應用程序名區分大小寫，用戶名必須用大寫字母指定。
下面，將可能的最高優先權分配給 HIGH_PRIO 服務子類中的應用程序。您可以分配代理優先權和預取優先權。
ALTER SERVICE CLASS HIGH_PRIO UNDER POWER AGENT PRIORITY -20
PREFETCH PRIORITY HIGH;
將可能的最低優先權分配給 LOW_PRIO 服務子類中的應用程序。
ALTER SERVICE CLASS LOW_PRIO UNDER POWER AGENT PRIORITY 20
PREFETCH PRIORITY LOW;
不屬於 LOW_PRIO 或 HIGH_PRIO 工作負載的應用程序被映射到默認工作負載，從而映射到默認用戶服務類 SYSDEFAULTUSERCLASS ，該類已經被保留為默認優先權（PREFETCH PRIORITY MEDIUM 和 AGENT PRIORITY 0 ）。
要確保系統工作在用戶工作之前執行，將系統服務類的代理優先權設置為等同於或高於您為用戶服務類設置的最高優先權。
ALTER SERVICE CLASS SYSDEFAULTSYSTEMCLASS AGENT PRIORITY -20
PREFETCH PRIORITY HIGH;
如果您在創建或更改工作負載管理對象後想要查看當前 DB2 工作負載管理設置，檢查系統目錄或使用 db2look 命令。例如，以下命令創建一個 wlm.definitions.out 輸出文件，該文件包含數據庫 PROD 的當前 DB2 工作負載管理設置。
db2look -d PROD -wlm -o wlm.definitions.out
定義工作操作集以區分工作類型
如果用戶定義的工作負載中出現不同的工作類型，您可以使用工作操作集來區分這些工作類型並對它們區別對待，如 “DB2 服務類”小節的圖 2 和圖 3 所示。
要使用工作操作集，可以使用以下語句將工作負載分配給一個服務超類而不是一個子類：
CREATE WORKLOAD ALL_PRIO APPLNAME('db2bp') SYSTEM_USER
('DB2INST3') SERVICE CLASS POWER;
要區分短期、中期和長期工作，創建一個定義工作類型標准的工作類型組。例如，對於 READ 類型，使用 timerons 中通過優化程序估計的查詢成本：
CREATE WORK CLASS SET control_cost
(WORK CLASS long
WORK TYPE READ FOR TIMERONCOST FROM 2000001 To UNBOUNDED,
WORK CLASS medium
WORK TYPE READ FOR TIMERONCOST FROM 20001 TO 2000000,
WORK CLASS short
WORK TYPE READ FOR TIMERONCOST FROM 0 TO 20000);
現在，您可以使用這個工作類組創建一個工作操作集以將該工作映射到 POWER 超類的 HIGH 、MEDIUM 和 LOW 優先權子類。
CREATE WORK ACTION SET query_cost FOR SERVICE CLASS POWER
USING WORK CLASS SET control_cost
(WORK ACTION MAP_LONG ON WORK CLASS long
MAP ACTIVITY TO LOW_PRIO,
WORK ACTION MAP_SHORT ON WORK CLASS short
MAP ACTIVITY TO HIGH_PRIO);
您還可以使用相同的工作類組來限制開銷高的工作類型的並發性（類似於 Query Patroller 方法，只在數據庫級別可行）：
CREATE WORK ACTION SET query_concur FOR DATABASE
USING WORK CLASS SET control_cost
(WORK ACTION limit_long ON WORK CLASS long
WHEN CONCURRENTDBCOORDACTIVITIES > 2 CONTINUE,
WORK ACTION limit_medium ON WORK CLASS medium
WHEN CONCURRENTDBCOORDACTIVITIES > 10 CONTINUE,
WORK ACTION no_limit_short ON WORK CLASS short COUNT ACTIVITY);
集成 AIX Workload Manager
在下一個示例中，DB2 工作負載服務類被直接映射到 AIX Workload Manager (WLM) 類，以便集成 DB2 工作負載管理和 AIX WLM 。上述映射完成後，DB2 數據服務器將忽略 DB2 服務類的代理優先權設置。要將此前創建的 DB2 服務類映射到 AIX WLM 類（將在稍後定義），發出以下語句（這個步驟也可以作為原始 CREATE 語句的一部分）：
ALTER SERVICE CLASS POWER OUTBOUND CORRELATOR 'Power';
ALTER SERVICE CLASS LOW_PRIO UNDER POWER AGENT PRIORITY DEFAULT
OUTBOUND CORRELATOR 'Power.LowPrio';
ALTER SERVICE CLASS HIGH_PRIO UNDER POWER AGENT PRIORITY DEFAULT
OUTBOUND CORRELATOR 'Power.HighPrio';
ALTER SERVICE CLASS sysdefaultsystemclass agent PRIORITY DEFAULT
OUTBOUND CORRELATOR 'DefSystem';
為了更好地監控，將所有默認 DB2 服務類映射到 AIX WLM 類：
ALTER SERVICE CLASS "SYSDEFAULTMAINTENANCECLASS" OUTBOUND
CORRELATOR 'DefMaint';
ALTER SERVICE CLASS "SYSDEFAULTUSERCLASS" OUTBOUND CORRELATOR
'DefUser';
您必須擁有根級別用戶特權才能配置和啟用 AIX WLM 。
首先，激活正確的 AIX WLM 配置或創建一個新的 AIX WLM 配置。要創建一個稱為 db2workload 的新 AIX WLM 配置，發出以下命令（或使用可以完成相同任務的工具）：
cp -r /etc/wlm/template /etc/wlm/db2workload
AIX WLM 的當前配置是由符號鏈接 /etc/wlm/current 指向的目錄中的配置。要使 /etc/wlm/db2workload 成為當前配置，發出以下命令：
wlmcntrl -d db2workload
這個命令更新 /etc/wlm/current 符號鏈接為指向 /etc/wlm/ db2workload 並啟動 AIX WLM 。
要匹配此前創建的 DB2 工作負載對象，必須創建一個 AIX WLM 類 db2Power 和兩個子類 db2HighPrio 和 db2LowPrio 。
這些對象將分別映射到 DB2 服務子類 HIGH_PRIO 和 LOW_PRIO 。
mkclass db2Power
mkclass db2Power.HighPrio
mkclass db2Power.LowPrio
mkclass db2DefSystem
為使 AIX Workload Manager 接受出站關聯器（correlator ），定義應用程序標記。這些應用程序標記確保這些 DB2 服務類自動分配到相關的 AIX 類。要定義應用程序標記，為 AIX 超類和子類編輯適當的規則文件並將新的出站關聯器添加為應用程序標記。
編輯後，應用到超類的規則文件如下所示：
/etc/wlm/db2workload vi rules
* IBM_PROLOG_BEGIN_TAG
* This is an automatically generated prolog.
*
* bos530 src/bos/etc/wlm/rules 1.2
*
* Licensed Materials - Property of IBM
*
* (C) COPYRIGHT International Business Machines Corp. 1999,2002
* All Rights Reserved
*
* US Government Users Restricted Rights - Use, duplication or
* disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
*
* IBM_PROLOG_END_TAG
* class resvd user group application type tag
System - root - - - -
db2Power - - - - - Power
db2Power - - - - - HighPrio
db2Power - - - - - LowPrio
db2DefSystem - - - - - DefSystem
db2DefUser - - - - - DefUser
db2DefMaint - - - - - DefMaint
Default - - - - - -
總是將上面列示的 System 類保留為用戶定義類，以便系統進程被映射到它們的默認服務類。另外，將下面列示的 Default 用戶類保留為用戶定義類。
應用到 db2Power 超類的子類的規則文件如下所示：
/etc/wlm/bcutest/db2Power> vi rules
* class resvd user group application type tag
HighPrio - - - - - Power.HighPrio
LowPrio - - - - - Power.LowPrio
使用 wlmcntrl 命令更新帶有這個配置的 AIX Workload Manager 的定義。
wlmcntrl -ud db2workload
AIX WLM 啟動後，您的數據服務器上的任何工作將自動分配到適當的 AIX WLM 類。
現在 AIX WLM 環境已經設置好，通過兩種方法設置 DB2 工作負載的優先權：通過使用共享分配相對值，或者通過使用硬限制分配絕對值。共享提供一個更靈活的方法，因為不同類之間的資源分配可能變化很大。如果您擁有嚴格的優先權要求，則選擇硬限制。對於共享或限制，您可以稍後動態修改 AIX WLM 配置。
要使用共享為每個 AIX 類設置處理器優先權，發出以下命令：
chclass -c shares=90 db2Power.HighPrio
chclass -c shares=10 db2Power.LowPrio
或者，要限制使用硬限制的低優先權類的處理器使用，發出以下命令：
chclass -c hardmax=10 db2Power.LowPrio
要刪除資源享有權，發出以下命令：
chclass -c hardmax=100 db2Power.LowPrio
只有處理器資源針對 DB2 服務類進行了限制。
在對 DB2 工作負載管理配置進行任何更改後，發出 wlmcntrl - ud db2workload 命令更新 AIX Workload Manager 。
您可以使用 wlmcntrl – q 命令來驗證 AIX WLM 是否啟動，使用 ls cla s s – f r 命令查看 AIX WLM 配置（不需要根權限）。
AIX WLM 可以使用 wlmcntrl – o 命令禁用。
請注意，當您使用分區數據庫特性（DPF ）和多個物理機器時，每個機器上創建的 AIX WLM 配置必須相同。這與 DB2 工作負載管理器不同，在那裡，任何更改將向所有機器上的所有 DB2 節點廣播。
要監控 AIX WLM ，使用 topas 命令，它報告關於本地系統上的一個行為的已選統計數據，或者生成一個 nmon 格式的報告（使用 W 和 S 選項）。您也可以使用 wlmstat 、wlmmon 或 wlmperf 命令等特定於 AIX WLM 的監控工具，這些工具提供圖形視圖。
保護您的系統以防超載
如果您不采取必要的預防措施，系統可能由於請求的數量太大而陷入困境。可以並發維持的查詢或事務的數量取決於很多因素（並不是所有因素都受到 DB2 工作負載管理控制），您應該在完成初始設置後根據真實負載調優您的數據服務器。
如果您已經設置好您的資源控制並希望進行並發控制，考慮將以下並發限制作為一個起點：
最多允許 20 個並發復雜查詢：
CREATE THRESHOLD QUEUE_LOW_PRIO
FOR SERVICE CLASS LOW_PRIO UNDER POWER
ACTIVITIES ENFORCEMENT DATABASE
WHEN CONCURRENTDBCOORDACTIVITIES > 20
CONTINUE;
當您對在您的數據倉庫環境中執行的工作有比較好的理解後，動態調節這些阈值的值，以便針對實際負載調節您的配置。
要刪除阈值，應該首先禁用它：
ALTER THRESHOLD QUEUE_LOW_PRIO DISABLE;
DROP THRESHOLD QUEUE_LOW_PRIO;
處理大型查詢
當您阻止開銷非常大的或失控的查詢獨占系統資源時，您就可以為在您的數據服務器上執行的其他工作維護系統穩定性，這是任何工作負載管理策略的關鍵。
開銷昂貴的查詢可能來自不同的位置。這些查詢可能是某個最終用戶偶然創建的，他當時忘記了要適當編碼一個聯合謂詞，結果導致創建了一個估計成本高昂、運行時間非常長的查詢。或者，它們可能反映評估復雜業務問題的報告查詢且的確需要執行，但是它們對您的數據服務器上的所有其他行為沒有負面影響。即使一個復雜的報告查詢的確需要盡快獲取答案，您也不應該在沒有實施工作負載管理控制之前就允許它執行，因為這樣的查詢會消耗您的大量系統資源，對所有其他查詢造成非常嚴重的影響。
成本很高的查詢可以通過兩種方法控制：一是在查詢評估開始前進行預測控制，二是在執行過程中根據查詢的表現進行反應式控制。
這兩種查詢控制方法都要求您創建一些阈值，當過度昂貴的查詢進入您的系統或當它執行時這些阈值將被違背。
要使用預測阈值在執行之前管理查詢，考慮哪些用戶、小組或應用程序應該被允許執行成本非常高的查詢並將他們放置到一個專用服務類中。然後，借助 CoordActEstCost 柱狀圖的幫助確定：對於您的數據服務器來說，在不對其他工作造成嚴重影響的前提下，估計哪些工作的成本太高而變得難以維系；然後為它創建一個阈值。
例如，在一個倉庫環境中，甚至對於高級用戶來說都是非常高的預計查詢成本可能為 10 000 000 timeron 。要為針對高級用戶的 POWER 服務類創建一個預計阈值以阻止任何查詢超過該成本，發出以下命令：
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 選項來決定運行這樣的查詢，但是要為未來的性能調優分析捕捉信息。
要使用反應式阈值根據查詢在執行過程中的表現進行反應式控制：確定什麼因素構成違背您的反應式阈值的條件。表明一個查詢已經開始消耗過多系統資源的條件可能包括查詢要執行多長時間，它要消耗多少臨時表空間，或者查詢評估期間已經返回了多少行。
例如，以下阈值在高級用戶的 POWER 服務類中使用查詢評估期間逝去的時間作為違背阈值的條件。查詢獲准在其服務類中運行 60 分鐘，隨後，該阈值強制停止 60 分鐘過後仍在運行的任何查詢，因為它們的運行時間被認為太長了。收集的行為數據帶有細節和數據值，這允許您了解需要太長時間才能完成的那些行為類型。
CREATE THRESHOLD TOO_LONG
FOR SERVICE CLASS POWER ACTIVITIES
ENFORCEMENT DATABASE
WHEN ACTIVITYTOTALTIME > 60 MINUTES
COLLECT ACTIVITY DATA WITH DETAILS AND VALUES
STOP EXECUTION;
當行為通過一個排隊阈值進行排隊時，其總行為時間包括在隊列中等待執行的時間。
限制並發負載操作的數量
由於內存要求，一項良好的實踐是限制系統上的並發負載操作的數量。如果您同時只運行一個或很少幾個負載操作，則使用 DATA BUFFER 參數控制它們的內存使用，這將設置負載實用程序可用的內存總量並允許它更有效地運行（如果不指定，負載實用程序從 UTIL_HEAP_SZ 參數確定 DATA BUFFER 值和並發負載操作的總數量）。有時需要大量的內存才能加載到多維集群化表。
通過將負載工作類型放入一個獨立的工作類來控制負載操作：
CREATE WORK CLASS SET LOAD_TYPE
(WORK CLASS LOAD_WC WORK TYPE LOAD);
要在數據庫級別將並發負載操作的數量限制為 1 ，創建一個工作操作：
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);
當幾個負載操作平行啟動時，它們現在只能按順序運行。您可以使用以下查詢在 WORKLOAD_OCCURRENCE_STATE 列中查看這些負載操作的狀態：
SELECT
SUBSTR(APPLICATION_NAME,1,10) AS APPL_NAME,
SUBSTR(CHAR(APPLICATION_HANDLE),1,10) AGENTID,
SUBSTR(WORKLOAD_NAME,1,22) AS WORKLOAD_NAME,
SUBSTR(CLIENT_APPLNAME,1,25) AS CLIENT_APPLNAME,
WORKLOAD_OCCURRENCE_STATE AS WL_STATE FROM
TABLE(WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURRENCES('','',-2))
ORDER BY WORKLOAD_OCCURRENCE_STATE DESC;
輸出顯示除一個負載操作外，所有負載操作都已排隊：
APPL_NAME AGENTID WORKLOAD_NAME CLIENT_APPLNAME WL_STATE
----- ---- ------- --------------- -------- ---
db2bp 65638 SYSDEFAULTUSERWORKLOAD CLP load_from_flat3.sql UOWWAIT
db2bp 65604 HIGH_PRIO - UOWEXEC
db2bp 65637 SYSDEFAULTUSERWORKLOAD CLP load_from_flat2.sql QUEUED
db2bp 65639 SYSDEFAULTUSERWORKLOAD CLP load_from_flat1.sql QUEUED
db2bp 65640 SYSDEFAULTUSERWORKLOAD CLP load_from_flat4.sql QUEUED
db2bp 65660 HIGH_PRIO CLP load_from_flat.sql QUEUED
要刪除這些限制，禁用 WLM 對象並丟棄它們：
ALTER WORK ACTION SET CONTROL_LOAD ALTER WORK ACTION LIMIT_LOAD
DISABLE;
ALTER WORK ACTION SET CONTROL_LOAD DISABLE;
DROP WORK ACTION SET CONTROL_LOAD;
DROP WORK CLASS SET LOAD_TYPE;
監控開銷較高的查詢
開銷高的查詢可能對您的數據服務器造成破壞性影響，您應該監控它們以便理解它們是什麼查詢，以及它們應該受到什麼程度的控制。您可以使用可用的各種柱狀圖查找以輕量級形式存在的任何異常（和可能有問題的）查詢。這還允許您通過使用自動化統計數據收集特性構建一個歷史透視圖。
事件監控器根據已定義的工作負載監控規則收集行為。例如：為定義一個規則來支持監控運行時間超過 5 分鐘（5 分鐘是您在 DB2 V9.5 中可以使用的最小值）的所有對整個數據庫的查詢，同時又不會打斷這些查詢，創建以下阈值：
CREATE THRESHOLD MONITOREVENT
FOR DATABASE ACTIVITIES
ENFORCEMENT DATABASE
WHEN ACTIVITYTOTALTIME > 5 MINUTES
COLLECT ACTIVITY DATA ON ALL WITH DETAILS AND VALUES
CONTINUE;
要收集關於復雜查詢的信息，您可以使用一個由估計查詢成本觸發的阈值。例如，如果任何查詢擁有大於 10 000 timeron 的估計成本，以下阈值打開行為數據收集功能，為服務類 HIGH_PRIO 收集細節和值：
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;
CREATE EVENT MONITOR 語句需要訪問在所有數據庫分區上都存在的默認表空間（例如，默認的 USERSPACE1 ）。您也可以重命名事件監控器需要的表並指定一個特意為監控數據創建的 MONITOR_TS 表空間：
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;
當同一類型的多個阈值應用到一個行為時，只有一個阈值將被執行。在我們的示例中，如果您在服務類上定義阈值來處理 ACTIVITYTOTALTIME 或 ESTIMATEDSQLCOST 上的“異常”查詢，相同類型的監控阈值將被忽略。
分析事件監控器數據
一旦您在您的數據服務器上運行一些工作，事件監控器表就可以被分析。以下是一些您可能感興趣的典型場景。
您可以使用以下語句發現運行時間最長的行為（或查詢）：
SELECT
SUBSTR(APPL_ID,1,26) as APPL_ID ,
SUBSTR(CHAR(ACTIVITY_ID),1,10) AS ACTIVITY_ID,
SUBSTR(APPL_NAME, 1,10) AS APPL_NAME,
SUBSTR(ACTIVITY_TYPE,1,10) AS TYPE,
TIMESTAMPDIFF(2, CHAR(TIME_COMPLETED-TIME_STARTED)) AS TOTALTIME,
SQLCODE, SUBSTR(SESSION_AUTH_ID,1,8) AS USER,
SUBSTR(SERVICE_SUBCLASS_NAME,1,20) AS SERVICE_SUBCLASS_NAME
FROM WLM_EVENT AS A
WHERE PARTITION_NUMBER=CURRENT DBPARTITIONNUM
ORDER BY TOTALTIME DESC
FETCH FIRST 10 ROWS ONLY;
這個查詢返回以下輸出：
APPL_ID ACTIVITY_ID APPL_NAME TYPE TOTALTIME SQLCODE
USER SERVICE_SUBCLASS_NAME
-------------------------- ----------- ---------- ---------- ----------- ----------- -
------- ---------------------
*N0.db2inst3.080609131850 2 db2batch READ_DML 2265 -1224
DB2INST3 LOW_PRIO
*N0.db2inst3.080609131856 1 db2batch READ_DML 1820 -1224
DB2INST3 LOW_PRI
*N0.db2inst3.080520113026 1 db2batch READ_DML 1230 0
DB2INST3 SYSDEFAULTSUBCLASS
*N0.db2inst3.080520113006 1 db2batch READ_DML 1222 0
DB2INST3 SYSDEFAULTSUBCLASS
*N0.db2inst3.080520113009 1 db2batch READ_DML 1215 0
DB2INST3 SYSDEFAULTSUBCLASS
…….
10 record(s) selected.
這個輸出通過一個較寬的空白顯示 APPL_ID *N0.db2inst3.080609131850 以及運行最長查詢的 ACTIVITY_ID 2 。要查看這個行為的 SQL 語句文本，發出以下命令：
SELECT SUBSTR(S.STMT_TEXT, 1,1000) AS STMT
FROM WLM_EVENT AS A,
WLM_EVENT_STMT AS S
WHERE A.APPL_ID = S.APPL_ID AND
A.ACTIVITY_ID = S.ACTIVITY_ID AND
A.UOW_ID = S.UOW_ID AND
A.APPL_ID='*N0.db2inst3.080609131850' AND
A.ACTIVITY_ID=2 AND
A.PARTITION_NUMBER=CURRENT DBPARTITIONNUM;
另一件有意思的事情是發現行為花費最多時間的數據庫分區，這可以通過以下語句完成：
SELECT SUBSTR(APPL_ID,1,26) as APPL_ID,
PARTITION_NUMBER AS DBPART,
SUBSTR(ACTIVITY_TYPE,1,10) AS TYPE,
TIMESTAMPDIFF(2, CHAR(TIME_COMPLETED-TIME_STARTED)) AS TOTALTIME
FROM WLM_EVENT WHERE APPL_ID=*N0.db2inst3.080609131850'
AND ACTIVITY_ID=2
ORDER BY PARTITION_NUMBER;
輸出顯示所有分區消耗的時間，您可以比較它們：
APPL_ID DBPART TYPE TOTALTIME
-------------------------- ------ ---------- -----------
*N0.db2inst3.080609131850 0 READ_DML 2265
*N0.db2inst3.080609131850 1 OTHER 2065
*N0.db2inst3.080609131850 2 OTHER 2240
*N0.db2inst3.080609131850 3 OTHER 2240
*N0.db2inst3.080609131850 4 OTHER 2240
*N0.db2inst3.080609131850 5 OTHER 2065
*N0.db2inst3.080609131850 6 OTHER 2240
*N0.db2inst3.080609131850 7 OTHER 2240
DB2 Workload Management Page 40
*N0.db2inst3.080609131850 8 OTHER 2240
*N0.db2inst3.080609131850 9 OTHER 1999
*N0.db2inst3.080609131850 10 OTHER 1999
*N0.db2inst3.080609131850 11 OTHER 1999
*N0.db2inst3.080609131850 12 OTHER 1999
*N0.db2inst3.080609131850 13 OTHER 1999
*N0.db2inst3.080609131850 14 OTHER 1999
*N0.db2inst3.080609131850 15 OTHER 1999
*N0.db2inst3.080609131850 16 OTHER 1999
17 record(s) selected.
…
緩解 AIX Workload Manager 處理器使用的最大硬性限制
當處理器沒有受到高需求的限制時，多數 AIX Workload Manager (WLM) 控制機制不會產生顯著的效果。相反，處理器使用的最大硬性限制可以嚴格控制處理器消耗，而與處理器利用程度無關，這允許您在所有時間內控制低優先權工作負載，從而使高優先權工作受益，即使是在沒有處理器限制的環境中也是如此。要重新獲取由於使用最大硬性限制而失去的動態處理器時間分配特性，您需要在後台運行一個如這裡所示的自動化腳本，該腳本根據當前利用率動態調節每個服務類中的最大硬性設置。
緩解後的最大硬性設置是這樣工作的：AIX WLM 提供輕松監控各個 AIX 服務類的系統資源使用情況的工具。您可以使用以下命令監控每秒的系統使用情況：
$ wlmstat 1
收集這個監控信息後，校正您的 AIX WLM 配置以滿足傳入的工作的優先權。與 DB2 工作負載管理不同，對 AIX WLM 的更改在運行查詢時立即生效。監控信息和配置然後可以使用一個自動腳本合並起來。
例如，假如您擁有來自您的公司的兩個部門的傳入查詢，您的目標是確保分配到 Power.HighPrio 類的部門 A 的查詢不會受到 Power.LowPrio 類中來自部門 B 的並發查詢的影響。
為簡便起見，假定來自部門 A 的所有查詢都來自使用 db2bp 的用戶 DB2INST3 ，來自部門 B 的所有查詢都來自 db2batch 命令。這樣，您可以重新使用“通過優先權設置獲取一致的響應時間”部分中的 CREATE SERVICE CLASS 和 CREATE WORKLOAD DDL 來設置 DB2 工作負載管理。您還需要使用“集成 AIX Workload Manager ”部分介紹的步驟設置 AIX WLM 並將 DB2 工作負載綁定到 AIX WLM 。
首先，使用 wlmstat 命令監控來自這兩個部門的查詢的處理器使用情況。以下是這兩個部門都不運行任何行為時 wlmstat 命令的輸出：
CLASS CPU MEM DKIO
UnclassifIEd 0 3 0
Unmanaged 0 24 0
Default 0 19 0
Shared 0 1 0
System 0 5 0
Power 0 0 0
Power.HighPrio - - -
Power.LowPrio - - -
TOTAL 0 52 0
部門 A 運行一些行為後，Power.HighPrio 條目顯示非零的處理器使用值，您可以使用腳本監控這個值。當部門 A 提交一些查詢並因此擁有非零的處理器使用值時，通過使用腳本為部門 B 設置一個較低的處理器最大硬性限制來有效抑制來自部門 B 的查詢：
> chclass -a inheritance=no -c hardxmax=1 Power.LowPrio
來自部門 A 的查詢完成後，腳本可以刪除部門 B 上的最大硬性限制：
> chclass -a inheritance=no -c hardxmax=100 Power.LowPrio
只要有新的查詢來自部門 A ，這個設置和重置的過程就會重復。整個流程可以通過運行作為根的腳本 auto_tune.sh （它依賴 compute.awk ）自動化。
auto_tune.sh:
#!/bin/bash
wlmstat 1 | gawk –f compute.awk | while read NEWCPUA NEWCPUB
do
echo "New processor limits for Departments A and B are $NEWCPUA
and $NEWCPUB \n"
chclass -a inheritance=no -c hardmax=${NEWCPUA} Power.High
chclass -a inheritance=no -c hardmax=${NEWCPUB} Power.Low
wlmcntrl -ud db2workload
done
compute.awk:
BEGIN{prev=0; newa=0;newb=0;}
/High/{prev=$2; next}
/Low/{
FIRST=prev;
SECOND=$2;
if(FIRST == "-" || FIRST == "0"){
print 100,100;
{fflush()}
}
else{
print 100, 1;
{fflush()}
}
next
}
圖 7 和圖 8 展示所有服務類的處理器使用情況，首先使用默認的 WLM 設置，然後使用自動調優腳本。藍色服務類表示來自部門 B 的單個 TPCH Q18 請求的工作負載，而紅色服務類表示來自部門 A 的特殊請求。這個特殊查詢從一個使用獨立緩存池的不同表拖動數據。單獨運行時，該特殊查詢大約需要 120 秒完成。使用默認 WLM 設置時，該特殊查詢被 Q18 減慢到 312 秒（幾乎減慢了 160% 。如果您比較圖 7 和圖 8 ，您將看到，在動態設置最大硬性處理器使用限制後，來自部門 A 的查詢獲得的處理器資源要比之前多很多，運行時間與單獨運行的時間差不多（從 312 秒下降到 138 秒），而 TPCH Q18 查詢只被延遲了不到 100 秒（從 1134 秒上升到 1233 秒）。
圖 7. 默認 WLM 下所有服務類的處理器使用情況
查看原圖（大圖）
圖 8. 動態最大硬性限制下所有服務類的處理器使用情況
查看原圖（大圖）
這個示例特意保持簡單性以傳達緩解後的最大硬性限制設置的概念。在現實中，您也許擁有兩個以上服務類，您的目標也許基於整個查詢流量而不是所有服務類的處理器使用情況。
如果您擁有一個以上 AIX 物理機器（或 LPAR ），您需要在每個機器（或 LPAR ）上調優最大硬性處理器使用限制。這與 DB2 工作負載管理器不同，對於後者，任何更改將被廣播到所有機器上的所有 DB2 節點。除了調優最大硬性處理器使用限制，您也可能希望通過 DB2 工作負載管理設置並發限制。
附錄：從 Query Patroller 和 DB2 Governor 升級時考慮 DB2 工作負載管理器
在 DB2 V9.5 之前，Query Patroller 和 DB2 Governor 一起使用，以提供在 DB2 上成功運行復雜工作負載所需的工作負載管理控制。到了 Version 9.5 ，DB2 工作負載管理器是在您的 DB2 數據服務器上進行工作負載管理的戰略工具，提供一組經過極大改進的工作負載管理特性。
下表從較高層次概述了 Query Patroller 和 DB2 工作負載管理器在控制和監控功能方面的主要區別：
Query Patroller DB2 工作負載管理 充當一個“守門員”：工作進入後就可以隨意執行
可以顯示當前狀態，SQL 和 ApplHandle ，但在執行完成之前不能提供關於工作的實時信息
只關注已提交工作的協調
不提供任何顯式控制用於執行的資源的機制
關於所有寫入控制表（磁盤）的受管理行為的細節
監控只是細粒度的（收集單獨行為）
充當“大廳監視器”：它確保工作到達正確的位置並在執行期間遵循相關規則可以顯示應用程序、SQL 和事件代理在執行期間的任何時刻的當前狀態
關注所有數據庫分區上的工作
提供在執行期間控制和影響所用資源的機制
除非用戶創建的事件監控器請求，否則不向磁盤寫入任何內容
監控可以是細粒度的（單獨行為）也可以是粗粒度的（聚合統計數據）
當您從 Query Patroller 升級到工作負載管理器時，可以根據這裡介紹的最佳實踐控制您的數據服務器上的工作。您可以利用已經從 Query Patroller 控制表獲得的關於您的工作負載的深入信息幫助您在工作負載管理器下獲得一個良好的初始實現。
使用 Query Patroller ，您可以根據其估計成本將一個行為歸類到一個查詢類，查詢類並發率規定每個類別允許同時運行的行為的數量。不要使用 DB2 Workload Management 盲目效仿這種方法，因為實現您的目標可能不需要並發控制。
使用 DB2 Workload Management ，您擁有許多選擇，應該探索它們。您可以使用 DB2 服務類分隔和隔離互相競爭的工作負載，通過更改每個服務類接收的處理器和預取器優先權來應用將影響響應時間的特定資源控制。如果您不能通過一個工作負載根據其來源分隔工作，您可以根據估計成本等特征使用一個 DB2 工作操作集分隔不同類型的工作，這類似於 Query Patroller 提供的方法。
在這一點上，您可以根據需要調節資源以實現您的性能目標。如果應用資源控制不能完全實現需要的結果，您可以應用 DB2 Workload Management 的其他特性。這包括應用並發阈值等其他 DB2 阈值。
某些 DB2 Governor 反應式阈值能在 DB2 工作負載管理阈值中發現功能直接對等的阈值，比如那些控制最大執行時間、返回的最大行數或最大連接閒置時間的阈值。其他阈值則是負載管理或 DB2 Governor 所特有的，升級到 DB2 Workload Management 要求您以當前工作負載管理術語重新思考控制您的 DB2 數據服務器上的工作的方法。您將發現的一個區別是對 DB2 Governor 規則的更改可以應用到已經運行的查詢，但對 WLM 阈值的更改只能應用到新查詢。
為何沒有從 Query Patroller 自動升級的工具？
沒有從 Query Patroller 升級到 DB2 Workload Management 的自動化工具，正如您不首先應用 DB2 Workload Management 的其他特性的話，您就不應該效仿 Query Patroller 的並發性管理方法一樣。DB2 Workload Management 和 Query Patroller 的可用控制類型和機制不同，它們的基本控制模式也不同。Query Patroller-DB2 Governor 和 DB2 Workload Mangement 可以在同一個環境中共存，以便您在它們之間的移動可以以一種可控的、粒狀的方式進行。
當您采用 DB2 工作負載管理器的特性和功能時，往往可以通過應用資源控制而不是通過基於查詢類持久化一個 Query Patroller 方法來更簡單有效地處理許多常見工作負載管理場景。利用您對 DB2 工作負載管理器的采用作為一個契機，檢查您的總體工作負載管理方法，以便找出最簡單且最好的解決方案。
從 Query Patroller （和 DB2 Governor ）升級到 DB2 工作負載管理器可以分階段進行，這允許通過逐步采用 DB2 工作負載管理器的特性和功能來減小風險和對您的數據服務器環境的影響。
在您的 DB2 數據服務器上，最終將在默認用戶服務超類 SYSDEFAULTUSERCLASS 中處理的用戶請求適合被 Query Patroller 攔截，無論其中用於映射它們的工作負載是什麼。類似地，DB2 Governor 只能將其控制應用到被映射到默認用戶服務超類的用戶請求。
下圖展示與 Query Patroller 共存的一個 DB2 工作負載管理器實現。有的用戶請求由 DB2 工作負載管理器處理，而其他用戶請求由 Query Patroller 在默認用戶服務類中處理。由 Query Patroller 處理的用戶請求從默認工作負載和用戶定義工作負載映射。
圖 9. DB2 工作負載管理器和 Query Patroller 共存
查看原圖（大圖）
圖片說明：
User Requests ：用戶請求
System Requests ：系統請求
Workloads ：工作負載
User-defined ：用戶定義
Default ：默認
Service classes ：服務類
User-defined Class ：用戶定義類
QP BYPASS ：QP 繞道
Query Patroller Tables ：查詢巡視器表
Default System Class ：默認系統類
