从AWR提取IO延迟需组合DBA_HIST_SYSTEM_EVENT与DBA_HIST_SNAPSHOT，聚焦db file sequential read、db file scattered read、direct path read三类事件的AVERAGE_WAIT（毫秒），并结合等待次数与IOPS综合判断，避免仅看平均值误判；高延迟+高频次时须下钻至DBA_HIST_IOSTAT_FILE定位问题文件；注意ASM/Exadata环境差异及buffer busy waits等非IO干扰项。
如何从AWR中提取关键IO延迟指标
oracle的awr本身不直接暴露“磁盘读取延迟”这个单一数值，而是通过多个关联视图组合计算得出。核心路径是：dba_hist_system_event（等待事件历史）结合dba_hist_snapshot（快照时间），筛选出与物理io强相关的等待事件。
重点关注以下三类事件的平均等待时间（AVERAGE_WAIT字段，单位为毫秒）：
-
db file sequential read：单块读，典型于索引查找、ROWID访问，反映随机IO延迟 -
db file scattered read：多块读，典型于全表扫描，反映顺序IO延迟 -
direct path read：直接路径读（如并行查询、大表排序），绕过Buffer Cache，更贴近底层存储响应
注意：log file sync和log file parallel write属于日志写入路径，不属于“数据文件读取”，不应混入磁盘读延迟评估。
用SQL快速定位高延迟时段和文件
不要依赖AWR报告图形界面——它默认只展示Top 5等待，且平均值可能掩盖尖峰。直接查视图更可控：
SELECT
s.snap_id,
TO_CHAR(s.begin_interval_time, 'YYYY-MM-DD HH24:MI') snap_time,
e.event_name,
ROUND(e.time_waited_micro/1000/e.total_waits, 2) avg_ms,
e.total_waits
FROM dba_hist_system_event e
JOIN dba_hist_snapshot s ON e.snap_id = s.snap_id AND e.dbid = s.dbid
WHERE e.event_name IN ('db file sequential read', 'db file scattered read', 'direct path read')
AND e.total_waits > 0
AND s.begin_interval_time >= SYSDATE - 7
ORDER BY s.snap_id DESC, avg_ms DESC
FETCH FIRST 20 ROWS ONLY;
这个查询能暴露两个关键事实：
- 某次快照中
db file sequential read平均达 25ms，而平时是 8ms → 存在瞬时IO抖动 -
direct path read在夜间批处理期间飙升至 40ms → 可能与备份、归档或存储资源争用有关
为什么只看avg_ms会误判？必须结合IOPS和等待次数
平均延迟高 ≠ 磁盘慢。例如：
- 如果
db file sequential readavg_ms 是 30ms，但total_waits只有 5 次/分钟 → 实际业务影响极小 - 如果 avg_ms 是 12ms，但
total_waits高达 5000 次/秒 → 即使延迟尚可，IO吞吐已成瓶颈
真正要警惕的是“高延迟 + 高频次”的组合。此时应进一步下钻到文件级别：
SELECT f.file_name, e.event_name, ROUND(SUM(e.time_waited_micro)/1000/SUM(e.total_waits), 2) avg_ms, SUM(e.total_waits) waits_total FROM dba_hist_iostat_file e JOIN dba_data_files f ON e.file_no = f.file_id WHERE e.snap_id IN (SELECT snap_id FROM dba_hist_snapshot WHERE begin_interval_time >= SYSDATE-1) GROUP BY f.file_name, e.event_name HAVING SUM(e.total_waits) > 1000 ORDER BY avg_ms DESC;
DBA_HIST_IOSTAT_FILE 提供按文件统计的IO等待，比系统级事件更准——比如某个临时表空间文件持续高延迟，很可能是TEMP表空间争用，而非存储故障。
容易被忽略的干扰项：ASM、Exadata、以及buffer busy waits
如果你用的是ASM，db file sequential read的延迟包含ASM striping和rebalance开销，不能直接对标裸设备；Exadata环境下，大部分cell smart table scan会替代direct path read，此时要看cell single block physical read而非原始事件。
更隐蔽的问题是：buffer busy waits常被误认为IO问题。它本质是Buffer Cache内部争用（如热块），不是磁盘响应慢。若该等待突增但db file sequential read avg_ms正常，优先检查热点对象、PCTFREE设置或是否缺少索引导致重复访问同一块。
真实IO延迟诊断，永远要分清“是磁盘慢了”，还是“Oracle在错误地频繁访问磁盘”。前者看存储层latency（如iostat %util、await），后者才靠AWR等数据库内部分析。
