AWR报告需交叉分析DB Time/AAS、Top 5等待事件三列（Wait Time/Waits/Avg Wait）、SQL Statistics（Elapsed vs CPU/Physical Reads Per Exec）才能准确定位瓶颈。
AWR报告本身不直接告诉你“瓶颈在哪”，它只提供时间窗口内的聚合统计；真正能定位瓶颈的，是你会不会交叉看三组数据：DB Time与AAS、Top 5等待事件的Wait Time/Avg Wait/Waits、SQL Statistics里的Elapsed vs CPU Time和Physical Reads Per Exec。
先盯DB Time和AAS，别急着翻等待事件
DB Time高≠系统出问题，但AAS（Average Active Sessions）超过2就得立刻盯住。计算方式就是DB Time ÷ Elapsed Time，报告开头的Report Summary里直接有这两个值。
- 快照间隔60分钟，
DB Time是180分钟 →AAS= 3，意味着平均同时有3个会话在争抢资源 -
AAS持续 >5（OLTP）或 >10（报表类）才说明排队已成常态 -
AAS很低（比如0.3）但用户喊慢，大概率是单条SQL延迟高、网络抖动或应用层超时设置过短，不是数据库全局瓶颈
看Top 5 Timed Foreground Events要交叉比三列
只看“占比”会误判。必须同时看Wait Time（总等待时间）、Waits（发生次数）、Avg Wait（平均等待毫秒数）。
-
log file sync占比只有3%，但一小时发生420万次、Avg Wait712 µs → 实际每秒提交超1160次，是事务粒度太细，不是磁盘慢 -
gc buffer busy acquire占比1.2%，但Avg Wait18 ms且只由7个活跃会话触发 → 基本锁定RAC热点块争用，跟整体负载无关 - 跳过所有以
SQL*Net message from client开头的空闲事件，除非它冲进Top 3且Avg Wait异常高（>100ms）
查SQL ordered by Elapsed Time时绕开伪高负载
别只盯着Elapsed Time最高的几条。容易踩的坑包括：
-
EXECUTIONS为0但CPU_TIME_SEC非零的SQL → 常因统计未刷新导致，是“伪高负载”，别动它 - 单次
Elapsed Time远大于CPU Time→ 卡在I/O或锁上，该查执行计划或阻塞链 -
Buffer Gets per Exec> 10万，但Physical Reads per Exec很低 → 可能是缓存失效或latch争用，不是SQL本身问题 - 优先关注
SQL ordered by Gets里Buffer Gets per Exec> 50000 的语句，大概率没走索引或谓词失效（比如where to_char(create_time, 'yyyymmdd') = '20260409'）
RAC环境必须分实例看DB Time和等待事件
用@?/rdbms/admin/awrrpti.sql生成per-instance报告，否则节点负载不均会被掩盖。比如一个实例AAS是8，另一个是0.5，合并报告里AAS可能只显示4.3，完全看不出失衡。
-
gc cr block lost平均等待 >1秒 → 必须结合GV$CLUSTER_INTERCONNECT验证私网延迟，不能只调SQL - 某实例
enq: TX - row lock contention的Wait Time占该实例DB Time>1% → 立刻搜enq:并下钻DBA_HIST_ACTIVE_SESS_HISTORY查具体会话和对象
最常被忽略的是：Load Profile不是起点，而是验证工具；db file sequential read占比突增时，先看Logical Reads和Physical Reads比值是否同步飙升——比值稳定但绝对值涨，说明Buffer Cache被刷，不是磁盘问题。
