DB2数据库面对混合负载时，如果没有资源限制，批处理任务很容易占满CPU和临时表空间，拖慢在线交易。DB2的资源限制与优先级控制不是一个孤立参数，而是由Workload Manager、threshold、service class和映射规则共同组成的管理框架。它的目标不是限制数据库本身的吞吐，而是把有限的CPU、内存、临时表空间和I/O能力按业务优先级分配给不同的连接与活动。
一、WLM对象模型与资源限制类型
DB2 LUW的Workload Manager围绕几个核心对象展开：workload、service class、work action set和threshold。workload代表一组具有相同业务属性的连接或活动，例如来自某个应用名的所有会话。service class是执行资源控制的目标，可以定义不同执行阶段和优先级。threshold定义某个资源上限或活动特征阈值，当条件触发时执行停止、降级或继续动作。
资源限制主要分为系统资源限制和活动行为限制。系统资源包括CPU时间、临时表空间使用量、排序内存、日志写入量等；行为限制包括返回行数、估计SQL成本、活动执行时间等。这些阈值可以挂在workload或service class上，执法范围可以是database、partition或activity级别。合理配置threshold能在问题扩大前阻断异常SQL。
-- 创建批处理工作负载，映射应用名
CREATE WORKLOAD wl_batch APPLNAME('BATCH_APP') SERVICE CLASS sc_batch;
-- 创建服务类，用于承载批处理活动
CREATE SERVICE CLASS sc_batch;
-- 限制批处理工作负载的临时表空间上限
CREATE THRESHOLD th_batch_tempspace
FOR WORKLOAD wl_batch ACTIVITIES
ENFORCEMENT DATABASE
WHEN TEMPSPACE > 1024 M
STOP EXECUTION;
上面的阈值一旦触发，超出1024M临时表空间的活动会被直接停止。除了STOP EXECUTION，还可以设置为CONTINUE只记录但不阻止，适合先观察再收紧策略。resource limit facility在z/OS环境下也有类似功能，通过资源限制表控制SQL语句的资源消耗，但在LUW中WLM更加灵活和动态。
二、优先级控制：Service Class与Workload映射
仅有限制还不够，当多个workload同时运行时，DB2如何决定谁先获得CPU和I/O？这由service class的优先级和代理优先级控制。DB2 WLM使用多层service class结构，默认服务类下可以创建子类，父类与子类都有period属性。不同period表示活动的执行阶段，例如第一个period用于短查询，第二个period用于长查询，可以根据阶段切换资源分配策略。
优先级数值越高，获得资源的比例越大。通过ALTER SERVICE CLASS可以调整agent priority、prefetch priority和buffer pool priority。agent priority直接影响代理进程获得CPU调度的能力；buffer pool priority影响页面读取和缓存命中竞争。常见策略是给在线交易服务类设置高优先级，给批处理和报表服务类设置较低优先级，确保关键业务不被拖垮。
-- 创建关键交易服务类并设置高代理优先级
CREATE SERVICE CLASS sc_oltp;
ALTER SERVICE CLASS sc_oltp AGENT PRIORITY 95;
-- 创建批处理服务类并设置较低代理优先级
CREATE SERVICE CLASS sc_batch;
ALTER SERVICE CLASS sc_batch AGENT PRIORITY 40;
-- 将不同应用映射到不同服务类
CREATE WORKLOAD wl_oltp APPLNAME('OLTP_APP') SERVICE CLASS sc_oltp;
CREATE WORKLOAD wl_batch APPLNAME('BATCH_APP') SERVICE CLASS sc_batch;
虽然CREATE WORKLOAD在代码中出现了两次，但真实环境中可以在一条DDL中为一个workload设置多个映射条件，如应用名、会话用户、客户端工作站名等。如果多个workload条件重叠，DB2按照创建顺序匹配第一个满足条件的定义，因此需要把更具体的规则放在前面。例如先匹配某个用户名的批处理会话，再匹配应用名的通用规则。
三、典型场景与监控验证
假设数据库白天主要承载在线交易，夜间运行大规模报表。白天如果报表任务启动，会与交易争抢CPU和临时表空间。可以为报表用户创建独立workload，限制其CPU时间和返回行数，同时把服务类优先级降到20。这样即使报表SQL出现笛卡尔积或缺少过滤条件，也不会拖垮整个实例。
-- 创建报表用户工作负载
CREATE WORKLOAD wl_report SESSION_USER ('report_user') SERVICE CLASS sc_report;
-- 限制报表活动CPU时间与返回行数
CREATE THRESHOLD th_report_cpu
FOR WORKLOAD wl_report ACTIVITIES
ENFORCEMENT DATABASE
WHEN CPUTIME > 50000
STOP EXECUTION;
CREATE THRESHOLD th_report_rows
FOR WORKLOAD wl_report ACTIVITIES
ENFORCEMENT DATABASE
WHEN SQLROWSRETURNED > 100000
CONTINUE;
配置完成后，不能只凭感觉判断是否生效。DB2提供了一系列表函数和系统视图用于监控。可以查询SYSCAT.WORKLOADS查看workload定义，查询SYSCAT.THRESHOLDS查看阈值定义，使用MON_GET_WORKLOAD和WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURRENCES查看运行时指标和阈值触发次数。重点关注警报名、活动被停止次数以及平均排队时间，如果频繁触发阈值，应调整阈值或优化SQL。
SELECT SUBSTR(WORKLOAD_NAME,1,30) AS WORKLOAD_NAME,
COORD_ACT_LIFETIME_AVG,
TOTAL_ACT_COMPLETED,
TOTAL_ACT_ABORTED
FROM TABLE(MON_GET_WORKLOAD('', -2)) AS T
ORDER BY WORKLOAD_NAME;
该查询返回全部工作负载的活动统计。如果TOTAL_ACT_ABORTED数量明显上升，说明阈值控制正在起作用，但也可能提示SQL需要优化。优先级调整后还可以观察平均活动执行时间和排队时间，验证高优先级workload是否获得了更稳定的响应。
四、常见误区与调优建议
一种常见误区是管理员把阈值设置得越严格越好，或者把所有资源都限制得很低。实际上资源限制的执法动作是STOP EXECUTION时，部分已经执行的活动会被回滚，频繁停止长时间统计查询可能造成重复计算和资源浪费。更合理的做法是先以CONTINUE模式运行一段时间，收集真实负载数据，再根据P95或P99耗时设置安全阈值。
优先级控制也不是简单调大一个数字。需要区分agent priority与buffer pool priority的关系。agent priority只影响CPU调度，如果瓶颈在磁盘I/O或缓冲池命中率，单独调高agent priority可能效果有限。此时应同时调整buffer pool priority，并通过db2pd或MON_GET_BUFFERPOOL视图分析命中率。只有针对瓶颈设置优先级，才能获得明显改善。
最后，资源限制规则需要纳入变更流程。每次上线新应用或修改连接属性时，要检查是否落入已有workload映射。映射顺序错误、服务类遗漏或阈值不匹配都可能让控制策略失效。可以定期导出SYSCAT.WORKLOADS和SYSCAT.THRESHOLDS的配置进行审计，并在测试环境回放生产负载，观察活动停止次数和排队时间，确保新的资源控制策略上线前经过验证。