ORACLE AWR报告之 log file sync等待事件优化的总结【转自ITPUB】

来自白大师（白鳝）对log file sync等待事件优化的总结，供各位puber们学习参考：

1、 　log file sync平均等待事件时间超过7ms，若是等待时间过长，说明log write每次写入的时间过长，若是可以优化redo日志文件存储，使之存放在更快的磁盘上，就能够减小这个等待事件的单次等待时间。（RAID 5--> RAID 10）
  　当没法经过优化redo日志的I/O性能来解决问题，或者优化了redo日志的I/O性能后仍是没法达到咱们的预期，那么该如何处理呢？


  2、 有经验的DBA可能会建议加大日志缓冲区（log buffer）。提到加大日志缓冲区，可能有些朋友就会感到疑惑，redo日志文件写等待时间长怎么会和日志缓存冲区直接关联起来呢？实际上这个问题解释 起来一点也不难，若是数据文件的I/O性能有问题，平均单块读的等待时间偏长，那么经过加大db cache来减小I/O总次数，从而达到优化I/O的效果。加大日志缓存区的原理也是同样的，这样可使
    日志缓存中的存储更多的redo日志数据，从而减小因为redo日志缓存区不足而产生lgwr写操做的数量，使平均每次写入redo日志文件的redo字节数增长，从而减小redo的I/O次数，进而达到优化log file sync等待事件的目的。


　3、若是上述两种方法都不行时，还有一种方法：就是减小提交的次数。若是提交过于频繁，那么不管怎么优化都没法完全解决问题。
　经过加大一次提交记录的数量，减小提交批次，能够有效地减小log file sync等待时间。采用此方法就意味着须要对应进行较大的调整，甚至要对应用架构作出修改，这种修改的代价将十分巨大。
　　
　4、还有一个方案能够优化log file sync事件，就是把部分常常提交的事务设置为异步提交。
　　异步提交是10g版本引入的新特性，经过设置commit_write参数，能够控制异步提交。
　　commit_write参数默认值是“immediate,wait”
    能够设置为“immediate,nowait”来实现异步提交。
    采用异步提交的系统须要作一些额外的校验和处理，清理不一致的数据，从新插入刚才因为异步提交而丢失的数据。这就须要在应用层面进行一些特殊处理，建校验 机制和错误数据处理机制。咱们须要在应用层面进行一些特殊的设置。应该注意的是，那些特别重要的，后续没法从新彻底补充的数据不适合使用这种方法
　　


  log file sync等待事件是十分关键的，咱们在数据库的平常维护中应该对此指标创建基线，若是这个指标有异常变化，必定要尽快分析并解决问题。一旦这个指标恶化， 可能致使系统性能急剧降低，甚至会致使短暂的挂起。去年，一个客户的系统，平时log file sync的指标是2-3ms。在一次巡检时老白发现该指标增加到了7ms, 当时巡检报告中建议客户关注这个指标，并尽快检查存储系统和操做系统，查出变慢的缘由。客户检查了存储，没发现故障，因而就不了了之了。在下个月巡检的时 候，发现该指标增加到了13ms,再次预警，依然没有发现问题。随后两个月这个指标一直持续恶化，增加到了20多毫秒。因为前面几个月的检查工做没有发现 问题，而目前系统也仍是很正常的，因此客户也没有再去认真核查。终于有一天，系统忽然挂起，５分钟后才恢复正常。后来检查缘由，就是log file sync等待致使。根据个人建议，客户从头至尾检查了一遍，最终发现LVM的一条链路存存闪断现象，修复了链路后，一切都恢复正常了。
  　　　
　　　经过上面的案例，咱们要吸收教训，若是log file sync指标有所恶化，必定要尽快排查问题的根源，若是log file sync的等待时间持续上升，那么系统出现挂起的可能性也在增长。尽快找到问题的缘由是势在必行的。

-----------------------------------------------------------------------------

来自盖大师（eygle）对log file sync等待事件优化的总结，供各位puber们学习参考：

http://www.eygle.com/statspack/statspack14-LogFileSync.htm
　当一个用户提交(commits)或者回滚(rollback),session的redo信息须要写出到redo logfile中.
用户进程将通知LGWR执行写出操做,LGWR完成任务之后会通知用户进程.
这个等待事件就是指用户进程等待LGWR的写完成通知.

对于回滚操做，该事件记录从用户发出rollback命令到回滚完成的时间.

若是该等待过多，可能说明LGWR的写出效率低下，或者系统提交过于频繁.
针对该问题，能够关注:
log file parallel write等待事件
user commits,user rollback等统计信息能够用于观察提交或回滚次数

解决方案:
1.提升LGWR性能
尽可能使用快速磁盘，不要把redo log file存放在raid 5的磁盘上
2.使用批量提交
3.适当使用NOLOGGING/UNRECOVERABLE等选项

能够经过以下公式计算平均redo写大小：

avg.redo write size = (Redo block written/redo writes)*512 bytes

若是系统产生redo不少，而每次写的较少，通常说明LGWR被过于频繁的激活了.
可能致使过多的redo相关latch的竞争,并且Oracle可能没法有效的使用piggyback的功能.

咱们从一个statspack中提取一些数据来研究一下这个问题.

咱们看到，这里log file sync和db file parallel write等待同时出现了.
显然log file sync在等待db file parallel write的完成.

这里磁盘IO确定存在了瓶颈，实际用户的redo和数据文件同时存放在Raid的磁盘上，存在性能问题.
须要调整.

因为过渡频繁的提交，LGWR过分频繁的激活，咱们看到这里出现了redo writing的latch竞争.
关于redo writing竞争你能够在steve的站点找到详细的介绍:
http://www.ixora.com.au/notes/lgwr_latching.htm

Oracle Internals Notes
LGWR Latching

When LGWR wakes up, it first takes the redo writing latch to update the SGA variable that shows whether it is active. This prevents other Oracle processes from posting LGWR needlessly. LGWR then takes the redo allocation latch to determine how much redo might be available to write (subject to the release of the redo copy latches). If none, it takes the redo writing latch again to record that it is no longer active, before starting another rdbms ipc message wait.
If there is redo to write, LGWR then inspects the latch recovery areas for the redo copy latches (without taking the latches) to determine whether there are any incomplete copies into the log buffer. For incomplete copies above the sync RBA, LGWR just defers the writing of that block and subsequent log buffer blocks. For incomplete copies below the sync RBA, LGWR sleeps on a LGWR wait for redo copy wait event, and is posted when the required copy latches have been released. The time taken by LGWR to take the redo writing and redo allocation latches and to wait for the redo copy latches is accumulated in the redo writer latching time statistic.

(Prior to release 8i, foreground processes held the redo copy latches more briefly because they did not retain them for the application of the change vectors. Therefore, LGWR would instead attempt to assure itself that there were no ongoing copies into the log buffer by taking all the redo copy latches.)

After each redo write has completed, LGWR takes the redo allocation latch again in order to update the SGA variable containing the base disk block for the log buffer. This effectively frees the log buffer blocks that have just been written, so that they may be reused.

------------------------------------------------------------------------------------

来自吕大师（vage）对log file sync等待事件优化的总结，供各位puber们学习参考：


一、Log File Sync是从提交开始到提交结束的时间。Log File Parallel Write是LGWR开始写Redo File到Redo File结束的时间。明确了这一点，能够知道，Log file sync 包含了log file parallel write。因此，log file sync等待时间一出，必先看log file parallel write。若是log file sync平均等待时间（也可称为提交响应时间）为20ms，log file parallel write为19ms，那么问题就很明显了，Redo file I/O缓慢，拖慢了提交的过程。

二、 Log File Sync的时间不止log file parallel write。服务器进程开始提交，到通知LGWR写Redo，LGWR写完Redo通知进程提交完毕，来回通知也是要消耗CPU的。除去来回通知 外，Commit还有增长SCN等等操做，若是log file sync和log file parallel write差距很大，证实I/O没有问题，但有多是CPU资源紧张，致使进程和LGWR来回通知或其余的须要CPU的操做，得不到足够的CPU，于是产 生延迟。

这 种状况下要看一下CPU的占用率、Load，若是Load很高、CPU使用率也很高，哪就是因为CPU致使Log file sync响应时间加长。这种状况下，数据库一般会有一些并发症，好比Latch/Mutex的竞争会比日常严重些，由于CPU紧张吗，Latch /Mutex竞争一些会加巨的。

三、 log file sync和log file parallel write相差很大，但CPU使用率也不高，这种状况比较少见，这就属于疑难杂症范畴了。I/O也很快，CPU也充足，log fie parallel write响应时间很短，但log file sync响应时间确很大。这是最难定位的状况，能够全面对比下Redo相关资料(v$sysstat中的资料）、Redo相关Latch的变化状况。
比 如，redo synch time的平均响应时间，不是每次redo synch time都有提交，但每次提交必有redo synch time。若是redo synch time向应快，而log file sync慢，则说明Lgwr和进程的互相通知阶段出了问题。还有redo entries，这个Redo条目数，真正含意是进程向Log Buffer中写Redo的次数。redo log space wait time、redo log space requests资料和Log Buffer Space等待事件也要关注下。Log Buffer的大小一般不会影响Log File Sync，但经过Log Buffer的变化，能够了解Redo量的变化。
关于Log Buffer对Log File Sync的影响，

在新IMU机制下，Redo数据先在共享池中，提交时传到Log Buffer中，若是这时有等待，等待时间是Log Buffer Space。从Log Buffer到磁盘，等待事件才是log file sync。
老机制下也同样，Log Buffer以前的等待是log buffer space，log buffer以后的等待才是log file sync。

四、控制文件I/O有可能影响log file sync。
此问题还没来得及深刻研究，只是之前在阿里的数据库中观察到这一现象。

五、Log File Sycn和Buffer Busy Waits。
没 有直接关系。是其余缘由，好比Redo相关的Latch，致使了Log File Sync和Buffer Busy Waits同时出现。此时Log File Sync和Buffer Busy Waits都不是原凶，真正的原凶是Log Buffer访问性能降低。

六、以同步模式向远端DataGuard传送Redo，也会致使Log File Sync。

Redo是Oracle重要的优化对象，DBWR的工做原理我已经破译的差很少了，下一目标就是LGWR，惋惜还没来得及搞，之后有时间再为你们详细总结。