在DB2的生产环境中，一个数据库实例往往同时承载着多种类型的业务：在线交易、报表查询、批处理作业、维护任务等。如果这些连接都以相同的优先级抢占CPU和内存，很容易出现批处理任务把核心交易挤占得无法响应的情况。DB2从9.5版本开始引入了工作负载管理（Workload Manager，简称WLM）机制，而CREATE WORKLOAD语句正是这套机制中最基础、最常用的一环。它负责回答一个核心问题：这条新的数据库连接到底属于谁，应该享受什么样的资源待遇。
什么是工作负载以及它在WLM中的定位
要理解CREATE WORKLOAD，首先要明白DB2工作负载管理的三层结构。最外层是工作量元素（work occurrence），即具体的一次事务或一条SQL；中间层就是工作负载（workload），它代表一类具有共同特征的数据库连接；最内层是服务类（service class），它定义了实际的资源控制策略，比如CPU占有率、并发度、内存限制等。
工作负载本质上是一个连接分类器。当客户端发起连接时，DB2会按照工作负载定义的匹配条件逐一检查，命中的连接会被分配到对应的服务类中，从而继承该服务类的资源属性。这种设计的好处在于解耦：分类规则和资源策略分开维护，业务特征变化时只需修改工作负载定义，资源策略调整时只需修改服务类，互不干扰。
需要注意，工作负载本身不直接控制资源，它只是一个入口和标签。如果只创建了工作负载却没有关联合适的服务类，或者关联的是默认服务类，那么资源隔离的效果就无从谈起。因此在规划时，通常是先设计服务类层次，再定义工作负载把连接映射进去。
CREATE WORKLOAD的完整语法与子句详解
CREATE WORKLOAD语句的常用形式如下：
CREATE WORKLOAD WL_REPORT
APPLNAME ('db2batch')
SYSTEM_USER ('reportsvc')
SERVICE CLASS OLAP_CLASS
POSITION 1
ENABLE;这条语句创建了一个名为WL_REPORT的工作负载，匹配条件是应用程序名为db2batch且系统用户为reportsvc的连接，命中后归入OLAP_CLASS服务类。下面逐个说明关键子句的含义。
匹配属性方面，DB2提供了多个维度：APPLNAME按客户端应用程序名称匹配；SYSID和SYSTEM_USER按操作系统的登录身份匹配；SESSION_USER、AUTHID按数据库授权ID匹配；INHERIT用于通过信任连接传递身份的场景；LOCATION可以匹配客户端的IP地址或主机名。多个条件同时出现时是逻辑与的关系，即必须全部满足才算命中。
POSITION子句决定匹配的优先顺序。DB2按POSITION值从小到大依次检查工作负载，数值越小优先级越高，第一个命中的工作负载即为连接的最终归属。如果多个工作负载的匹配范围有重叠，务必显式指定POSITION，否则DB2会按系统内部顺序处理，结果可能不符合预期。一般做法是把条件最严格的工作负载放在最前面，宽泛的放在后面。
每个子句中还可以使用通配符，例如APPLNAME ('report%')表示匹配所有以report开头的应用名，百分号代表任意长度的任意字符，这为批量分类提供了灵活性。
工作负载与服务类、阈值的三件套配合
单独的工作负载没有意义，它必须和CREATE SERVICE CLASS以及CREATE THRESHOLD配合使用，才能形成完整的资源管控方案。下面是一个典型组合：
-- 创建服务类，指定资源代理方式
CREATE SERVICE CLASS OLAP_CLASS;
-- 创建工作负载，把报表应用的连接映射进去
CREATE WORKLOAD WL_REPORT
APPLNAME ('report_app')
SERVICE CLASS OLAP_CLASS
POSITION 1
ENABLE;
-- 创建阈值，限制该类连接的最大并发查询成本
CREATE THRESHOLD TH_REPORT_COST
FOR SERVICE CLASS OLAP_CLASS
ACTIVITIES ENFORCEMENT STATEMENT
WHEN ESTIMATEDSQLCOST > 100000
STOP EXECUTION;
COMMIT;这套配置实现了三层控制：工作负载负责识别report_app应用的连接；服务类作为资源分配的载体，可以进一步通过ALTER SERVICE CLASS设置代理方式、并发属性等；阈值则对进入该服务类的活动施加限制，这里设定估算成本超过十万的SQL直接停止执行，防止失控的大查询拖垮系统。
阈值既可以绑定服务类，也可以直接绑定工作负载。绑定工作负载时只影响该分类的连接，粒度更细；绑定服务类时则对该类下的所有工作负载生效。实践中建议阈值尽量挂在服务类上，便于统一管理和复用。
验证、修改与删除工作负载的常用操作
创建完成后，验证工作负载是否正确命中是必不可少的步骤。DB2提供了系统目录视图来检查定义，通过查询SYSCAT.WORKLOADS可以看到所有工作负载的匹配条件、服务类归属和POSITION值。而要确认实际连接被分到了哪个工作负载，可以使用MON_GET_CONNECTION表函数：
SELECT VARCHAR(application_handle, 10) AS APP_HANDLE,
VARCHAR(workload_name, 20) AS WORKLOAD,
VARCHAR(service_class_name, 20) AS SERVICE_CLASS
FROM TABLE(MON_GET_CONNECTION(NULL, -2));如果查询结果显示连接仍落在SYSDEFAULTUSERWORKLOAD上，说明没有命中预期的工作负载，需要回头检查匹配属性是否写对，尤其是应用名称的大小写和通配符的使用。
修改工作负载使用ALTER WORKLOAD语句，例如ALTER WORKLOAD WL_REPORT POSITION 2调整优先级，或者ALTER WORKLOAD WL_REPORT DISABLE临时禁用。禁用后新连接不再按该工作负载匹配，已存在的连接不受影响。删除则使用DROP WORKLOAD，但如果已有阈值绑定在该工作负载上，需要先删除相关阈值，否则会报依赖错误。
另一个常见报错是SQL20312，提示服务类不存在。这提醒我们执行顺序很重要：必须先创建服务类，再创建引用它的工作负载。所有WLM对象的创建和修改都要在提交后才完全生效，脚本中别忘了最后的COMMIT语句。
生产环境实践建议
在实际部署中，建议先梳理业务清单，明确哪些应用需要隔离、各自期望的资源水平，再设计服务类层次和工作负载匹配规则。匹配条件应尽量选择稳定且唯一的属性，比如专用的授权ID或应用名称，避免使用容易变化的IP地址作为主要分类依据。
POSITION规划建议预留间隔，例如按1、10、20编排，方便后续插入新的工作负载而不必整体调整。同时保留默认工作负载SYSDEFAULTUSERWORKLOAD作为兜底，未被任何规则命中的连接会进入默认用户服务类，其资源策略也不应完全放任不管。
上线后要持续观察各服务类的资源消耗情况，利用MON_GET_SERVICE_SUBCLASS等监视器表函数收集CPU时间、活动数量等指标，根据实际情况动态调整阈值参数和并发限制。WLM不是一次配置就一劳永逸的功能，随着业务演进不断迭代优化，才能真正发挥资源隔离与保障核心业务的价值。
DB2 workloadcreate workloadDB2工作负载修改时间：2026-09-02 14:50:51