谈谈log file sync

数据库中的log file sync等待事件指的是，当user session 提交（commit）时，user session会通知LGWR进程将redo buffer中的信息写入到redo log file，当LGWR进程完成写操作后，LGWR进程再post（通知）user session 写操作已经完成，user session 接收到LGWR的通知后提交操作才完成。因此user session 在没有收到LGWR post（通知）之前一致处于等待状态，具体的等待事件为log file sync。根据实践经验，引起log file sync等待事件的原因有以下几种：
 事务过度的提交，即应用程序过度commit或者rollback。
 存储I/O资源紧张，导致lgwr进程写速度缓慢。
 CPU资源紧张，lgwr进程获得不了响应的CPU时间片。
 RAC节点之间SCN同步。
 RAC节点之间CR块传递。
 控制文件争用。
不同的原因，其解决方法会不同，当多种原因混合在一起时，则需要进行综合考虑。
事务过度提交
事务过度提交是引起log file sync等待事件的主要原因之一。前面提到，默认情况下，当事务提交时，LGWR进程会将事务相关的日志条目立即写至redolog中，直到日志写成功之后才显示提交成功。所以事务提交越频繁，触发LGWR进程写操作越频繁，引起log file sync等待时间的可能性越大。所以当由于事务过度提交引起log file sync等待事件时，最好的解决方法是修改应用，将小事务变成大事务。可在很多情况下，修改应用不是很简单的事情，需要应用厂商配合。当应用厂商配合程度不足时，我们就需要在DB端想办法了。所幸的是从Oracle 10g开始，Oracle推出了新的数据库参数commit_write用于控制LGWR进程写日志操作，其默认值为空，表示wait和immediate。也可以将其在线修改（即参数值修改后不需要重启数据库就能生效）成nowait和batch，表示事务提交时，LGWR进程并不马上将事务相关条目写至日志文件中，而是异步模式将相关条目批量（batch）写至日志文件中。所以采用这种方法，在缓减了log file sync等待事件的同时，数据库异常宕机后可能会引起数据丢失，所以要引起注意！
当然使用临时表或者NOLOGGING选项，尽可能少产生redo日志，也是解决log file sync等待事件的方法之一。
存储I/O资源紧张
LGWR进程写redolog特征是连续顺序小I/O写，存储的IOPS能力对其影响最大。当存储I/O资源紧张时，LGWR进程写日志的速度就受到明显影响，从而出现log file sync等待事件。如果要确定是否是存储I/O资源紧张导致log file sync等待事件，我们通常情况下只要检查以下两方面：
（1）检查存储的I/O资源是否紧张，如在AIX系统中可以通过topas命令观察磁盘的繁忙程度，如下所示：

（2）检查系统每次等待log file parallel write等待事件和log file sync等待事件的时间差，如果两者时间接近，则说明存储I/O资源紧张是引起log file sync等待事件的主要原因。log file parallel write等待事件和log file sync等待事件的关系如下图所示：

我们可以通过V$EVENT_HISTOGRAM视图观察log file parallel write等待事件消耗时间的分布情况，如下所示：
SQL> select event, wait_time_milli,wait_count
2 from v$event_histogram
3 where event = 'log file parallel write';
EVENT                   WAIT_TIME_MILLI  WAIT_COUNT
---------------------------------------------------
log file parallel write     1                22677
log file parallel write     2                  424
log file parallel write     4                  141
log file parallel write     8                  340
log file parallel write     16                1401
log file parallel write     32                 812
log file parallel write     64                 391
log file parallel write     128                 21
log file parallel write     256                  6
当由于存储I/O资源紧张而导致log file sync等待事件时，我们可以采取以下措施：
1、如果有空闲的物理磁盘，且这些物理磁盘的I/O性能能满足系统要求，那么将logfile在线迁移至空闲物理盘中。如果空间允许，还可以考虑将数据库的UNDO表空间在线迁移至其他盘，从而释放I/O压力。
2、如果在线日志设置了多组member，为了减少LGWR写日志操作，可以考虑删除其他member，只保留一组。
CPU资源紧张
主机CPU资源紧张从而导致LGWR进程获得不了CPU时间片也可能导致log file sync等待事件。某系统由于主机CPU资源紧张，而出现较多的log file sync等待事件，CPU资源如下所示：

数据库的AWR报告显示log file sync等待比较严重，如下所示：

事实上，LGWR进程写存储的速度并不慢，log file parallel write等待事件每次才等待2ms，如下所示：

针对CPU资源紧张而导致log file sync等待事件，有以下几种解决方案：
1、增加CPU资源，优化消耗CPU资源的语句，这是效果最为明显的解决方法，但同时成本也较高。
2、在操作系统级别使用renice命令提交LGWR进程优先级，如果存在多颗CPU，为减少LGWR进程轮询CPU时间，可以将其绑定在某颗CPU上运行。
3、在数据库级别设置隐含参数_high_priority_processes提高LGWR进程优先级。
RAC节点之间SCN同步
在RAC数据库中为了一致性读，需要将Commit SCN同步/传播到所有的节点上。SCN同步/传播的主要方法有两种：Lamport SCN 和 immediate commit propagation。其中immediate commit propagation这种方式就也被称为BOC（Broadcast On Commit）。
Oracle 10gR1 及以下版本默认使用Lamport SCN，Lamport SCN方式即一个节点上的commit SCN 不保证立刻同步/传播到所有节点，也就是说可能延时同步/传播，对于一些实时性要求高的RAC数据库Lamport SCN方式是不可取的。如果希望commit SCN 立刻同步/传播到所有节点，手动修改参数MAX_COMMIT_PROPAGATION_DELAY=1。
从Oracle 10gR2开始默认使用immediate commit propagation (BOC)，即一个节点上的commit SCN 立刻同步/传播到所有节点（受隐含参数_immediate_commit_propagation控制，默认为true）。
immediate commit propagation (BOC)的原理如下：
（1） user session 执行提交（commit），user session会通知LGWR进程将redo buffer中的信息写入到redo log file。
（2） LGWR进程收到user session通知后，将redo buffer中的信息写入redo log file，同时LGWR进程 将COMMIT SCN 同步/传播给远程的数据库实例的LMS 进程。
（3） 远程数据库实例的LMS将commit SCN同步到本地SCN，然后通知commit实例的LMS进程，表示SCN 同步已经完成。
（4） 当commit 实例的LMS进程接收到所有远程数据库实例的LMS进程的通知后，commit 实例的LMS进程再通知本地的LGWR 所有节点SCN同步已经完成。
（5） LGWR进程 在完成了IO 操作和LMS进程通知后，LGWR进程通知user session commit 成功。user session在没有收到LGWR进程通知前，一直处于等待log file sync。
RAC节点之间SCN传递的指标可以在AWR报告中观察，如下所示：

当log file sync等待事件是由于RAC节点之间SCN同步引起的，其解决方法如下：
1、检查LMS进程数量是否足够。
2、检查系统CPU资源是否足够。
3、检查RAC节点之间的私有通信是否正常。
4、设置隐含参数_immediate_commit_propagation为false，禁用immediate commit propagation特性。
RAC节点之间CR块传递
Oracle为了保证Instance Recovery实例恢复机制，而要求每一个current block在本地节点local instance被修改后(modify/update) 必须要将该current block相关的redo 写入到logfile 后（要求LGWR必须完成写入后才能返回)，才能由LMS进程传输给其他节点使用。如下图所示：

某客户数据库出现log file sync等待事件，正是由于这种机制引起的。AWR报告如下所示：



当出现这种情况时，其解决方法如下：
1、修改应用尽量减少跨节点取数据。
2、修改隐含参数_cr_server_log_flush为fasle（默认为true），关闭CR块节点传输特性。
控制文件争用
LGWR进程写日志的同时会在控制文件中记录写进度。当控制文件争用而出现enq: CF–contention等待事件时，前台进程可能会出现LOG FILE SYNC等待。AWR报告部分数据如下所示：

由于LGWR进程写日志的过程中需要更新控制文件。当RMAN操作比较频繁时（如利用RMAN批量删除归档），服务器进程也会更新控制文件，所以多个会话同时更新控制文件时可能会引起enq:CF–contention等待事件。当LGWR进程获得不了CF锁时，可能导致LOG FILE SYNC等待。这个案例再次表明了Oracle是一台巨大的同步机器，看起来风马牛不相及的东西，往往存在着相互因果关系。