log file parallel write 平均等待>15ms才真要怀疑磁盘；低于该值90%问题在LGWR自身行为或配置，如LOG_BUFFER过大、归档干扰、未禁用文件系统journal等。
log file parallel write 平均等待 >15ms 才真要怀疑磁盘；低于这个值，90% 问题出在 lgwr 自身行为或配置上。
查清 log file parallel write 的真实平均耗时
AWR 报告里的 Avg Wait (ms) 是个“表观值”，它把 LGWR 每次批量写（含多个 block）的总耗时除以写次数，容易掩盖单次 I/O 实际延迟。更准的做法是用系统统计值反推：
- 执行
SELECT name, value FROM v$sysstat WHERE name IN ('redo writes', 'redo write time'); - 计算：
redo write time / redo writes * 10（单位 ms），这个结果才接近 LGWR 单次物理写的真实延迟 - 若该值稳定在 2–8ms，但 AWR 显示 12ms，说明 LGWR 在一次写里塞了太多 block（比如 LOG_BUFFER 过大或事务太碎），不是磁盘慢
- 注意：v$sysstat 的
redo writes包含所有写动作（包括非 commit 触发的），所以不能直接等同于 commit 频次
区分 log file sync 和 log file parallel write 的时间关系
这两个事件必须一起看，光盯一个会误判根源：
- 如果
log file sync平均等待 ≈log file parallel write（比如都是 9–12ms），那存储 I/O 就是瓶颈，优先查磁盘调度、SSD 队列深度、文件系统挂载参数 - 如果
log file sync是 400ms 而log file parallel write只有 6ms，说明 LGWR 写得不慢，但写完后没及时通知用户进程——大概率是 CPU 调度滞后、run queue 高，或 OS 层sched_latency_ns设置不合理 - 用
v$event_histogram看分布：SELECT wait_time_milli, wait_count FROM v$event_histogram WHERE event = 'log file parallel write' AND wait_time_milli >= 16;若 16ms+ 档位占总等待 25% 以上，才值得怀疑硬件层异常
验证存储是否真拖累 LGWR：绕过缓存测裸写
LGWR 默认使用 O_SYNC | O_DIRECT，文件系统缓存对它无效。用普通 dd 测出来的吞吐不能反映真实 redo 性能：
- Linux 下模拟 LGWR 写模式：
dd if=/dev/zero of=/path/to/testfile bs=512k count=200 oflag=direct,sync（512KB 块、同步落盘） - 同时跑
iostat -x 1，重点看：w_await（写响应时间）、%util（设备忙时比）、aqu-sz（平均队列深度） - 若
w_await 但 <code>%util > 95%，说明存储吞吐已到极限，需扩容或调优队列策略；若aqu-sz 且 <code>w_await低，说明 LGWR 没压满设备，问题在 Oracle 层唤醒逻辑或日志组配置 - 别忘了检查 RAID 卡缓存策略：Write-Through 模式会让 SSD 白瞎，必须设为 Write-Back + BBU 正常
最容易被忽略的 LGWR 行为陷阱
很多 DBA 花半天调磁盘，最后发现是 LGWR 被自己“喂撑了”：
-
LOG_BUFFER设成 1GB？危险。Oracle 不保证大 buffer 下的写合并效率，反而可能因内存拷贝、pin lock 加重 CPU 开销；3–8MB 是安全起步区间，观察redo buffer allocation retries是否 > 0 - 日志文件放在同一 SSD 上，还和归档目录共用路径？归档刷盘会打断 LGWR 的顺序写节奏，造成隐式随机 IO；必须物理隔离
- 应用频繁
COMMIT WRITE NOWAIT？这会让 LGWR 被反复唤醒，调度开销放大，尤其在高并发小事务场景下；先确认业务能否接受丢毫秒级数据，再决定是否启用 - 没禁用文件系统 journal：ext4 建议挂载加
data=writeback，xfs 则无需 journal；否则每次写 redo 都多一次元数据落盘
真正卡住 LGWR 的，往往不是磁盘本身，而是它被要求“做太多事又不给好工具”。查延迟前，先确认你有没有无意中把它变成一个频繁起停、带宽受限、还要兼职元数据管理的苦力进程。
