開始之前
了解本教程提供的內容,以及如何從本教程獲得最大收益。
關於本教程
本教程采用以一種簡單的方法來實現 WLM,幫助您輕松地理解基礎功能。
目標
本教程教您如何:
理解 DB2 WLM 對象以及它們之間的關系
在服務類定義中使用新的 DB2 9.7 BUFFERPOOL PRIORITY
在工作負載定義中使用新的 DB2 9.7 連接屬性通配符
在工作負載定義中使用新的 DB2 9.7 ADDRESS 連接屬性
通過新的 DB2 9.7 CPUTIME 度量指標使用阈值
使用服務子類阈值執行 DB2 9.7 服務子類重新映射(也稱為優先級時限)
使用一個新的 DB2 9.7 WLM 樣例腳本構建分層服務類環境
使用 WLM 過程設置客戶端信息
使用 WLM 功能監控環境 —— 短期
使用 WLM 事件監控器監控環境 —— 長期
理解重新映射度量指標
先決條件
本教程面向具有使用 DB2 的經驗但不了解 DB2 WLM 特性的數據庫管理員(DBA)。
系統需求
要跟隨本教程的 WLM 實踐,您必須能夠訪問 DB2 Enterprise Edition for Linux®, UNIX®, and Windows® (DB2 ESE) Version 9.7。
本教程的例子是基於 Windows 環境的。這是為了易於使用,您完全可以將本教程的流程應用到 Linux 或 UNIX 系統上。
本教程的例子使用的文件包含在附帶的 WLMLab.zip 下載文件中。從 下載 部分下載 WLMLab.zip 文件並將其解壓縮到 Windows C:\ drive。
WLM 特性概述
本文提供 WLM 特性的簡單定義,並介紹 DB2 9.7 中的新特性。
WLM 特性的簡單定義
DB2 工作負載作為主要控制點,基於工作提交者源,並通過連接屬性將工作路由到服務類DB2 服務類作為所有進行中的工作活動的主要資源控制點DB2 阈值基於預測性和響應性元素為發生在數據庫或服務類中的所有活動提供數據庫行為控制限度DB2 工作操作集(工作操作 > 工作類集 > 工作類)提供區分發生在數據庫或服務類中的數據庫行為類型(讀、寫、調用、DML、DDL 和加載)的能力DB2 WLM 監控器和控制功能db2pd 實用程序、表函數、存儲過程和事件監控器提供實時和歷史監控功能
圖 1. DB2 9.5 中的 WLM 特性總結
DB2 9.7 中的新 WLM 特性
連接屬性中的通配符
DB2 9.7 中的新特性
通過使用 db2user* 可以避免編寫 db2user01、db2user02、db2user03、db2user04、db2user05 和 db2user06 等。
可以通過為一組連接屬性提供映射值定義工作負載
為了最大限度地減少腳本編寫,您可以對以下連接屬性使用通配符:
APPLNAME
CLIENT_USERID
CLIENT_APPLNAME
CLIENT_WRKSTNNAME
CLIENT_ACCTNG
CREATE WORKLOAD "work1" CLIENT_USERID('db2user*');
不能對以下連接屬性使用通配符:
SYSTEM_USER
SESSION_USER
SESSION_USER GROUP
SESSION_USER ROLE
新的 ADDRESS 連接屬性
除了以上提供的連接屬性之外,DB2 9.7 還引入了一個新的連接屬性,即 ADDRESS。下面是通過各種語法類型使用該屬性的例子:
安全域語法: CREATE WORKLOAD "IPADDR1" ADDRESS(‘mydomain.ibm.com’);
IPv4 語法: CREATE WORKLOAD "IPADDR2" ADDRESS('9.26.53.111');
IPv6 長語法: CREATE WORKLOAD "IPADDR3" ADDRESS('2002:91a:519:13:204:acff:fe57:6135');
IPv6 短語法: CREATE WORKLOAD "IPADDR4" ADDRESS('fe80::202:55ff:fe9a:6eee');
聚合活動
現在,您可以在工作負載級別積累聚合活動數據(DB2 9.5 僅能使用服務類和工作類級別)。
這個新特性有利於:
通過在工作和服務子類之間重新進行映射,工作的優先級可以隨著時間延長逐步下降。
可以在工作負載級別收集聚合活動數據,以為在工作負載域中定義的阈值確定最佳的最大值。
粒度監控隨著存儲需求的降低而增加。
CREATE EVENT MONITOR DB2Activities FOR ACTIVITIES WRITE TO TABLE;
SET EVENT MONITOR DB2ActivitIEs STATE 1;
CREATE WORKLOAD WORKLD1 APPLNAME('DB2APP1')
COLLECT AGGREGATE ACTIVITY DATA EXTENDED; <--- New in DB2 9.7
緩沖池 I/O 優先級
您可以使用這個新的 DB2 9.7 特性影響緩沖池中可能由特定 DB2 服務類中的活動占用的分頁比例。
您可以指定以下為特定服務類分配的緩沖池優先級的值:
HIGH
MEDIUM
LOW(這是超類的默認值)
WLM 中保留的另一些 DB2 9.5 服務類優先級:
代理 (CPU) 優先級
UNIX 的值范圍 -20 - 20
Windows 的值范圍 -6 - 6
預抓取 (I/O) 優先級的可能值:
HIGH
MEDIUM
LOW
CREATE SERVICE CLASS “Managers”
UNDER "Marketing"
AGENT PRIORITY 5
PREFETCH PRIORITY HIGH
BUFFERPOOL PRIORITY HIGH; <--- New in DB2 9.7
Linux WLM 集成
DB2 9.5 WLM 服務類將 DB2 處理與 AIX WLM 服務器集成起來。DB2 9.7 現在為 Linux 操作系統提供相同級別的集成。
每個 DB2 服務類都可以與特定的 Linux WLM 服務類關聯起來:
DB2 自動將在 DB2 服務類中工作的所有代理與識別到的 Linux WLM 服務類關聯起來。
這根據 CPU 使用量提供退費功能。
ALTER SERVICE CLASS "Marketing"
OUTBOUND CORRELATOR "_DB2_Marketing"; <-- Linux WLM definition
Linux WLM 提供高級的 CPU 管理,以在充分利用資源的同時遵從顯式的分配:
CPU 的分配是通過為 Linux WLM 服務類分配 CPU 份額完成的。
可以使用 Linux WLM 界面動態地調整 CPU 份額。
提供從其他服務類中借用未使用 CPU 份額的功能。
為每個 Linux 服務類提供操作系統(OS)級別的數據統計。
圖 2. Linux WLM 集成
優先級時限
優先級時限也稱為當前進行的活動的時限。
優先級時限可以自動地提升和降低當前進行活動的優先級。例如,您可以使用優先級時限控制長期活動,以改善短期活動的吞吐量。
優先級時限是 Query Patroller 功能的必須代替物。
優先級時限是通過服務類阈值實現的,服務類阈值可以將活動從服務子類重新映射到其他服務子類。
圖 3. 新的優先級時限
優先級時限步驟 1:創建服務類層次結構
CREATE SERVICE CLASS WLM_TIERS;
CREATE SERVICE CLASS WLM_SHORT UNDER WLM_TIERS;
CREATE SERVICE CLASS WLM_MEDIUM UNDER WLM_TIERS;
CREATE SERVICE CLASS WLM_LONG UNDER WLM_TIERS;
優先級時限步驟 2:創建重新映射阈值
CREATE THRESHOLD WLM_TIERS_REMAP_SHORT_TO_MEDIUM FOR
SERVICE CLASS WLM_SHORT UNDER WLM_TIERS ACTIVITIES
ENFORCEMENT DATABASE PARTITION WHEN
CPUTIMEINSC > 10 SECONDS CHECKING EVERY 5 SECONDS <--- New in DB2 9.7
REMAP ACTIVITY TO WLM_MEDIUM; <--- New in DB2 9.7
CREATE THRESHOLD WLM_TIERS_REMAP_MEDIUM_TO_LONG FOR
SERVICE CLASS WLM_MEDIUM UNDER WLM_TIERS ACTIVITIES
ENFORCEMENT DATABASE PARTITION WHEN
CPUTIMEINSC > 10 SECONDS CHECKING EVERY 5 SECONDS <--- New in DB2 9.7
REMAP ACTIVITY TO WLM_LONG; <--- New in DB2 9.7
優先級時限步驟 3:創建工作類集(識別將要映射的操作)
CREATE WORK CLASS SET WLM_TIERS_WCS
( WORK CLASS WLM_DML_WC WORK TYPE DML,
WORK CLASS WLM_CALL_WC WORK TYPE CALL,
WORK CLASS WLM_OTHER_WC WORK TYPE ALL );
優先級時限步驟 4:創建工作操作集(執行主要的活動映射)
CREATE WORK ACTION SET WLM_TIERS_WAS FOR SERVICE CLASS WLM_TIERS
USING WORK CLASS SET WLM_TIERS_WCS
( WORK ACTION WLM_DML_WA ON WORK CLASS WLM_DML_WC
MAP ACTIVITY TO WLM_SHORT,
WORK ACTION WLM_CALL_WA ON WORK CLASS WLM_CALL_WC
MAP ACTIVITY TO WLM_SHORT,
WORK ACTION WLM_OTHER_WC ON WORK CLASS WLM_OTHER_WC
MAP ACTIVITY TO WLM_MEDIUM );
新的阈值
AGGSQLTEMPSPACE 控制可以在服務子類的所有活動中使用的系統臨時表空間的最大值。
CREATE THRESHOLD "Detect High Temp"
FOR SERVICE CLASS "Marketing" ACTIVITIES
ENFORCEMENT DATABASE
WHEN AGGSQLTEMPSPACE > 100 M <--- New in DB2 9.7
COLLECT ACTIVITY DATA WITHOUT DETAILS
CONTINUE;
CPUTIME 控制在執行期間某個活動可用於特定數據庫分區的處理器時間的最大值。
SQLROWSREAD 控制某個活動可以在特定數據庫分區上讀取的行數的最大值。
CREATE THRESHOLD DBMAXCPU
FOR DATABASE ACTIVITIES
ENFORCEMENT DATABASE PARTITION
WHEN CPUTIME > 30 SECONDS CHECKING EVERY 5 SECONDS <--- New in DB2 9.7
STOP EXECUTION;
工作負載域中其他可用阈值
工作負載域中基於活動的阈值已被添加到某些現有的阈值中,並且包含一些新的阈值以更好地控制資源。
這些阈值的用途是避免在分開的服務類中隔離應用程序。
這些阈值是:
ESTIMATEDSQLCOST 指定 DML 活動的最大估計開銷。
SQLROWSRETURNED 指定數據服務器能夠向客戶機返回的最大行數。
ACTIVITYTOTALTIME 活動的最大壽命。
SQLTEMPSPACE 指定 DML 可以在特定數據庫分區上使用的最大系統臨時表空間。
SQLROWSREAD 是一個新的阈值,它指定 DML 活動可以在任意數據庫分區上讀取的最大行數。
CPUTIME 是一個新的阈值,它指定某個活動在運行時可以在特定數據庫分區上使用的最大組合用戶和系統處理器時間。
新的最大值
通過以下最大值,您可以更容易地確定新的 CPUTIME 和 SQLROWSREAD 阈值的值:
act_cpu_time_top 是工作負載、服務類或工作類中的所有活動能夠使用的最大處理器時間。
act_rows_read_top 是工作負載、服務類或工作類中的所有活動能夠讀取的最大行數。
新的 lock_wait_time_top 最大值讓您能夠確定在特定時間間隔內請求分區工作負載的最大鎖定等待時間(毫秒)。
針對重新映射活動的新監控器
您可以使用 3 個新監控器元素來識別重新映射的活動和受影響的服務子類:
num_remaps 表示活動重新映射的時間。
act_remapped_in 計算重新映射到服務子類中的活動的數量。
act_remapped_out 計算從特定服務子類映射出來的活動的數量。
新的 DB2 9.7 樣例腳本
以下是 DB2 9.7 中的新的 WLM 樣例腳本,用於演示針對數據庫的分層服務類配置。
wlmtIErsdefault.db2
指向進入的活動的已消耗執行時間
在活動執行期間根據已消耗時間將活動從一個服務子類重新映射到另一個服務子類
演示服務類、工作負載和阈值的使用
wlmtIErstimerons.db2
指向進入的活動的估計開銷
在活動執行之前根據開銷將活動從一個服務子類重新映射到另一個服務子類
wlmtIErsdrop.db2
刪除在以上腳本創建的 WLM 對象
設置定制工作負載管理環境
遵循這個小節的步驟設置定制工作負載管理環境。
打開 Windows 命令提示符並導航到解壓縮 WLMLab.zip 文件的目錄。默認情況下該目錄為 C:\COBRA_LAB_SCRIPTS\WLM。
輸入命令 db2cmd(見圖 4)啟動 DB2 Command Line Processor(見圖 5)。
圖 4. 啟動 DB2 CLP
圖 5. DB2 CLP 窗口
找到並查看您從 WLMLab.zip 解壓出來的 SETUP_COBRA_LABS.CMD 和 WLM01.CMD 命令(見圖 6)。注意,WLM01.CMD 調用 WLM02.DDL。此外,還要看看 WLM02.DDL。
圖 6. 在 Windows Explorer 浏覽器中的 SETUP_COBRA_LABS.CMD 和 WLM01.CMD
從 CLP 輸入 SETUP_COBRA_LABS.CMD 運行該命令。
注意:本教程的 WLM 實踐例子不能用於 DB2 9.7 之前的其他版本。如果您發現在運行 SETUP_COBRA_LABS.CMD 時 GRANTS 失敗,這表明您運行的是 DB2 9.7 之前的 DB2 版本。
從 CLP 輸入 WLM01.CMD 運行該命令。
WLM01.CMD 命令在其所在的目錄中創建一個名為 WLM01_OUTPUT.TXT 的文件,並將其輸入寫到該文件。查看首次運行該命令的輸出結果(見圖 7)。
圖 7. 首次運行 WLM01.CMD 命令時創建的默認 WLM 環境
注意,還沒有為您的數據庫定義任何特定的工作負載和服務類等。這是 WLM 的默認外觀。
關閉 WLM01_OUTPUT.TXT 文件。
查看 WLM03.CMD 和 WLM04.DB2 文件。WLM03.CMD 調用 WLM04.DB2,而後者將創建一個定制的 WLM 環境。
WLM04.DB2 創建兩個工作負載/服務類配置,如以下兩個表所示:
工作負載 #1
Name:
CLP_Workload_Admin
Identify by:
客戶機用戶 ID —— 登錄用戶
Service Class:
CLP_Serv_Admin
使用默認的預抓取、代理和緩沖池優先級
Sub Srv Class1:
CLP_Serv_Admin_HI
使用高級的預抓取、代理和緩沖池優先級
Service Class:
CLP_Serv_Admin
使用默認的預抓取、代理和緩沖池優先級
Sub Srv Class2:
CLP_Serv_Admin_MED
使用中級的預抓取、代理和緩沖池優先級
Work Act. Set:
Admin_Actions
將 WRITE 工作映射到高級子服務類
將 READ 工作映射到中級子服務類
工作負載 # 2
Name:
CLP_Workload_User1
Identify by:
客戶機用戶 ID db2user*
Service Class:
CLP_Serv_User
使用低級的預抓取、代理和緩沖池優先級
圖 8 突出顯示了與 DB2 9.7 中的新的 WLM 特性相關的 WLM04.DB2 腳本。
圖 8. DB2 9.7 中的新 WLM 特性
從 CLP 輸入 WLM03.CMD 運行該命令並創建一個定制的 WLM 環境。
從 CLP 輸入 WLM.CMD 再次運行該命令。
再次查看 WLM01_OUTPUT.TXT 文件。現在它反映了 WLM03.CMD 創建的定制 WLM 環境。注意以下與這個定制的 WLM 環境相關的事項:
服務超類、服務子類和工作操作等有一個層次結構。
有一個稱為 CLP_Serv_User 的服務超類(見圖 9),它不包含任何已定義的服務子類。它唯一的服務子類是 SYSDEFAULTSUBCLASS。
有一個不包含任何服務類的工作負載 IPADDR(它將使用默認值)。
現在,這個腳本創建了阈值和事件監控器。
圖 9. WLM03.CMD 創建的定制 WLM 環境
關閉 WLM01_OUTPUT.TXT 文件。
設置顯示優先級時限的分層服務類
遵循本小節的步驟,設置一個顯示優先級時限的分層服務類。
查看您從 WLMLab.zip 下載文件解壓得到的 WLM05.CMD 和 wlmtiersdefault.db2 文件。WLM05.CMD 調用 wlmtIErsdefault.db2,後者是一個新的 DB2 9.7 樣例腳本(見圖 10)。
圖 10. WLM05.CMD 調用新的 DB2 9.7 樣例腳本 wlmtIErsdefault.db2
花些時間查看整個 wlmtIErsdefault.db2 腳本能夠幫助您更好地理解它的作用。下面列出一些需要注意的事項:
該腳本創建了一個分層 WLM 服務類環境和阈值,阈值將一個服務子類重新映射到另一個服務子類(見圖 11)。
圖 11. wlmtIErsdefault.db2 中的服務超類和服務子類定義
該腳本並沒有創建一個工作負載,而是通過修改默認的工作負載以使用新的分層服務類。
該腳本使用阈值從 WLM_SHORT 子類映射到 WLM_MED 子類(見圖 12)。
圖 12. wlmtIErsdefault.db2 中的阈值映射
從 CLP 輸入 WLM05.CMD 以運行該命令並創建分層服務環境。
從 CLP 輸入 WLM.CMD 再次運行該命令。
再次查看 WLM01_OUTPUT.TXT 文件,它現在反映了 WLM05.CMD 創建的定制 WLM 環境。現在,這個定制的 WLM 環境包含 WLM_TIERS 服務超類及其子類,並且擁有新的服務子類阈值(見圖 13)。
圖 13. 運行 WLM05.CMD 之後得到的定制 WLM 環境
查看 WLM10.CMD 命令文件。它使用 db2pd 實用程序來在您創建的定制 WLM 環境中查找每個 WLM 對象。WLM10.CMD 還在該命令所在的目錄中創建一個名為 WLM10_OUTPUT.TXT 的文件,並將其輸出寫出到該文件。
從 CLP 輸入 WLM10.CMD 運行該命令。
查看 WLM10_OUTPUT.TXT 文件中針對 WLM 對象的 db2pd 報告。目前,大部分統計數據都顯示為 0(見圖 14),因為您還沒在自己的環境中運行任何工作負載。在本教程的後面,您還將再次運行 WLM10.CMD 腳本,並且 db2pd 報告中的統計數據將反映您已經運行了工作負載。
圖 14. 顯示統計數據為 0 的 WLM10.CMD 輸出
關閉 WLM10_OUTPUT.TXT 文件。
為模擬工作負載做好設置
遵循本小節的步驟設置一個顯示優先級時限分層的服務類。
找到並查看您從 WLMLab.zip 下載文件解壓出來的 WLM20.CMD 和 WLM21.DDL 腳本文件。注意,WLM20.CMD 調用 WLM21.DDL。這些腳本創建一個名為 WLM_SAMPLE_TABLE 的表(見圖 15)。然後,這些腳本將 200,000 條記錄插入到該表中。創建了表之後,您就可以對它運行工作負載。
圖 15. 創建一個可以運行工作負載的樣例表
從 CLP 輸入 WLM20.CMD 以運行該命令。運行這個命令需要幾分鐘時間。您可以在命令運行時繼續查看本教程的下一個步驟。
Data Studio
如果您喜歡的話,可以使用 Data Studio 產品(比如 Data Studio Administrator)來執行使用 Command Editor 的練習。結果是一樣的。
輸入 db2ce 啟動 DB2 Command Editor。
注意 :Command Editor 是已經在 DB2 9.7 中否定的 Control Center 工具集的一部分,但這些工具仍然受支持並且可用,因此您不必首先學習如何使用 Data Studio 產品(見側邊欄),本教程中的例子將使用 Command Editor 工具。您應該考慮使用新的 GUI 工具集,而不是 Control Center 工具。
在 Command Editor 中,導入從 WLMLab.zip 下載文件解壓出來的 WLM30.SQL 的內容(見圖 16)。為此,轉到菜單欄並選擇 Selected -> Open。默認情況下,該文件位於 C:\COBRA_LAB_SCRIPTS\WLM 目錄。
圖 16. 導入 WLM30.SQL 之後的 Command Editor
在這個例子中,您將以單個或組的形式運行 SQL 語句。注意,不要立即運行整個腳本。為了運行該腳本的單個行,可以在 Command Editor 中高亮顯示需要運行的行,然後單擊綠色箭頭圖標運行該語句。
如果您還沒有連接到 SAMPLE 數據庫,那麼在 WLM30.SQL 的頂部高亮顯示 CONNECT 語句,然後單擊綠色箭頭運行它(見圖 17)。
圖 17. 連接到 SAMPLE 數據庫
在標題 #1 Workload -> service class occurrences 下高亮顯示第一個查詢,然後單擊綠色箭頭運行它(見圖 18)。
圖 18. 在 Command Editor 中運行 #1 Workload 查詢
通過使用 Command Editor 的 Query Results 查詢頁面查看查詢的結果(見圖 19)。
圖 19. #1 Workload 查詢的結果
關於這些結果,需要注意:
因為您沒有運行真正的工作負載,所以結果僅顯示您連接到 Command Editor(如果您使用 Data Studio Administrator,很可能得到一個 JDBC 連接)。
您使用的是默認的工作負載 SYSDEFAULTUSERWORKLOAD,它映射到您前面用新的 wlmtiersdefault.db2 樣例腳本創建的 WLM_TIERS 服務超類。
在下一個小節中,您將使用一些真正的工作負載,並觀察結果的變化。
開始第一個模擬工作負載
遵循本小節的步驟,開始使用第一個模擬工作負載。
找到並查看您從 WLMLab.zip 下載文件解壓出來的 WLM22.CMD、WLM28.BAT 和 WLM29.DML 腳本文件。
WLM22.CMD 是您將運行的、模擬服務器工作負載的第一個腳本。它使用您之前創建的 WLM 環境。WLM22.CMD 作為 db2user1 用戶進行連接,並且通過一個存儲過程設置客戶機信息,從而使客戶機用戶為 db2user1(見圖 20)。還可以通過其他方法設置客戶機信息,但在這裡您必須使用存儲過程,因為您通過 CLP 提交工作負載。
圖 20. WLM22.CMD 在連接時將客戶機設置為 db2user1
WLM22.CMD 腳本的末尾運行 WLM28.BAT 200 次(見圖 21)。
圖 21. 作為用戶 db2user1 運行工作負載模擬腳本 200 次的 WLM22.CMD
WLM28.BAT 腳本調用 WLM29.DML(見圖 22)。
圖 22. WLM28.BAT 調用 WLM29.DML
WLM29.DML 腳本包含運行 200 次的工作負載。它由各種實用程序調用組成,比如 SELECT(見圖 23)、UPDATE、INSERT 和 DELETE 等等。
圖 23. WLM29.DML SELECT 語句
轉到 CLP 並輸入 WLM22.CMD 讓 db2user1 用戶運行這個工作負載 200 次。
注意:在運行 WLM22.CMD 之前,確保您在前面小節中運行的 WLM20.CMD 腳本已經完成。
開始運行 WLM22.CMD 之後,CLP 窗口在以 db2user1 用戶的身份運行工作負載 200 次期間會被鎖定(見圖 24)。
圖 24. db2user1 運行工作負載 200 次
返回到 Command Editor 並運行 #1 Workload -> service class occurrences 查詢,然後查看 Query Results 頁面(見圖 25)。
圖 25. 第二次運行 #1 Workload 查詢的結果
注意,db2user1 用戶被映射到 CLP_Workload_User1 工作負載。這是因為當您使用 WLM04.DB2 腳本創建工作負載時,您在 CLIENT_USERID 連接屬性上使用了通配符特性,如下所示:
CURRENT CLIENT_USERID('db2user*')
從 Command Editor 運行 #2 Service class activity counts - In-memory statistics function 查詢並查看 Query Results 頁面(見圖 26)。
圖 26. 運行 #2 Service class activity counts 查詢的結果
CLP_Workload_User1 工作負載被分配給 CLP_Serv_User 超類,所以 CLP_Serv_User 的完成活動的總數表示由 WLM22.CMD 腳本運行的活動。(您的運行結果得出的實際數量可能與圖中顯示的不同)。
WLM_TIERS 服務超類的活動總是表示您從 Command Editor(或 Data Studio)運行的任何 SQL。這是因為您的默認工作負載映射到 WLM_TIERS 服務超類,並且您作為分配給默認工作負載的用戶進入 Command Editor。您每次在 Command Editor 中運行查詢時,活動的數量都會增加。
注意:保持打開運行 WLM22.CMD 的 CLP 窗口,然後運行本教程的其他腳本。不要關閉該窗口。
開始第二個模擬工作負載
遵循本小節的步驟開始使用第二個模擬工作負載。
找到並查看從 WLMLab.zip 下載文件解壓出來的 WLM23.CMD 腳本文件。WLM23.CMD 是您將在數據庫上運行的第二個模擬工作負載。它和 WLM22.CMD 一樣運行 200 次,但使用不同的用戶 ID。WLM23.CMD 運行的用戶 ID 為 db2cobra(見圖 27),這是您用於登錄的用戶 ID。
圖 27. WLM23.CMD 使用用戶 ID db2cobra 模擬另一個工作負載
打開第二個 CLP 窗口並輸入 WLM23.CMD 以運行啟動第二個模擬工作負載的命令。現在,您有兩個運行模擬工作負載的 CLP 窗口(見圖 28)。
圖 28. 兩個運行模擬工作負載的 CLP 窗口
由於您在開始第一個和第二個工作負載時消耗了一些時間,db2cobra 運行的次數將比 db2user1 運行的次數少。
返回到 Command Editor 並運行 #1 Workload -> service class occurrences 查詢,然後查看 Query Results 頁面。
現在的結果包含用戶 ID db2cobra,它被映射到 CLP_Workload_Admin 工作負載。這是因為當您使用 WLM04.DB2 腳本創建工作負載時,您在 CLIENT_USERID 連接屬性上顯式地指定了 db2cobra(當前登錄的用戶),如下所示:
CURRENT CLIENT_USERID('db2cobra')
從 Command Editor 再次運行 #2 Service class activity counts 查詢並查看 Query Results 頁面(見圖 29)。
圖 29. 運行 #2 Service class activity counts 查詢的結果
注意,CLP_Serv_Admin 超類的一些活動映射到 CLP_Serv_Admin_HI 子類,而它的另一些活動映射到 CLP_Serv_Admin_MED 子類。這是取決於您使用 WLM04.DB2 腳本為 CLP_Serv_Admin 定義工作操作集的方式。工作操作集將寫操作映射到 CLP_Serv_Admin_HI 子類,而將讀操作映射到 CLP_Serv_Admin_MED 子類。下一個步驟詳細顯示了該過程。
從 Command Editor 運行 #3 Work Action Set Activity Count - In-memory statistics function 查詢並查看 Query Results 頁面(見圖 30)。
圖 30. 運行 #3 Work Action Set Activity Count 查詢的結果
現在,您可以看到 Admin_Actions 工作操作集的 Read_Work 和 Write_Work 類之間的活動的差異。這些結果還顯示了來自其他工作負載和服務類的行為如何映射到其他工作操作集中。
注意:讓運行 WLM23.CMD 腳本的第二個 CLP 窗口保持打開,然後運行本教程的其他腳本。不要關閉該窗口。
開始第三個模擬工作負載
遵循本小節的步驟開始使用第三個模擬工作負載。
找到並查看從 WLMLab.zip 下載文件解壓出來的 WLM24.CMD 腳本文件。WLM24.CMD 是您將在數據庫上模擬工作負載運行的第三個腳本。它與 WLM22.CMD 和 WLM23.CMD 一樣運行 200 次工作負載,但使用另一個用戶 ID。WLM24.CMD 使用用戶 db2default 運行。
打開第三個 CLP 窗口並輸入 WLM24.CMD 以運行開始第三個模擬工作負載的命令。現在您有 3 個分別以不同用戶運行模擬工作負載的 CLP 窗口(見圖 31)。
圖 31. 運行模擬工作負載的 3 個 CLP 窗口
從 Command Editor 再次運行 #1 Workload -> service class occurrences 查詢並查看 Query Results 頁面。
現在的結果包含 db2default 用戶 ID,它映射到您使用 WLM04.DB2 腳本創建的默認工作負載 SYSDEFAULTADMWORKLOAD。
從 Command Editor 再次運行 #2 Service class activity counts 查詢,然後查看 Query Results 頁面(圖 32)。
圖 32. 運行第三個 #2 Service class activity counts 查詢的結果
db2default 用戶的活動映射到您使用 wlmtiersdefault.db2 腳本定義的 WLM_TIERS 服務超類的 WLM_SHORT 服務子類。WLM_SHORT 服務子類開始完成更多的活動,因為 db2default 用戶現在也完成該服務子類中的大部分工作。
您還可能會看到一些活動失敗了。這是因為這些活動對其他活動是鎖定的,一定時間之後就會超時。
從 Command Editor 運行 #4 long query to test activity remapping 查詢。
這個查詢專門編寫得低效一些,它需要超過 5 秒鐘才能運行完畢。這比在 wlmtIErsdefault.db2 腳本中定義的阈值要大,因此該活動將從 WLM_SHORT 服務子類重新映射到 WLM_MEDIUM 服務子類。
在 #4 long query to test activity remapping 完成之後,再次運行 #2 Service class activity counts 查詢並查看 Query Results 頁面(見圖 33)。
圖 33. 運行 #2 Service class activity counts 查詢的結果
這些結果顯示一個活動被從 WLM_SHORT 重新映射到 WLM_MEDIUM 服務子類。活動達到了 WLM_SHORT 阈值是發生重新映射的原因。這是 DB2 9.7 中的新特性。
注意:保持運行 WLM24.CMD 腳本的第三個 CLP 窗口打開,並運行本教程的其他剩余腳本。不要關閉該窗口。
處理事件監控器
遵循本小節的步驟,了解如何使用 WLM 事件監控器。
從 Command Editor 高亮顯示並運行 CALL WLM_COLLECT_STATS() 存儲過程(見圖 34)。
圖 34. 收集事件監控器統計數據的存儲過程
要查看 CALL WLM_COLLECT_STATS() 存儲過程對常駐型統計數據的影響,請轉到 Command Editor 並再次運行 #2 Service class activity counts 查詢,然後查看 Query Results 頁面。
注意,該存儲過程將您的常駐型計數器重置為 0。
要查看 CALL WLM_COLLECT_STATS() 存儲過程對活動 WLM 事件監控器的影響,請轉到 Command Editor 並運行 #5 Workload event monitor summary table select 查詢,然後查看 Query Results 頁面。
這些結果顯示第一個事件監控器表 WLSTATS_DB2STATISTICS,並標明該存儲過程將當前的統計數據寫到您的所有活動 WLM 事件監控器。
從 Command Editor 運行 #6 Workload aggregate event monitor summary table select 查詢,然後查看 Query Results 頁面(見圖 35)。
圖 35. 運行 #6 Workload aggregate event monitor summary table select 查詢的結果
這個查詢顯示了新的 DB2 9.7 特性,它使您能夠在工作負載級別聚合活動數據。注意,這些結果僅顯示兩個工作負載的聚合信息。這是因為您在使用 WLM04.DB2 創建定制的 WLM 環境時僅定義兩個收集統計數據的工作負載(見圖 36)。
圖 36. 在 WLM04.DB2 中定義的聚合活動信息收集
從 Command Editor 運行 #7 Service Class event monitor summary table select 查詢,並查看 Query Results 頁面。
從 Command Editor 運行 #8 Work Action Set event monitor summary table select 查詢,並查看 Query Results 頁面。
從 Command Editor 運行 #9 Threshold violations event monitor summary table select 查詢,並查看 Query Results 頁面(見圖 37)。
圖 37. 運行 #9 Threshold violations event monitor summary table select 查詢的結果
這個查詢顯示了一個阈值違反事件監控器,它導致了重新映射操作。這是 DB2 9.7 中的新特性。
使用 db2pd 實用程序
遵循本小節的步驟,了解如何使用 db2pd 實用程序和完整的表查詢。
打開第 4 個 CLP 窗口並輸入 WLM10.CMD 運行調用 db2pd 實用程序的命令。打開 WLM10_OUTPUT.TXT 文件查看來自 db2pd 實用程序的輸出(見圖 38)。
圖 38. 顯示當前工作負載統計數據的 WLM10.CMD 輸出
您在前面設置分層服務類時使用的就是 WLM10.CMD 命令。先前,WLM10_OUTPUT.TXT 表明您沒有任何工作負載。但是現在您擁有了工作負載。
返回到 Command Editor 並運行 WLM30.SQL 文件末尾提供的查詢(見圖 39),然後查看對應的 Query Results 頁面。這使您能夠查看來自完整的表查詢的結果。
圖 39. WLM30.SQL 末尾的完整表查詢
結束語
DB2 9.7 LUW Workload Manager 是一個強大並且易於使用和定制的特性,您可以在自己的環境中使用它,以確保滿足服務水平協議以及其他管理或用戶需求。它使您能夠控制復雜數據庫工作負載的使用,而且不需要更改程序代碼。本教程向您展示了如何利用 DB2 9.7 for LUW 中的新特性,比如服務類優先級時限、連接屬性通配符、地址連接屬性和服務類緩沖池 I/O 優先級。
本文示例源代碼或素材下載