log file parallel write 等待高未必是存储瓶颈，需满足平均等待＞10ms且占DB Time＞5%才深挖；redo日志须独占RAID 1+0磁盘、避免共享路径；LOG_BUFFER建议3–8MB，过大反增单次写延迟。
LGWR 写磁盘慢，先看 log file parallel write 等待事件是否真瓶颈
不是所有高 log file parallel write 等待都意味着存储慢——它只是 lgwr 把 redo buffer 里一批日志块（通常 1–3 个）同步写入到在线 redo log 文件时的等待。如果这个事件平均等待时间 > 10ms，且占 db time 比例 > 5%，才值得深挖存储层。
- 用
SELECT event, time_waited_micro/1000 wait_ms, waits FROM v$system_event WHERE event = 'log file parallel write';查实时值 - 注意：单次写可能含多个 block（
blocks列在v$session_event），但等待时间只记一次，所以平均 ms 偏低不等于 I/O 快 - 如果
log file sync也高（常 >log file parallel write的 2–3 倍），说明提交响应已受拖累，调优更紧迫
Redo 日志文件位置和条带化配置直接影响 log file parallel write
LGWR 是单线程、顺序写、要求低延迟的 I/O 模式，最怕随机干扰和争用。把 redo log 放错位置，性能直接打折。
- 必须独占物理磁盘或 LUN：不能和数据文件、归档、备份、OS swap 共享同一组磁盘或同一 RAID LUN
- 推荐使用 RAID 1+0（非 RAID 5/6）：RAID 5 的写惩罚会放大 LGWR 小块写开销
- 多组日志建议跨不同物理路径：比如
/u01/oradata/DB/redo01.log和/u02/oradata/DB/redo02.log应映射到不同控制器+磁盘柜 - 避免 NFS 或某些超融合存储后端：它们对
O_SYNC写支持弱，Linux 下甚至可能 fallback 到非 direct I/O 模式
LOG_BUFFER 大小不是越大越好，过大会延长单次 log file parallel write
LOG_BUFFER 决定了 LGWR 多久触发一次写——不是按时间，而是按空间满或 commit 触发。设太大，单次写的数据量就大，反而拉长等待时间。
- 默认值（如 32MB）对多数 OLTP 不合理；建议从
3MB–8MB起步，观察v$sysstat中redo buffer allocation retries是否 > 0 - 如果
redo entries/redo writes比值长期 > 100，说明每次写进了很多事务，可适当增大；但若比值 log file parallel write 平均 ms 升高，大概率是 buffer 太大了 - 不要盲目设成 1GB：Oracle 不保证大 buffer 下的写合并效率，反而可能因内存拷贝、pin lock 加重 CPU 开销
存储层验证必须绕过文件系统缓存，用 dd + O_DIRECT 测真实 redo 写性能
用 iotop 或 iostat -x 1 看 %util 高，不代表磁盘慢——可能是文件系统缓存掩盖了问题。LGWR 默认用 O_SYNC | O_DIRECT，测试必须模拟它。
- 在 redo 所在裸设备或文件系统上跑：
dd if=/dev/zero of=/redo/testfile bs=512 count=10000 oflag=direct,sync - 关注
latency（单次 512B 同步写耗时），而非吞吐：目标是P99，超过 10ms 就有问题 - 检查存储队列深度：
cat /sys/block/<code>sdX/device/queue_depth，太小（如 1）会导致 LGWR 请求排队，需调大或换驱动 - 确认无限速行为：某些存储网关或云盘（如 AWS gp3 在 baseline IOPS 下）会静默限速，需查厂商 QoS 策略
真正卡点往往不在 Oracle 参数，而在那条从 LGWR 进程到磁盘扇区的链路上——中间任何一个环节（HBA 驱动、多路径策略、存储 cache 模式、甚至 RAID 卡 BBU 状态）掉链子，log file parallel write 就会暴露出来。别急着改 LOG_BUFFER，先让 dd 说话。
