aas超过2需关注，持续>5（oltp）或>10（报表）才表明严重排队；db time远大于db cpu说明等待占主导；rac下须分实例分析；top 5等待事件需结合wait time、waits、avg wait三列交叉判断；sql优化重点看elapsed vs cpu time及disk reads per exec。
先看 db time 和 aas，别急着翻等待事件
db time 高 ≠ 系统出问题，但 aas（average active sessions）超过 2 就得立刻盯住。计算方式是 db time / elapsed time，awr 报告开头的 report summary 里直接有这两个值。比如快照间隔 60 分钟，db time 是 180 分钟，aas 就是 3 —— 意味着平均同时有 3 个会话在争抢资源。
真正要警惕的是 AAS 持续 >5（OLTP 场景）或 >10（报表类），这时才说明排队已成常态。如果 AAS 很低（比如 0.3），但用户喊慢，大概率是单条 SQL 延迟高、网络抖动或应用层超时设置过短，不是数据库全局瓶颈。
- 别被
DB CPU占比误导：它只是前台会话消耗 CPU 时间的总和，不是操作系统 CPU 使用率 -
DB Time远大于DB CPU（比如 DB Time=1200s，DB CPU=200s），说明 83% 的时间花在等待上，必须往下查等待事件 - RAC 环境下，
DB Time必须按实例拆分看 —— 用awrrpti.sql生成 per-instance 报告，否则节点负载不均会被掩盖
Top 5 Timed Foreground Events 要交叉看三列：Wait Time、Waits、Avg Wait
只看“占比”会误判。比如 log file sync 占比只有 3%，但一小时发生 420 万次，平均等待 712 µs，实际每秒提交超 1160 次 —— 这是事务粒度太细，不是磁盘慢。
再比如 gc buffer busy acquire 占比 1.2%，但平均等待 18 ms，且只由 7 个活跃会话触发，基本锁定 RAC 热点块争用，跟整体负载无关。
- 跳过所有以
SQL*Net message from client开头的空闲事件，除非它冲进 Top 3 且Avg Wait异常高（>100ms） -
DB CPU排第一时，立刻翻到SQL ordered by CPU Time，确认是否某条 SQL 贡献了 60% 以上；若不是，再查parse count (hard)是否远高于parse count (total)的 10% -
enq: TX - row lock contention可能只排第 9，但只要Wait Time占 DB Time >1%，就得手动搜enq:并结合DBA_HIST_ACTIVE_SESS_HISTORY下钻
Load Profile 不是起点，是验证工具
看到 db file sequential read 占比突增，别急着调索引。先看 Load Profile 里的 Physical Reads 和 Logical Reads 比值：
- 比值突然升高 → 真实物理 IO 增多，再查
Tablespace IO Stats中Avg Rd(ms)是否持续 >20ms - 比值稳定甚至下降，但
Physical Reads绝对值飙升 → Buffer Cache 被挤出，或某张小表被频繁全扫（比如缺失索引） -
Redo Size每秒超 10MB，结合User Calls/sec和Transactions/sec判断：是业务高峰，还是循环里逐行COMMIT导致 LGWR 压力过大
注意：Logical Reads/sec 高本身不危险，它反映的是工作量密度，不是卡点。一个健康 OLTP 系统本就该有高逻辑读。
SQL Statistics 里真正要抓的是 “Disk Reads Per Exec” 和 “Elapsed Time vs CPU Time”
SQL ordered by Elapsed Time 是必看页，但重点不在排序靠前的那几条，而在它们的两组对比：
- 如果
Elapsed Time远大于CPU Time（比如 5s vs 0.2s），说明卡在 I/O 或锁上，查执行计划里是否有全表扫描、是否走了direct path read - 如果两者接近（比如 4.8s vs 4.5s），才是真·计算密集型，该看是否用了低效函数（如
TO_CHAR(date_col)在 WHERE）、是否排序落盘（查sorts (memory)/sorts (disk)比值） -
Disk Reads Per Exec超 10000 的 SQL 必须处理；Gets Per Exec高但Disk Reads Per Exec低，说明缓存效率好，不用优先优化
特别注意：EXECUTIONS = 0 但 CPU_TIME_SEC 非零的 SQL，是统计未刷新的伪高负载项，直接过滤掉。
