db file sequential read的avg wait(ms)超基线（ssd>3ms/san>10ms）且time waited占db time>15%即判定i/o滞后；需结合tablespace io stats、dba_hist_filestatxs及log file parallel write交叉验证，避免误判。
看 db file sequential read 的 Avg Wait (ms) 是否超基线
这是最直接的信号。AWR报告里 Top 5 Timed Foreground Events 中，db file sequential read 的 Avg Wait (ms) 若持续 >10 ms（SAN环境）或 >3 ms（SSD环境），且该事件 Time Waited 占 DB Time 超 15%，基本可判定 I/O 子系统响应已滞后。注意：不能只看“占比”，比如它占 8% 但 Avg Wait 达 42 ms，仍属异常——低占比+高延迟=小范围但严重的卡顿。
交叉验证 Tablespace IO Stats 里的单文件延迟
AWR 报告末尾的 “Tablespace IO Stats” 只给汇总值，掩盖热点文件。真正要定位瓶颈设备，得查 DBA_HIST_FILESTATXS 视图，用 readtim / phyrds 算单次读耗时（单位是百分之一秒，不是毫秒）：
SELECT file_name,
ROUND((readtim / NULLIF(phyrds, 0)) * 10, 2) AS avg_read_ms
FROM dba_hist_filestatxs f
JOIN dba_data_files d ON f.file# = d.file#
WHERE snap_id = &snap_id AND phyrds > 0
ORDER BY avg_read_ms DESC
FETCH FIRST 5 ROWS ONLY;
常见坑点：
-
readtim是 centiseconds，漏乘 10 就会把 20 ms 误判成 2 ms - 没加
NULLIF(phyrds, 0)，遇到phyrds = 0会报 ORA-01476 - 未限定
snap_id，默认查全历史，性能差且结果不可比
对比 log file sync 和 log file parallel write 的 Avg Wait
log file sync 高延迟常被当成磁盘慢，其实多数时候是假象。必须同步看 log file parallel write：
- 若
log file syncAvg Wait 是 15 ms，log file parallel write是 14 ms → 存储写入确实慢，优先查 LGWR 所在磁盘 LUN - 若前者是 18 ms，后者仅 0.8 ms → 根本不是磁盘问题，而是应用 COMMIT 太密，或 Data Guard SYNC 模式拖累主库
- 两者差值 >5 ms 且稳定存在 → 应立刻查
v$session_wait中等待log file sync的会话是否集中在少数事务上
别信 AAS 或 DB Time 单一指标，I/O 瓶颈可能静默发生
I/O 压力未必表现为高 AAS。比如一个 OLTP 实例 AAS=1.2，用户却频繁超时，这时要盯 Load Profile 里的 Physical Reads/sec 和 Logical Reads/sec 比值。如果比值从 0.05 突升至 0.3，说明缓存失效加剧，哪怕 DB Time 不高，I/O 请求密度已在击穿存储吞吐极限。更隐蔽的是：iostat -x 显示 %util r_await 持续 >30 ms —— 这说明队列在内核层堆积，AWR 无法捕获瞬时毛刺，必须结合 OS 层实时工具交叉确认。
