AWR性能分析应聚焦Top 5 Timed Foreground Events中“三高组合”（高Wait Time、高Avg Wait、高Physical Reads/Exec）及SQL执行计划突变，结合Load Profile、DB Time/AAS和OS统计交叉验证I/O、内存与CPU瓶颈。
直接看AWR报告里Top 5 Timed Foreground Events和SQL ordered by Elapsed Time两页，90%的性能回退根源就藏在这两处——不是执行计划变差本身，而是它背后暴露的统计信息失真或等待事件突变。
先盯住Top 5 Timed Foreground Events里的“三高组合”
别只看占比最高的等待事件。重点找同时满足以下三个条件的项：
-
Wait Time绝对值高（比如单小时超300秒） -
Avg Wait异常长（如db file sequential read平均 >10ms，正常应 -
Waits频次离谱（例如log file sync每小时发生200万次以上）
例如看到gc buffer busy acquire排第4但Avg Wait达18ms，基本锁定RAC热点块争用；若db file scattered read占比突增且Avg Wait稳定在4ms，大概率是某张表从索引扫描退化为全表扫描，触发大量多块读。
查SQL ordered by Elapsed Time时过滤“伪高耗时”
很多DBA一上来就优化Elapsed Time最高的SQL，结果白忙活。真正要抓的是：
-
Elapsed Time per Exec> 1秒 且Physical Reads Per Exec> 10000 -
CPU Time per Exec远低于Elapsed Time per Exec（说明卡在I/O或锁上，不是SQL逻辑问题） - 同一条SQL在11g AWR快照里
Executions很高、Elapsed Time per Exec很低，升级后变成低执行+高单次耗时
这类SQL往往对应着执行计划突变。立刻用EXPLAIN PLAN FOR重跑，再比对DBMS_XPLAN.DISPLAY输出，确认是否出现TABLE ACCESS FULL替代了原来的INDEX RANGE SCAN。
交叉验证Load Profile和DB Time / AAS
如果DB Time远大于DB CPU（比如DB Time=1500s，DB CPU=220s），说明85%时间花在等待上，必须回头深挖Top 5事件；反之若DB CPU占DB Time 70%以上，才该翻到SQL ordered by CPU Time查真实计算密集型SQL。
同时看Load Profile里的Physical Reads/Logical Reads比值：若该比值从0.05飙升至0.3，说明缓存失效或物理I/O暴增，不是SQL写得差，而是数据访问模式被新执行计划强行改变。
别跳过Operating System Statistics里的CPU与内存信号
哪怕数据库层DB CPU不高，也要扫一眼Operating System Statistics：
-
IOWAIT_TIME显著高于历史均值 → 存储层可能已成瓶颈，AWR里看到的I/O等待只是表象 -
FREE_MEMORY_BYTES持续下降 +SWAP_FREE_BYTES同步减少 → SGA/PGA配置可能不匹配19c默认行为，触发频繁换页 -
NUM_CPUS和LOAD不匹配（如CPU数112但LOAD长期>20）→ 并发控制策略或应用连接池需调整
这些指标不会直接报错，但会放大统计信息不准带来的执行计划偏差——比如本该走索引的SQL因缓存不足被迫反复物理读，最终在AWR里表现为db file sequential read等待堆积。
