AWR报告应聚焦DB Time、Top 5 Timed Foreground Events和SQL by Elapsed Time定位瓶颈，避免误判高Buffer Gets SQL；需结合ASH、SQLSTAT等视图快速诊断，并合理设置快照频率与保留策略。
AWR报告怎么看才抓得住性能瓶颈
awr本身不直接“优化”，它只忠实记录数据库在采样周期内的资源消耗和等待事件。真正有用的是从db time、top 5 timed foreground events、sql ordered by elapsed time这三块快速定位根因。
常见错误是盯着Buffer Gets排序的SQL看——高逻辑读不等于慢，可能只是被频繁执行的小查询；更应优先关注Elapsed Time和Executions比值异常高的语句（单次执行耗时长），或Wait Class里长期占主导的Application、Cluster、IO类等待。
- 用
awrrpt.sql生成HTML报告时，务必指定两个快照ID（而非默认最近一小时），避免跨业务高峰/低谷导致失真 - 若
DB Time远高于Elapsed Real Time（比如DB Time=1200s，实际过去时间仅300s），说明CPU严重争用，需查OS CPU Usage小节和Top SQL中CPU Time占比 - 注意AWR默认保留8天，如需分析更长时间趋势，得提前调大
retention：执行EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(retention => 43200)（单位分钟）
哪些AWR视图能直接查出问题SQL
不是所有性能问题都等得及跑完整报告。日常巡检或应急时，直接查底层视图更快：
-
DBA_HIST_SQLSTAT结合DBA_HIST_SQLTEXT可按ELAPSED_TIME_DELTA倒序找出历史最慢SQL，注意加SNAP_ID范围过滤，否则全库扫描极慢 -
DBA_HIST_ACTIVE_SESS_HISTORY（ASH）是AWR的“秒级快照”，查EVENT字段能定位瞬时锁等待，比如enq: TX - row lock contention，配合SESSION_ID和SQL_ID立刻追溯 - 别漏掉
DBA_HIST_SYSMETRIC_SUMMARY，其中METRIC_NAME = 'Average Synchronous Single-Block Read Latency'超过20ms基本说明存储I/O有问题，和SQL优化无关
自定义AWR快照频率和采样粒度怎么设才合理
默认每60分钟一次快照，对OLTP系统明显太粗。但盲目调密（比如改到5分钟）会导致AWR表空间暴涨、报告生成变慢，且掩盖不了真正的慢SQL——因为慢SQL往往跨多个快照。
- 核心业务库建议：高峰时段（如9:00–18:00）设为30分钟，非高峰设为60–120分钟；用
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT手动补采快照只在故障复现窗口内用，别常态化 - 调整前先确认
SYSAUX表空间余量，AWR数据占满会直接导致DBA_HIST_*视图不可查；可用SELECT occupant_name, space_usage_kbytes FROM v$sysaux_occupants WHERE occupant_name = 'AWR'实时查看 - 如果发现
DBA_HIST_SEG_STAT数据量过大（尤其LOGICAL_READS_DELTA暴增），说明某些大表被频繁全扫，这时快照频率再高也无济于事，得先做SQL层优化或加索引
为什么AWR里找不到刚发生的SQL性能抖动
AWR快照是“事后汇总”，不是实时监控。一个SQL执行完立刻结束，如果它没跨过快照边界（比如9:59:50执行，10:00:00快照生成），那它只会出现在ASH里，不会进AWR的SQL统计部分。
- 验证方法：查
DBA_HIST_ACTIVE_SESS_HISTORY中SQL_ID对应记录，若SNAP_ID为空或为0，说明该会话未被捕获进AWR快照，纯ASH数据 - 临时应急：启用
SQL Monitoring（/*+ MONITOR */提示或设置CONTROL_MANAGEMENT_PACK_ACCESS = DIAGNOSTIC+TUNING），它能捕获运行超5秒的SQL详细执行计划和实时统计 - 真正要捕获“刚刚发生”的抖动，得靠
ASH轮询（如每10秒查一次V$ACTIVE_SESSION_HISTORY），而不是依赖AWR报告
AWR的价值不在实时性，而在提供可比对的历史基线。很多团队花大力气调优一条SQL，却忘了比对它在上周同时间段的Elapsed Time是否本就波动剧烈——那可能根本不是SQL问题，而是应用流量突增或上游依赖延迟导致的连锁反应。
