resmgr:cpu quantum等待事件表明会话因资源管理器cpu配额耗尽被强制暂停，非cpu不足；根本原因是default_maintenance_plan在调度窗口（如周一至周五22:00–02:00）自动激活，需通过dbms_scheduler.set_attribute清空各窗口的resource_plan绑定，而非仅置空resource_manager_plan。
resmgr:cpu quantum 等待不是 cpu 不够，而是资源管理器在“掐表”——会话被强制暂停，等下一轮配额。直接关掉默认维护计划比调权重更有效。
查清是不是 DEFAULT_MAINTENANCE_PLAN 在偷偷生效
即使 RESOURCE_MANAGER_PLAN 显示为空，DBA_SCHEDULER_WINDOWS 仍可能在窗口开启时自动激活 DEFAULT_MAINTENANCE_PLAN。这是 Oracle 12c（及 11g 后）的默认行为，每周一至周五 22:00–02:00、周末 06:00–02:00 自动触发。
- 执行
SELECT window_name, resource_plan FROM dba_scheduler_windows;，确认SATURDAY_WINDOW、WEEKEND_WINDOW等是否绑定了DEFAULT_MAINTENANCE_PLAN或SYSTEM_PLAN - 检查 alert log，搜索 “Setting Resource Manager plan … DEFAULT_MAINTENANCE_PLAN”，出现即为实锤
- 不要只看
SHOW PARAMETER resource_manager_plan—— 它可能为 NULL，但 scheduler 窗口仍可覆盖
禁用窗口级资源计划（推荐首选操作）
关闭窗口绑定的资源计划，比全局禁用更精准，且不影响其他自定义资源管理策略。
- 逐个清除窗口关联：
EXEC DBMS_SCHEDULER.SET_ATTRIBUTE('MONDAY_WINDOW', 'RESOURCE_PLAN', '');，对TUESDAY_WINDOW到SUNDAY_WINDOW重复执行 - 验证是否生效：
SELECT window_name, resource_plan FROM dba_scheduler_windows;，所有RESOURCE_PLAN应为空字符串或NULL - 注意：该操作无需重启实例，但需有
MANAGE SCHEDULER权限；若使用 RAC，需在所有节点执行
彻底关闭资源管理器（谨慎使用）
当确认不需要任何资源组隔离或优先级控制时，可停用底层机制。但 12c 默认启用隐含参数，仅设空 RESOURCE_MANAGER_PLAN 不够。
- 先清空主参数：
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '' SCOPE=BOTH; - 再禁用隐含开关（需重启）：
ALTER SYSTEM SET "_resource_manager_always_on" = FALSE SCOPE=SPFILE; - 重启后检查：
SELECT name, value FROM v$parameter WHERE name LIKE '%resource%';，确认_resource_manager_always_on为FALSE，且resource_manager_plan为空 - 风险：禁用后，自动 SQL 调优、AWR 快照收集等维护任务将失去 CPU 保障，可能延长执行时间或失败
为什么优化 SQL 有时无效？
遇到 resmgr:cpu quantum 时，别急着重写 SQL——它不反映语句本身慢，而是反映“该语句正在被资源管理器按计划掐断”。常见误判点：
- ASH 中看到高频率
resmgr:cpu quantum+ 某个SQL_ID，不代表这 SQL 有问题；它只是恰好在窗口期运行、且属于被限速的消费者组 - 加索引、改执行计划可能降低单次 CPU 消耗，但只要资源计划还在，它仍会被反复暂停——等待事件次数未必下降
- 真正该查的是：这个 SQL 是否属于
OTHER_GROUPS？是否被意外分配到低配额消费者组？用V$SESSION查CONSUMER_GROUP列
最常被忽略的一点：窗口配置是持久化的，哪怕你临时 ALTER SYSTEM 清空了 RESOURCE_MANAGER_PLAN，一旦窗口时间到达，它又会自动拉起。必须从 DBA_SCHEDULER_WINDOWS 层面切断源头。
