log file parallel write平均等待>15ms才怀疑存储，2–8ms波动多因lgwr行为或日志配置；需结合直方图（如16ms档占比超30%）、系统统计（redo write time / redo writes × 10）及iostat（%util >90%、w_await升高）综合判断。
查log file parallel write平均等待是否真超标
平均等待时间 >15ms 才值得怀疑存储，2–8ms 波动大概率是 LGWR 行为或日志配置问题。别被 AWR 里“Avg Wait (ms)”单独数值带偏——它只是算术平均，掩盖了尾部延迟。真正要盯的是 v$event_histogram 中高毫秒档位的占比：比如 wait_time_milli = 16 的 wait_count 占总量超 30%，才说明 LGWR 写盘已明显卡顿。
更准的参考值来自系统统计：redo write time / redo writes * 10（单位 ms），这个公式算出的是实际单次写耗时，比 AWR 报告里的“平均等待”更贴近真实 I/O 延迟。
- 查法：
SELECT name, value FROM v$sysstat WHERE name IN ('redo writes', 'redo write time'); - 若结果
- 若结果 >20ms，再结合
iostat -x 1 5看%util是否持续 >90%、w_await是否同步升高
确认是不是RAID 5或归档干扰了LGWR顺序写
RAID 5 上放 redo 日志是经典错误——Redo 小块顺序写在 RAID 5 下会转成随机大写，I/O 效率归零；而把归档目录和联机日志放在同一 SSD 上，归档刷盘会打断 LGWR 的连续写节奏，造成写放大和延迟抖动。
- 检查日志文件物理位置：
SELECT member FROM v$logfile;，确认是否跨多个物理磁盘（非 ASM/LVM 条带时容易误配成单盘多文件） - Linux 下检查挂载参数：
mount | grep "your_redo_fs"，确保含noatime,barrier=0 - SSD 后端队列深度不足、RAID 卡缓存设为 Write-Through（直写），都会让 SSD 低延迟优势失效
看redo blocks written/user commits是否过低
这个比值反映每次提交产生的重做量。正常 OLTP 场景下应在 20–50 之间；若长期
查法：SELECT ROUND(SUM(CASE WHEN NAME = 'redo blocks written' THEN VALUE END) / NULLIF(SUM(CASE WHEN NAME IN ('user commits','user rollbacks') THEN VALUE END),0), 2) AS rb_per_commit FROM v$sysstat WHERE NAME IN ('redo blocks written','user commits','user rollbacks');
- 结果 LOG_BUFFER
- 结果 >100 → 检查是否有大字段更新、LOB 操作或未用
/*+ APPEND */的批量插入 - 盲目调大
LOG_BUFFER可能适得其反：触发刷盘阈值后移，导致单次写量变大、I/O 峰值更陡峭
别漏掉RAC或Data Guard带来的隐性延迟
RAC 环境下 log file parallel write 时间正常，但 log file sync 高，很可能是 SCN 同步延迟——LGWR 写完后还得等其他节点 ACK；DG 环境中 LNS 进程卡住，也会拖慢 LGWR 的写完成通知路径。
- RAC：查
v$ges_enqueue或 AWR 中gc cr grant 2-way等等待是否异常升高 - DG：查
v$archive_dest_status的status和gap_status，确认 LNS 是否 stalled - 这两类问题不会体现在
log file parallel write直方图上，但会拉长用户感知的提交延迟
最容易被忽略的是：log file parallel write 高往往不是孤立事件，它常和 latch: redo writing、log file sync、甚至 control file parallel write 成对出现——必须交叉看 AWR Top 5 Timed Events 和系统级 iostat 输出，否则优化方向全错。
