resmgr:cpu quantum 等待事件占比过高的原因

“resmgr:cpu quantum” 等待事件是 Oracle 资源管理器（Resource Manager） 调控 CPU 资源时产生的典型等待，当该事件占比过高，表明数据库的 CPU 资源分配正被资源管理器严格限制，本质是目标会话 / 消费者组的 CPU 配额已耗尽，需等待下一个 CPU 时间片（Quantum）才能继续执行。

一、核心原理：为什么会产生该等待？

Oracle 资源管理器通过 消费者组（Consumer Group） 对不同类型的会话进行分组，并基于 资源计划（Resource Plan） 定义的规则分配 CPU 资源。其核心机制如下：

1. CPU 时间片（Quantum）：资源计划会为每个消费者组分配一个 “CPU 时间片”（例如 100ms），即该组的会话一次最多可连续占用 CPU 的时长。
2. 配额耗尽触发等待：当某个会话所在的消费者组耗尽了其分配的 CPU 时间片后，Oracle 会暂停该会话，将 CPU 资源让给其他符合规则的消费者组，并标记该会话处于 “resmgr:cpu quantum” 等待状态。
3. 等待下一轮调度：被暂停的会话需等待资源管理器重新调度，获取新的 CPU 时间片后才能恢复执行。

简言之，该等待是资源管理器 “主动调控 CPU 分配” 的直接体现，而非 CPU 硬件本身完全饱和（但可能间接相关）。

二、等待事件占比过高的 4 类核心原因

1. 资源计划配置不合理（最直接原因）

资源计划的规则定义直接决定了 CPU 分配逻辑，配置不当是该等待高发的首要因素：

• CPU 配额分配不足目标消费者组（如业务核心的 OLTP_GROUP）分配的 CPU 比例过低，无法满足其实际需求。例如：资源计划规定 OLTP_GROUP 仅占 20% CPU，而该组的业务（如高频交易、实时查询）实际需要 50% 以上的 CPU，导致会话频繁耗尽时间片并等待。
• CPU 时间片设置过小时间片（Quantum）设置过短（如 <50ms），即使总配额足够，会话也会因 “频繁被打断” 而产生大量等待。例如：某组的 CPU 配额占比 50%，但时间片仅 20ms，会话每执行 20ms 就需等待调度，累计等待时间剧增。
• 资源计划规则冲突 / 优先级倒置资源计划中存在 “低优先级组抢占高优先级组资源” 的规则（如 SWITCH_TIME 或 MAX_UTILIZATION_LIMIT 配置不当）。例如：为了限制 “报表查询组” 的 CPU 使用率不超过 30%，但误将规则应用于核心业务组，导致核心会话被频繁限制。

2. 目标消费者组负载过高

即使资源计划配置合理，若某个消费者组的 实际 CPU 需求远超其分配的配额，也会触发大量等待：

• 会话数量过多：同一消费者组内并发会话数激增（如促销活动导致 OLTP 会话从 100 增至 500），单个会话能分到的 CPU 时间片被稀释，频繁等待。
• SQL 执行效率低下：组内存在大量 “CPU 密集型” 慢 SQL（如全表扫描、复杂排序 / 聚合、低效循环），单条 SQL 就耗尽了组内的 CPU 配额，导致其他正常会话被迫等待。

3. 系统 CPU 整体饱和（间接诱因）

若数据库服务器的 物理 CPU 已完全耗尽（操作系统层面 %user + %sys 接近 100%），资源管理器的调度会更加频繁，间接放大 “resmgr:cpu quantum” 等待的占比：

• 此时即使消费者组的配额未耗尽，操作系统也无法分配物理 CPU 资源，资源管理器会延长会话的等待时间，直到有 CPU 核心空闲。
• 常见场景：多实例共享主机、数据库与应用 / 中间件混部，导致 CPU 争抢严重。

4. 资源管理器配置错误

• 消费者组映射错误：将核心业务会话错误地映射到了低优先级消费者组（如本应属于 OLTP_GROUP 的会话，因 DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING 配置错误，被分配到 BATCH_GROUP），导致核心会话被严格限制 CPU。
• 资源计划未生效或切换错误：例如，计划在 “业务高峰” 启用 PEAK_PLAN（给 OLTP 高配额），但实际未切换，仍使用 OFF_PEAK_PLAN（给 OLTP 低配额），导致高峰时等待激增。

三、排查与验证思路

1.确认资源计划与消费者组配置

-- 查看当前激活的资源计划
--11g 及更早版本：
SELECT name, is_top_plan
FROM   dba_resource_plans
WHERE  is_active = 'TRUE';

--12c 及之后（包括 19c）：
-- 方式1
SELECT plan, status
FROM   dba_rsrc_plans
WHERE  status = 'ACTIVE';
-- 方式2
SELECT name, is_top_plan
FROM   v$rsrc_plan;

-- 查看消费者组的 CPU 分配规则

2.定位高等待的会话 / 消费者组

-- 查看各消费者组的 resmgr:cpu quantum 等待统计
SELECT 
    cg.consumer_group,
    SUM(sw.total_waits) AS total_waits,
    SUM(sw.time_waited_micro)/1000 AS total_wait_ms
FROM 
    v$session_event sw
JOIN 
    v$session s ON sw.sid = s.sid
JOIN 
    dba_rsrc_consumer_groups cg 
    ON s.resource_consumer_group = cg.consumer_group
WHERE 
    sw.event = 'resmgr:cpu quantum'
GROUP BY 
    cg.consumer_group
ORDER BY 
    total_wait_ms DESC;

-- 查看各消费者组的 resmgr:cpu quantum 等待统计
SELECT 
    s.resource_consumer_group,
    SUM(se.total_waits) AS total_waits,
    SUM(se.time_waited_micro)/1000 AS total_wait_ms
FROM 
    v$session_event se
JOIN 
    v$session s ON se.sid = s.sid
WHERE 
    se.event = 'resmgr:cpu quantum'
GROUP BY 
    s.resource_consumer_group
ORDER BY 
    total_wait_ms DESC;

3.检查系统 CPU 与 SQL 效率

• 操作系统层面：通过 top（Linux）或 perf 查看 CPU 使用率，确认是否整体饱和。
• 数据库层面：通过 v$sql 或 AWR 报告，排查目标消费者组中 CPU 消耗最高的 SQL（按 CPU_TIME 排序），判断是否存在低效 SQL。

4.验证时间片设置资源计划的 CPU_QUANTUM 参数（默认 100ms）可通过以下视图查看：

SELECT plan, cpu_quantum 
FROM dba_resource_plans 
WHERE name = '当前激活的计划名';