《log file sync》 等待事件问题分析汇总 -m6米乐安卓版下载

背景

  “log file sync”是oracle中的经典等待事件之一，做为dba 经常在awr报告top 5 timed foreground events版块，发现它的存在。
  在之前面试的时候也有考官问过这样的问题，引起log file sync等待事件有哪几种情况，当时脑袋里一堆问号，“log file sync不是因为频繁事务commit/rollback引导的吗？”当时我是这样回答的，考官说：“你只回答上了一部分，回头自己多查查资料吧！”。
  后来自己也查询许多的资料，想着做个整理，正好借着学习张维照老师的《oracle dba日常运维及应急故障处理手册》第1.1就是讲的《oracle redo file on ssd wait event ‘log file sync’》做个笔记总结。

现象

• 课程示例：
  
  数据库的log file sync： avg wait (ms)达500ms以上，并且cpu 负载相对空闲，io吞吐量并不大，top event还有其它数据文件相关的i/o class wait event, 并且都是ms级别，这样的负载对于ssd存储通常应该就是在us级。

• 我的环境：
  
  我这log file sync： avg wait (ms)也就1。一般log file sycn的等待时间都非常短 1-5ms，不会有什么问题。

log file sync理论

• 官方的definition如下：
  when a user session(foreground process) commits (or rolls back), the session’s redo information needs to be flushed to the redo logfile. the user session will post the lgwr to write all redo required from the log buffer to the redo log file. when the lgwr has finished it will post the user session. the user session waits on this wait event while waiting for lgwr to post it back to confirm all redo changes are safely on disk.

  大概的意思指前台进程从提交或回滚事务通知lgwr写redo开始，直到确认redo已成功写入redo logfile为止，期间这个过程就是log file sync等待的过程。
  所以，log file sync是每个事务commit或rollback操作都必经的过程，是否被判为异常等待，主要参考等待时间的长短、等待次数的多少。
  由于需要等待lgwr写redo logfile，因此，log file sync的等待时间涵盖了log file parallel write的时间。

原因分析汇总

1、小事务频繁提交引起：

官方的经验值是：
如果：user calls÷(user commits user rollbacks) < 30 ，那么可以算事务太过频繁。
以我的环境为例：

sql> select 10316411/(963806 31450) from dual;
10316411/(963806 31450)
-----------------------
             10.3655853 < 30 ，那么可以算事务太过频繁。

2、bug

commit的过程可以分为两个阶段：
第一阶段为lgwr将redo从log buffer写到redo logfile的过程；
第二阶段lgwr和user session(foreground process) 之间关于写redo logfile结果的信息交互过程。
对于第二阶段，oracle自从11g r2开始引入了adaptive log file sync的特性，该特性由参数隐含参数“ _use_adaptive_log_file_sync” 控制，决定着前台进程和lgwr之间的交互使用何种方式。
在 oracle 11201 和 oracle 11202的版本中，该参数默认设置为 false。从 11.2.0.3 开始默认是 true。
当设置为true启用时，oracle 可以在两种方法之间自行切换：
post/wait，传统发布写重做日志完成的方法。
polling，一种新的方法，其中前台进程会检查 lgwr 是否已写完成。
本环境为11.2.0.3 隐含参数： _use_adaptive_log_file_sync

      indx name                           ksppdesc                                           ksppstvl
---------- ------------------------------ -------------------------------------------------- ----------
      1060 _use_adaptive_log_file_sync    adaptively switch between post/wait and polling    true

详细可查：bug 13707904  – lgwr sometimes uses polling,sometimes post/wait.

该bug可通过设置隐藏参数_use_adaptive_log_file_sync的默认值解决问题。

alter system set "_use_adaptive_log_file_sync"= false  scope=both;

同时，此bug开始在oracle 11.2.0.4以及12.1.0.1版本中得到解决。

3、结合：log file parallel write 事件分析

  log file parallel write 事件是lgwr进程专属的等待事件，发生在lgwr将日志缓冲区（log_buffer）中的重做日志信息写入联机重做日志文件组的成员文件，lgwr在该事件上等待该写入过程的完成。该事件的等待表示重做日志所处的磁盘设备缓慢或存在争用。

• log file parallel write出现原因
  意味着重做日志(redo log)所处的磁盘设备i/o缓慢或存在争用：

1. 磁盘i/o性能比较差
2. redo文件的分布导致了i/o争用，例如，同一组的redo成员文件放在相同的磁盘上。

• 查看log file parallel write等待事件

select s.event as event_name
 ,s.time_waited/100 as time_waited
,s.average_wait as averge_wait
from v$system_event s
where s.event in ('log file parallel write','log file sync');
event_name                                                       time_waited averge_wait
---------------------------------------------------------------- ----------- -----------
log file parallel write                                           2408236.83         .03
log file sync                                                     2503386.33         .06

来自网络汇总：

1. log file sync的平均io较高，log file parallel write的平均io较高，可能的io系统问题；
2. log file sync的平均io较高，log file parallel write的平均io低于5ms，远低于log file sync：可以确定io无问题，有可能是cpu瓶颈。
3. log file sync等待次数很高，log file parallel write的平均io较低，可能是大量小事务频繁提交导致，这时候通常伴随着cpu使用率较高的现象出现。
4. log file sync和log file parallel write的平均io都较低，这不一定就代表系统没有问题，有可能是刷redo过程中出现了间隙性的性能问题，io时间被平均了，这个需要进一步通过os的信息诊断。

张维照老师的《oracle dba日常运维及应急故障处理手册》里面的第1.1就是讲的《oracle redo file on ssd wait event ‘log file sync’》请的就是关于系统io引起的log file sync，在此不再重复，有兴趣可以学习：https://www.modb.pro/course/article/160?lsid=6885&catalogid=1