awr报告中top 5 timed events按总等待时间降序排列，需通过前缀识别瓶颈类型：db file→i/o问题，enq:→并发冲突，latch/mutex→内存争用，log file→redo写入瓶颈，user i/o异常→大表扫描或pga溢出；须结合aas、时段对比及ash下钻精准定位根因。
看top 5 timed events里等待事件的类型前缀
awr报告中top 5 timed events不是按字母排序的列表，而是按“总等待时间”降序排列的真实瓶颈线索。关键不在事件名本身，而在其命名规则隐含的类别归属——oracle用固定前缀标识等待性质，直接决定排查路径。
-
db file开头（如db file sequential read、db file scattered read）→ I/O子系统问题：先查Tablespace IO Stats里的Avg Wait(ms)，超20ms说明存储响应慢；再看Physical Reads是否异常高，区分是真I/O压力还是缓存不足 -
enq:开头（如enq: TX - row lock contention、enq: TM - contention）→ 应用并发冲突：立刻跳转Segments by Row Lock Waits定位具体表，再结合SQL ordered by Gets找高频DML语句，这类问题90%出在应用逻辑或缺失索引 -
latch或mutex开头（如latch: cache buffers chains）→ 内存争用：说明热点块或共享池配置不当，需检查Instance Efficiency Percentages中的Buffer Hit %和Library Hit %，低于95%就值得深挖 -
log file开头（如log file sync、log file parallel write）→ Redo写入瓶颈：对照Load Profile里的Redo Size Per Second，若该值突增且log file sync排前三，大概率是LGWR写磁盘慢或归档跟不上
忽略空闲类等待事件，但别漏掉伪装成“正常”的User I/O
AWR默认把SQL*Net message from client、PL/SQL lock timer等标记为Idle Event，它们出现在Top 5里通常意味着前台应用层有问题——比如应用没发完SQL就断开连接，或者中间件连接池配置错误。但更危险的是那些被归类为User I/O却长期高占比的事件，例如direct path read在OLTP系统里占DB Time 15%以上，基本可以判定有未走索引的大表扫描正在发生。
- 检查
SQL ordered by Physical Reads，单条SQL物理读超过10万次就是典型信号 - 对比问题时段与正常时段的
Logical Reads / Physical Reads比值，下降超过30%说明Buffer Cache效率骤降，可能因SGA被其他进程挤压或大查询刷出了热块 - 注意
direct path read temp：这代表大量排序或哈希操作溢出到临时表空间，需查PGA Aggr Summary确认PGA Memory MBytes是否持续接近pga_aggregate_target
等待事件的“并发放大效应”必须结合AAS判断
单独看time_waited容易误判。一个db file sequential read平均等待5ms，如果只发生在1个会话上，影响微乎其微；但如果AAS=8且该事件占DB Time 40%，说明8个会话在同时排队等同一类I/O，本质是资源供给能力不足。
- 先算
Average Active Sessions (AAS) = DB Time / Elapsed Time，在报告开头的Report Summary里直接有数值 - 再看该等待事件的
Total Waits除以Elapsed Time，得到每秒发生次数。若>100次/秒且AAS>3，基本可锁定为系统级瓶颈，而非个别SQL问题 - 特别警惕
cursor: pin S wait on X这类事件：它常伴随硬解析飙升，但根源可能是Shared Pool过小或cursor_sharing参数设置不当，不能只盯着SQL文本优化
当多个等待事件并存时，优先处理有因果链的那个
现实中常出现enq: TX和db file sequential read同时上榜。这时不能平行处理，要识别主次——前者是果，后者可能是因。比如某UPDATE语句因缺少索引导致全表扫描，锁住大量行，后续会话被迫等待TX锁，此时解决索引问题就能连带消除锁等待。
- 查
SQL ordered by CPU Time和SQL ordered by Gets交集：同一SQL同时出现在两个Top列表，90%是根因 - 翻到
SQL ordered by Elapsed Time，看该SQL的%CPU+%IO之和是否远低于100%：若只有30%，剩下70%大概率消耗在enq:或latch:类等待上，说明它正被其他资源争用阻塞 - RAC环境要额外看
Global Cache Transfer相关等待（如gc cr block busy），这类事件往往暴露节点间心跳延迟或网络丢包，和单实例排查逻辑完全不同
实际动手时，最易被忽略的是等待事件背后的时间粒度错位：AWR快照间隔默认1小时，但业务故障可能只持续3分钟。如果只看整点快照，很可能把峰值等待摊薄成“看起来还行”的平均值。务必用awrrpti.sql生成10分钟粒度的短区间报告，再叠加ASH视图做分钟级下钻——这才是定位瞬时瓶颈的真正起点。
