DB CPU高不等于操作系统CPU满载，需结合AWR中DB CPU/DB Time占比、AAS与物理核数对比判断真瓶颈；CPU per Exec突增、硬解析泛滥、resmgr:cpu quantum等待才是关键根因。
DB CPU高 ≠ 操作系统CPU满载
OS层看到top里某个oracle进程占90% CPU，不代表数据库真在“算得疯”，更可能是它卡在等待或争用上。关键看AWR报告里的DB CPU在DB Time中的占比：如果DB CPU / DB Time > 70%，且Average Active Sessions远超物理CPU核数（比如12核机器AAS=18），才说明CPU确实是瓶颈；否则大概率是假象——真实问题藏在latch: library cache、latch: shared pool这类等待事件里。
CPU per Exec突增才是真凶线索
AWR报告中SQL ordered by CPU Time只看总CPU时间容易误判。必须下钻到CPU per Exec列：
- 跳过
EXECUTIONS = 0但CPU_TIME_SEC > 0的SQL（游标异常或统计未刷新） - 重点关注
CPU per Exec > 10秒 +Executions per Sec > 0.1的语句——它每秒都在稳定吃CPU - 对比历史报告：同一
sql_id在问题时段CPU per Exec暴涨3倍以上，基本锁定执行计划劣化（如索引失效、统计信息陈旧）
用DBMS_XPLAN.DISPLAY_AWR('<sql_id>', NULL, 'ALLSTATS LAST')查实际执行计划，重点盯FULL TABLE SCAN、NESTED LOOPS放大、FILTER操作——这些才是CPU密集型模式。
硬解析泛滥会把CPU耗在“准备”上
Oracle 12c虽有自适应游标共享，但应用若没用绑定变量，每次执行都走硬解析：语法校验、权限检查、生成执行计划……全在CPU上干。这时DB CPU高，但实际不是SQL在跑，而是解析在卡。
- 看AWR里
Parse CPU to Parse Elapsd %：低于20%，说明解析过程大量等latch，不是真计算 - 查
parse count (hard)是否飙升——每秒硬解析上百次，就是绑定变量缺失的铁证 -
cursor_sharing设为FORCE只是临时缓解，治本要改应用代码
resmgr:cpu quantum等待常被误读
看到大量resmgr:cpu quantum等待，第一反应不是“CPU不够”，而是资源管理器在主动限流。尤其当resource_manager_plan非空（如DEFAULT_MAINTENANCE_PLAN），自动任务（如统计信息收集、段收缩）可能被调度到业务高峰期。
- 执行
show parameter resource_manager_plan确认是否启用 - 查
dba_scheduler_windows，看维护窗口是否与业务高峰重叠 - 临时禁用：
alter system set resource_manager_plan = ''，观察是否缓解
真正难啃的骨头，往往不在SQL本身，而在执行计划失稳、绑定变量缺失、资源计划误配这三处——它们不报错，但会让CPU持续发热，且每次波动原因还不一样。
