若user commits超50/s且log file sync平均等待≥5ms，基本为提交风暴；log file sync与log file parallel write等待时间接近则存储I/O是主因；RAC下需优先检查SCN传播延迟、GC块争用及DRM活动。
怎么看是不是提交太频繁导致的 log file sync
直接查每秒提交次数（user commits）和平均等待时间（log file sync 的 avg wait ms）。如果 awr 或 ash 里看到 user commits 超过 50/s，且 log file sync 平均等待在 5–15ms 以上，基本可以锁定是提交风暴。
更准一点：用下面 SQL 看提交密度与等待是否同步尖峰：
SELECT TO_CHAR(sample_time, 'HH24:MI') tm,
COUNT(*) waits,
ROUND(AVG(time_waited)/1000, 2) avg_ms
FROM v$active_session_history
WHERE event = 'log file sync'
AND sample_time > SYSDATE - 1/24
GROUP BY TO_CHAR(sample_time, 'HH24:MI')
ORDER BY tm;- 如果每分钟都稳定出现几十次
log file sync等待，且时间分布均匀，大概率是应用层小事务轮番提交 - 注意对比
user rollbacks—— 频繁回滚也会触发 LGWR 写日志，效果等同于 commit - 别只看总等待时间，要结合
commit cleanouts和immediate (CR) block cleanout等指标，高频率 cleanout 也说明事务粒度太碎
怎么确认 Redo 日志写盘慢是主因
核心看两个等待事件的时间比对：log file sync 和 log file parallel write。如果两者平均等待时间接近（比如都是 8–12ms），问题几乎肯定出在存储 I/O 上。
执行这个查询看分布：
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 写盘已出现明显延迟 - 再配合 OS 层验证：Linux 下跑
iostat -x 1 5，重点看%util是否持续 >90%，await是否 >15ms，svctm是否异常升高 - Redo 日志千万别放在 RAID 5 上——小块顺序写 + 校验计算会让性能雪崩；也别和归档日志、数据文件混在同一 LUN
commit_write=nowait,batch 能不能开？风险在哪
能开，但不是万能膏药，且必须清楚代价：数据库意外宕机时，最近一批未刷盘的 commit 可能丢失（通常几毫秒到最多 100ms 数据）。
- 只建议在业务允许“最多丢一次秒级事务”的场景启用，比如日志类、埋点类、非金融交易类系统
- 参数可在线改：
ALTER SYSTEM SET commit_write='NOWAIT,BATCH';，但要注意它不作用于已存在的会话，新连接或显式执行ALTER SESSION SET commit_write='NOWAIT,BATCH'才生效 - 不要和
COMMIT WRITE IMMEDIATE NOWAIT混用——后者是语句级覆盖，优先级更高，容易造成会话间行为不一致 - 开启后务必监控
redo write time和redo writes的变化：如果redo writes明显下降但redo write time升高，说明 batch 积压严重，可能引发突发延迟
RAC 环境下 log file sync 特别高，先盯哪几个点
RAC 的 log file sync 天然比单机重，因为每次 commit 还要同步 SCN 到其他节点。别一上来就调存储或加日志组，先看这三处：
- 检查
MAX_COMMIT_PROPAGATION_DELAY：10gR2+ 默认 BOC（立即传播），但如果被误设为较大值（如 700），会导致 SCN 同步卡顿，直接拉长log file sync - 查
v$cr_block_server和v$gcshv，看是否有节点长期处于高busy状态；再看gc cr blocks received是否突增——大量 CR 块争用会抢占 LGWR 调度资源 - 观察 DRM（Dynamic Remastering）活动：
select * from v$dynamic_remaster_stats;。如果replayed locks sent每秒几百上千，说明频繁主控权迁移，会强制插入额外 SCN 同步动作，显著拖慢 commit 路径
DRM 在 11g+ 默认开启，但 OLTP 类 RAC 若表访问模式稳定，关掉反而更稳：ALTER SYSTEM SET "_gc_affinity_time"=0;（需评估业务局部性）
