存储迁移后最直接信号是file io stats中某数据文件av i/o wait从3–5ms突增至12ms以上；ssd环境超5ms、hdd超15ms且持续>30分钟可锁定新存储链路问题。
看 file io stats 里哪些数据文件的 av i/o wait 突然变高
存储迁移后最直接的信号，不是 top 5 里 db file sequential read 占比飙升，而是下钻到 file io stats 表格中，某几个数据文件的 av i/o wait (ms) 从平时的 3–5ms 跳到 12ms 以上。ssd 环境下超过 5ms 就该警惕，hdd 环境超过 15ms 且持续 >30 分钟，基本可锁定是新存储链路问题。
注意别只盯“平均值”——用下面 SQL 查单次快照的尖峰：
SELECT s.snap_id, TO_CHAR(s.begin_interval_time,'HH24:MI') t, f.file_name,
ROUND(f.time_waited_micro/1000/f.physical_reads, 2) avg_ms,
f.physical_reads
FROM dba_hist_iostat_file f
JOIN dba_hist_snapshot s ON f.snap_id = s.snap_id AND f.dbid = s.dbid
WHERE f.file# IN (
SELECT file# FROM dba_data_files
WHERE tablespace_name IN ('USERS','INDEXES')
)
AND f.physical_reads > 0
AND s.begin_interval_time >= SYSDATE - 2
ORDER BY avg_ms DESC
FETCH FIRST 10 ROWS ONLY;
- 结果里如果
avg_ms高但physical_reads很低（比如 - 如果
avg_ms和physical_reads同步暴涨，优先查对应 ASM diskgroup 或底层 LUN 的 iostat -x 1 输出 - 迁移后新增的数据文件（如
+DATA_NEW）必须单独拉出来比对，旧文件延迟正常不能代表新路径没问题
对比迁移前后两个 AWR 报告的 Physical Reads Per Second 和 Redo Size Per Second
单纯看 IO 延迟容易误判——得确认“是不是真在读更多”，还是“读得慢但读得少”。关键看 Load Profile 里两组数字的联动关系：
-
Physical Reads Per Second暴涨 +Redo Size Per Second不变 → 存储响应变慢，或 buffer cache 命中率塌方（查Buffer Hit Ratio是否从 96% 掉到 87%） -
Physical Reads Per Second暴涨 +Redo Size Per Second同步翻倍 → 更可能是应用层行为变化（比如批量作业未适配新存储吞吐特性），而非存储本身故障 -
Physical Reads Per Second不变但Av I/O Wait升高 → 几乎可断定是存储层延迟升高，和数据库配置无关
特别注意：迁移窗口若跨了统计信息收集任务，Buffer Hit Ratio 可能被临时拉低，要排除这个干扰——查 DBA_TAB_STATISTICS 中相关表的 LAST_ANALYZED 时间是否集中在迁移后几小时内。
检查 db file scattered read 的 Avg Wait 和 IOPS 是否背离
db file scattered read 是全表扫描、并行查询的典型等待，它对顺序 IO 吞吐更敏感。迁移后如果这个事件的 Avg Wait (ms) 没怎么变，但报告里 Physical Reads Per Second 暴跌（比如从 3500 掉到 800），说明新存储顺序读吞吐能力不足，或者 RAID 配置/条带大小没调优。
- 用
v$sysmetric实时验证：Physical Read Total IO Requests Per Sec和Physical Read Total Bytes Per Sec要同步下降，否则是应用逻辑卡在了别的地方 - 如果
db file scattered read的Total Waits也同步腰斩，说明某些大查询干脆执行不完了，得去v$session_longops里捞超时任务 - 别忽略
direct path read——它绕过 Buffer Cache，更能反映裸存储性能；迁移后若它的Avg Wait比db file scattered read高出一倍以上，大概率是 ASM diskgroup 的 AU 大小或 failgroup 分布没适配新盘
为什么 AWR 有时看不出迁移后的 IO 退化
不是数据不准，是聚合方式掩盖了关键细节：
- AWR 默认按 60 分钟粒度汇总，而存储迁移后的抖动常发生在前 15 分钟内，且被后续平稳时段均摊掉——务必用 15 分钟快照区间生成报告，别用默认 1 小时
- 如果迁移后启用了新的归档模式（如从 NOARCHIVELOG 切到 ARCHIVELOG），
log file sync延迟上升会挤占 IO 资源，但 AWR 不会把这部分压力计入db file*类事件，得单独查v$archived_log归档速率和v$dataguard_stats - Exadata 或 Oracle Cloud RDS 环境下，
db file sequential read的等待可能被 offload 到智能扫描层，AWR 显示延迟低但实际端到端响应慢——此时必须结合云平台监控（如 OCI Metrics）交叉验证
真正要命的是那种“延迟没爆表、IOPS 没打满、但业务 SQL 响应时间翻倍”的情况——这时候往往不是存储硬件问题，而是迁移后未重建索引统计信息，导致执行计划退化成全表扫描，IO 请求量翻了几倍，但每块读的延迟看着还凑合。
