DB2 最佳实践: DB2 Workload Management 工作负载管理最佳实践（下）

核心提示：确定在工作负载定义中使用的连接属性您可以通过使用 DB2 工作负载管理器表函数确定定义连接到数据库的每个应用程序的工作负载对象的连接属性，例如：SELECTCOUNT(*)COUNT,SUBSTR(APPLICATION_NAME,1,10)APPLNAME,SUBSTR(SYSTEM_AUTH_ID,1,10)SYS

确定在工作负载定义中使用的连接属性

您可以通过使用 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 ：默认系统类