AWR报告需对比正常与异常时段两份报告交叉验证才能准确定位瓶颈；Top 5 Timed Events需结合占比、平均等待时间及并发基数综合判断；SQL应优先关注Gets高、解析/执行比异常及全表扫描等执行计划问题；Buffer Hit Ratio等效率指标低于阈值即需干预。
awr报告不是“看一遍就能定位瓶颈”的工具，它是一份需要交叉验证的诊断快照集——单看一份报告容易误判，必须对比正常时段与异常时段的两份报告，才能识别真实劣化点。
怎么看 Top 5 Timed Events 才不被误导
这个模块是AWR里最先该盯住的地方，但它只告诉你“在等什么”，不直接说“为什么等”。比如 db file sequential read 占比高，可能是索引缺失，也可能是统计信息过期导致优化器选错执行路径，甚至只是某张小表被高频随机访问。
- 先看占比：若
db file scattered read+db file sequential read合计 > 70%，I/O 很可能已是瓶颈；若log file sync单独超 15%，别急着换磁盘，先查应用是否每条 insert 都 commit - 再看平均等待时间（Av Rd(ms)）：> 20ms 就要警惕，去
Tablespace IO Stats里查具体数据文件的读延迟，而不是笼统说“磁盘慢” - 注意并发基数：1个会话等了 10 秒，和 100 个会话各等 1 秒，对用户体验的影响完全不同，得结合
Snapshot Information里的Sessions数一起看
SQL Statistics 里哪些指标真值得动刀
别只盯着“Elapsed Time Per Exec”最高的那条 SQL。真正拖垮系统的，往往是执行频次高、每次消耗中等但累积量大的语句。
- 优先关注
SQL ordered by Gets：单次buffer gets per exec超过 50000 的 SQL，大概率没走索引或谓词失效（比如where to_char(create_time, 'yyyymmdd') = '20260409'） - 检查
Parse Calls/Executions比值：如果接近 1:1，说明几乎每次都在硬解析，绑定变量没用好，共享池压力会持续升高 - 用
dbms_xplan.display_awr查执行计划时，重点确认是否出现TABLE ACCESS FULL或NESTED LOOPS驱动大表——后者在并发高时极易引发latch: cache buffers chains
Instance Efficiency Percentages 哪些值一掉就得动手
这些百分比不是“参考值”，而是 Oracle 内部资源调度健康度的硬指标，低于阈值往往意味着底层机制已开始降级运行。
-
Buffer Hit Ratiodb_cache_size 就能解决，先确认是不是热点块（latch: cache buffers chains是否同步升高），否则加内存只是把争用从磁盘搬到 buffer cache -
Parse To Execute Ratiocursor_sharing 参数是否匹配版本（12c+ 推荐force，11g 及以下慎用similar） -
Redo Nowait %log file sync 等待必然飙升，应优先检查存储响应时间而非盲目加日志组
真正难的不是看懂 AWR 报告里的每一行数字，而是把 Top 5 Timed Events、SQL Statistics 和 Instance Efficiency Percentages 三者串起来——比如看到 db file sequential read 高，就立刻跳转到 SQL ordered by Physical Reads 找对应 SQL，再用 dbms_xplan.display_awr 看它的执行计划里有没有索引扫描，最后回过头核对 Buffer Hit Ratio 是否同步下降。漏掉任一环，都可能把索引问题诊断成内存问题。
