先查每秒user commits是否超50/s（超200/s即提交风暴），再比对log file parallel write延迟分布；若两者平均等待时间接近（如均为8–12ms）且直方图中16ms+档位wait_count占比超30%，才指向存储I/O瓶颈。
log file sync 等待高，90% 以上不是磁盘慢，而是提交太密或 lgwr 写盘被拖住——先查每秒 user commits，再比对 log file parallel write 延迟分布，否则调优方向全错。
怎么快速判断是提交风暴还是 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)——如果结果 - 若
log file sync和log file parallel write的平均等待时间高度接近（比如都是 8–12ms），才真正指向 LGWR 写盘慢
如何验证 LGWR 写盘是否真卡在 I/O 上
光看 iostat -x 1 5 的 %util 不够，RAID 5 或混放 LUN 下，%util 可能虚高但延迟已崩。
- 查写盘延迟分布：
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 层必须交叉验证：
await > 15ms或r_await/w_await显著升高（尤其 NVMe 盘），才是物理瓶颈；%util > 90%仅作辅助参考 - Redo 日志绝不能放在 RAID 5 上——小块顺序写被校验计算拖成随机大写，I/O 效率归零；也别和归档日志、数据文件混在同一 LUN
commit_write=BATCH,NOWAIT 能不能开、怎么开
能开，但不是绕过问题的捷径，而是用“可接受的数据丢失风险”换响应时间——实例崩溃时，最近一批未刷盘的 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 环境下最容易被忽略的隐藏杀手
单机数据库 log file sync 是 LGWR 写完就通知；RAC 下还必须等 SCN 同步到所有节点，否则其他实例读不到最新提交。
- 不能只查 LGWR，得看
gc current block busy、gc cr block busy和 DRM（Dynamic Remastering）活动是否频繁 - ASH 中若发现
log file sync紧跟enq: KO - fast object checkpoint，说明 checkpoint 被提交阻塞，是典型的 RAC 同步链路卡点 - SQL_ID 为
NULL且program LIKE '%tnslsnr%'的样本若也带log file sync，常因登录初始化阶段的递归事务或字典更新引发，容易误判为业务 SQL 问题
