转自：http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0912db2workloadm/index.html

概要介绍

今天，不管是出于战略考虑还是因为财务原因，许多公司正在将多个单独的数据服务器固化到一个共享数据服务器上。每个新的数据服务器出现时，它都有可能向这个带有不同系统交互的混合体添加一个非常不同的工作负载类型。这个固化的服务器现在必须支持各种不同的并发工作负载。良好的工作负载管理实践对实现这种环境中的业务承诺至关重要。

当您的数据库系统遇到由于在该系统上执行的不同的（有时是矛盾的）资源需求所导致的性能下降时，那么您需要 DB2 工作负载管理器来帮助您阻止、探测和解决这些冲突。

本文向您介绍目前针对您的 DB2 Version 9.5 for Linux, UNIX, and Windows 数据服务器上的 DB2 工作负载管理器的最佳实践，这些最佳实践可以用于帮助您实现在 DB2 数据服务器上执行的工作的业务目标。这里介绍的最佳实践的依据是基准测试和概念证明中的 IBM 领域体验和来自采用 DB2 Version 9.5 的客户的反馈。

本文涵盖以下领域的最佳实践：

1. 设计领域的最佳实践
2. 实现领域的最佳实践
3. 监控领域的最佳实践

本文附录还提供以下参考资源和指南：

• 展示如何在数据仓库环境中使用 IBM 工作负载管理器满足业务优先权的一个特定场景；
• 对 CPU 使用实施最大硬性限制时在 AIX^® Workload Manager 中用来实现动态处理器分配的一个示例脚本；
• 关于如何从 Query Patroller 和 DB2 Governor 升级的指南。

如果您已经熟悉 DB2 工作负载管理的一些基本概念，那么您能够更好地利用本文。如果您想先阅读一些背景信息，那么请您参阅本文末尾推荐的参考资源。

最佳实践：设计

工作负载管理背后的工作原理总是相同的：

1. 理解需要在您的数据服务器上运行的工作及其如何与您的业务目标相关联。
2. 确定您的系统是否可以运行这个工作而没有任何限制；您在任何时段执行的工作量必须是您的系统能够处理的工作量。
3. 在需要时对系统上运行的工作采取“分而治之” 的方法，以便根据工作的业务优先权执行它们，同时避免超出您的系统的处理能力。

本小节讨论有关任何工作负载管理实现中的调查和设计部分的当前最佳实践。

理解现有系统

这些原理适用于正准备发布到生产中的数据库，其适用程度与已经得到部署的数据库相同。现有系统的优势在于它们能够被监控和挖掘，以便帮助您理解将要在目标系统上运行的工作。

理解将要在您的数据库上运行的工作对设计适当的工作负载管理实现很关键，这些信息告诉您将遇到什么类型的争用和交互，这反过来帮助您确定应该关注 DB2 工作负载管理的哪些特性和功能。要更好地理解可用的信息类型，请参见“DB2 最佳实践 : 性能调优和问题诊断最佳实践”。

要收集关于在现有 DB2 系统上运行的工作的信息，利用新的监控功能（如本文监控部分所述）从默认 DB2 工作负载和 DB2 V9.5 安装后立即可用的用户服务类收集信息。

如果您在现有系统上使用 Query Patroller (QP) ，可以首先通过使用存储在 QP 控制表中的信息寻求答案。这些表显示正在提交的工作的类型和来源。

向数据库工作分配业务优先权

与知道将要执行什么工作一样重要的是要知道工作的业务优先权和系统上的其他工作如何相关联，该工作有什么性能目标（如果有的话），这些业务优先权如何映射到已提交的数据库请求。有时，业务优先权（或预期）的表达方式为一个正式的服务级别协议（SLA ）；有时，优先权完全不可知，或者以非常随意的比较词汇表达（如应用程序 A 比应用程序 B 更重要）。

首先将应用程序映射到业务优先权：谈到业务优先权，很容易想到一个简单的分类系统，比如高、中、低优先权。然后您开始检查提交工作并将它们按照优先权级别分类的不同业务流程。有些业务流程中包含多个级别和路径，并不是所有的级别和路径都共享针对主流程的相同的高级别分类。例如，一个高优先权在线应用程序可能拥有一些辅助报告或维护路径，它们不与主应用程序共享相同的高优先权。应用程序通过业务流程被惟一标识的程度在很大程度上决定您是使用直接映射到一个应用程序的简单业务优先权映射，还是必须分析由一个应用程序提交的请求来将不同的优先权分配给那些请求。

业务优先权通过拥有一个为每个不同的业务优先权类定义的 DB2 服务类很好地反映出来。服务类是数据库工作实际执行的地方，也是控制分配给该工作的优先权的最好位置。为传入的工作分配业务优先权，即将传入的工作分配给不同 DB2 服务类，最好使用 DB2 工作负载定义和 DB2 工作负载操作集完成。

在您可以将业务优先权直接应用到一个特定应用程序提交的工作的情况下，将工作负载映射到反映分配到该应用程序的业务优先权的 DB2 服务类。要映射工作负载，创建一个 DB2 工作负载以表示该应用程序产生的连接，将该工作负载直接指向表示针对该应用程序的适当的业务优先权的 DB2 服务类。

在其他情况下，比如处理一些中间件应用程序时，您可能无法将一个业务优先权分配给一个特定的应用程序，因为该应用程序同时服务多个优先权不同的流程，而且并不是总能区分接受服务的不同用户。在这些情况下，检查正在提交的单个请求，并使用一种可行技术将业务优先权应用到每个流程（或用户）。可以通过将那些请求导向适当的 DB2 服务类来在单一的请求级别映射业务优先性，最好的实现方法是使用可作为 DB2 工作操作集机制的一部分的映射机制（因为它在 DB2 服务超类中使用）。

一种映射业务优先性的替代方法：如果您没有适当的关于正提交到数据库的工作的信息级别，您可以选择使用一种替代方法将业务优先性映射到数据库工作。从一个纯粹的数据库角度着手处理优先性分配问题。为此，使用一个 “短 - 中 - 长” 分类系统，根据服务器上的预期影响（或生命期）对工作分类。在这个系统中，您将短期请求视为最重要的请求，长期请求视为最不重要的请求。这个模式的想法是：可以穿过您的系统的短期查询越多，向整个企业提供的服务也就越好。换句话说，这里的原理是：作为一个整体，系统稍微降低长时间查询的运行速度要好于短时间查询遭受性能下降。

但是，即使在这种模式中，相同的问题也会出现。一个应用程序只提交一个请求类的程度决定您是使用简单映射还是必须基于具体情况对请求分类。同样，确定已提交工作的相对影响的方法将在您选择的工作负载管理机制中反映。一个只提交一种类型工作的应用程序可以通过使用普通的 DB2 工作负载到 DB2 服务类的映射机制直接映射到一个针对该类工作的服务类。同样，对工作的分类和根据请求的既定影响将单个请求映射到适当的 DB2 服务类也最好使用 DB2 工作操作集映射机制实现。

显然，将这两个分类系统组合在一起是可能的，就像组合任意数量的其他系统一样。可以得出的关键结论是，不管使用哪种分类系统，单独的应用程序和正在使用的业务优先权分类系统之间的匹配程度决定哪一种 DB2 工作负载管理机制能够最好地告知数据库优先权。

利用您的经验

如果您有一个现有系统，那么您就拥有关于系统如何运行和系统以前经历的问题的重要知识。您对导致这些困难的根本原因了解得越少，那么您在实现一个新的工作负载管理方法中就越被动。如果是这样，计划一个良好的初始实现（如下一节将介绍的）并计划多次重复监控和调优，直到系统变得稳定和可控。

另外，利用您的经验确保您的系统上的所有活动因素都受到考虑。将系统视为一个整体，只使用 DB2 工作负载管理的功能并不会解决所有问题。考虑您可以使用的所有 DB2 特性和功能。进行 DB2 工作负载管理时，可以且应该利用您的 DB2 数据服务器的其他特性和功能来确保您的性能目标得以满足。

一个可预测的、稳定的数据服务器需要满足以下条件：

• 良好的逻辑和物理设计。参阅以下文档了解更多信息：
  • “DB2 最佳实践 : 物理数据库设计最佳实践”和 Balanced Warehouse 文档
  • “DB2 最佳实践 : 性能调优和问题诊断最佳实践”
• 调优以产生最佳性能的查询。
  • 更多信息请参阅“DB2 最佳实践 : 编写并调试查询语句以优化性能最佳实践”
• 使用其他可以协助性能的特性，如自调优内存和实用程序节流（throttling ）。

您多年一直在使用的知识和工具并非突然变得无关紧要，它们只是需要与 DB2 工作负载管理中的新功能相协调。通过结合 DB2 工作负载管理和其他特性和功能，您就可以创建出稳定的、可预测的 DB2 数据服务器，这样的服务器甚至在需求达到峰值时也能保持稳定的性能。

简单开始并循序渐进

与其他新功能一样，实现一个复杂的设计或同时进行许多不同的更改通常不是一个好主意。复杂性和剧烈变化通常会隐藏真正的问题，有时甚至还会引入新问题。

对于 DB2 工作负载管理的控制功能，从一个简单的、直观的实现开始，然后在此基础上逐次添加改变。这种方法完全理解每次更改的影响并觉察到任何违背初衷的结果或交互。

而且，最好使任何控制（比如 DB2 阈值提供的控制）的关注范围尽可能地狭窄，而不是全局应用它们。某些广泛的数据库级别阈值也许对于管理系统的全局行为比较理想，但是一般而言，使那些阈值只关注问题区域能够确保您只看到预期的效果。通常，分配一个 DB2 阈值的最有效的地方是在一个 DB2 服务子类上。

最佳实践：实现

这个部分提供当前实现 DB2 V9.5 中引入的 DB2 工作负载管理提供的每个功能的最佳实践。

DB2 工作负载

一个 DB2 工作负载应该针对您感兴趣的每个可能的工作源（即一个数据库连接），无论它是一个应用程序、一个用户、一个特定部门或其他任何东西。

引入新的工作负载定义不会产生性能影响，每个工作负载定义允许您监控或控制您的系统上传入工作的一个特定部分。工作负载定义还允许您快速实现未来更改，因为您已经拥有现成的机制来识别您打算通过更改来影响的特定连接组。

中间件应用程序也许会产生一个识别问题，因为许多中间件使用相同的授权 ID 和一致的连接信息与数据库交互。这时，如果没有其他信息，数据库就不能识别这些请求后面的最终用户。

通过使用可修改的客户机信息字段（例如 CLIENT USERID 、CLIENT APPLNAME 、CLIENT WRKSTNNAME 和 CLIENT ACCTNG ）使中间件应用程序支持最终用户应用程序的识别。这些字段可以被连接到 DB2 数据服务器的任何应用程序设置，设置方法是使用各种 DB2 客户机连接选项或调用 WLM_SET_CLIENT_INFO 存储过程。

最流行的中间件应用程序要么提供设置客户机信息字段的能力，要么提供在处理期间将用户提供的 SQL 注入策略位置的方法。这些字段提供一种明确识别将工作提交到 DB2 数据服务器的业务流程和组织的许多外部特征的方法。这些字段还能用于创建独特的 DB2 工作负载定义。

客户机信息在许多问题确定和监控场景中都非常有用，因此，重要的是要在您的业务中为这些字段建立一个标准格式和使用预期，以确保这些信息经过良好的重新组织并被目标人群理解。

如果没有为感兴趣的连接创建独特的工作负载的能力，那么您必须依赖工作操作集等机制来隔离并处理某个工作，该工作仅仅基于工作的实际特征（如 DML 或 DDL ，READ 或 WRITE 等）或成本估计被提交。这严重限制了未来的灵活性以及利用工作负载管理提供的细粒度监控功能的能力。

DB2 服务类

当您安装 DB2 V9.5 时，一个默认用户服务类将自动创建，这个默认用户服务类是提交到数据库的所有工作运行（通过将连接映射到同样是在安装时创建的默认工作负载定义）的地方。这是您的起点，您自动创建的任何其他 DB2 工作负载指向这个默认服务类，除非显式指定了一个新的服务类。

本小节提供创建新的 DB2 服务类并将工作从默认服务类中拉出以便它能够根据业务优先权被区别对待的推荐方法。您定义的每个 DB2 服务类为您提供了一个定义用于执行的资源优先权的控制点，以及对正在执行的工作进行轻量级监控的能力。反之，您定义的服务类越多，您的系统作为一个整体进行监控和控制时就更复杂。

在您的实现完成以后，您也许会选择继续使用默认服务类，将其作为处理未映射的和不重要的工作的地方。如果这样，确定这样的工作应该分配何种业务优先权并适当控制默认用户服务类的资源以及您可能创建的其他资源。

如“向数据库工作分配业务优先权”小节所述，DB2 服务类是反映数据库中的业务优先权的最好方法。这一过程通常通过实现一个相当直观的分类系统来简化，在这个分类系统中，对传入的工作分配的服务类要么表示为 HIGH 、MEDIUM 或 LOW 业务优先权，要么表示为短期、中期或长期预期持续时间。

要实现一个 HIGH 、MEDIUM 或 LOW 业务优先权分类系统，创建一个 DB2 服务超类并在该超类中创建其他两个服务子类。

每个这些服务类表示一个不同的业务优先权，其中超类的默认子类也是提交到该超类的任何未映射工作的默认位置。根据您想要处理这类工作的方式，您很可能分配这个默认子类以表示工作的 LOW 或 MEDIUM 优先权类别。本文中的示例实现将 LOW 类别分配给为该超类创建的默认子类，将 MEDIUM 和 HIGH 类别分配给两个显式创建的子类。参见示例“图 1. 推荐的服务类实现”。

图 1. 推荐的服务类实现

图片说明：

Service Superclass A：服务超类 A
Default subclass: LOW priority：默认子类：LOW 优先权
Subclass A2: MEDIUM priority：子类 A2：MEDIUM 优先权
Subclass A1: HIGH priority：子类 A1：HIGH 优先权

每个这些不同的服务类的资源可以反映出相对优先权，具体方法是将服务类属性设置为反映对应优先权的值 ¹，例如，LOW 业务优先权服务子类能够获取 LOW 预取优先权和一个较低的相对处理器优先权设置，而 HIGH 业务优先权子类能够获取一个 HIGH 预取优先权和一个较高的相对处理器优先权）。一般而言，首先使用 MEDIUM 业务优先权类反映超类的原始默认（即未经修改的）设置，因为这是 DB2 数据库中常见的执行设置。

不要将任何服务类的服务类处理器优先权设置得比 DB2 默认系统服务类的高，设置方法为要么直接使用处理器优先权属性，要么通过 AIX Workload Manager 集成间接设置。

这种方法中的默认行为如下：由一个 DB2 工作负载映射到服务超类 A 的任何事物在默认子类中执行并采用 LOW 优先权设置。为了获取不同的优先权设置，传入的工作要么使用一个 DB2 工作操作集映射到其他服务子类，要么直接映射到理想的服务子类。参见 “图 2. 分配工作到不同的服务子类的示例”。

图 2. 分配工作到不同的服务子类的示例

图片说明：

Service Superclass A ：服务超类 A
Priority assigned by work type ：按照工作类型分配的优先权
Priority assigned by workload ：按照工作负载分配的优先权
Work Action Set ：工作操作集
Default subclass: LOW priority ：默认子类：LOW 优先权
Subclass A2: MEDIUM priority ：子类 A2 ：MEDIUM 优先权
Subclass A1: HIGH priority ：子类 A1 ：HIGH 优先权

默认服务子类被赋予最低的或中等的优先权，因为只要 DB2 工作负载被映射到超类，没有在应用到该超类的一个 DB2 工作操作集中识别的或重新映射的任何工作将自动被赋予最低（或中等）优先权 ² 。通常，高优先权为特殊工作预留，而不是用于提交到数据库的普通日常工作。您还可以将传入的工作直接映射到一个子类本身，以便向那个工作分配该优先权；通过这样做，该工作将绕过超类上的任何 DB2 工作操作集。请注意，您不能直接分配一个工作负载到默认子类，这应该在决定哪个子类将表示哪个业务优先权时考虑。

您可以使用这个推荐方法作为模板，将其用于管理您的数据库上的工作的整体方法（即数据库上的所有工作都在一个超类中处理），或者用于更多样化的方法，其中不同的工作组使用不同的方法管理（例如，一个工作组使用业务优先权管理，另一个工作组使用预期持续时间管理）。

一旦您已经设置 DB2 服务类和工作负载来反映您想要的工作处理方式，通过运行已知的工作负载并比较每个工作负载和服务类的不同请求和行为计数来验证您的实现，确保事情按预期发展。您也可以使用这个时间来测试这个处理模式上的实现的效果。您可以通过两种方法来验证这一点：一是使用 WLM 表功能来直接询问 DB2 ，二是使用 WLM 统计数据事件监控器将不同 WLM 对象的统计数据收集到一个表以备未来分析之用。

图 3. 一个完整的数据库实现示例

图片说明：

User database requests ：用户数据库请求
System database requests ：系统数据库请求
Workload ：工作负载
Default workload ：默认工作负载
Superclass ：超类
Default User Service Class ：默认用户服务类
Default System Service Class ：默认系统服务类集成 AIX Workload Manager 服务类

集成 AIX Workload Manager 服务类

如果您正在 AIX 操作系统上运行 DB2 V9.5 ，您可以集成 DB2 服务类和补充的 AIX Workload Manager (WLM) 服务类。这样做允许您利用 AIX WLM 提供的本机控制和监控功能。

AIX WLM 提供许多控制处理器的方法，您必须通过试验了解哪一种方法（如果有的话）更适合您。需要记住的关键点是：AIX WLM 处理器控制机制（例外情况是最大硬性限制）运行的前提是仅当处理器循环处于高峰期时才需要限制低优先权工作。当处理器不受限制时，多数 AIX WLM 控制机制没有什么效果。反之，处理器的利用率越高，这些控制机制发挥的作用越大。

在 AIX 系统上控制处理器使用的推荐方法：为实现处理器控制目标而与 AIX Workload Manager 集成时，使用有关处理器使用的最大硬性限制，除非在您想要控制生效的时候您的系统总是受到严重的处理器限制。

处理器使用上的最大硬性限制　严格控制处理器使用，不管处理器利用程度如何。低优先权工作负载总是受到控制，这样高优先权工作将受益，即使是在没有处理器限制的环境中。我们的 AIX WLM 测试和基准测试经验都证明了这一点。

最大硬性限制的主要局限性是设置不灵活且在没有高优先权工作时不允许低优先权工作动态借用处理器时间。

我们发现一种方法可以改进这个限制并模拟处理器使用的最大软性限制的某些好处，那就是在后台运行一个脚本，它根据每个服务类中的当前利用率动态调节最大硬性限制设置。当高优先权工作开始使用更少的处理器时间时，设置被调节为允许低优先权工作使用更多处理器时间，而当高优先权处理器的使用开始上升时，情况正好相反。附录“缓解 AIX Workload Manager 使用的最大硬性限制”提供了这样一个脚本示例。

我们在一些基础测试中的经验表明，AIX WLM 服务类的一个有效使用方法是通过使用最大硬性处理器限制在企业的不同部分之间实现一个严格的处理器资源分配。在每个这些 AIX WLM 服务类中，几个 DB2 服务类（全部引用相同的 AIX 服务类）被随后引入进来，以便针对不同的目的进一步细分每个严格的分配。目前为止，我们还没有遇到一个场景需要两个或三个以上的 WLM 服务类来调节处理器使用优先权。

图 4. DB2 工作负载管理器和 AIX WLM 集成示例

图片说明：

Workloads ：工作负载
Service classes ：服务类
REPORTING ：报告
SUMMARY ：摘要
MARKETING ：市场营销
MANAGERS ：管理器
Default ：默认
Default User Class ：默认用户类
Default System ：默认系统
AIX WLM service classes ：AIX WLM 服务类

拥有一个已定义 AIX WLM 服务类的一个好处是您可以使用针对 AIX WLM 服务类的操作系统统计数据来补充从 DB2 数据服务器收集的统计数据。当您在 DB2 工作负载管理服务类和 AIX WLM 服务类之间拥有 1:1 映射时，您可以直接将 AIX 统计数据应用于在该 DB2 服务类中运行的工作。

DB2 工作操作集

DB2 工作操作集是 DB2 V9.5 中提供的一种用于区分不同的工作类型并以不同方式对待它们的机制。引入一个工作操作集的原因有很多，包括本文已经提到过的原因。

遵循以下最佳实践定义一个工作操作集（和必要的 DB2 工作类组）：

1. 最小化工作类组的数量；理想情况下，您应该只需要一个工作类组，不管现有工作操作集的数量如何。
2. 确保单独的工作类定义之间没有互相重叠，以免在工作分类中造成混淆；确保重叠的工作类定义的命名方法反映它们共享的或公共的关注点。
3. 确保您的工作操作集定义的顺序正确，且工作被适当分类和处理。
4. 通过运行已知的工作负载并比较每个工作类的计数来验证您的工作操作集；检查默认工作类的内容获取工作操作统计数据，看看是否有一些工作没有被适当分类。

DB2 阈值

在实现期间，遵循本文设计部分提到的关于阈值的最佳实践，以确保阈值的范围尽可能有限且定义良好。针对任何 DB2 阈值的实现的主要最佳实践是确保阈值违被事件监控器已经创建并激活，否则，您将不会知道何时遇到阈值和遇到了什么阈值。

对于影响行为的任何阈值，如果一个阈值将要停止一个行为的执行，则应总是收集详细的行为信息，以便允许执行一个有效的后续调查。

使用 CONCURRENTDBCOORDACTIVITIES 阈值

CONCURRENTDBCOORDACTIVITIES 阈值指定可以在数据库上同时运行的已识别协调器行为的最大数量 ³ 。这个阈值也是一个允许队列化的并发控制阈值，它是一个非常有效和强大的工具，可用于排序和限制任何时刻要求数据库执行的工作量。

由于该阈值在整个数据库上执行指定的并发率，这个阈值的应用拥有比其他多数阈值略高的开销。一般而言，只在服务子类级别应用这个阈值。如果它的确需要在数据库级别应用（例如，控制可能具有破坏性的行为，如负载操作），那么一定要非常小心，可以使用数据库级别的工作操作集来最小化受到该阈值影响的工作。

应用这个阈值减小或限制一组工作对数据库系统的影响，从而允许其他工作利用限制的资源。如果您发现高优先权工作没有按照理想的方式执行，而同时一些低优先权工作正在执行，那么您可以考虑在低优先权工作上施加一个并发控制，直到高优先权的性能目标得到满足。

如何开始：首先使用包含最低的优先权工作的服务类并在该服务类上定义一个 CONCURRENTDBCOORDACTIVITIES 阈值。根据您的系统的需要，您的初始阈值的值可能还不够低，您需要进一步减小该值以增加高优先权工作可用的资源。您可以以迭代方式重复这个过程，同时监控高优先权工作，直到找到适当的平衡。

有时，低优先权阈值并发限制的值达到 1 ，假如您不想完全停止那个工作，那么要减少在系统上运行的低优先权工作的工作量，下一步就是将这个特定阈值的设置保留为 1 ，并向上移动到包含具有次低优先权的工作的服务类以重复相同的步骤。

总是使用一个未绑定的队列化限制定义低优先权阈值，以便新的行为队列不会失败，阈值也不会受到违背。

尽量不要在优先权最高的工作上定义一个并发阈值，因为额外的开销带来的坏处超过了收益，特别是该工作的持续期较短时。通常，向最繁重的工作应用一个并发阈值的好处大大超过了将其应用于更轻松的工作。有时，如果在数据库系统上执行的全部工作量超出了系统资源的处理能力，那么也需要在高优先权工作上设置一个阈值。

在这些情况下，考虑将包含 HIGH 、MEDIUM 和 LOW 优先权工作的服务类之间的并发率的比例分解为 85% 、10% 和 5% 。这强调了在允许高优先权工作顺利完成的同时还要允许低优先权工作取得进展。

CONCURRENTDBCOORDDACTIVITIES 阈值与 Query Patroller 查询类机制使用的并发控制并不相同。CONCURRENTDBCOORDDACTIVITIES 阈值控制所有直接和间接行为，但间接行为是在一个存储过程中运行的嵌套行为（如 SQL 语句）。CALL 语句是一个行为，任何嵌套的 SQL 是另一个行为。

在某些应用 CONCURRENTDBCOORDDACTIVITIES 阈值的场景中，启动了超过一个并发行为的应用程序可能会消耗掉该阈值允许的所有并发性，形成一个队列死锁场景。

以下是两个这样的场景示例：

场景 #1 （假设并发阈值为 2 ）

1. 应用程序 A 打开一个光标（消耗票证 #1 ）
2. 应用程序 B 打开一个光标（消耗票证 #2 ）
3. 应用程序 A 在当前语句处发出更新（排队）
4. 应用程序 B 在当前语句处发出更新（排队）

场景 #2 （假设并发阈值为 2 ）

1. 应用程序 A 打开一个光标（消耗票证 #1 ）
2. 应用程序 B 打开一个光标（消耗票证 #2 ）
3. STPA 打开一个光标（排队）
4. 应用程序 B 在当前语句处发出更新（排队）

始终要注意您放入队列中的内容，以便确保正在排队的内容适用于这个特定的并发阈值。

当您使用 CONCURRENTDBCOORDACTIVITIES 阈值时，总是使用一个影响排队中的相同工作的伴随 ACTIVITYTOTALTIME 行为阈值，从而确保当 ACTIVITYTOTALTIME 对队列中的行为失效时，任何队列死锁场景最终被探测出来并得以解决。

如果您正使用通过 CALL 语句调用的存储过程和其他 SQL 例程，同时想在嵌套的工作而不是 CALL 语句本身上施加一个并发阈值，考虑以下在某些上下文中可以接受的替代实现：

1. 按照本文前面推荐的方法，使用一个包含 3 个子类（表示不同的业务优先权）的超类定义标准服务类环境。
2. 必要时对这些子类应用并发阈值。
3. 添加一个额外的子类来表示 CALL 语句，不要对它应用任何并发阈值。
4. 引入一个将所有 CALL 语句映射到专为 CALL 语句预备的子类的工作操作集，但是在工作操作定义中使用 WITHOUT NESTED 子句。这个子句规定，在这个被调用例程中的任何后续 SQL 语句必须自己穿过该工作操作集，在那里，它们可以被映射到与它们的父语句不同的服务类。
5. 将所有工作负载路由到共享超类。

在这个实现中，CALL 语句自身不存在并发控制，但它们的所有子语句受到这样的并发控制。参见 “图 5. 一个替代 CONCURRENTDBCOORDACTIVITIES 阈值实现的示例” 获得对这种替代方法的概览。

图 5. 一个替代 CONCURRENTDBCOORDACTIVITIES 阈值实现的示例

图片说明：

Workload definition ：工作负载定义
Work Action Set ：工作操作集
Service Superclass A ：服务超类 A
CALL subclass ：CALL 子类
Subclass A2: MEDIUM priority ：子类 A2 ：MEDIUM 优先权
Subclass A1: HIGH priority ：子类 A1 ：HIGH 优先权
Concurrency Threshold TH1 ：并发阈值 TH1
Concurrency Threshold TH1 ：并发阈值 TH2

如果您怀疑一个可能的队列死锁情形，使用 WLM_GET_QUEUE_STATS 表函数或 db2pd 命令来查询涉及的并发阈值的最新统计数据，从而帮助您确认或消除怀疑。如果您自动收集 WLM 统计数据，使用这个信息来探测并发阈值队列是否出现停顿。

如果确实出现了一个队列死锁场景且您没有定义一个 ACTIVITYTOTALTIME 行为阈值（或者不希望被动违背该阈值），可以采用以下两种解决方法：

• 使用 ALTER THRESHOLD 语句提高并发率。
• 使用 WLM_CANCEL_ACTIVITY 流程取消一些正在执行的行为或队列中的行为，直到问题得以解决。

如果您想彻底删除并发阈值：

1. 首先禁用阈值以阻止新行为加入队列。
2. 改变阈值以提高并发率，允许队列中的行为开始执行。
3. 一旦队列为空，删除阈值。

最后，在某些情况下，也可能使用 TOTALSCPARTITIONCONNECTIONS 阈值作为施加控制的替代方法。这个阈值影响位于同一个数据库分区的新连接，因此兼容场景将需要一个在其中建立所有连接的单个数据库分区（例如一个平衡的仓库配置中的管理分区）以及那些在工作完成时断开了连接的连接。

最佳实践：监控

监控是任何成功的工作负载管理实现的初始设计和持续调优的关键组成部分。本部分并不会向您介绍监控的内容和方式，因为答案取决于具体场景，但本部分的确介绍一些所有场景都使用的最佳实践，从而使监控工作在总体上变得更加轻松。

第一个监控最佳实践是创建 DB2 V9.5 引入的所有新的工作负载管理事件监控器，特别是行为、统计数据和阈值违背监控器。与其他事件监控器不同，工作负载管理事件监控器的创建和激活并不导致事件生成。相反，事件生成在单独的工作负载管理实体（如服务类和工作负载）上定义。通过创建这些事件监控器，您不会对系统施加任何开销，而且，您设置的监控环境允许您随时调用 WLM_CAPTURE_ACTIVITY_IN_PROGRESS 存储过程或改变一个实体（如一个服务类）的收集属性，并及时捕获想要的信息。

理解您的数据库系统的行为和工作负载非常重要。

在 BASIC 级别为您的所有服务类打开收集聚合行为数据的功能，将 WLM_COLLECT_INT 数据库配置参数设置为使所有工作负载管理统计数据以最适合您的监控需要的固定时间间隔收集到统计数据事件监控器。

这些设置所做的工作是以固定的间隔为每个不同的工作负载管理对象收集存储在 DB2 内存中的所有统计数据，将所有这些统计数据写入工作负载管理统计数据事件监控器，然后重置内部统计数据以便在下一次间隔中使用。收集所有这些统计数据和聚合行为数据的开销可以忽略不计，但其对于帮助您遵循您的系统中的工作模式和行为的价值是巨大的。打开聚合行为数据并定期收集可用的工作负载管理统计数据将向您提供您的数据库系统性能在不同时段（比如一天或一周）的实时概况，这可以用于确定问题时段并理解正在进行的趋势和模式。这个信息对于帮助您确定需要设置什么阈值（如果需要的话）来控制您的系统中的异常行为也很有价值。要了解关于统计数据的更多信息，请参见 “参考资源”。　

尽管人们常常想了解一个语句的执行的完整细节，但是这些人很难接受为了收集这些统计数据而在这些语句上施加任何额外的开销。

对于其中的语句非常短或并发语句的数量非常大的系统，避免同时为所有服务类收集详细的行为数据。

如果您想要详细的行为数据，但是您的工作负载或系统不能接受收集所有语句的详细信息所带来的开销，可以通过两种方法小心地处理您的数据收集：收集关于所选工作负载的单独行为信息，或者将收集限制到一个特定的时段。将收集行为视为对工作负载的 SQL 采样。工作量和开销允许的情况下，如果工作负载级别对于您的监控需求过于细粒度，则相同的概念也可以应用到服务类的级别。

使用这种方法，您可以控制受影响的工作和时间，同时仍旧将详细信息捕获到行为事件监控器。向 DB2 设计顾问提供这个数据或使用 DB2 V9.5 提供的 wlmhist.pl 运行关于这个数据的历史报告将对独立样本或整个数据库（如果您一直等待所有采样结束）产生有意义的结果。

根据需要改进任何事件监控器，并归档重要信息以备将来使用。

不要在生产期间直接备份事件监控器表本身，因为这将在此期间内干扰写入流程并影响系统性能或您的监控功能。将数据从事件监控器表中提取出来并放到一个备用位置，然后备份这个备用源。

在高度利用的系统上，考虑建立一个独立的服务类以通过您的监控应用程序或连接使用工作负载管理 SQL 表函数，以便查询能够得到更高的优先权和更好的响应时间。

修改工作负载管理设置本身时，一个好主意是：如果您想要请求绕过任何可能存在的并发阈值，则最好在提交这类请求时总是使用 SYSDEFAULTADMWORKLOAD 工作负载定义（但注意您不能将这个工作负载分配给一个独立的服务类）。

结束语

工作负载管理是创建一个稳定的、可以预测的 DB2 数据服务器所需的关键特性之一。您可以利用 DB2 V9.5 提供的 DB2 工作负载管理特性和您的 DB2 数据服务器的其他特性和功能来确保您的业务目标可以通过一个按预期运行的数据服务器实现。如果您的确遵循了这里简要描述的 DB2 工作负载管理最佳实践，那么您的工作负载管理实现应该取得了一个成功的开端。

附录场景：数据仓库环境中的最佳实践

前面介绍的最佳实践适用于许多不同的场景，本部分介绍如何在一个数据仓库环境中使用 DB2 工作负载管理特性和 AIX Workload Manager 。

首先，问自己以下问题以帮助您识别您的环境中运行的工作的不同特征：

• 您想使用什么粒度控制您的工作？根据部门、用户 ID 或应用程序等标准将查询分为多个类别。考虑与其他工作相比，哪些行为、用户或应用程序应该拥有较高的优先权。
• 哪些查询或行为是不理想的或不允许的？例如，如果一个查询需要 1000 秒才能完成，您也许会认为它的开销太大了。
• 您的环境最多能处理多大的工作量？可以运行多少查询而不会导致系统超载？
• 您想了解您的工作的哪些状况？也就是说，您首先应该监控什么内容？您可能会问自己以下问题：
  • 哪些应用程序运行开销最高的查询？
  • 哪个查询需要的 CPU 资源最多？
  • 运行时间超过 5 分钟的查询有多少？

理解您的数据仓库执行的工作

如果您对运行在您的系统上的工作还没有很好的理解，在您定制 DB2 工作负载管理之前应监控它以便了解它的工作特征。有关特征的示例包括用户名、应用程序名、并发级别和资源消耗。要理解在您的数据服务器上执行的工作，使用显示行为估计成本和运行时的柱状图。

例如，在默认工作负载管理配置中，以下语句创建一个事件监控器、激活它并改变服务类以启用扩展的聚合行为数据统计收集：

CREATE EVENT MONITOR DB2STATISTICS FOR STATISTICS WRITE TO TABLE;
SET EVENT MONITOR DB2STATISTICS STATE 1;
ALTER SERVICE CLASS SYSDEFAULTSUBCLASS UNDER SYSDEFAULTUSERCLASS
COLLECT AGGREGATE ACTIVITY DATA EXTENDED;

现在运行一个典型的工作负载或等待当前已在运行的行为全部完成，以便收集一些统计数据。下面，使用以下命令将统计数据刷新到 HISTOGRAMBIN_DB2STATISTICS 表，该命令同时重置内存中的统计数据。

CALL WLM_COLLECT_STATS;

要查看运行时分布情况，查询柱状图表以返回一个 CoordActExecTime 柱状图，该图显示在协调器分区的非嵌套行为的执行时间。该结果主要用于识别运行时间超过 1 秒的行为，次秒级查询通常不需要在数据仓库环境中进行工作负载管理。

SELECT TOP/1000 AS TIME_seconds,
SUM(NUMBER_IN_BIN) AS #EXECUTIONS
FROM HISTOGRAMBIN_DB2STATISTICS
WHERE HISTOGRAM_TYPE = 'CoordActExecTime'
GROUP BY TOP/1000 order by TOP/1000
The output might look like this:
TIME_SECONDS #EXECUTIONS
----------- -----------
0 385
1 37
1 40
1 25
2 11
3 15
5 10
7 16
11 8
16 9
25 6
38 6
59 22
89 21
136 12
208 8
317 0
483 0
737 0
1124 0
1715 0
2616 0
3990 1
6086 1
9283 0
14160 0
21600 0
24 record(s) selected.

图 6. 协调器分区的非嵌套行为的执行时间柱状图（CoordActExecTime）

当表示为一个曲线图时，这个柱状图显示大多数查询在不到 1 秒的时间内完成，有些查询的完成时间在几秒到几分钟不等，还有两个查询的运行时间特别长。短查询的累计执行时间比长查询的执行时间少得多。通常，运行时与资源消费相关，如果您查看曲线图中蓝线表示的平均累计执行时间，您将看到这些长查询消耗大多数可用资源，应该通过工作负载管理进行控制。

为了帮助定义阻止高成本查询独占资源的查询类和阈值，查看柱状图中相同工作负载的估计成本。

以下查询返回一个 CoordActEstCost 柱状图：

SELECT TOP/1000 AS TIMERONS_in_THOUSAND,
SUM(NUMBER_IN_BIN) AS #EXECUTIONS
FROM HISTOGRAMBIN_DB2STATISTICS
WHERE HISTOGRAM_TYPE = 'CoordActEstCost'
GROUP BY TOP/1000 order by TOP/1000;

对于服务器上的当前连接，一些工作特征可以通过查询 SNAPAPPL_INFO 管理视图获得（管理视图在被调用时施加一个应用程序快照的开销）。另外，也可以使用工作负载管理表函数。历史透视图可以从类似于 DB2 Performance Expert 这样的工具获取，也可以通过使用行为事件监控器捕获信息。

例如，以下查询返回当前数据库连接的数量和所有分区的代理使用的处理器时间，按照应用程序名和来自 SNAPAPPL_INFO 视图的系统授权 ID 分组。

SELECT A.DBPARTITIONNUM, COUNT(*) #CONNECTION,
INTEGER(SUM(AGENT_USR_CPU_TIME_S+AGENT_SYS_CPU_TIME_S))
CPU_SECOND,
SUBSTR(APPL_NAME,1,20) APPLNAME,
SUBSTR(PRIMARY_AUTH_ID,1,16) SYSTEM_USER
FROM SYSIBMADM.SNAPAPPL_INFO A, SYSIBMADM.SNAPAPPL B
WHERE APPL_NAME NOT IN
('db2stmm','db2wlmd','db2taskd','db2evmg_DB2DETAILDEA')
AND A.AGENT_ID=B.AGENT_ID
AND A.DBPARTITIONNUM=B.DBPARTITIONNUM
GROUP BY APPL_NAME,PRIMARY_AUTH_ID, A.DBPARTITIONNUM
ORDER BY A.DBPARTITIONNUM,APPL_NAME;

这个查询返回以下输出：

DBPARTITIONNUM #CONNECTION CPU_SECOND APPLNAME SYSTEM_USER
----------- ------- ------- ------------ ------------
0 504 312 db2batch DB2INST3
0 1 0 db2bp DB2INST3
1 496 3868 db2batch DB2INST3
1 1 0 db2bp DB2INST3
...
16 497 3681 db2batch DB2INST3
16 1 0 db2bp DB2INST3
34 record(s) selected.

要获取更好的关于数据库行为的历史透视图，使用一个行为事件监控器来为您捕获信息。也可以通过使用像 DB2 Performance Expert 这样的性能分析和调优工具来执行一个更详细的工作负载分析。

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

您可以通过使用 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 boss2 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 升级到工作负载管理器时，可以根据这里介绍的最佳实践控制您的数据服务器上的工作。您可以利用已经从 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 ：默认系统类

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15082138/viewspace-622533/，如需转载，请注明出处，否则将追究法律责任。