**No.5 Which Workload Manager (WLM) objects can the COLLECT ACTIVITY DATA clause be
used with?**
A. Data class, work class, and a limit
B. Data class, action class, and a threshold
C. Service subclass, action class, and a limit
D. Service subclass, work class, and a threshold
Workload Manager 是DB2高级企业服务器版本和高级工作组服务器版本所具有的特性,它可以将数据库工作划分到不同的buckets内。 一个work bucket 可以获得优先的执行权以及CPU和存储器的优先使用权,而另个bucket则获得一个较低的资源使用权。关键的业务流程可能需要保证拥有对系统资源的最大使用权,而一个突发的TOAD user 则需要避免其获得对资源的垄断使用权。相比较与一堆的 I/O、内存缓冲池、锁列表排序堆等报告,一个以应用程序为中心的性能监控所产生的优异的性能报告则更容易被客户所理解。虽然传统的技术报告对于技术娴熟的DBA们来说可能是一个非常有趣的读物,但这些报告对于应用程序的开发人员和客户来说可能没有多少意义。和其他团队使用同一语言可以帮助他们更好地理解数据库性能。这正是DB2 Workload Management所擅长的地方。
注:使用企业服务器版DB2,您将不能创建新的工作负载和服务类,但你仍然可以修改以监控和管理工作量为目的默认WLM对象。
WLM的生态系统是由多个部分组成的。在部署WLM之前,了解WLM生态系统的组成部分同样很重要。
*Service class 定义了work可以运行的执行环境。这个执行环境分配给可用资源(CPU、内存等)一个特定的阈值,该阈值决定了工作是如何运行的。
可以这样理解---一个service class 是一个分配给work运行的环境或者bucket。不同的buckets和service classes 对和他们相关的资源(像预取优先权和缓冲池优先权等)都有不同的资源控制设定,并且可以设置相互关联的阀值。*
DB2 拥有3个默认的 service superclasses (父类服务):
SYSDEFAULTSYSTEMCLASS
SYSDEFAULTMAINTENANCECLASS
SYSDEFAULTUSERCLASS
subclass是父类buckets下面一个小一点的bucket。尽管service superclass是最高级别的服务,但是活动总是运行在子类服务上。每个父类服务有一个默认的子类服务,这个子类服务被用来运行不需要你定义或者指定的子类活动。
DB2拥有两个默认的subclasses(子类服务):
SYSDEFAULTSUBCLASS
SYSDEFAULTMANAGEDSUBCLASS
你可以使用 SYSCAT.SERVICECLASSES 编目视图去查看系统中默认的父类服务和子类服务。
db2 "select serviceclassname, parentserviceclassname from syscat.serviceclasses with UR"
SERVICECLASSNAME PARENTSERVICECLASSNAME
---------------------------------------------------------------------------------------------------------------------------
SYSDEFAULTSUBCLASS SYSDEFAULTSYSTEMCLASS
SYSDEFAULTSUBCLASS SYSDEFAULTMAINTENANCECLASS
SYSDEFAULTMANAGEDSUBCLASS SYSDEFAULTUSERCLASS
SYSDEFAULTMAINTENANCECLASS -
SYSDEFAULTSYSTEMCLASS -
SYSDEFAULTUSERCLASS -
*注意 SERVICECLASSNAMES :
SYSDEFAULTMAINTENANCECLASS,
SYSDEFAULTSYSTEMCLASS,
SYSDEFAULTUSERCLASS并没有任何的 PARENTSERVICECLASSNAME ,就像上面提到的一样他们是默认的父类服务(也是最高级的服务)*。
把工作负载器看作是一个铲子,它识别工作,将它捡起来,为了运行这些工作将其转储到类服务(service classes)或buckets中。DB2 WLM允许你识别基于不同属性的应用程序,像程序名,session用户,客户端工作站名称等等。和默认的service classes一样,DB2也拥有默认的workloads。
db2 "select workloadname, serviceclassname, parentserviceclassname from syscat.workloads with UR"
WORKLOADNAME SERVICECLASSNAME PARENTSERVICECLASSNAME
------------------------------------------------------------------------------------------------
SYSDEFAULTUSERWORKLOAD SYSDEFAULTSUBCLASS SYSDEFAULTUSERCLASS
SYSDEFAULTADMWORKLOAD SYSDEFAULTSUBCLASS SYSDEFAULTUSERCLASS
就像你从SYSCAT.WORKLOADS 编目视图看到的那样,DB2有两个默认的Workloads:SYSDEFAULTUSERWORKLOAD 和 SYSDEFAULTADMWORKLOAD。
通过上面的铲子和bucket例子我们可以得出这样的结论:DB2把所有来自systemdefaultuserworkload和systemdefaultadminworkload的所有转储工作到systemdefaultuserclass父类服务和子类systemdefaultsubclass服务。
Workclass集是将不同的工作负载组集合在一起 。一旦workclass集被创建,我们可以创建work action 集,他将诠释一个指定的workclass集是怎么被控制的。Work classes总是作为workclass集的一部分被创建而不是作为单独的对象被创建。
DB2 有下面的 default workclass 和 workclassset.
db2 "select workclassname, workclasssetname from syscat.workclasses with UR"
WORKCLASSNAME WORKCLASSSETNAME
---------------------------------------------------------------------------------------------
SYSMANAGEDQUERIES SYSDEFAULTUSERWCS
下面是IBM Knowledge Center的一个示例:
CREATE WORK CLASS SET LARGE_QUERIES
(WORK CLASS LARGE_ESTIMATED_COST WORK TYPE DML
FOR TIMERONCOST FROM 9999 TO UNBOUNDED,
WORK CLASS LARGE_CARDINALITY WORK TYPE DML
FOR CARDINALITY FROM 1000 TO UNBOUNDED)
此示例创建一个名称为LARGE_QUERIES的workclass set ,它将采集timeroncost值(估算值)大于9999和预估cardinality值(估算值) 大于1000的所有DML活动。可以注意到LARGE_QUERIES 包含两个work classes: LARGE_ESTIMATED_COST 和 LARGE_CARDINALITY。
Workaction sets定义了如何向归属在workclass sets下的workloads提供服务。
回顾下前面 workclass set 示例, 名称为DATABASE_ACTIONS 的work action set定义了2个work actions。
名为ONE_CONCURRENT_QUERY的Work action 将会管理LARGE_QUERIES workclass set下的所有work,它的功能:如果 concurrentdbcoordactivites >1(有1个以上的并发活动) 同时queuedactivities >1 (有超过1个队列活动) 而且 the work隶属于 workclass LARGE_ESTIMATED_COST,该Work action 将会停止执行查询活动和SQL语句!!!
名为TWO_CONCURRENT_QUERIES的Work action将会管理LARGE_QUERIES workclass set下的所有Work,它的作用:如果 concurrentdbcoordactivites >2 (有两个以上的并发活动)同时 queuedactivities >2(有超过两个队列活动) 而且这个 work 隶属于LARGE_CARDINALITY workclass,它将收集活动数据并继续运行DML。
CREATE WORK ACTION SET DATABASE_ACTIONS
FOR DATABASE USING WORK CLASS SET LARGE_QUERIES
(WORK ACTION ONE_CONCURRENT_QUERY ON WORK CLASS LARGE_ESTIMATED_COST
WHEN CONCURRENTDBCOORDACTIVITIES > 1 AND QUEUEDACTIVITIES > 1
STOP EXECUTION,
WORK ACTION TWO_CONCURRENT_QUERIES ON WORK CLASS LARGE_CARDINALITY
WHEN CONCURRENTDBCOORDACTIVITIES > 2 AND QUEUEDACTIVITIES > 2
COLLECT ACTIVITY DATA CONTINUE)
通过上面的文章,我们现在应该对service superclasses, service classes, workloads, work class sets, and work action sets 有所了解。 下面的图表描述了在数据库环境中如何将工作分配到service classes 和 subclasses的。
下面将探讨建立一个非常简单的监控策略所需要的步骤。
定义一个监控策略——你想要监控什么?为什么?
创建一个表空间,该表空间将保存监测数据;
创建活动监视器,它将捕获活动并汇总数据库活动的统计数据;这些是与WLM相关的特殊活动事件监控器;
执行已经定义了服务超类、服务子类以及监视策略周围的工作负载的监控策略;
打开收集监测数据的“开关”(switch)。
过程流程图:
在这个示例中,我们有一个报表应用程序,它每天运行报表。还有其他一些应用程序也会对同一数据库进行访问,但我们只关心针对报表应用程序的监视工作。
该报表应用程序由两个主机运行,其IP地址分别为101.7.64.98和101.7.64.99。我们将创建一个名为REPORTING的service superclass和一个名为SLARPTSC的service sub class。然后我们创建一个名为SLARPTWL的工作负载,并定义它将来自这两个主机的所有活动转储到 REPORTING superclass下面名为SLARPTSC 的 service subclass中。
在我们的示例中,我们使用单分区数据库。我们将创建一个自动存储表空间。
DDL如下:
CREATE LARGE TABLESPACE "TBLSP_WLM" IN DATABASE PARTITION GROUP IBMDEFAULTGROUP
PAGESIZE 4096 MANAGED BY AUTOMATIC STORAGE
USING STOGROUP "IBMSTOGROUP"
AUTORESIZE YES
INITIALSIZE 1 M
INCREASESIZE 20 M
MAXSIZE 5 G
EXTENTSIZE 16
PREFETCHSIZE AUTOMATIC
BUFFERPOOL "BP4K"
DATA TAG INHERIT
OVERHEAD 7.500000
TRANSFERRATE 0.060000
NO FILE SYSTEM CACHING
DROPPED TABLE RECOVERY ON;
如果您正在为DB2 DPF环境创建一个WLM解决方案,请确保监视表空间分布在数据库的所有分区上。
WLM事件监控器是特殊的写入表内的事件监视器,它们捕获监视数据并将其加载到物理表中。活动事件监视器捕捉特定数据库活动的信息,而统计事件监视器捕捉聚合性能数据。DDL如下:
定义名称为DB2ACTIVITIES的活动事件监视器:
CREATE EVENT MONITOR DB2ACTIVITIES
FOR ACTIVITIES
WRITE TO TABLE
ACTIVITY (TABLE ACTIVITY_DB2ACTIVITIES
IN TBLSP_WLM
PCTDEACTIVATE 100),
ACTIVITYSTMT (TABLE ACTIVITYSTMT_DB2ACTIVITIES
IN TBLSP_WLM
PCTDEACTIVATE 100),
ACTIVITYVALS (TABLE ACTIVITYVALS_DB2ACTIVITIES
IN TBLSP_WLM
PCTDEACTIVATE 100),
CONTROL (TABLE CONTROL_DB2ACTIVITIES
IN TBLSP_WLM
PCTDEACTIVATE 100)
AUTOSTART;
CREATE EVENT MONITOR DB2STATISTICS
FOR STATISTICS
WRITE TO TABLE
SCSTATS (TABLE SCSTATS_DB2STATISTICS
IN TBLSP_WLM
PCTDEACTIVATE 100),
WCSTATS (TABLE WCSTATS_DB2STATISTICS
IN TBLSP_WLM
PCTDEACTIVATE 100),
WLSTATS (TABLE WLSTATS_DB2STATISTICS
IN TBLSP_WLM
PCTDEACTIVATE 100),
QSTATS (TABLE QSTATS_DB2STATISTICS
IN TBLSP_WLM
PCTDEACTIVATE 100),
HISTOGRAMBIN (TABLE HISTOGRAMBIN_DB2STATISTICS
IN TBLSP_WLM
PCTDEACTIVATE 100),
CONTROL (TABLE CONTROL_DB2STATISTICS
IN TBLSP_WLM
PCTDEACTIVATE 100)
AUTOSTART;
用于创建服务类和子类的DDL:
CREATE SERVICE CLASS REPORTING;
CREATE SERVICE CLASS SLARPTSC UNDER REPORTING;
用于创建工作负载的DDL:
CREATE WORKLOAD SLARPTWL ADDRESS ('101.7.64.98', '101.7.64.99') service class SLARPTSC under REPORTING;
一旦创建了服务类和工作负载,您就可以通过下面的方式找到关于它们的信息.
db2pd –db TESTDB –----serviceclasses
db2pd –db TESTTB ------workloads
db2 "SELECT SUBSTR(WORKLOAD_NAME, 1, 22) AS WL_DEF_NAME, WLO_COMPLETED_TOTAL, CONCURRENT_WLO_ACT_TOP FROM TABLE(WLM_GET_WORKLOAD_STATS(CAST(NULL AS VARCHAR(128)), -2)) AS WLSTATS"
WL_DEF_NAME WLO_COMPLETED_TOTAL CONCURRENT_WLO_ACT_TOP
SLARPTWL 0 1
SYSDEFAULTUSERWORKLOAD 190 2
SYSDEFAULTADMWORKLOAD 0 0
性能监视数据收集可以在活动级别和聚合级别上启用。请在IBM Knowledge Center查阅“create service class”和 “create workload ”语句,以获取更多关于活动和聚合级别数据收集的信息。
在这种情况下,我们将收集在服务类级别上数据扩展的聚合活动和基于service class级别的数据请求聚合活动,以及工作负载级别的聚合活动数据。
IBM Knowledge Center 网址:
IBM® IBM Knowledge Center
DDL如下:
ALTER SERVICE CLASS SLARPTSC UNDER REPORTING COLLECT AGGREGATE ACTIVITY DATA EXTENDED;
ALTER SERVICE CLASS SLARPTSC UNDER REPORTING COLLECT AGGREGATE REQUEST DATA BASE;
ALTER WORKLOAD SLARPTWL COLLECT AGGREGATE ACTIVITY DATA EXTENDED;
当你想要删除service class或workload时,首先需要禁用它。然后在drop service类语句中,您需要提到superclass 和subclass的 关系,否则你将无法删除它们
下面是我们可以用来删除前面创建的服务类和工作负载的语句:
alter workload slarptwl disable
drop workload slarptwl
alter service class slarptsc under reporting disable
drop service class slarptsc under reporting
alter service class reporting disable
drop service class reporting
您必须将适当的权限授予工作负载的使用者。在本例中,我们将工作负载使用权分配给wlmuser组:
GRANT USAGE ON WORKLOAD SLARPTWL TO WLMUSER;
请注意:您需要确保所有通过这两个主机的用户都是组“wlmuser”的成员,否则它们将不会映射到工作负载。
现在我们已经建立了基础架构,我们需要收集性能监控数据并将数据加载到事件监控表中。下面展示的两种方法:
db2 => CALL SYSPROC.WLM_COLLECT_STATS()
Return Status = 0
这个存储过程将手动将性能监视数据加载到WLM事件监控表中,并从内存中重新设置它们。
这个参数将根据设定的值自动每N分钟收集一次数据。可以使用' get db cfg和update db cfg '命令来查看和更新这个数据库配置参数。
db2 get db cfg for testdb | grep WLM_COLLECT_INT --查看
WLM Collection Interval (minutes) (WLM_COLLECT_INT) = 240
db2 update db cfg for testdb using grep WLM_COLLECT_INT 240 --更新
DB2工作负载管理对象可用于收集两种类型的数据
a).聚合类数据统计—---这些数据将收集总体级别的指标,如平均执行时间、平均CPU利用率等。这是从整体上查看服务类比较廉价的方法。
b).活动信息——它收集活动级别粒度的信息,并可用于对特定问题进行故障排除。这可能是非常资源密集型的。
当启用service class, workload 和 work class来收集统计数据或活动级数据时,监视数据就会被保存在内存中。可以使用WLM_GET_SERVICE_SUBCLASS_STATS和WLM_GET_WORKLOAD_STATS等表函数查看存储在内存中的统计数据。我们将在下一章节中详细讨论这个问题。使用sysproc . wlm_collect_stats()存储过程或将WLM_COLLECT_INT数据库配置参数设置为某个值,我们可以调用统计和活动事件监视器,并使用它们将内存中的数据存储到事件监视器表中。需要注意的是,无论是通过WLM_COLLECT_INT数据库配置参数调用sysproc . wlm_collect_stats()过程还是将监控数据自动收集到事件监视器表中的任何调用都将重置内存中的监控数据。这样我们就可以获得统计趋势。事件监视器将此监视信息加载到我们前面创建的WLM事件监视器表中。
此时,您应该能够看到创建的以下事件监视器表。注意以_db2activities结尾的表名,它维护活动类型信息,以 _db2statistics结尾的表名,这些表名维护聚合性能数据。
db2 list tables for schema inst01
--------------------------------------------------------------------------------------------------
Table/View Schema ype Creation time
------------------------------- --------------- ----- ----------------------------------------------------------
ACTIVITYSTMT_DB2ACTIVITIES db2inst01 T 2014-05-28-15.57.53.761735
ACTIVITYVALS_DB2ACTIVITIES db2inst01 T 2014-05-28-15.57.53.797127
ACTIVITY_DB2ACTIVITIES db2inst01 T 2014-05-28-15.57.53.729954
CONTROL_DB2ACTIVITIES db2inst01 T 2014-05-28-15.57.53.719138
CONTROL_DB2STATISTICS db2inst01 T 2014-05-28-15.57.53.826357
HISTOGRAMBIN_DB2STATISTICS db2inst01 T 2014-05-28-15.57.53.915142
QSTATS_DB2STATISTICS db2inst01 T 2014-05-28-15.57.53.903199
SCSTATS_DB2STATISTICS db2inst01 T 2014-05-28-15.57.53.836101
WCSTATS_DB2STATISTICS db2inst01 T 2014-05-28-15.57.53.862970
WLSTATS_DB2STATISTICS db2inst01 T 2014-05-28-15.57.53.873555
**对于从WLM表中删除数据,实际上没有任何实用或命令。您需要创建自己的delete语句来从这些表中删除数据。
本节讨论了实现和设置WLM监控策略所涉及的步骤。在最后一篇文章中,我们将看到一些有趣的性能报告和从这个配置中提取的直方图。**
下面将介绍一些可以用来查看性能趋势并简要介绍直方图的报告,这些都是非常酷的技术。
如前所述,DB2将一直在内存中存储监控数据,直到通过调用WLM_COLLECT_STATS()存储过程或由WLM_COLLECT_INT数据库参数设置的自动数据捕获设定来具体化(load)到WLM事件监视器表并清空内存。
可以使用表函数查看DB2内存中仍然存在的监控数据:
MON_GET_SERVICE_SUBCLASS
MON_GET_SERVICE_SUBCLASS_DETAILS
MON_GET_SERVICE_SUBCLASS_STATS
MON_GET_SERVICE_SUPERCLASS_STATS
MON_GET_WORKLOAD
MON_GET_WORKLOAD_DETAILS
MON_GET_WORKLOAD_STATS
以WLM_GET_SERVICE_SUBCLASS_STATS表函数为例:
SELECT VARCHAR(SERVICE_SUPERCLASS_NAME, 30) AS SUPERCLASS,
VARCHAR(SERVICE_SUBCLASS_NAME, 30) AS SUBCLASS,
LAST_RESET,
NUM_REQUESTS_TOTAL,
REQUEST_EXEC_TIME_AVG,
REQUEST_EXEC_TIME_TOTAL,
UOW_THROUGHPUT,
UOW_COMPLETED_TOTAL,
TOTAL_CPU_TIME,
FROM TABLE(SYSPROC.WLM_GET_SERVICE_SUBCLASS_STATS('REPORTING',
'SLARPTSC', -1)) AS T;
-----------------------------------------------------------------
SUPERCLASS SUBCLASS LAST_RESET NUM_REQUESTS_TOTAL REQUEST_EXEC_TIME_AVG
----------------------------------------------------------------------------------------------
REPORTING SLARPTSC 2014-07-07-12.00.10.977721 272 +5.40000000000000E-002
Output continued....
REQUEST_EXEC_TIME_TOTAL UOW_THROUGHPUT UOW_COMPLETED_TOTAL TOTAL_CPU_TIME
136 +8.26245471835136E-002 68 94587
从查询的结果可以看出, service superclass “REPORTING”的service subclass “SLARPTSC” 于7月7日12时被重置过。自上次重置以来,这个服务类的平均SQL请求执行时间为+ 5.40000000000000e - 002毫秒,完成了68个UOW活动
下面的SQL可以使用存储历史数据的事件监视器表来获取服务类“SLARPTSC”的类似服务类统计数据。
SELECT VARCHAR(SERVICE_SUPERCLASS_NAME, 30) AS SUPERCLASS,
VARCHAR(SERVICE_SUBCLASS_NAME, 30) AS SUBCLASS,
LAST_WLM_RESET,
REQUEST_EXEC_TIME_AVG,
UOW_COMPLETED_TOTAL
FROM SCSTATS_DB2STATISTICS where SERVICE_SUBCLASS_NAME = 'SLARPTSC';
SUPERCLASS SUBCLASS LAST_WLM_RESET REQUEST_EXEC_TIME_AVG UOW_COMPLETED_TOTAL
REPORTING SLARPTSC 2014-05-29-09.45.08.261369 0 10
REPORTING SLARPTSC 2014-05-29-09.56.51.716245 0 4
REPORTING SLARPTSC 2014-05-29-10.01.44.728405 0 10
REPORTING SLARPTSC 2014-05-29-10.14.42.899526 0 4
REPORTING SLARPTSC 2014-05-29-10.19.03.255451 0 142
REPORTING SLARPTSC 2014-05-29-13.58.57.710431 1 7640824
这些数据告诉我们,自2014 -05-29-13.58 57.710431重置以来,平均请求执行时间为1毫秒,完成了7640824个工作单元。
可以使用类似的SQL从历史WLSTATS_DB2STATISTICS表查找有关工作负载的统计数据。
SELECT VARCHAR(WORKLOAD_NAME, 30) AS WORKLOAD_NAME,
LAST_WLM_RESET,
LOCK_WAIT_TIME_TOP,
ROWS_RETURNED_TOP,
UOW_LIFETIME_AVG
FROM WLSTATS_DB2STATISTICS where WORKLOAD_NAME ='SLARPTWL';
WORKLOAD_NAME LAST_WLM_RESET LOCK_WAIT_TIME_TOP ROWS_RETURNED_TOP UOW_LIFETIME_AVG
SLARPTWL 2014-05-29-11.00.37.167154 264041 246 3
SLARPTWL 2014-05-29-14.13.08.173211 2458262 246 3
上面的输出为我们提供了锁等待时间、返回的行和工作生命周期的平均工作时间,以及每一个WLM重置时间。
显示一些聚合性能报告的SQLs:
SELECT DATE(statistics_timestamp) AS stat_date, TIME(statistics_timestamp) AS stat_time,
SUBSTR(service_subclass_name,1,10) AS subclass_name,
CASE WHEN 0 > INT(SUM(concurrent_act_top))
THEN 0 ELSE
INT(SUM(concurrent_act_top))
END AS con_act_top,
CASE WHEN 0 > INT(SUM(concurrent_connection_top))
THEN 0 ELSE INT(SUM(concurrent_connection_top))
END AS CON_CONN_TOP,
CASE WHEN 0 > INT(SUM(coord_act_completed_total))
THEN 0 ELSE INT(SUM(coord_act_completed_total))
END AS coord_act_comp,
CASE WHEN 0 > INT(SUM(coord_act_exec_time_avg))
THEN 0 ELSE INT(SUM(coord_act_exec_time_avg))
END AS avg_c_exe_tm,
CASE WHEN 0 > INT(SUM(request_exec_time_avg))
THEN 0 ELSE INT(SUM(request_exec_time_avg))
END AS avg_r_exe_tm
FROM db2inst01.scstats_db2statistics
WHERE CHAR(DATE(statistics_timestamp)) = CURRENT DATE
AND SERVICE_SUBCLASS_NAME = 'SLARPTSC'
GROUP BY DATE(statistics_timestamp), TIME(statistics_timestamp),
SUBSTR(service_subclass_name,1,10) ORDER BY 1,2,3
STAT_DATE STAT_TIME SUBCLASS_NAME CON_ACT_TOP CON_CONN_TOP AVG_C_EXE_TM AVG_R_EXE_TM
---------- --------- ------------- ----------- ------------ -------------- ------------
07/07/2014 00:00:21 SLARPTSC 1 2 0 2
07/07/2014 04:00:22 SLARPTSC 1 2 0 3
07/07/2014 08:00:24 SLARPTSC 1 2 0 4
07/07/2014 12:00:10 SLARPTSC 1 2 0 2
上面的SQL以统计日期、时间和子类名分组显示了服务类SLARPTSC的top concurrent connections和平均执行时间,。
SELECT DATE(statistics_timestamp) AS stat_date,
TIME(statistics_timestamp) AS stat_time,
SUBSTR(service_subclass_name,1,10) AS subclass_name,
CASE WHEN 0 > INT(SUM(act_cpu_time_top))
THEN 0 ELSE INT(SUM(act_cpu_time_top))
END AS act_cpu_time_top,
CASE WHEN 0 > INT(SUM(act_rows_read_top))
THEN 0 ELSE INT(SUM(act_rows_read_top))
END AS act_rows_read_top,
CASE WHEN 0 > INT(SUM(coord_act_completed_total))
THEN 0 ELSE INT(SUM(coord_act_completed_total))
END AS coord_act_completed_total,
CASE WHEN 0 > INT(SUM(concurrent_wlo_top))
THEN 0 ELSE INT(SUM(concurrent_wlo_top))
END AS concurrent_wlo_top,
CASE WHEN 0 > INT(SUM(coord_act_aborted_total))
THEN 0 ELSE INT(SUM(coord_act_aborted_total))
END AS coord_act_aborted_total
FROM db2inst01.scstats_db2statistics
WHERE service_subclass_name = 'SLARPTSC'
AND CHAR(DATE(statistics_timestamp)) = CURRENT DATE
GROUP BY DATE(statistics_timestamp), TIME(statistics_timestamp),
SUBSTR(service_subclass_name,1,10) ORDER BY 1,2,3
STAT_DATE STAT_TIME SUBCLASS_NAME ACT_CPU_TIME_TOP ACT_ROWS_READ_TOP
---------- --------- ------------- ---------------- ----------------- ------------------------- -
07/07/2014 00:00:21 SLARPTSC 147 142
07/07/2014 04:00:22 SLARPTSC 266 348
07/07/2014 08:00:24 SLARPTSC 266 348
07/07/2014 12:00:10 SLARPTSC 266 348
Output continued …..
COORD_ACT_COMPLETED_TOTAL CONCURRENT_WLO_TOP COORD_ACT_ABORTED_TOTAL
------------------------------------------------------------------------------------------------
0 2 0
0 2 0
0 2 0
0 2 0
上面的SQL提供了由stats date、stats time和subsclass名称分组统计出的像top cpu时间、top rows read等数据。
SELECT DATE(statistics_timestamp) AS stat_date,
TIME(statistics_timestamp) AS stat_time,
SUBSTR(service_subclass_name,1,10) AS subclass_name,
CASE WHEN 0 > INT(SUM(coord_act_est_cost_avg))
THEN 0 ELSE INT(SUM(coord_act_est_cost_avg))
END AS coord_act_est_cost_avg,
CASE WHEN 0 > INT(SUM(coord_act_exec_time_avg))
THEN 0 ELSE INT(SUM(coord_act_exec_time_avg))
END AS coord_act_exec_time_avg,
CASE WHEN 0 > INT(SUM(coord_act_interarrival_time_avg))
THEN 0 ELSE INT(SUM(coord_act_interarrival_time_avg))
END AS coord_act_interarrival_time_avg,
CASE WHEN 0 > INT(SUM(coord_act_lifetime_avg))
THEN 0 ELSE INT(SUM(coord_act_lifetime_avg))
END AS coord_act_lifetime_avg,
CASE WHEN 0 > INT(SUM(coord_act_lifetime_top))
THEN 0 ELSE INT(SUM(coord_act_lifetime_avg))
END AS coord_act_lifetime_avg,
CASE WHEN 0 > INT(SUM(coord_act_queue_time_avg))
THEN 0 ELSE INT(SUM(coord_act_queue_time_avg))
END AS coord_act_queue_time_avg
FROM db2inst01.scstats_db2statistics
WHERE service_subclass_name = 'SLAREPORTS'
AND CHAR(DATE(statistics_timestamp)) = CURRENT DATE
GROUP BY DATE(statistics_timestamp), TIME(statistics_timestamp), SUBSTR(service_subclass_name,1,10) ORDER BY 1,2,3
STAT_DATE STAT_TIME SUBCLASS_NAME COORD_ACT_EST_COST_AVG COORD_ACT_EXEC_TIME_AVG
---------------- ---------------------- ----------------------- -------------------------------
07/07/2014 00:00:21 SLARPTSC 6 0
07/07/2014 04:00:22 SLARPTSC 5 2
07/07/2014 08:00:24 SLARPTSC 6 0
07/07/2014 12:00:10 SLARPTSC 5 3
Output continued……
COORD_ACT_INTERARRIVAL_TIME_AVG COORD_ACT_LIFETIME_AVG COORD_ACT_QUEUE_TIME_AVG
49562 2 1
28392 3 1
44872 3 1
32700 3 1
上面的SQL按照统计日期、时间和服务类SLARPTSC分组的形式统计出像平均成本估算、平均执行时间、平均队列时间等的数据。
SELECT DATE(statistics_timestamp) AS stat_date,
TIME(statistics_timestamp) AS stat_time,
SUBSTR(service_subclass_name,1,10) AS subclass_name,
CASE WHEN 0 > INT(SUM(coord_act_rejected_total))
THEN 0 ELSE INT(SUM(coord_act_rejected_total))
END AS coord_act_rejected_total,
CASE WHEN 0 > INT(SUM(cost_estimate_top))
THEN 0 ELSE INT(SUM(cost_estimate_top))
END AS cost_estimate_top,
CASE WHEN 0 > INT(SUM(rows_returned_top))
THEN 0 ELSE INT(SUM(rows_returned_top))
END AS rows_returned_top,
CASE WHEN 0 > INT(SUM(temp_tablespace_top))
THEN 0 ELSE INT(SUM(temp_tablespace_top))
END AS temp_tablespace_top,
CASE WHEN 0 > INT(SUM(uow_total_time_top))
THEN 0 ELSE INT(SUM(uow_total_time_top))
END AS uow_total_time_top,
CASE WHEN 0 > INT(SUM(agg_temp_tablespace_top))
THEN 0 ELSE INT(SUM(agg_temp_tablespace_top))
END AS agg_temp_tablespace_top
FROM db2inst01.scstats_db2statistics
WHERE service_subclass_name = 'SLARPTSC'
AND CHAR(DATE(statistics_timestamp)) = CURRENT DATE
GROUP BY DATE(statistics_timestamp), TIME(statistics_timestamp),
SUBSTR(service_subclass_name,1,10) ORDER BY 1,2,3
STAT_DATE STAT_TIME SUBCLASS_NAME COORD_ACT_REJECTED_TOTAL COST_ESTIMATE_TOP
---------- --------- ------------- ------------------------ ----------------- -----------------
07/07/2014 00:00:21 SLARPTSC 0 8
07/07/2014 04:00:22 SLARPTSC 0 23
07/07/2014 08:00:24 SLARPTSC 0 23
07/07/2014 12:00:10 SLARPTSC 0 23
Output continued …..
ROWS_RETURNED_TOP TEMP_TABLESPACE_TOP UOW_TOTAL_TIME_TOP AGG_TEMP_TABLESPACE_TOP
-------------------------------------------------------------------------------------------------
1 0 6 0
1 0 24 0
1 0 8 0
1 0 38 0
上面的SQL以统计日期、时间和服务类SLARPTSC分组的统计了像临时表空间使用、返回的行、工作总时间单位等的统计数据。
在查询这些表的有用数据时,只有你想不到没有它做不到的。
**直方图是非常有用的。直方图是收集离散数据范围的工具集。
让我们创建一个直方图模板,将其分配给“SLARPTSC”服务子类,并创建一些直方图报告。
可以通过DB2的工作负载管理系统绘制七种类型的直方图。**
• CoordActQueue Time – Coordinator activity queue time
• CoordActLifetime – Coordinator activity Lifetime
• CoordActInterArrivalTime – Coordinator activity inter arrival time
• CoordActEstCost – Coordinator activity estimated cost
• ReqExecTime – Request execution time
• UOWLifetime – Unit of work lifetime
为ReqExectime指标创建一个直方图,以毫秒为单位定义
首先使用以下SQL创建一个模板和定义规模:
CREATE HISTOGRAM TEMPLATE REQEXEC HIGH BIN VALUE 90000
接下来,我们使用以下命令将此级别与服务类关联:
ALTER SERVICE CLASS SLARPTSC UNDER REPORTING REQUEST EXECUTETIME HISTOGRAM TEMPLATE REQEXEC
定义了直方图之后,数据将开始填充HISTOGRAMBIN_DB2STATISTICS表。在HISTOGRAMBIN_DB2STATISTICS表上创建一些视图会更容易,创建完成后便可以查询这些视图。
建议建立的视图:
CREATE VIEW HISTOGRAMTYPES AS
SELECT DISTINCT SUBSTR(HISTOGRAM_TYPE,1,24) AS HISTOGRAM_TYPE
FROM HISTOGRAMBIN_DB2STATISTICS;
------------------------------------------------------------------------------------------------
CREATE VIEW HISTOGRAMSERVICECLASSES AS
SELECT DISTINCT SUBSTR(HISTOGRAM_TYPE,1,24) AS HISTOGRAM_TYPE,
SUBSTR(PARENTSERVICECLASSNAME,1,24) AS SERVICE_SUPERCLASS,
SUBSTR(SERVICECLASSNAME,1,24) AS SERVICE_SUBCLASS
FROM HISTOGRAMBIN_DB2STATISTICS AS H,
SYSCAT.SERVICECLASSES AS S
WHERE H.SERVICE_CLASS_ID = S.SERVICECLASSID;
-----------------------------------------------------------------------------------------------
CREATE VIEW HISTOGRAMS(HISTOGRAM_TYPE,
SERVICE_SUPERCLASS,
SERVICE_SUBCLASS,
BIN_TOP,
NUMBER_IN_BIN) AS
SELECT DISTINCT SUBSTR(HISTOGRAM_TYPE,1,24) AS HISTOGRAM_TYPE,
SUBSTR(PARENTSERVICECLASSNAME,1,24) AS SERVICE_SUPERCLASS,
SUBSTR(SERVICECLASSNAME,1,24) AS SERVICE_SUBCLASS,
TOP AS BIN_TOP,
SUM(NUMBER_IN_BIN) AS NUMBER_IN_BIN
FROM HISTOGRAMBIN_DB2STATISTICS AS H,
SYSCAT.SERVICECLASSES AS S
WHERE H.SERVICE_CLASS_ID = S.SERVICECLASSID
GROUP BY HISTOGRAM_TYPE, PARENTSERVICECLASSNAME, SERVICECLASSNAME, TOP;
SQL用于分析“SLAREPORTS”服务类的请求执行时间直方图。
SELECT BIN_TOP, NUMBER_IN_BIN
FROM HISTOGRAMS
WHERE HISTOGRAM_TYPE = 'ReqExecTime'
AND SERVICE_SUPERCLASS = 'REPORTING'
AND SERVICE_SUBCLASS = 'SLARPTSC'
ORDER BY BIN_TOP;
查询结果:
BIN_TOP NUMBER_IN_BIN
-1 0
1 597
2 1
3 0
4 0
6 0
9 0
12 0
17 1
..
..
300000 0
可以看出,对于服务类的“SLARPTSC”,有597个请求在1毫秒内完成,1个请求在1 - 2毫秒内完成,1个请求在12 - 17毫秒内完成。
直方图是一个非常有用的工具,可以用来剖析SQL活动的运行情况,看看它们是否真的符合应用程序的SLA。
WLM不仅可以用于收集分配服务资源信息或监视SQL,而且还有其他用途。
来自特定工作负载或服务类生成的SQL语句可以由db2 designer advisor解释。
db2advis -d TESTDB1 -wlm DB2ACTIVITIES sc ‘SLARPTSC’
上面的db2advis语句将使用SLARPTSC服务类下运行的所有SQLs,并推荐索引、mqt等,以对SQL语句进行调优,将它们作为工作负载进行处理。
您可以创建针对特定工作负载的锁定事件监视器。
注:全文翻译自abhik roy的下面三篇文章,如有兴趣可以阅读原文。
DB2 Workload Manager (WLM) as a Monitoring Solution – Understanding WLM (Part1 of 3) as a Monitoring Solution – Understanding WLM (Part1 of 3)")
DB2 Workload Manager (WLM) as a Monitoring Solution– How to Set up WLM (Part 2 of 3) as a Monitoring Solution– How to Set up WLM (Part 2 of 3)")
DB2 Workload Manager (WLM) as a Monitoring Solution– Analyzing WLM Information (Part 3 of 3) as a Monitoring Solution– Analyzing WLM Information (Part 3 of 3)")
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论