log buffer —— log file sync

如果服务器进程执行提交或回滚，LGWR就将重做缓冲区上最近写入的时刻到最近提交时刻为止的重做记录，写入到日志文件上，这就是“sync write”，它可以通过redo synch writes统计值查询。服务器进程在下达提交命令后，一直等待知道LGWR成功写入为止，这事等待log file sync事件。

SQL> select event#,name,parameter1,parameter2,parameter3 from v$event_name where name = 'log file sync';    EVENT# NAME                           PARAMETER1      PARAMETER2      PARAMETER3---------- ------------------------------ --------------- --------------- ---------------       140 log file sync                  buffer#         sync scn

这个等待事件有两个个参数。
buffer#：redo buffer中需要写入到磁盘中的buffer。
sync scn：scn号码。

若log file sync等待广泛出现，就应该怀疑以下事实。
提交次数是否过多？
过于频繁的提交是log file sync等待的关键因素。一般情况下，每当执行一次提交都发生一次log file sync等待。因此如果多个会话上同时执行大量的提交，就可能广泛发生log file sync等待。因提交每次执行sync write时，可能给整个系统性能带来较坏影响，所以oracle尽量将提交请求集结后一次性执行sync write。这就是组提交。

I/O系统是否缓慢？
重做日志文件所在I/O系统的性能缓慢时，执行LGWR的sync write时间将会延长，因此可能增加log file sync等待时间。这时，服务器进程在等待log file sync事件期间，LGWR会等待log file parallel write事件。提交次数适当或因系统的特性无法减少提交次数时，如果广泛发生log file sync等待，就需要对I/O系统性能改善进行检查。一般LGWR所等待log file parallel write事件的时间长或整个系统上相对等待时间长，就可以理解为重做日志文件所在的I/O系统的性能存在问题。
一般oracle指南里会讲：将重做日记文件置于最快的设备上。还有为了避开磁盘争用，互相不同组的重做日志文件应分散在不同的磁盘上。将重做日志文件分配在与数据文件或控制文件不同的磁盘上也是有必要的。

重做数据是否不必要的被创建？
执行提交时，只要减少重做日志文件上需要写入的数据量，就可以减少log file sync等待时间。特别是大而长的事务减少重做数据量，LGWR的后台写入工作就将减少，与重做相关的争用也可以解除。
（1）能否使用nologging选项？若使用nologging选项，可以最大限度减少重做数据。Direct load功能和Create ...、Alter ...之类的工作大部分提供了nologging选项。若灵活应用这些功能，可最大限度减少重做数据量。
（2）通过SQL*Loader装载大量数据时，将使用Direct load option。
（3）需要临时操作时，尽量使用临时表。如果使用了临时表，虽然因撤销会创建重做，但是不会创建对于数据的重做。因此具有重做数据的量整体减少的效果。
（4）对已经有索引的表执行Direct load操作时，应该使用如下步骤，防止索引引起的重做的创建。
          a、将索引修改为Unusable状态。
          b、生成数据。
          c、将索引以nologging模式重建。
（5）若LOB数据较大，则尽量赋予nologging属性。

重做缓冲区是否过大？
一般重做缓冲区过大时，有log file sync等待增加的趋势。这是因为重做缓冲区大时，LGWR引起的后台写入次数相对较少，这时用户会话上执行sync write时需要写入的数据量增加，因此log file sync等待时间可能延长。
重做缓冲区大小多大才合适呢？这个没有一个正确的答案。从前1M左右的缓冲区就觉得大，但最近5M以上的重做缓冲区也被广泛使用。一般oracle指南里是赋予1~5M的大小并观察的。如果log file sync等待有增加的趋势，那最好减少重做缓冲区的大小。相反，log buffer space等待有增加的趋势，加大重做缓冲区的大小就是一般的解决方法。