AWR报告是性能问题发生后必须第一时间打开的诊断主界面，自带时间窗口、聚合逻辑和跨层关联；看Top 5 Timed Foreground Events需关注“等待总时间长+平均等待高+频次异常”组合；Load Profile用于交叉验证而非定位卡点；SQL Statistics中应重点排查Elapsed Time per Exec >1秒且Physical Reads Per Exec >10000的SQL；Instance Efficiency Percentages反映内存配置真相，但需结合ASH查瞬时尖峰。
awr报告不是“看看再说”的辅助材料，而是性能问题发生后必须第一时间打开的诊断主界面——它自带时间窗口、聚合逻辑和跨层关联，比实时视图更稳，比手工查v$session更系统。只要你拿到两份间隔合理的快照（比如业务高峰期前后），瓶颈通常在前5页就能锁定。
怎么看Top 5 Timed Foreground Events才不踩坑
这个页面不是让你挑“占比最高”的事件来优化，而是找“等待总时间长 + 平均等待高 + 频次异常”的组合信号。孤立看占比会误判：
-
log file sync占比12%但平均等待896 µs、每小时发生140万次 → 实际是应用层事务太碎，不是磁盘慢 -
gc buffer busy acquire占比仅1.2%，但平均等待15 ms、只由10个活跃会话触发 → 极大概率是RAC热点块争用，不是整体负载问题 -
SQL*Net message from client只要没进Top 5，基本不用管；真要查网络，得盯SQL*Net more data to client或超时类事件
重点关注三类：CPU类（DB CPU排第一≠加CPU，先翻SQL ordered by CPU Time）、Commit类（log file sync高→查提交频率和LGWR路径）、RAC类（gc cr block lost平均>1秒→必须结合GV$CLUSTER_INTERCONNECT验证私网延迟）。
Load Profile不是起点，是交叉验证工具
Load Profile里的Logical reads/sec、Physical reads/sec等指标反映的是“工作量密度”，不是“卡点”。比如Logical reads/sec高，可能是SQL写得差反复扫缓存，也可能是业务峰值本该如此。它不告诉你哪条SQL、哪个资源拖慢了系统。
更危险的是：Load Profile数值正常，Top 5却已暴露严重问题。所以要用它反向验证等待事件：
- 看到
db file sequential read突增 → 查Load Profile中Physical reads与Logical reads比值：比值突然升高→真实物理IO增多；比值稳定甚至下降→Buffer Cache被挤出或小表被频繁全扫 -
direct path read排第一 +Physical reads direct同步飙升 → 基本锁定大表全表扫描
SQL Statistics里最容易忽略的伪高负载SQL
在「SQL ordered by Elapsed Time」里，别只盯着Elapsed Time最高的几条。注意排除这些干扰项：
-
EXECUTIONS为0但CPU_TIME_SEC非零的SQL → 常因统计未刷新导致，是“伪高负载”，别动它 - 单次
Elapsed Time远大于CPU Time→ 卡在I/O或锁上，该查执行计划或阻塞链 - 单次
Buffer Gets per Exec> 10万，但Rows Processed per Exec极少 → 全表扫描缺索引，不是SQL本身慢
真正要抓的是：Elapsed Time per Exec > 1秒、且Physical Reads Per Exec > 10000的SQL，再用DBMS_XPLAN.DISPLAY_AWR下钻执行计划确认是否走了全表扫描。
Instance Efficiency Percentages里藏着内存配置真相
这里的百分比是健康度硬指标，但容易被当成“参考值”跳过：
-
Buffer Nowait % -
Buffer Hit %db_cache_size，先查是不是某张表被高频DML且无索引（比如无主键的大表update） -
Parse CPU to Parse Elapsed %低 +parse count (hard)/parse count (total)> 10% → 硬解析过多，绑定变量使用严重不足，CPU争用根源
最常被忽略的一点：这些百分比背后没有时间维度。如果某指标在快照窗口内是“先崩后稳”，AWR汇总值会掩盖瞬时尖峰。真要抓秒级波动，得配合DBA_HIST_ACTIVE_SESS_HISTORY反查最近1小时活跃会话。
