先看time model statistics中db cpu占db time比例是否超70%且aas持续超物理核数，才是真实cpu瓶颈；低于40%则多为解析或闩锁争用所致，需结合top 5 events、os statistics及后台任务交叉验证。
看Time Model Statistics里的DB CPU占比，别信top输出
操作系统top里看到oracle进程占CPU 90%，不等于数据库真在满负荷计算。AWR的Time Model Statistics页才是判断依据：DB CPU占DB Time比例低于40%，大概率不是SQL执行问题，而是解析或闩锁争用把CPU耗在等待路径上；超过70%且Average Active Sessions（AAS）持续高于物理核数，才说明CPU是真实瓶颈。
注意：DB CPU是累计值——12核机器1秒最多贡献12秒CPU时间；报告里显示3600秒，意味着该时段平均每秒消耗了300秒CPU（即25核等效满载），远超物理资源。
查Top 5 Timed Foreground Events，识别非SQL类CPU消耗源
当DB CPU占比不高但CPU使用率仍高时，往下翻到Top 5 Timed Foreground Events：
- 若
latch: shared pool或latch: library cache排进前五，说明硬解析泛滥，CPU耗在语法校验、权限检查、计划生成上，而非SQL执行本身 - 若
cursor: pin S wait on X高频出现，常伴随大量短生命周期游标，与PL/SQL批量操作或未关闭的REF CURSOR有关 -
enq: TX - row lock contention虽属等待事件，但若Wait Time占DB Time >1%，需结合DBA_HIST_ACTIVE_SESS_HISTORY确认是否由定时JOB触发的批量更新引发锁争用
这些都不是“前台SQL”，而是后台任务或共享池管理逻辑在暗中吃CPU。
交叉验证OS Statistics里的IOWAIT_TIME和LOAD，排除IO假象
AWR的Operating System Statistics页里，IOWAIT_TIME和LOAD比BUSY_TIME更早暴露真实瓶颈：
-
IOWAIT_TIME飙升（比如从几百跳到上万）+LOAD持续 >NUM_CPUS→ CPU大量时间在等磁盘，此时DB CPU高是结果，不是原因 -
LOAD升高但USER_TIME占比很低（如1200万 / 1293万 ≈ 93%）→ 负载集中在内核态或不可中断睡眠（D状态），要重点查db file sequential read或log file sync -
LOAD显示为0？可能是Oracle解析/proc/loadavg失败（老版本按制表符解析，但Linux 2.6+用空格分隔），建议手动cat /proc/loadavg确认，或查GV$OSSTAT的LOAD字段
定位具体后台任务：查DBA_HIST_SQLSTAT + DBA_SCHEDULER_JOBS
光看Top SQL不够，很多后台任务不走常规SQL路径：
- 查
DBA_HIST_SQLSTAT中sql_text含/*+ NO_PARALLEL */或DBMS_STATS关键字的记录，它们常对应统计信息自动收集JOB - 运行
SELECT job_name, state, last_start_date, next_run_date FROM dba_scheduler_jobs WHERE state = 'RUNNING' OR last_start_date > SYSDATE - 1/24，确认是否有物化视图刷新、自定义清理JOB正在执行 - 对
sql_id为0000000000000000或0的记录，它们代表非SQL后台活动（如LGWR写日志、CKPT刷检查点），需结合V$SYSMETRIC中CPU Usage Per Sec趋势比对
真正难缠的不是某条慢SQL，而是那些每小时固定跑一次、每次吃掉5秒CPU、AWR却只记到1秒的JOB——它不在Top SQL里，但能把CPU拉成锯齿波。
