log file sync等待高不等于磁盘慢，应先查user commits是否超50/s（超200/s即提交风暴），再比对log file parallel write延迟；若两者接近才指向存储I/O问题。
log file sync 等待高，不等于磁盘慢——先查每秒提交次数，再看 log file parallel write 延迟是否匹配，否则调优方向全错。
查 user commits 每秒速率比看平均等待时间更准
单次 log file sync 平均 3ms 没意义，如果每秒发生 300 次，实际每分钟就多压了 54 秒延迟。AWR 里只盯“平均等待时间”容易误判。
- 直接运行：
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)看事务粒度：结果 INSERT; COMMIT; 这种写法
log file sync 和 log file parallel write 时间是否接近
两者平均等待毫秒数高度一致（比如都是 8–12ms），说明瓶颈就在 LGWR 写盘环节，不是 CPU、Latch 或 RAC 同步问题。
- 查直方图确认延迟分布：
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验证：重点关注%util > 90%、await > 15ms、svctm异常升高 - RAID 5 上放 redo 日志是经典错误——Redo 小块顺序写在 RAID 5 下会转成随机大写，I/O 效率归零
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 备份一致性会直接破坏
RAC 环境下不能只查 LGWR，SCN 传播延迟才是隐藏杀手
单机数据库 log file sync 是 LGWR 写完就通知；RAC 下还必须等 SCN 同步到所有节点，否则其他实例读不到最新提交。
- 10gR2+ 默认用
immediate commit propagation (BOC)，但若参数MAX_COMMIT_PROPAGATION_DELAY被设为较大值（如 700ms），SCN 传播就会人为拖慢 - 查 RAC 特有等待：
gc cr block busy、gc buffer busy acquire、DFS lock handle是否同步升高 - 用 AWR 报告里的 “Global Cache and Enqueue Services” 部分交叉验证 DRM（Dynamic Remastering）活动是否频繁
最容易被忽略的是：应用层每行 INSERT 后跟 COMMIT 的写法，在数据库端无论怎么调存储、加 buffer、改参数，都只是给 LGWR 持续喂高频小任务。真正的优化点不在 DBA 手里，而在那段循环体里。
