awr中resmgr:cpu quantum排第一说明非硬件cpu瓶颈，而是oracle资源管理器主动限频，源于默认维护窗口（如weeknight_window）激活default_maintenance_plan，导致业务sql被限制cpu时间片；需禁用各窗口resource_plan或设隐含参数_resource_manager_always_on=false。
AWR里resmgr:cpu quantum排第一，说明什么
这通常不是硬件CPU瓶颈，而是Oracle资源管理器在主动限频——哪怕你没手动配过任何resource plan，10g+版本默认启用的维护窗口（如WEEKNIGHT_WINDOW）也会悄悄激活DEFAULT_MAINTENANCE_PLAN，导致业务SQL被掐住CPU时间片。
关键判断依据：DB CPU(s)在Load Profile里占比低，但resmgr:cpu quantum在Top Events里占60%以上；或者DB Time(s)远高于DB CPU(s)，差值主要由该事件贡献。
- 不是CPU不够用，是Oracle自己“不让用”
- 常见触发时段：每天22:00–06:00、周末全天（维护窗口默认开启）
- 受影响SQL往往逻辑读高、执行频繁，比如批量UPDATE或统计信息收集作业
禁用默认维护计划的实操命令
直接清空所有窗口关联的resource plan，比单纯设resource_manager_plan=''更彻底。注意必须对每个已定义的窗口单独执行dbms_scheduler.set_attribute，漏掉一个就可能继续触发等待。
先查当前有哪些窗口在用资源计划：
SELECT window_name, resource_plan FROM dba_scheduler_windows WHERE resource_plan IS NOT NULL;
再逐个清空（Oracle 11g+通用）：
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', '');- 对
MONDAY_WINDOW到SUNDAY_WINDOW也需同样处理（12c起新增的每日窗口不能漏）
执行后立即生效，无需重启实例。
隐含参数_resource_manager_always_on的使用场景
如果按上一步操作后resmgr:cpu quantum仍持续出现，大概率是Oracle内部强制开启了资源管理（尤其10.2.0.5前版本有Bug 8221960）。此时必须用隐含参数关断：
ALTER SYSTEM SET "_resource_manager_always_on"=FALSE SCOPE=SPFILE;- 需重启数据库才生效
- 该参数在11gR2+版本中依然有效，但仅在紧急情况下使用——它会全局禁用Resource Manager所有功能
- 确认是否真有必要：查
v$parameter中resource_manager_plan值为空且所有窗口resource_plan为NULL后仍报该等待，再启用
别忽略BUG和补丁的影响
某些版本中，即使资源计划已禁用，resmgr:cpu quantum仍会因Bug持续出现。重点排查：
- Bug 8221960（10.2.0.4/11.1.0.7）：导致等待事件虚假高企，需One-off补丁
- Bug 10326338（11.2.0.1）：维护窗口关闭后resource plan残留，需升级到11.2.0.3+
- MOS文档
786346.1列出的版本兼容性清单必须核对
补丁不是万能解药——打完补丁后仍要验证AWR中该事件是否归零，否则说明配置未清理干净或存在其他隐式plan绑定。
