resmgr:cpu quantum等待高说明资源管理器正强制限制cpu，非数据库真忙而是自限导致卡顿；需重点检查调度窗口（如weeknight_window）是否绑定default_maintenance_plan，而非仅看resource_manager_plan参数是否为空。
resmgr:cpu quantum 等待高，说明资源管理器正在强制限 cpu，不是数据库真忙，而是被自己卡住了。 这在 oracle 11g 中尤其典型——哪怕你 alter system set resource_manager_plan=''，它仍可能高频出现，因为默认维护窗口（如 weeknight_window）会悄悄激活 default_maintenance_plan。
查清到底是谁在触发资源管理
别只看 RESOURCE_MANAGER_PLAN 参数是否为空。11g 起，调度窗口才是“幕后开关”：
- 运行
SELECT window_name, resource_plan, active FROM DBA_SCHEDULER_WINDOWS;，重点确认WEEKNIGHT_WINDOW和WEEKEND_WINDOW的RESOURCE_PLAN字段是否为DEFAULT_MAINTENANCE_PLAN - 查 alert log，搜索
Setting Resource Manager plan.*DEFAULT_MAINTENANCE_PLAN，确认触发时间是否与等待高峰吻合 - 用
SELECT sid, event, state, seconds_in_wait FROM v$session WHERE event = 'resmgr:cpu quantum';定位活跃会话，再关联v$session.sql_id看是不是维护任务（如SYS_AUTO_SQL_TUNING_TASK）在跑
禁用 DEFAULT_MAINTENANCE_PLAN 的安全操作顺序
直接设空 RESOURCE_MANAGER_PLAN 不够，必须切断窗口绑定：
- 先清空当前计划：
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN='' SCOPE=BOTH; - 再解除所有窗口的资源计划绑定（缺一不可）：
EXEC DBMS_SCHEDULER.SET_ATTRIBUTE('WEEKNIGHT_WINDOW', 'RESOURCE_PLAN', '');EXEC DBMS_SCHEDULER.SET_ATTRIBUTE('WEEKEND_WINDOW', 'RESOURCE_PLAN', '');EXEC DBMS_SCHEDULER.SET_ATTRIBUTE('MONDAY_WINDOW', 'RESOURCE_PLAN', '');（其他工作日窗口同理） - 重启后验证：
SELECT * FROM DBA_RSRC_PLANS WHERE plan = 'DEFAULT_MAINTENANCE_PLAN';应无返回；SELECT window_name, resource_plan FROM DBA_SCHEDULER_WINDOWS;所有RESOURCE_PLAN列应为空
隐含参数是最后手段，但有时绕不开
如果上述操作后仍有等待，且确认是 Oracle 11.1.0.6–11.2.0.4 的已知 Bug（如 Bug 7510766、Bug 8221960），需启用隐含参数：
-
ALTER SYSTEM SET "_resource_manager_always_on"=FALSE SCOPE=SPFILE SID='*';—— 关闭资源管理器常驻逻辑 -
ALTER SYSTEM SET "_resource_manager_always_off"=TRUE SCOPE=SPFILE SID='*';—— 强制禁用底层调度器参与 - 这两个参数必须加
SCOPE=SPFILE并重启实例才生效；修改前务必备份 spfile - 注意：Oracle 官方不推荐长期启用这些参数，仅用于紧急规避；升级到 11.2.0.5+ 或 12c 可规避多数相关 Bug
别忽略维护窗口本身的合理性
彻底禁用维护计划能止痛，但代价是优化器统计信息陈旧、SQL 自动调优停摆、AWR 清理延迟——长期可能引发更隐蔽的性能退化：
- 优先尝试把
WEEKNIGHT_WINDOW时间段从 22:00–02:00 改到业务低谷期（如 03:00–05:00），用DBMS_SCHEDULER.SET_ATTRIBUTE调整START_DATE和DURATION - 若 CPU 确实长期吃紧，应同步检查
V$SQL中 CPU 消耗 Top SQL，避免把资源管理当成低效 SQL 的遮羞布 - 监控
DBA_HIST_ACTIVE_SESS_HISTORY中event='resmgr:cpu quantum'的 P1 值：若多为"2","0","0"，基本可锁定是维护任务而非用户 SQL 触发
真正麻烦的不是怎么关掉它，而是关掉之后没人记得——下次窗口自动打开，或者某次补丁升级重置了 scheduler 属性，resmgr:cpu quantum 就会无声无息地卷土重来。
