DB2中如何使用create workload创建工作负载？语法与实例详解

在DB2的数据库管理体系中，工作负载管理（Workload Management，简称WLM）是一项非常核心的能力。它允许管理员按照业务优先级来分配系统资源，比如让交易类应用优先获得CPU，让报表类查询在资源紧张时被限流。而要实现这一切，第一步就是通过create workload语句创建工作负载对象，把不同的数据库连接映射到对应的服务类上。本文将围绕这条语句的语法细节、使用场景和实操注意事项展开详细讲解。

什么是工作负载，它在WLM中扮演什么角色

DB2的工作负载管理框架由三个主要概念构成：workload（工作负载）、service class（服务类）和threshold（阈值）。其中workload处在最外层，它是数据库连接的入口分类器。每当一个新的数据库连接建立时，DB2会根据连接的属性（比如登录用户名、应用程序名称、来源IP等）去匹配已定义的workload，匹配成功的连接会被分配到该workload所指向的service class中，进而继承相应的资源分配策略和并发控制规则。

需要注意的是，DB2在创建数据库时会自动生成一个名为SYSDEFAULTUSERWORKLOAD的系统默认工作负载。所有没有被任何自定义workload匹配到的用户连接，都会落到这个默认工作负载中，并被路由到SYSDEFAULTUSERCLASS服务类。这就意味着，如果你不做任何配置，所有连接实际上共享同一套默认的资源策略。当你希望对特定应用做区别对待时，就需要创建自己的workload了。

workload的匹配规则遵循"最具体优先"的原则。假设你定义了两个workload，一个只按用户名匹配，另一个同时按用户名和应用程序名匹配，那么当一个连接同时满足两个条件时，DB2会选择条件更具体的那个workload。理解这个优先级规则对后续排查"为什么我的连接没有进入预期的工作负载"这类问题非常重要。

create workload的完整语法与参数解析

create workload的基本语法结构如下：

CREATE WORKLOAD workload_name
  [属性匹配子句]
  SERVICE CLASS service_class_name
  [POSITION position_value]
  [禁用或启用选项];

其中属性匹配子句可以包含多种连接属性的判断条件，最常用的是SYSTEM USER（操作系统用户）、SESSION USER（数据库授权ID）和APPLICATION NAME（应用程序名称）。下面通过几个具体的例子来说明。

第一个例子，为订单交易系统创建一个工作负载，按照数据库用户名匹配：

-- 为交易系统用户创建工作负载，并绑定到交易服务类
CREATE WORKLOAD WL_ORDER_APP
  SESSION USER 'ORDERAPP'
  SERVICE CLASS SC_TRADE
  POSITION 1;

-- 授予该用户使用此工作负载的权限
GRANT USAGE ON WORKLOAD WL_ORDER_APP TO USER ORDERAPP;

这里有两个非常容易踩坑的地方需要特别强调。第一，CREATE WORKLOAD执行完成后，工作负载默认处于DISABLED状态，必须执行ALTER WORKLOAD语句将其启用，否则它不会参与连接匹配。第二，必须使用GRANT USAGE ON WORKLOAD把使用权限授予对应用户，否则即使连接属性完全匹配，也无法进入这个工作负载。很多初学者创建完workload后发现"没生效"，十有八九是栽在这两步上。

-- 启用工作负载（创建后默认是禁用状态）
ALTER WORKLOAD WL_ORDER_APP ENABLE;

-- 同样地，禁用一个工作负载
-- ALTER WORKLOAD WL_ORDER_APP DISABLE;

第二个例子演示多条件组合匹配。假设报表系统使用REPORT用户连接，且应用程序名称为cognos_report，可以这样定义：

CREATE WORKLOAD WL_REPORT
  SESSION USER 'REPORT'
  APPLICATION NAME 'cognos_report'
  SERVICE CLASS SC_REPORT
  POSITION 2;

ALTER WORKLOAD WL_REPORT ENABLE;
GRANT USAGE ON WORKLOAD WL_REPORT TO USER REPORT;

POSITION关键字指定了匹配的优先顺序，数值越小优先级越高。当多个工作负载都能匹配同一个连接时，DB2会参考POSITION值来决定归属。如果不显式指定，系统会自动分配位置，但为了便于维护和排查，建议在创建时就明确指定。

工作负载与服务类、阈值的联动配置

单靠workload本身并不能实现资源控制，它必须和service class配合才能发挥作用。service class定义了CPU份额、内存限制、并发度等资源属性。一个完整的配置流程通常是：先创建service class，再创建workload并指向它，最后可以追加threshold来限制查询行为。

下面是一个端到端的完整示例，展示如何为报表类查询做资源隔离：

-- 第一步：在用户服务类下创建子服务类，限制并发活动
CREATE SERVICE CLASS SC_REPORT
  UNDER SYSDEFAULTUSERCLASS
  AGENT PRIORITY DEFAULT
  PREFETCH PRIORITY DEFAULT;

-- 第二步：创建工作负载指向该服务类
CREATE WORKLOAD WL_REPORT
  SESSION USER 'REPORT'
  SERVICE CLASS SC_REPORT
  POSITION 2;
ALTER WORKLOAD WL_REPORT ENABLE;
GRANT USAGE ON WORKLOAD WL_REPORT TO USER REPORT;

-- 第三步：创建并发阈值，限制同时执行的查询数
CREATE THRESHOLD TH_REPORT_CONCURRENCY
  FOR SERVICE CLASS SC_REPORT
  ACTIVITIES ENFORCEMENT CONNECTION
  CONCURRENT ACTIVITY WHEN > 10
  CONTINUE;

通过这样的三层结构，报表用户发出的所有查询都会被限制在最多10个并发活动以内，超出的连接虽然可以建立，但其查询请求会被排队或按策略处理，从而避免报表大查询把交易系统的资源吃光。

创建完成后，如何验证连接是否进入了预期的工作负载？可以通过监控表函数查询。例如查询SYSIBMADM.MON_CONNECTION_TABLE，其中WORKLOAD_NAME字段会显示当前每个连接所属的工作负载。如果发现连接仍然落在SYSDEFAULTUSERWORKLOAD，通常需要检查三个方面：工作负载是否已ENABLE、GRANT USAGE是否执行、匹配属性是否拼写正确（注意应用程序名称是区分大小写的）。

常见报错与维护操作

在实际使用中，有几个高频报错值得关注。一是SQL20361，表示连接属性与任何启用的工作负载都不匹配，此时连接会进入默认工作负载，这本身不算错误，但如果不符合预期就要检查匹配条件。二是权限相关的SQL0552，说明执行GRANT USAGE时当前用户没有足够的权限，需要用SYSADM或SECADM身份操作。

日常维护中常用的管理语句汇总如下：

-- 查看数据库中已定义的工作负载
SELECT * FROM SYSCAT.WORKLOADS;

-- 修改工作负载的服务类归属
ALTER WORKLOAD WL_REPORT SERVICE CLASS SC_REPORT_V2;

-- 重命名工作负载
ALTER WORKLOAD WL_REPORT RENAME TO WL_REPORT_OLD;

-- 删除工作负载（必须先禁用并撤销权限）
REVOKE USAGE ON WORKLOAD WL_REPORT FROM USER REPORT;
ALTER WORKLOAD WL_REPORT DISABLE;
DROP WORKLOAD WL_REPORT;

删除工作负载时DB2有严格的依赖检查，如果仍有活动连接挂在该工作负载下，或者存在指向它的阈值对象未清理，DROP操作会失败。稳妥的做法是先DISABLE让新连接不再进入，等存量连接自然释放后再执行删除。整体来看，create workload的语法本身并不复杂，真正需要花心思的是前期的业务分类设计和后期的监控调优，建议在生产环境上线前先在测试库完整演练一遍匹配和资源限制的效果。

DB2 workloadcreate workloadDB2工作负载管理修改时间：2026-09-13 20:22:53