user commits每秒速率是核心指标，需用v$sysstat计算：ROUND(SUM(CASE WHEN NAME='user commits' THEN VALUE END)/3600,2)，超50/s预警、超200/s即提交风暴；配合user calls/(user commits+user rollbacks)判断事务粒度，再结合log file sync与log file parallel write等待时间对比及AWR直方图、RAC SCN同步、存储I/O特征综合诊断。
查 user commits 每秒速率，不是看平均等待时间
log file sync 平均等待 3ms 或 8ms 没实际意义——如果每秒发生 200 次，光这一项就吃掉 1.6 秒/秒的 DB Time。真正该盯的是提交频率。
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)看事务粒度：结果接近 1 表示INSERT; COMMIT;这类短事务泛滥
比对 log file sync 和 log file parallel write 的平均等待毫秒数
两者数值高度接近（比如都是 9–12ms），才说明瓶颈真在 LGWR 写盘环节；若 log file sync 高而 log file parallel write 仅 1–2ms，问题大概率出在 CPU、Latch 或 RAC 同步上。
- AWR 中直接对比两个事件的
Avg Wait(ms)字段 - 再查直方图确认延迟分布：
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 已明显卡顿
RAC 环境下必须检查 SCN 同步延迟，不能只盯 LGWR
单机数据库 log file sync 在 LGWR 写完就结束；RAC 下还必须等 SCN 传播到所有节点，否则其他实例读不到最新提交。SCN 同步慢会直接抬高 log file sync 时间，但 AWRTop5 里不显式体现。
- 查 AWR 中
Dynamic Remastering Stats部分：replayed locks sent异常高（如每秒上万）说明 DRM 频繁，加剧 SCN 传播压力 - 检查私有网络延迟：用
ping -s 65507测节点间大包时延，>5ms 就需警惕 - 确认是否启用了
_use_adaptive_log_file_sync=FALSE导致固定 polling 模式，在高并发下放大等待
验证存储 I/O 是否真拖后腿，别被 RAID 5 坑了
即使 log file sync 和 log file parallel write 时间一致，也不能直接断定是磁盘慢——得看 I/O 特征是否匹配小块顺序写场景。
- Linux 下跑
iostat -x 1 5：重点关注%util > 90%、await > 15ms、svctm异常升高 - Redo 日志绝不能放在 RAID 5 上：小块顺序写在 RAID 5 下强制转成随机大写，I/O 效率归零
- 确认 redo 日志文件大小是否合理：AWR 中看
Log File Switch (checkpoint incomplete)是否频繁；理想切换间隔是 15–20 分钟
真实排查中，最容易被跳过的点是：把 log file sync 当成纯 I/O 问题去调存储，却漏掉了 user commits/s 超 200 这个硬指标，或在 RAC 下完全忽略 SCN 传播链路。这两个地方一错，后续所有优化动作都南辕北辙。
