top 5 timed events是awr报告中记录前台会话耗时最多的5类等待事件的聚合统计，反映i/o、内存或锁等资源争用瓶颈；它不是最慢sql列表或错误日志汇总，需结合%total time、avg wait(ms)、waits三列交叉分析，并通过sql执行计划、v$视图等验证根因。
Top 5 Timed Events 是什么，不是什么
它不是“最慢的SQL列表”，也不是“错误日志汇总”。它是数据库在采样窗口内，前台会话（非后台进程）花费时间最多的5类等待事件的聚合统计。每一行代表一种资源争用类型，db file sequential read、log file sync 这些名字背后对应着真实的I/O、内存或锁机制瓶颈。DB Time远大于Elapsed Time时，这个表尤其关键——说明大量时间耗在等待上，而非CPU计算。
看懂三列：%Total Time、Avg wait(ms)、Waits
别只盯着百分比。三个数字要交叉看：
-
%Total Time高（比如 >30%），说明该事件是主要瓶颈，但不等于必须立刻优化；得结合场景判断是否合理。例如报表时段出现大量db file scattered read，可能是计划内全表扫描，而非问题。 -
Avg wait(ms)偏高（如log file sync> 5ms），往往指向硬件或配置问题：磁盘响应慢、日志文件放在慢盘、LOG_BUFFER太小、或应用层频繁COMMIT。 -
Waits数量巨大（如SQL*Net message from client占比不高但 Waits 超百万），可能只是客户端网络延迟或应用未启用连接池，未必是数据库侧问题。
常见事件的典型归因与验证动作
不能见名就治。每个事件背后有多个可能根因，需快速验证：
-
db file sequential read：优先查关联的Top SQL是否走了索引。用DBMS_XPLAN.DISPLAY_CURSOR看实际执行计划，确认是不是INDEX RANGE SCAN还是FULL TABLE SCAN——后者即使叫“sequential read”，也常因缺失索引导致。 -
log file sync：先查V$SYSSTAT中user commits和user rollbacks每秒次数。若每秒提交超200次，大概率是应用层事务粒度太细，而不是日志写入慢。 -
buffer busy waits：不是“缓存不够”，而是多个会话争抢同一数据块。查V$SEGMENT_STATISTICS找logical reads和buffer busy waits都高的对象，再定位到具体SQL和表的热点块（如主键序列插入热点）。 -
latch: cache buffers chains：通常伴随高逻辑读SQL。用V$LATCH_CHILDREN和V$ACTIVE_SESSION_HISTORY关联，看 latch holder 正在访问哪个对象的哪个 block，再反推是否缺少谓词或存在低效索引。
容易被忽略的上下文陷阱
同一个等待事件，在不同业务时段含义完全不同：
- 交易系统白天出现
enq: TX - row lock contention，大概率是并发更新同一条记录；夜间批处理时段出现，很可能是ETL脚本没加FOR UPDATE SKIP LOCKED或分区设计不合理。 -
direct path read在数据仓库查询中占比高是正常的；但在OLTP接口里出现，就得立刻检查是否SQL意外触发了大结果集排序或临时表溢出。 - 多实例RAC环境，
gc buffer busy类事件必须结合Instance Number和Global Cache Statistics看跨节点传输是否成为瓶颈，不能直接当成单机问题处理。
AWR报告里的 Top Timed Events 是一张快照，不是诊断终点。它告诉你“哪里堵”，但堵因藏在SQL执行路径、应用调用模式和底层资源配置的交界处——跳过这层交叉验证，直接改参数或加索引，大概率白忙活。
