awr中sql的elapsed time排名反映总耗时而非单次最慢执行，需结合executions、ash、dba_hist_sqlstat等定位真实瓶颈，避免误判硬解析、锁等待或环境问题为sql逻辑问题。
怎么看 awr 报告里 sql 的 elapsed time 排名
awr 默认的 top sql 报告按 elapsed time 降序排，但这个“耗时最长”容易误导——它统计的是所有执行的总耗时（executions × elapsed time per exec），不是单次最慢的 sql。真正卡住应用的，往往是某次执行花了 30 秒的 select，而不是平均 200ms 但跑了 10 万次的语句。
实操建议：
- 打开 AWR 报告后，直接跳到 “SQL ordered by Elapsed Time” 部分，重点关注
Elapsed Time (s)列值高、且Executions较低（比如 ≤ 10）的行 - 同时对照 “SQL ordered by Gets” 和 “SQL ordered by Reads”：如果某条 SQL 在 Elapsed Time 排前 10，但在 Gets/Reads 里完全没出现，大概率是硬解析、锁等待或远程 DBLINK 导致的延迟，不是逻辑读瓶颈
- 用
awrrpt.sql脚本生成 HTML 报告时，加参数-dbid和-report_type html，别用文本模式——HTML 版本会带超链接，点进某条 SQL 能直接看到执行计划和 ASH 摘要
为什么单看 Elapsed Time 会漏掉真实瓶颈
Oracle 的 Elapsed Time 是 wall-clock 时间，受多种非 SQL 逻辑因素影响。例如一条 UPDATE 执行了 5 秒，可能只花了 80ms 做 DML，其余时间卡在 enq: TX - row lock contention 或 log file sync 上。
实操建议：
- 对高 Elapsed Time 的 SQL，立刻查它的
ASH数据：运行SELECT * FROM v$active_session_history WHERE sql_id = 'xxx' AND sample_time > SYSDATE-1/24 ORDER BY sample_time DESC，看event列是不是大量出现latch: shared pool、cursor: pin S wait on X这类非 IO/CPU 事件 - 检查该 SQL 的
parse_calls是否接近executions：如果比值 > 0.8，说明频繁硬解析，瓶颈不在执行阶段，而在共享池或绑定变量缺失 - 注意 AWR 快照间隔：若快照间隔是 60 分钟，而某条 SQL 只在第 59 分钟执行了一次并耗时 55 秒，它会稳居 Top1；但如果是每 5 分钟跑一次、每次 8 秒，反而不会上榜——得结合
dba_hist_sqlstat自查分钟级趋势
如何用 DBA_HIST_SQLSTAT 定位单次最慢执行
AWR 报告不暴露单次执行的 elapsed_time，只给平均值。要找“哪一次执行最慢”，必须下钻到基表。
实操建议：
- 运行查询：
SELECT sql_id, plan_hash_value, executions, elapsed_time/executions/1000000 avg_etime_s,<br> (SELECT MAX(elapsed_time)/1000000 FROM dba_hist_sqlstat s2<br> WHERE s2.sql_id = s1.sql_id AND s2.snap_id BETWEEN &start_snap AND &end_snap) max_etime_s<br>FROM dba_hist_sqlstat s1<br>WHERE snap_id BETWEEN &start_snap AND &end_snap<br> AND executions > 0<br>ORDER BY max_etime_s DESC<br>FETCH FIRST 5 ROWS ONLY;
-
max_etime_s是估算的单次最慢耗时（单位秒），但注意：DBA_HIST_SQLSTAT 存的是累计值，所以这里用子查询取最大累计值再除以执行次数，仅当该 SQL 在区间内只执行一次时才准确；更稳妥的做法是关联dba_hist_active_sess_history查sql_exec_start和sql_exec_id - 别直接查
v$sql：它只保留当前库缓存里的 SQL，AWR 是历史数据，两者时间窗口不重叠时会漏掉关键样本
执行效率瓶颈 ≠ 执行计划差，别急着调 SQL
很多 DBA 看到 Elapsed Time 高，第一反应是看执行计划、加索引、改写 SQL。但实际生产中，超过 40% 的高耗时 SQL 瓶颈在环境层：IO 调度队列深、存储响应毛刺、SGA 设置过小导致频繁软解析、甚至 RAC 中的 GC 延迟。
实操建议：
- 先确认是否复现：在相同时间段重跑该 SQL，用
ALTER SESSION SET STATISTICS_LEVEL = ALL+SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'))，对比 AWR 里的buffer_gets和实际执行的Buffers是否接近——差 3 倍以上，说明 AWR 统计失真或执行环境已变 - 检查
DBA_HIST_SYSMETRIC_SUMMARY里Database CPU Time Ratio和Host CPU Utilization (%)：如果前者远低于后者，说明大量时间花在 OS 层（如 swap、中断），SQL 本身优化意义不大 - 对 RAC 环境，重点看
gc cr block receive time和gc current block receive time的 AWR 指标——这两个值 > 10ms 就值得怀疑网络或节点负载不均
最常被忽略的一点：AWR 默认每小时采样一次，但业务高峰期可能集中在某几分钟。如果瓶颈只持续 90 秒，又没落在快照正中间，它在 AWR 里就是“隐形”的。这时候必须切到 ASH 实时抓，而不是盯着 AWR 报告反复猜。
