log file sync
	1、事务过度的提交，即应用程序过度commit或者rollback。
		事务过度提交事务过度提交是引起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等待事件的方法之一。
	2、存储I/O资源紧张，导致lgwr进程写速度缓慢。
		存储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 from v$event_histogram 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，只保留一组。

![](http://img.blog.itpub.net/blog/2022/10/11/e1a229b19c588d95.png?x-oss-process=style/bb)

图一

![](http://img.blog.itpub.net/blog/2022/10/11/d044092c0cc8cb8e.png?x-oss-process=style/bb)

图二
	3、CPU资源紧张，lgwr进程获得不了响应的CPU时间片。
		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进程优先级。_

![](http://img.blog.itpub.net/blog/2022/10/11/13f1038967b31d66.png?x-oss-process=style/bb)
			图一

![](http://img.blog.itpub.net/blog/2022/10/11/c491d3f1e9dc51cd.png?x-oss-process=style/bb)

图二

![](http://img.blog.itpub.net/blog/2022/10/11/306f11a874934565.png?x-oss-process=style/bb)

图三
	4、RAC节点之间SCN同步。
		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特性。_

![](http://img.blog.itpub.net/blog/2022/10/11/2280a633561d7b11.png?x-oss-process=style/bb)
			图一
	5、RAC节点之间CR块传递。
		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块节点传输特性。

![](http://img.blog.itpub.net/blog/2022/10/11/4288c980fea7dcd7.png?x-oss-process=style/bb)

图一

![](http://img.blog.itpub.net/blog/2022/10/11/dfc8a442012c1b1b.png?x-oss-process=style/bb)

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

![](http://img.blog.itpub.net/blog/2022/10/11/1bc3f3e51ecc91cb.png?x-oss-process=style/bb)

图一

ITPub博客

log file sync等待事件处理思路

最新文章