Log File Sync延迟高主因常非磁盘慢，而是提交过频（>50/s为警戒线，>200/s即提交风暴）、redo日志文件过小（建议≥1GB，切换间隔应≥15分钟）、RAID 5误用或commit_write配置不当；须优先查user commits每秒速率及log file parallel write直方图分布，二者等待时间高度一致（如均为8–12ms）才指向I/O瓶颈。
log file sync延迟高，90%以上不是磁盘慢，而是提交太勤、日志太小、或配置没对齐。
查 user commits 每秒速率比看平均等待时间更准
AWR里log file sync平均等 8ms？没意义——如果每秒发生 300 次，实际每分钟就多压了 54 秒延迟。真正该盯的是提交频次：
- 直接运行：
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)，结果就说明平均每不到 30 次调用就 commit 一次，属于高频小事务
log file parallel write 和 log file sync 时间是否接近
两者平均毫秒数高度一致（比如都是 8–12ms），才说明瓶颈真在 LGWR 写盘环节；否则问题不在 I/O，而在 CPU 调度、Latch 争用或 RAC 的 SCN 同步上。
- 查直方图确认延迟分布：
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异常升高才是 I/O 瓶颈证据
Redo 日志文件大小与组数是否合理
AWR 中 Log switches (derived) 显示每小时切换 9.95 次？约 6 分钟切一次，远高于推荐的 15–20 分钟——说明日志文件太小，LGWR 总在忙切换，没空好好写。
- 单个 redo log 文件建议至少
1GB起（OLTP 场景下常见为 2–4GB） - 日志组数至少
4组，避免归档未完成就触发 checkpoint 或 forced log switch - 别把 redo 放 RAID 5 上：小块顺序写在 RAID 5 下会转成随机大写，I/O 效率归零；改用 RAID 10 或 NVMe 直连盘
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 同步到所有节点，否则其他实例读不到最新提交。
