先看log file sync与log file parallel write平均等待时间是否接近（如均在8–15ms），若高度接近且wait_time_milli≥16ms的写盘延迟占比超30%，再结合iostat显示%util>90%或await>15ms，即可锁定存储I/O瓶颈。
log file sync等待时间长，先看是不是LGWR写盘慢
直接比对 log file sync 和 log file parallel write 的平均等待时间。如果两者都在 8–15ms 区间且高度接近，问题基本锁定在存储 i/o——lgwr 没法快速把 redo 刷到磁盘。
用这个 SQL 查写盘延迟分布：
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 或更高的档位占总写次数 30% 以上，说明 LGWR 已持续卡在写盘环节。再配合 iostat -x 1 5 看 OS 层：如果 %util > 90% 或 await > 15ms，就是物理瓶颈。
- Redo 日志绝不能放在 RAID 5 上——小块顺序写被校验计算拖垮
- 别和数据文件、归档日志混在同一 LUN，哪怕都是 SSD
- 检查是否开了
ARCHIVELOG且归档路径慢，LGWR 会等归档完成才能重用日志组
ASH里怎么定位“提交风暴”而不是单次慢
不要只查 log file sync 的总平均值。它可能才 3ms，但每秒触发 300 次，实际已吃掉近 1 秒的前台响应时间。
用 ASH 按分钟聚合，看等待是否密集且规律：
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;如果每分钟都稳定出现几十次等待，且 avg_ms 波动不大（比如始终在 5–10ms），大概率是应用层小事务轮番提交，不是偶发 I/O 抖动。
- 同步查
user commits和user rollbacks每秒速率：超过 50/s 就值得警惕，超 200/s 基本确认是提交风暴 - 注意
enq: KO - fast object checkpoint是否紧随log file sync出现在同一 session 的连续样本中——这是 checkpoint 被提交阻塞的典型链路 -
sql_id IS NULL+program LIKE '%tnslsnr%'的样本若也带log file sync，说明登录初始化阶段就被卡住，常因递归事务或字典更新引发
commit_write=nowait,batch 能不能开，开完要注意啥
能开，但不是绕过问题的捷径，而是用“可接受的数据丢失风险”换响应时间。实例崩溃时，最近几毫秒内未刷盘的 commit 可能丢失——业务敢不敢接，得一起拍板。
生效方式有两种：
- 系统级：执行
ALTER SYSTEM SET commit_write='NOWAIT,BATCH' SCOPE=BOTH，但只影响新连接 - 会话级：在应用连接池初始化时加
ALTER SESSION SET commit_write='NOWAIT,BATCH'
副作用很实在：
-
log file parallel write次数下降，但单次写量变大，可能触发更大 I/O 峰值 - redo allocation latch 争用可能上升，尤其高并发 insert 场景
- 开启后
user commits统计值不变，但log file sync等待锐减——容易误判问题已解决，其实只是前台不等了
为什么加大 log_buffer 不一定有用
加大 log_buffer 的逻辑是：攒更多 redo 再批量写，减少 log file parallel write 次数。但它只在 LGWR 因 buffer 满而频繁唤醒时才有效。
现实里更常见的是：buffer 还没满，但事务已提交，前台就催 LGWR 写盘——这时加 buffer 毫无意义。
- 判断依据：查
redo log space requests和redo log space wait time。如果这两个值极低，说明 buffer 从不缺，加了白加 - 真正该盯的是
redo entries（进程向 log buffer 写 redo 的次数）和user commits的比值。如果接近 1:1，说明每个事务几乎只写一条 redo，根本没机会攒 - log_buffer 超过 100MB 后收益急剧衰减，还可能增加 LGWR 单次扫描开销
最隐蔽的坑是：调大 log_buffer 后，log file sync 等待没降，但 log file parallel write 的 90% 分位反而升高——因为每次写的数据块更大，I/O 延迟被拉长了。
