为什么Oracle 19c中Log File Sync等待时间突然飙升？

Log File Sync等待时间突然飙升，通常并非由磁盘故障引起。需要明确的是，超过90%的突发性等待上升，其根本原因在于提交节奏或同步链路异常——例如应用程序中新功能导致每行提交、RAC节点间SCN广播阻塞，或者归档滞后引发的日志切换风暴。

第一步：检查提交频率

平均等待时间（如8毫秒）通常可忽略，需重点关注提交频次。若在AWR中观察到log file sync总等待时间显著增长，应首先执行以下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');

将结果与故障前的数据进行对比：

• 若每秒提交次数从12次跃升至187次，则可判定为提交风暴，与存储性能无关。
• 同时需关注 user calls / (user commits + user rollbacks) 的比值。
• 注意：若序列的 NEXTVAL 设置为 NOCACHE，可能触发大量递归提交，此情况需纳入排查范围。

第二步：比对log file parallel write与log file sync的时间

当两个等待事件的时间接近（例如均为9–12毫秒）时，表明LGWR确实被I/O所阻塞；否则问题大概率不在磁盘：

• 若 log file sync 高达250毫秒，而 log file parallel write 仅为1毫秒，则I/O无问题，根源可能在于CPU调度、Latch争用或RAC的SCN同步。
• 通过直方图查看延迟分布：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);。若16毫秒及以上档位的计数占总量的30%以上，则LGWR已出现明显卡顿。
• 在Linux环境下使用 iostat -x 1 5 验证：若%util超过90%、await大于15毫秒、svctm异常升高，则说明存在I/O瓶颈。

第三步：RAC环境下检查wait for scn ack

在Oracle 19c RAC中，log file sync飙升常伴随 wait for scn ack 等待事件——此现象并非I/O问题，而是LMS进程在跨节点同步SCN时发生阻塞：

• 检查 v$system_event 中 wait for scn ack 是否突然增加；同时查看 v$sysstat 中 redo write broadcast ack time 统计值是否同步上升。
• 若LMS trace文件中持续出现 broadcast time 异常高，则很可能由某个节点的网络延迟、心跳不稳定或LMS进程被CPU抢占所致。
• 在非紧急情况下，可临时禁用自适应日志同步：ALTER SYSTEM SET "_adaptive_log_file_sync"=FALSE SCOPE=BOTH;，但需评估对RAC一致性的影响。

第四步：检查日志切换频率

若AWR中 Log switches (derived) 显示每小时切换9.95次（约6分钟一次），远低于推荐的15–20分钟切换间隔，则说明redo日志文件过小：

• 单个redo日志文件建议至少1GB（OLTP环境通常为2–4GB），组数至少4组，避免归档未完成即触发forced log switch。
• 应避免将redo部署在RAID 5上：小块顺序写入在RAID 5中会转化为随机大写，I/O效率显著下降。推荐使用RAID 10或NVMe直连盘。
• 归档路径空间不足、归档进程 ARCH 阻塞，或 log_archive_dest_n 配置了低效传输方式（如ASYNC且网络抖动），均会导致LGWR等待归档完成后才能重用日志。

最后需注意一个容易被忽略的问题：log file sync并非单一瓶颈，而是前台进程、LGWR、LMS、I/O子系统乃至操作系统信号量调度共同构成的链路。任一环节的轻微劣化，在高并发场景下都会被指数级放大。因此排查时不能仅依赖单一指标，必须横向比对 commits_per_sec、log file parallel write 直方图、wait for scn ack、iostat 以及归档状态——这五类数据缺一不可。