avg wait (ms) >15ms才需怀疑存储，2–8ms属正常波动；该值反映lgwr总等待耗时而非单次io延迟，须结合v$sysstat计算真实单次io延迟（redo write time / redo writes × 10）交叉验证。
看AWR里Avg Wait (ms)是否真超标
平均等待时间 >15ms 才值得怀疑存储性能；2–8ms 波动基本正常，别急着换SSD。直接翻 AWR 报告的 Top 5 Timed Events 表格，找 log file parallel write 对应的 Avg Wait (ms) 列——这是第一道过滤器。
注意：这个值是 LGWR 等待所有并行 I/O 完成的总耗时，不是单次磁盘写延迟。它受日志组成员数、IO 调度、fsync 开销共同影响，不能直接等同于磁盘 await。
- 若
Avg Wait (ms) - 若 >15ms，继续查
V$SYSSTAT算真实 IO 延迟：redo write time / redo writes * 10（单位 ms） - 如果算出来只有 1–2ms，但 AWR 显示 20ms，说明瓶颈不在磁盘，而在 OS 层同步（如 fsync）、CPU 调度或 RAID 卡策略
用iostat和V$INSTANCE_RECOVERY交叉验证
iostat -x 1 是绕不开的验证步骤。重点盯两个指标：%util 和 w_await（Linux）或 svctm（旧版，已弃用但仍有参考性）。
常见误判场景：
-
%util接近 100% 但w_await -
w_await>10ms 且%util高 → 存储层真慢，检查 SSD 是否被归档目录、数据文件共用同一物理盘 -
V$INSTANCE_RECOVERY中actual_redo_blks持续远高于target_redo_blks→ LGWR 写不过来，要么 redo 量爆炸，要么写能力被压制
查日志配置和写模式是否把SSD用废了
SSD 对 LGWR 有效，前提是它真在顺序大块写。很多环境把它用成了「伪随机」，优势全丢。
必须确认这几件事：
- redo 日志文件是否跨多个物理 SSD？单 SSD 上放多组日志文件 ≠ 条带化，只是串行排队
- 文件系统挂载参数是否含
noatime,barrier=0（ext4）或禁用 journal（xfs）？否则每次写都触发元数据刷盘 - RAID 卡缓存策略是不是
Write-Through？必须设为Write-Back并启用电池/电容保护 - 归档路径是否和
LOG_ARCHIVE_DEST_1共享同一 SSD？归档刷盘会打断 LGWR 的顺序写节奏
别漏掉LGWR自身行为导致的假高延迟
log file parallel write 高，不等于磁盘慢。LGWR 自身行为经常被忽略：
- 大量小事务：频繁
COMMIT WRITE NOWAIT导致 LGWR 被反复唤醒，调度开销放大 - 日志组太小或太少：频繁日志切换（
switches per hour > 4）让 LGWR 忙于切换而非写入 - CPU 资源紧张：
log file sync高但log file parallel write正常（ - OS 调度优先级过低：检查
ps -eo pid,comm,nice,rtprio | grep lgwr，确保 LGWR 进程没被降权
真正难判断的，是那些 log file parallel write 在 8–12ms 区间波动的情况——它既不够高到明确指向存储，又不够低到排除硬件问题，这时候必须结合 iostat、V$SYSSTAT 和应用事务模式一起看，而不是单点下结论。
