先查每秒user commits是否超50/s（超200/s即提交风暴），再比对log file parallel write延迟分布；若两者平均等待时间接近且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)——如果结果，说明平均每不到 30 次操作就提交一次，属于高频小事务 - 若
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混用——后者绕过 redo，commit_write仍走 redo 流程，语义和风险完全不同
最容易被忽略的细节：RAC 和轮询模式的影响
在 RAC 环境中，log file sync 不仅包含本地 LGWR 写盘，还隐含跨节点 SCN 同步耗时。即使存储和 CPU 都正常，LMS 进程响应慢、私网延迟高、甚至节点间时钟漂移，都会拉长等待。
Oracle 11.2+ 默认支持 LGWR 自动切换 post/wait 与 polling 模式。polling 模式下，前台进程不等信号量，而是轮询共享内存里的写进度标志——这会降低 IPC 开销，但也让 log file sync 时间更难直接对应到某次 I/O，需结合 v$lgwrs 和 LGWR trace 分析。
真正复杂的地方在于：当多个因素叠加（比如提交密集 + RAC 同步抖动 + 小日志文件频繁切换），AWR 报告里的单个平均值会掩盖分层延迟。此时必须拆解为“通知 LGWR 耗时”“LGWR 收集 redo 耗时”“物理写耗时”“SCN 同步耗时”“唤醒前台耗时”五个段，分别抓取 systemstate 和 lgwr trace 才能准确定位。
