awr报告中db cpu占比高不等于sql密集计算，需重点核查db cpu占db time比例、aas是否超核数、cpu per exec突增的sql，并手动下钻dba_hist_sqlstat和rac实例详情定位根因。
AWR报告里DB CPU占比高，不等于SQL在猛算——真正要盯的是DB CPU占DB Time的比例、AAS是否持续超核数，以及CPU per Exec突增的SQL。
看Time Model Statistics：先验真“CPU高”是不是假象
操作系统top看到oracle进程占90% CPU，不代表数据库真在密集计算。必须进AWR报告的Time Model Statistics页确认：
-
DB CPU占DB Time比例低于40%？那大概率不是执行层问题，而是latch: shared pool或library cache争用，CPU耗在解析等待上 -
DB CPU数值是累计值：比如报告里显示3600秒，意味着该时段平均每秒消耗了300秒CPU时间（25核等效满载），远超物理核数才叫真过载 - 若
Parse CPU to Parse Elapsd %低于20%，或parse count (hard)每小时超500次，说明CPU主要耗在硬解析，不是SQL本身
查SQL ordered by CPU Time：别被“总CPU”带偏，重点看单次消耗
AWR默认按累计CPU排序，但拖垮系统的往往是那些单次就吃掉大量CPU、且高频执行的SQL：
- 跳过
EXECUTIONS = 0但CPU_TIME_SEC > 0的SQL——这类是游标异常终止或统计未刷新的干扰项 - 重点关注
CPU per Exec > 5且Executions per Sec > 0.1的SQL，它们才是稳定输出CPU压力的“定时炸弹” - 同一
sql_id在不同快照里CPU per Exec突增3倍以上？立刻用DBMS_XPLAN.DISPLAY_AWR('<sql_id>')</sql_id>查执行计划，确认是否出现FULL TABLE SCAN或NESTED LOOPS放大
盯住plan_hash_value：执行计划突变更危险，但AWR不直接标出
AWR报告只列Top 30 SQL，且不标记plan_hash_value是否变化。很多CPU飙升源于计划从12345变成67890，但报告里根本看不出：
- 手动查
DBA_HIST_SQLSTAT：SELECT sql_id, plan_hash_value, executions, ROUND(elapsed_time / NULLIF(executions, 0), 2) elap_per_exec FROM dba_hist_sqlstat WHERE sql_id = 'xxx' ORDER BY snap_id - 如果
plan_hash_value变了但elap_per_exec同步飙升，基本锁定执行路径劣化 - RAC环境下还要进SQL子页面点开「Instance Detail」，确认该SQL是否在某节点集中执行——QC总在节点1而PX Server跑在节点2，但节点1 CPU飙升，问题可能出在QC端串行逻辑
RAC环境必须分实例看：汇总报告会掩盖节点级失衡
默认AWR报告是全局汇总的，RAC下必须用awrrpti.sql生成per-instance报告，否则节点负载不均会被掩盖：
- 查各节点物理核数：
SELECT value FROM gv$parameter WHERE name = 'cpu_count' - 算真实饱和度：不能只看
DB CPU绝对值，得算DB CPU / CPU Count比率，才反映实际压力 - 查某SQL在各节点分布：
SELECT inst_id, executions, cpu_time/1000000 cpu_sec, buffer_gets FROM gv$sql WHERE sql_id = 'abc123xyz' - 留意
LOAD_PROFILE里的Logons per Second，若某节点登录数突增，可能是连接池没启用负载均衡（如TNS alias未配LOAD_BALANCE=on）
最易被忽略的是：plan_hash_value变化和RAC节点间执行分布，这两处不手动下钻DBA_HIST_SQLSTAT或点开「Instance Detail」，光看AWR首页永远发现不了。
