log file sync等待高90%以上不是磁盘慢而是提交风暴或lgwr写盘被拖住，需先查每秒user commits是否超50/s（超200/s即提交风暴），再比对log file parallel write延迟分布，仅当两者平均等待时间接近且16ms+档位wait_count占比超30%才指向存储i/o瓶颈。
先看每秒提交次数，别只盯平均等待时间
AWR里log file sync平均等待3ms没意义——如果每秒发生300次，前台实际每分钟多压54秒延迟。真正该查的是提交频率是否失控。
运行这个SQL获取真实压力：
SELECT ROUND(SUM(CASE WHEN NAME = 'user commits' THEN VALUE END) / 3600, 2) AS commits_per_sec FROM v$sysstat WHERE NAME IN ('user commits','user rollbacks');
- 超过
50/s是警戒线，需警惕 - 超过
200/s基本就是提交风暴，和磁盘快慢无关 - 配合
user calls / (user commits + user rollbacks)看事务粒度：若结果接近1，说明大量INSERT; COMMIT;这种单行小事务
比对log file parallel write延迟分布，确认瓶颈是否在IO
log file sync高 ≠ 磁盘慢。只有当它和log file parallel write的平均等待时间高度接近（比如都是8–12ms），才说明LGWR写盘真卡住了。
查直方图看延迟是否集中爆发：
SELECT wait_time_milli, wait_count FROM v$event_histogram WHERE event = 'log file parallel write' AND wait_time_milli IN (1,2,4,8,16,32);
- 若
wait_time_milli = 16或更高档位的wait_count占总量超30%，LGWR已持续卡顿 - Linux下必须交叉验证：
iostat -x 1 5中await > 15ms或w_await显著升高（尤其NVMe盘）才是物理瓶颈 -
%util > 90%只是辅助参考，RAID 5或混放LUN下可能虚高
检查Redo日志存放位置是否踩了经典陷阱
Redo日志绝不能放在RAID 5上——小块顺序写被校验计算拖成随机大写，I/O效率归零。也别和归档日志、数据文件混在同一LUN。
- 优先用
RAID 10或专用NVMe设备存放redo log - 确认
v$log和v$logfile指向的路径是否与db file sequential read热点文件共用同一存储路径 - 单机环境重点查LGWR写盘；RAC环境下还要看SCN传播延迟，
MAX_COMMIT_PROPAGATION_DELAY=1可能加剧log file sync
慎用commit_write=BATCH,NOWAIT，别把它当万能解药
它能压低log file sync，但代价明确：实例崩溃时最近一批未刷盘的commit可能丢失（通常几毫秒到最多100ms）。
启用命令：
ALTER SYSTEM SET commit_write='BATCH,NOWAIT' SCOPE=BOTH;
- 仅适用于埋点、日志等可丢数据场景；含资金、状态变更的关键事务禁用
- 副作用真实存在：LGWR单次写量变大，可能触发I/O峰值；
redo writing latch争用可能转移成redo allocation latch争用 - 别和
NOLOGGING或临时表混用——Data Guard同步、闪回、RMAN备份一致性会直接破坏
log file sync高往往不是IO问题，而是跨节点同步卡住了。
