log file parallel write 等待高不一定是磁盘慢，可能源于lgwr行为、日志配置或系统参数；平均等待>15ms才需怀疑存储，否则应检查redo写量、io调度、ssd配置及事务大小。
log file parallel write 等待高，真就是磁盘慢？
不是。这个等待事件反映的是 lgwr 进程把 redo 写入 log file 的耗时总和，但「高」不等于「磁盘瓶颈」——它可能被单次写量、io 调度、redo 日志配置或甚至 cpu 调度拖累。
先看 AWR 报告里 log file parallel write 的平均等待时间（Avg Wait (ms)）：如果长期 > 15ms，才值得怀疑底层存储；若在 2–8ms 波动，更可能是 LGWR 自身行为或日志组设计问题。
- 检查
V$SYSSTAT中redo writes和redo write time，算出实际平均单次写耗时：redo write time / redo writes * 10（单位 ms），比 AWR 的“平均等待”更贴近真实 IO 延迟 - 确认日志文件是否跨多个物理磁盘（非 ASM 或 LVM 条带时容易误配成单盘多文件）
- 留意是否有大量小事务（
COMMIT WRITE NOWAIT频繁触发）导致 LGWR 被反复唤醒，放大调度开销
SSD 能不能压低 log file parallel write？关键看写模式
SSD 对随机小写延迟改善有限，而 LGWR 的典型写模式是顺序大块（通常 512KB 左右），这恰好是 SSD 最擅长的场景——但前提是系统没把它用成「伪随机」。
常见踩坑点：RAID 卡缓存策略设为 Write-Through（直写）、SSD 后端队列深度不足、或文件系统挂载参数未启用 noatime,barrier=0（Linux 下 ext4/xfs），都会让 SSD 的低延迟优势打折扣。
- 用
iostat -x 1观察%util和await：若%util接近 100% 但await仍低（ - 确认 Oracle 使用的裸设备或文件系统是否禁用 journal（如 xfs 不需 journal，ext4 建议用
data=writeback） - 避免将
log file和归档目录放在同一 SSD 上——归档刷盘会干扰 LGWR 的顺序写节奏
AWR 里哪些指标能交叉验证 LGWR 瓶颈是否真在存储层？
单看 log file parallel write 容易误判。必须结合 LGWR 的工作负载特征和系统级 IO 行为反推。
重点盯三个地方：AWR 的 Top 5 Timed Events 里有没有配套出现 latch: redo writing 或 log file sync 高等待；OS 层 iostat 的 svctm（已弃用，但 r_await/w_await 仍有参考价值）；以及 V$LGWR（12c+）或 V$INSTANCE_RECOVERY 中的 actual_redo_blks 与 target_redo_blks 是否持续偏离。
-
log file sync平均时间 >log file parallel write的 2 倍？说明 LGWR 写完后，用户进程还在等 commit 返回，大概率是 LGWR 没及时唤醒或 CPU 调度滞后 -
V$SYSSTAT中redo blocks written/user commits若远低于 20（正常 OLTP 多在 50–200），说明事务太小，LGWR 在「写得勤但每次写得少」，SSD 改善有限 - 检查
FAST_START_MTTR_TARGET是否设得过小（如
换 SSD 前，先做这几件事比盲目上硬件更有效
很多案例里，调优 LGWR 相关参数或调整日志结构，比换 SSD 降得更多——因为瓶颈根本不在磁盘响应时间。
优先验证这些改动是否立刻见效（改完 1 小时内看 AWR）：
- 把在线日志组数量从 2 组扩到至少 4 组，每组大小 ≥ 1GB（避免频繁日志切换引发的 checkpoint 和 LGWR 阻塞）
- 确认
LOG_BUFFER没被设得过大（> 200MB 易引发内存争用），也别过小（ - 关闭
_use_adaptive_log_file_sync（11g/12c 默认 TRUE），强制使用post/wait模式（实测在某些 Linux 内核下比polling更稳） - 检查是否有应用在循环中执行
INSERT + COMMIT，改成批量提交（哪怕每 100 行 commit 一次）对log file parallel write的降低效果常超 40%
真正需要 SSD 的场景其实很窄：归档密集型数据库、逻辑备库 Apply 线程重放压力大、或者 RAC 环境中因网络同步 redo 导致本地 LGWR 被卡住——这时候 SSD 的低延迟才能穿透协议栈堆叠的延迟。其他情况，先调 LGWR，再看磁盘。
