resmgr:cpu quantum等待表明oracle资源管理器正主动限速，非cpu不足而是按时间片分配；ash可确认其是否真实主导负载，需过滤session_state='waiting'并结合dba_scheduler_windows定位维护窗口。
遇到 resmgr:cpu quantum 等待，说明会话正被资源管理器主动限速，不是 CPU 不够用，而是 Oracle 在“掐表”分配时间片。ASH 本身不记录该等待的内部调度细节，但能帮你确认它是否真实主导了系统负载、是否集中在特定窗口或用户组，从而避免误判为硬件瓶颈或 SQL 性能问题。
查ASH里resmgr:cpu quantum是否真在吃CPU
很多人一看到 top 显示 CPU 高、AWR 报告里 resmgr:cpu quantum 排第一，就急着关资源管理。但 ASH 能告诉你：这个等待是不是“真忙”，还是只是“假高”——比如大量会话排队等量子，实际却没干活。
- 必须加
session_state = 'WAITING'过滤，否则ON CPU样本会被混入，扭曲判断 - 只统计
event = 'resmgr:cpu quantum'，注意大小写敏感，不能写成'RESMGR:CPU QUANTUM' - 别漏掉时间范围：
SAMPLE_TIME > SYSDATE - INTERVAL '10' MINUTE比SYSDATE - 1/144更可靠，防 NLS 时区偏差 - 示例查询：
SELECT sql_id, COUNT(*) cnt, COUNT(DISTINCT session_id) sess_cnt FROM v$active_session_history WHERE event = 'resmgr:cpu quantum' AND session_state = 'WAITING' AND sample_time > SYSDATE - INTERVAL '10' MINUTE GROUP BY sql_id ORDER BY cnt DESC;
如果结果里 sql_id 大量为 0000000000000000，说明是后台任务（如自动维护）触发的限速，不是业务 SQL；如果 cnt 很高但 sess_cnt 很低，说明少数会话反复被掐，可能配置了过严的 CPU_P1。
关联DBA_SCHEDULER_WINDOWS确认是否在维护窗口内
resmgr:cpu quantum 高发往往不是配置错误，而是撞上了默认维护窗口——Oracle 11g+ 每天固定时段会启用 DEFAULT_MAINTENANCE_PLAN，强制把后台任务塞进资源组，哪怕你没显式开资源管理。
- 直接查窗口状态：
SELECT window_name, resource_plan, active FROM dba_scheduler_windows WHERE active = 'TRUE'; - 重点看
WEEKNIGHT_WINDOW（周一至周五 22:00–02:00）、WEEKEND_WINDOW（周末 06:00–02:00），这些窗口默认绑定了限制性计划 - 如果发现
resource_plan非空（如DEFAULT_MAINTENANCE_PLAN），且 ASH 中resmgr:cpu quantum样本集中出现在该窗口内，基本可锁定根源 - 此时不要急着禁用整个资源管理器，先临时解除窗口绑定更安全：
EXEC DBMS_SCHEDULER.SET_ATTRIBUTE('WEEKNIGHT_WINDOW', 'RESOURCE_PLAN', '');
区分用户级 vs 后台任务引发的等待
同一个等待事件，源头不同，处理方式完全不同：业务用户被限速要调 consumer group 配额；后台任务被限速则要关窗口或禁用自动任务。
- 加
session_type判断来源：session_type = 'BACKGROUND'表明是cjq0、mmon等后台进程在等量子，和业务 SQL 无关 - 加
program和module辅助定位：program LIKE '%cjq%'或module = 'oracle@db01 (J000)'是 job 队列典型特征 - 如果是业务会话（
session_type = 'USER'），再查consumer_group：SELECT consumer_group FROM v$session WHERE sid = <sid>;</sid> - 常见陷阱：用户映射到了
OTHER_GROUPS，而该组未在 plan 中定义 CPU 配额，默认就是“零配额”，导致所有会话都被卡在resmgr:cpu quantum
为什么ASH查不到完整调用链
ASH 记录的是“谁在等”，但不记录“为什么被限”——它不会告诉你当前会话属于哪个 consumer group、该 group 的 CPU_P1 是多少、是否被 plan directive 动态调整过。这些元信息只存在 dba_rsrc_consumer_groups、dba_rsrc_plan_directives 等数据字典里。
所以，仅靠 ASH 无法闭环排查。必须把 ASH 结果中的 sql_id 或 session_id 拿去反查 v$session，再关联 v$rsrc_session_info 获取实时 consumer group 和 active plan，最后比对 dba_rsrc_plan_directives 中的配额设置。这三步缺一不可，跳过任何一步都容易把配置错误当成性能 bug。
