应优先检查Oracle默认维护窗口（如WEEKNIGHT_WINDOW）是否启用了DEFAULT_MAINTENANCE_PLAN，若其RESOURCE_PLAN非空，则正是resmgr:cpu quantum排队根因；需用DBMS_SCHEDULER.SET_ATTRIBUTE显式清空各窗口的RESOURCE_PLAN属性，而非仅修改RESOURCE_MANAGER_PLAN参数。
这是资源管理器在强制限 CPU，不是性能瓶颈本身，而是限制造成的排队现象。直接关掉默认维护窗口的 resource plan 就能大幅缓解，别先去调 SQL 或加硬件。
查清是不是默认维护窗口在作怪
10g 及以后版本默认启用了 DEFAULT_MAINTENANCE_PLAN，它会在 WEEKNIGHT_WINDOW（周一至周五 22:00–02:00）和 WEEKEND_WINDOW（周末全天）自动激活。只要这些窗口开着，哪怕没手动配 plan，resmgr:cpu quantum 就可能出现。
执行以下语句确认当前状态：
SELECT window_name, resource_plan, enabled FROM dba_scheduler_windows;
如果看到 WEEKNIGHT_WINDOW 或 WEEKEND_WINDOW 的 resource_plan 不为空（比如是 DEFAULT_MAINTENANCE_PLAN），那就是它了。
禁用维护窗口的 resource plan
不要只改 RESOURCE_MANAGER_PLAN 参数为 ''，那只能停当前全局 plan，但窗口自带的 plan 还在生效。必须显式清空每个窗口的 RESOURCE_PLAN 属性：
EXEC DBMS_SCHEDULER.SET_ATTRIBUTE('WEEKNIGHT_WINDOW', 'RESOURCE_PLAN', '');EXEC DBMS_SCHEDULER.SET_ATTRIBUTE('WEEKEND_WINDOW', 'RESOURCE_PLAN', '');- 11g 及以上还要逐个清空
MONDAY_WINDOW到SUNDAY_WINDOW—— 漏一个，那个窗口一到点就触发等待
执行完后，重启窗口或等下次窗口开启时生效。注意：这不会影响自动统计信息收集本身，只是去掉它的 CPU 限制逻辑。
警惕 FORCE: 和隐藏参数陷阱
有人试过设 RESOURCE_MANAGER_PLAN = 'FORCE:'，但这只是让资源管理器“强制启用但无实际 plan”，反而可能加剧等待，尤其在 10.2.0.5 前的版本有已知 bug（如 BUG 10326338）会导致会话 hang 在 resmgr:cpu quantum 上不动。
也别碰 _resource_manager_always_on 这类隐含参数 —— 它在 12c+ 已被废弃，强行设 FALSE 可能引发不可预知调度异常，且需重启实例，风险远大于收益。
真要保留资源管理，就得配 consumer group CPU 比例
如果业务确实需要资源隔离（比如 OLTP 和报表共用库），不能简单关 plan，而要显式配置 consumer group 并分配 CPU 资源份额：
- 用
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP创建组 - 用
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE给组设CPU_P1~CPU_P4权重 - 确保
RESOURCE_MANAGER_PLAN指向你自定义的 plan，而非DEFAULT_MAINTENANCE_PLAN
否则，哪怕开了 plan，所有会话默认进 OTHER_GROUPS，而这个组在默认 plan 中的 CPU 配额极低，结果就是大量会话卡在 resmgr:cpu quantum 等额度。
最常被忽略的一点：resmgr:cpu quantum 看似是 CPU 不够，实则是资源管理器在“主动掐表”。它不反映真实负载，只反映限制策略是否过于激进。检查窗口配置比看 top、查 SQL 执行计划更优先。
