awr报告不直接提供iops数值，但可通过db file sequential read的avg wait(ms)是否超基线（ssd>3ms、san>10ms）、load profile中physical reads/sec突增且高延迟、dba_hist_filestatxs中单文件avg_read_ms严重偏斜三类指标交叉反推iops是否已达存储瓶颈。
AWR报告本身不直接提供IOPS数值，但能通过等待事件、物理读写速率和单文件延迟三类指标交叉反推IOPS是否已达存储瓶颈——关键不是看“多少IOPS”，而是看“IOPS是否引发高延迟与排队”。
db file sequential read 的 Avg Wait (ms) 是否持续超基线
这是最敏感的IOPS过载信号。当存储已满负荷，哪怕IOPS没到理论峰值，响应延迟也会跳升：
- SSD环境：Avg Wait > 3 ms 就该警惕；持续 > 5 ms 基本可判定随机IO路径饱和
- SAN环境：阈值放宽至 > 10 ms，但若稳定 > 15 ms，说明磁盘队列深度已溢出
- 注意：不能只盯“占比”。比如该事件占DB Time仅 6%，但 Avg Wait 达 42 ms → 是小范围但严重的卡顿，常对应某张高频访问的小表或索引块
- 查位置：AWR报告第一页的
Top 5 Timed Foreground Events表格中，第三列即Avg Wait (ms)
Load Profile 中 Physical Reads/sec 是否突增且伴随高延迟
AWR的 Load Profile 区域给出每秒物理读写量，它是IOPS的近似代理（尤其对8KB标准块）：
- Physical Reads/sec > 2000 +
db file sequential readAvg Wait > 10 ms → 高概率IOPS打满 - 对比正常时段报告：若该值翻倍而业务QPS未明显增长，说明缓存失效或SQL执行计划劣化放大了I/O压力
- 警惕伪高值：
direct path read也计入 Physical Reads，但它走的是大块直读（如1MB），一次调用可能触发上百次底层OS I/O，实际IOPS远高于报表数字 - 不要单独看 Logical Reads/sec —— 它反映逻辑工作量，与存储负载无关
DBA_HIST_FILESTATXS 中单文件 avg_read_ms 是否严重偏斜
AWR聚合掩盖热点。真正压垮存储的，往往不是平均IOPS，而是某几个LUN或ASM diskgroup的局部饱和：
- 必须运行查询，算出真实毫秒级单次读耗时：
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)遇到无读文件直接报ORA-01476 - 若前5名中某文件
avg_read_ms> 30 ms，而其他文件均
log file parallel write 与 log file sync 的差值是否异常扩大
归档日志写入是存储最刚性的I/O路径。它的延迟直接约束最大安全IOPS上限：
- 查AWR中两个事件的
Avg Wait (ms)：log file parallel write是LGWR实际写盘耗时；log file sync是用户进程等待commit确认的总耗时 - 差值
- 差值 > 5 ms 且稳定存在：说明LGWR提交队列积压，存储写入能力已达瓶颈，此时继续增大会话或事务频率只会加剧排队
- 特别注意：如果
log file sync高但log file parallel write很低（如 0.3 ms），问题在应用层（COMMIT太密）或Data Guard SYNC模式，而非IOPS
真正难判断的，是那些IOPS数值尚可、但延迟毛刺频发的场景——AWR快照粒度（默认60分钟）会平滑掉瞬时尖峰，这时必须用 v$iostat_file 实时抓取最近5分钟的 AVG_READ_TIME 和 AVG_WRITE_TIME，才能捕获真实瓶颈时刻。
