Top 5 Timed Events 是性能诊断起点，反映数据库时间消耗分布；需结合等待次数、平均等待时间、业务上下文及底层指标（如IO延迟、RAC互连状态）综合判断真瓶颈，而非孤立解读事件名称。
Top 5 Timed Events 是性能诊断的起点，不是终点
awr报告里最该先看的，就是 top 5 timed events ——它不是“发生了什么”，而是“数据库时间被谁吃掉了最多”。占比高 ≠ 问题大，但它是唯一能快速过滤噪音的入口。
常见错误是盯着“db file sequential read”就去调索引，结果发现是归档日志写满导致LGWR卡住，连带拖慢所有单块读；或者看到“CPU time”排第一，却没往下翻到 SQL ordered by CPU Time，直接去加CPU，而实际是一条没走索引的报表SQL在刷全表。
- 必须结合等待次数（Waits）和平均等待时间（Avg Wait ms）一起看：比如
log file sync平均 896 µs 看似很短，但若 1 小时内发生 140 万次，说明提交太密，不是IO慢，是应用层事务粒度太细 - 注意并发基数：10个用户触发 50 万次
gc buffer busy acquire，比 1000 个用户触发 50 万次严重得多——前者大概率是热点块，后者可能是正常RAC流量 - 跳过空闲事件：
SQL*Net message from client属于空闲等待，只要不占 Top 5，基本不用管；真要查网络问题，得看SQL*Net more data to client或超时类事件
IO类等待怎么区分“真瓶颈”和“假警报”
db file scattered read 和 db file sequential read 都是物理读，但背后原因天差地别。不能一见“read”就查磁盘，得先问：这读是必要的吗？
比如 OLTP 系统里 db file scattered read 占 Top 2，十有八九是某张小表被频繁全扫——可能因为缺失索引，也可能因为优化器觉得走索引更贵（optimizer_index_cost_adj 设太高），甚至只是开发写了 SELECT * 却忘了加 WHERE。
- 查是否真IO慢：去报告末尾的
Tablespace IO Stats看对应表空间的Avg Rd(ms)，持续 >20ms 才算磁盘响应慢；如果只有 3ms，那问题在SQL逻辑，不在存储 - 查是不是被逼的：用
v$session_longops找出正在跑的长操作，看是不是某条SQL在做全表扫描；再用DBA_HIST_SQLSTAT对比历史执行计划，确认是不是最近才变慢 - 别忽略
direct path read：它不走Buffer Cache，常出现在排序、Hash Join、并行查询中。如果它突然飙升，优先查PGA_AGGREGATE_TARGET是否够用，而不是急着调SGA
RAC环境下的等待事件要绑定互连和实例状态看
RAC不是“多台Oracle叠在一起”，GC（Global Cache）相关的等待事件，本质是节点间协调成本。单独看数字毫无意义，必须和集群健康度交叉验证。
比如 gc cr block lost 平均等待 1.15 秒，表面是块丢了，但真实原因可能是私网丢包、心跳超时、或某个实例已hang住但还没被驱逐——此时只调参数没用，得先登录各节点查 crsctl check crs 和 oifcfg getif。
-
gc current grant busy次数高 +gc buffer busy acquire时间长 → 往往是同一数据块被多个实例高频修改，典型如序列号表、计数器字段；解决方向是拆分热点（如用hash分区）、改用序列缓存，而非加buffer cache -
gc cr multi block mixed出现多但平均时间短（如 4.54ms）→ 更可能是CR请求模式变化（比如新上线一个报表用了大量并行），先确认业务变更，再决定是否调_gc_read_mostly_locking - 所有GC类等待都高于 0.1% 时，必须同步检查
GV$CLUSTER_INTERCONNECTS的吞吐和延迟，以及netstat -s | grep "retrans"看TCP重传率
log file sync 高了，别只盯着磁盘IO
log file sync 等待高，90%的人第一反应是“把redo log放SSD上”，但真正根因常在别处：LGWR写得慢，未必是磁盘慢，可能是它根本没被及时唤醒，或者被其他进程堵住了。
比如 _log_io_size 默认 1MB，如果业务每秒只产生 200KB redo，LGWR 3 秒才刷一次，commit 就得等满 3 秒；又比如 RAC 私网延迟高，LGWR 在等其他节点的确认，也会拖长单次 sync 时间。
- 先看等待次数：如果每秒 commit 超过 500 次，即使磁盘再快也扛不住——这是应用层问题，得推动业务方合并事务或用批量提交
- 查LGWR状态：在
ASH里搜event = 'log file sync'的会话，看它们的blocking_session是不是指向 LGWR；再查 LGWR 自己在等什么（常是log file parallel write或gc cr block busy） - 参数级干预要谨慎：
commit_logging= BATCH可降低 sync 频次，但牺牲持久性；commit_wait= NOWAIT跳过等待，但应用需自行处理可能丢失的提交——这些不是诊断手段，是兜底方案
真正难的不是识别哪个等待事件高，而是判断这个高，是系统在“喊疼”，还是它本来就这样工作。AWR 报告不会告诉你答案，它只负责把时间账本摊开给你看——剩下的，得你带着业务上下文去对账。
