> 本文主要说明 log file sync 等待事件及相关内容 #### 1.说明是'log file sync'等待事件 当一个用户会话提交，那个用户产生的所有redo需要从内存刷新到重做日志文件，使事务对数据库的修改永久化。 在提交时，用户会话会通知 LGWR 把日志缓冲区中的信息写到重做日志文件（当前所有未被写入磁盘的 redo 信息，包括本次会话的 redo 信息）。当 LGWR 发现写操作完成后，它会通知用户会话。当等待LGWR通知确认所有redo 已经安全的保存到磁盘的过程时，用户会话会等待'log file sync'。 用户会话显示等待'log file sync'，是用户会话通知LGWR和LGWR通知用户的写操作完成之间的时间。 注意在11.2及以上版本，LGWR会在默认的post/wait模式和polling模式之间自动切换。在polling模式下，写操作的进展会维护在一个内存结构中，等待'log file sync'的会话可以不时检查这个内存结构看是否自己所发起的事务对应的redo已经写入磁盘。这时，等待时间会从用户会话通知LGWR开始到会话自己发现对应的redo已经写入磁盘结束。 #### 2.初步分析，需要哪些信息 - 'log file sync'等待在可接受范围的类似时间的 AWR 报告，作为用于比较的性能基线 - 'log file sync'等待很严重期间的 AWR 报告 - LGWR 日志文件（在12.2版本以上还需收集LGnn日志文件） **引起该等待事件最常见的原因：** - I/O性能问题 - 过多的commit - redo log 太小，切换频繁 **比较 user commit/rollback 同 user calls 比值的平均值** 如果平均每 5.76 次 user calls 就会有一次 commit, 大约高出建议值 5 倍。基于经验，我们期望 user calls/user commit 至少是 25。当然，这取决于应用程序设计。 **间歇性物理IO缓慢对 'log file sync' 等待事件的影响** GWR倾向于做很多小的IO操作，而不是大块的IO操作。大部分的磁盘配置并不能在这种场景下很好的工作，可能会发生间歇性物理IO缓慢. 如果你发现系统的'log file sync'很高，但是'log file parallel write'是处于正常的范围，那么这可能是由于间歇性物理IO缓慢导致的。可以检查AWR的部分，也可以使用一些像OSWatcher一样的工具(参照 Document 301137.1)来确定是否系统中存在间歇性物理IO缓慢。如果可以确定存在间歇性物理IO缓慢, 那么你需要与磁盘提供商一起来解决这个问题。 出现问题，一定要检查 LGWR trace文件，尽管'log file parallel write'的平均等待时间可能在一个合理的区间范围内，在峰值时刻写操作时间还是可能会很长进而影响’log file sync’的等待时间。从10.2.0.4 开始如果写操作超过 500 毫秒我们会在 LGWR 的 trace 中写警告信息。这个阀值很高所以就算没有警告也不代表没有问题。警告信息如下： ``` *** 2011-10-26 10:14:41.718 Warning: log write elapsed time 21130ms, size 1KB (set event 10468 level 4 to disable this warning) *** 2011-10-26 10:14:42.929 Warning: log write elapsed time 4916ms, size 1KB (set event 10468 level 4 to disable this warning) ``` 注意：上面的峰值如果时间间隔的很远,可能不会对'log file parallel wait'有大的影响。 但是，如果有 100 个会话等待'log file parallel wait'完成，'log file sync'总等待可能就会很高，因为等待时间将被乘以会话的个数 100。因此，值得探讨日志写 IO 高峰的原因。 #### 3.Adaptive Log File Sync 11.2 中引入了 Adaptive Log File sync，由参数 _use_adaptive_log_file_sync 控制，在 11.2.0.1 和 11.2.0.2 默认设置为 false。从 11.2.0.3 开始默认是 true。 当启用时，Oracle 可以在两种方法之间切换： - Post/wait，传统发布写重做日志完成的方法.LGWR显式发布所有等待提交完成的进程。优点是，当重做被刷新到磁盘时，会话几乎应该立即发现。 - Polling，一种新的方法，其中前台进程会检查 LGWR 是否已写完成。前台处理睡眠和轮询以查看提交是否完成。这种新方法的优点是使LGWR不必通知许多等待提交完成的进程，从而释放LGWR的高CPU使用率。 最初，LGWR使用post/wait，并根据内部算法评估轮询是否更好。在高系统负载下，轮询可能会执行得更好，因为post/wait实现通常不能很好地扩展。如果系统负载较低，则post/wait性能良好，并且提供比轮询更好的响应时间。Oracle依靠内部统计信息来确定应该使用哪种方法。因为在post/wait和轮询之间切换会产生开销，所以有安全防护措施以确保切换不会太频繁。 所有开关都记录在LGWR的跟踪文件中，带有时间戳和字符串“日志文件同步切换到…”： Switch to polling: ``` *** 2012-10-02 08:15:47.049 kcrfw_update_adaptive_sync_mode: post->poll long#=316 sync#=1719 sync=247657 poll=12382 rw=6191 rw+=13890 ack=0 min_sleep=10023 *** 2012-10-02 08:15:47.050 Log file sync switching to polling Current scheduling delay is 234 usec ``` Switch to post/wait: ``` ***2012-10-02 08:16:23.325 kcrfw_update_adaptive_sync_mode: poll->post current_sched_delay=0 switch_sched_delay=234 current_sync_count_delta=2275 switch_sync_count_delta=1719 *** 2012-10-02 08:16:23.325 Log file sync switching to post/wait Current approximate redo synch write rate is 758 per sec ``` 轮询统计信息存储在v$sysstat中： ``` sql SQL> select name,value from v$sysstat where name in ('redo synch poll writes','redo synch polls'); NAME VALUE ---------------------------------------------------------------- ---------- redo synch poll writes 0 redo synch polls 0 ``` 在上面的示例中，我们看到轮询没有发生. 该功能在一些版本也出现过一些问题，后续优化，相对好点，如果有影响，请及时查看，并关闭。如果需要禁用自适应日志文件同步，可以通过在spfile中设置_use_adaptive_log_file_sync=false并重新启动数据库或在内存中动态设置来实现。 **Redo Synch Time Overhead** 统计值'redo synch time overhead'在11.2.0.4和12c被引入，记录了理想的log file sync时间以及真正的log file sync时间的差值。 如果这个差值很小，说明很大的log file sync可能是由于离群（就是偏离平均等待时间很大的log file parallel write等待）的log file parallel write等待导致的。 #### 4.解决办法 一些建议： - 与系统管理员一起检查重做日志所在的文件系统以及本地卷的位置，以提高 IO 性能。 - 不要把重做日志放在需要额外计算的较老的或者复杂的RAID上，比如 RAID-5或者RAID-6或者只有很少cache部件的存储上 - 不要把重做日志放在上一代或者较老的Solid State Disk (SSD)磁盘上 虽然通常情况下，SSD 写入性能好于平均水平，他们可能会遇到写峰值,从而导致大量的严重'log file sync'等待并引发数据库性能不稳定或者hung住(关于这一点您需要详尽的测试，因为我们也碰到一些即使SSD的写性能不稳定但数据库性能仍然可以接受的系统) (Engineered Systems (Exadata, SuperCluster 和 Oracle Database Appliance) 除外，因为在这些系统上已经为使用SSD来存放重做日志而做了额外的优化) - 监控其他可能需要写到相同路径的进程，确保该磁盘具有足够的带宽，足以应付所要求的容量。如果不能满足,增加硬盘或者更快的磁盘设备或者把这些文件分散到不同的磁盘设备。 - 确保 LOG_BUFFER 不要太大，一个非常大的 log_buffer 的不利影响就是刷新需要更长的等待时间。当缓冲区满了的时候，它必须将所有数据写入到重做日志文件。LGWR 将一直等待,直到最后的 I/O 完成。 - 扩容redo log ，增加日志组 - 如果有很多短事务，看是否可能把这些事务组合在一起，从而减少 commit 操作。 因为每一个 commit 都必须收到相关 REDO 已写到磁盘上的确认，额外的 commit 会显著的增加开销。虽然 Oracle 可以将某些 commit 组合在一起，通过事务的批处理来减少commit的总体数量还是可以带来非常有益的效果。 - 看看是否有操作可以使用 COMMIT NOWAIT 选项 （务必在使用前应明白语义）。 - 看看是否有操作可以安全地使用 NOLOGGING/ UNRECOVERABLE 选项完成。 #### 参考 - https://cloud.tencent.com/developer/article/1605049 - 故障排除："log file sync"等待 (Doc ID 1626301.1) - Adaptive Log File Sync Optimization (Doc ID 1541136.1)