事务提交延迟高需综合分析提交频率、lgwr写盘行为及延迟分布，而非仅看log file sync平均值；每秒提交超200次即为提交风暴，应优先批量提交；需比对log file sync与log file parallel write直方图判断瓶颈是否在磁盘；commit_write设为batch,nowait可降延迟但需重启生效；rac/dg环境需排查私网延迟或lns等待；行锁争用也可能导致提交慢。
事务提交延迟高，不能只盯着 log file sync 的平均等待时间——它可能看起来只有 2ms，但每秒发生 300 次，实际拖慢了整个业务链路。真正要拆开看的是提交频率、LGWR 写盘行为、以及延迟分布形态。
先查每秒提交次数，别被平均值骗了
单次 log file sync 等待 1–3ms 很常见，但如果 user commits 每秒超 50，延迟就开始累积；超 200 就是提交风暴，和磁盘快慢无关。
- 运行这条语句确认速率：
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'); - 再算事务粒度：
SELECT ROUND(SUM(CASE WHEN NAME = 'user calls' THEN VALUE END) / (SUM(CASE WHEN NAME IN ('user commits','user rollbacks') THEN VALUE END)), 2) FROM v$sysstat;——结果接近 1.0 说明大量INSERT; COMMIT;这种小事务 - 如果
commits_per_sec> 200，优先考虑批量提交或应用层合并事务，而不是调存储
比对 log file sync 和 log file parallel write 的直方图
两者延迟分布不匹配，问题就不在磁盘上。比如 log file sync 尾部拉长（16ms+ 占比超 15%），但 log file parallel write 仍集中在 1–2ms，说明卡点在 LGWR 排队或日志缓冲区争用，不是 I/O。
- 查
log file sync分布：SELECT wait_time_milli, wait_count FROM v$event_histogram WHERE event = 'log file sync' AND wait_time_milli IN (1,2,4,8,16,32,64); - 查
log file parallel write分布：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); - 重点关注：1–2ms 档占比是否 15%；8→16ms 是否跳变剧烈（增长 >3 倍）
确认 commit_write 设置是否生效且符合业务容忍度
commit_write = BATCH,NOWAIT 能压低 log file sync，但代价明确：实例崩溃时最多丢失 100ms 内的已提交事务。这不是默认值，必须显式设置并重启才生效。
- 查当前值：
SHOW PARAMETER commit_write - 设为
IMMEDIATE（默认行为，强一致性）：ALTER SYSTEM SET commit_write = 'IMMEDIATE' SCOPE = SPFILE; - 设为
BATCH,NOWAIT（降低延迟，牺牲部分持久性）：ALTER SYSTEM SET commit_write = 'BATCH,NOWAIT' SCOPE = SPFILE; - 修改后必须
SHUTDOWN IMMEDIATE+STARTUP，否则不生效
别漏掉 RAC 或 Data Guard 场景下的干扰项
在 RAC 中，gc cr block lost 或私网延迟会抬高 log file sync；在 DG SYNC+AFFIRM 模式下，LNS wait on SENDREQ 高才是真瓶颈，不是 log file sync 本身。
- RAC 环境下，先查私网延迟：
SELECT * FROM gv$sysmetric WHERE metric_name = 'Interconnect Ping Latency Statistics';—— 8KB 包平均 > 1.5ms 就需排查网卡驱动或交换机 QoS - DG 环境下，
log file sync高大概率是LNS wait on SENDREQ或LGWR-LNS wait on channel引起，直接查V$MANAGED_STANDBY比翻 AWR 报告快得多 - AWR 报告里出现
enq: TX - row lock contention，说明提交慢可能是行锁阻塞，不是日志路径问题
最易被忽略的点：延迟毛刺往往藏在直方图尾部，而非平均值；而 commit_write 修改后不重启，等于没改。查完 v$event_histogram，立刻去 iostat -x 1 5 看 %util 和 await，别等下一个 AWR 快照。
