在一台共享的DB2数据库服务器上，报表系统跑一个大查询把CPU吃满，导致在线交易响应变慢甚至超时，这类资源争抢问题几乎每个DBA都遇到过。传统做法是靠操作系统层面的资源限制或者人为错峰调度，效果有限且维护成本高。DB2从9.5版本开始引入的工作负载管理（Workload Manager，简称WLM），把资源控制能力下沉到数据库引擎内部，可以按照业务来源识别请求，再针对性地分配CPU、I/O、内存和并发资源。要用好这套机制，首先要弄清楚它的几个基本概念和整体工作流程。
WLM要解决什么问题
在没有WLM的时代，数据库只能被动地处理到达的每一个请求，先来先服务。问题在于，不同请求对业务的重要性差别很大：一笔在线支付请求可能要求毫秒级返回，而一个月度统计报表跑十分钟也无所谓。如果两者混在同一个队列里抢资源，就可能出现低价值的长查询把高价值交易挤到一边的情况。
WLM的核心思想是分类加控制。所谓分类，就是根据连接属性、SQL文本、会话用户等条件，把进入数据库的请求划分到不同的逻辑组；所谓控制，就是对每个逻辑组施加不同的资源策略，比如限制并发数、设置排队阈值、控制CPU占用比例。这样一来，数据库不再是简单的一锅粥，而是一个有秩序的资源分配体系。
需要注意的是，WLM不是限流工具的简单替代品。它是一个声明式的管理框架，DBA定义的是业务意图，比如这个应用优先级更高、那个作业最多允许并发5个，具体怎么实现由数据库引擎自动完成。这也是它比外部脚本调度更稳定、更精细的根本原因。
WLM的核心对象模型
WLM由一组相互协作的对象构成，理解这些对象的职责是掌握WLM的关键。下面逐个说明。
工作负载是入口对象，它定义了一组识别条件，用来匹配进入数据库的连接或请求。常见的匹配维度包括SESSION_USER、APPLICATION_NAME、客户端IP地址等。一个连接一旦命中某个工作负载的定义，就会被映射到对应的服务类中。可以把工作负载理解为数据库前台的接待员，负责判断来的人该走哪条通道。
服务类是资源分配的实际载体。每个服务类拥有独立的执行环境，包括并发控制、CPU共享、内存限制、I/O优先级等。服务类分为服务超类和服务子类，超类通常对应一个大业务系统，子类对应系统内部更细的请求类型。没有命中任何工作负载的请求会进入默认的系统服务类SYSDEFAULTUSERCLASS，这也是排查问题时的重要线索。
工作类集和工作操作集提供了更细粒度的请求级控制。工作类按SQL特征分类，比如READ类型匹配查询、WRITE类型匹配增删改，还可以配合正则表达式匹配特定SQL文本。工作操作集则定义命中工作类之后的动作，比如把请求映射到某个服务子类，或者直接拒绝执行。这套机制弥补了工作负载只能按连接级识别的不足，可以做到语句级的精细管理。
阈值是限制和熔断手段。可以针对服务类或工作类设置阈值，常见类型包括并发数上限CONCURRENTDBCOORDACTIVITIES、执行时间上限ACTIVITYTOTALTIME、队列等待时间QUEUEDACTIVITIES等。超限动作可以是继续执行、停止活动、强制中断连接或者将其排队，组合起来就能实现削峰、熔断、隔离慢SQL等目标。
一个请求在WLM中的完整流转
理解了各个对象，再把它们串起来看请求的处理流程就清晰了。当一个连接请求到达DB2时，引擎首先评估所有已定义的工作负载定义，按照优先级顺序找到第一个匹配的定义，并将该连接映射到其对应的服务超类。这一步决定了连接整个生命周期内的基础资源策略。
连接建立后执行具体SQL时，引擎会继续评估服务超类下挂的工作类集。如果某条语句命中了某个工作类，对应的工作操作就会被触发，这条语句可能被路由到不同的服务子类，也可能触发一个阈值检查。整个过程是流水式的：先连接级识别，再语句级识别，最后执行前的阈值校验。
举例来说，可以把ERP系统的连接通过工作负载映射到ERP专属服务超类，再在工作类集中定义一条规则，凡是包含全表扫描特征的统计报表语句路由到低优先级子类，并设置并发阈值为3，超出部分排队等待。而普通交易语句走高优先级子类，不设并发限制。这样就实现了同一系统内部轻重业务的隔离。
实际配置时建议循序渐进：先只创建工作负载和服务类做识别与基础隔离，观察监控数据确认分类准确后，再逐步添加阈值和语句级规则。一上来就配置复杂的阈值组合，很容易误伤正常业务，排查起来也非常困难。
常用监控与验证手段
WLM配置完成后，验证请求是否按预期分类是必须做的功课。DB2提供了几个关键的监控表函数，其中MON_GET_CONNECTION可以查看每个连接当前映射的工作负载和服务类，MON_GET_WORKLOAD和MON_GET_SERVICE_SUBCLASS则分别返回工作负载级和服务子级的活动数、CPU时间等统计信息。
-- 查看当前连接的工作负载与服务类映射情况
SELECT VARCHAR(APPLICATION_HANDLE, 20) AS APP_HANDLE,
SESSION_USER,
WORKLOAD_NAME,
SERVICE_SUPERCLASS_NAME,
SERVICE_SUBCLASS_NAME
FROM TABLE(MON_GET_CONNECTION(NULL, -2)) AS T;
上面的查询能够直观展示每个会话被分到了哪里。如果发现某些连接落在了SYSDEFAULTUSERCLASS，说明工作负载的匹配条件没有覆盖到它们，需要调整定义中的属性条件。
除了表函数，事件监视器也是WLM体系的重要一环。通过创建阈值违规事件监视器和活动事件监视器，可以记录哪些语句触发了限流或超时，为后续调整阈值参数提供数据依据。配合DB2提供的WLM统计信息，就能形成配置、监控、调整的闭环，让工作负载管理真正服务于业务目标。
总的来说，WLM的基本概念并不复杂：工作负载负责识别，服务类负责承载资源策略，工作类和操作负责语句级路由，阈值负责限制与保护。把这些对象的职责和协作关系理清楚，后续无论是做资源隔离还是慢SQL管控，都有了清晰的理论基础。