完全揭秘log file sync等待事件 – Oracle数据库管理 – ITPUB论坛－中国最专业的IT技术社区

guoyJoe ![1756815232778-83e5ce7f-3b78-4993-acff-4c339ebbb9a8.jpg

](http://www.itpub.net/home.php?mod=space&uid=28460966)!1756815232853-52045885-dd94-41cd-b8b0-812a38437e58.png

..!1756815232947-17e57bd1-188b-4350-9d79-d413b71c8305.gif!1756815233033-989aa5b9-21b8-4144-9faa-62bea3110961.gif!1756815233121-80185070-a2c3-4fbc-a572-304f098d84ce.gif!1756815233185-a5052d02-36dc-4c43-b977-a1c0bee1d9d7.png!1756815233263-36174a5e-806a-409c-b999-f1c136e895ab.png!1756815233332-6a6a187e-d0dc-4f46-bdaf-49e6d3428fdb.gif!1756815233387-ecef90a9-36bd-47cb-b6ae-b7dad4cb2b32.gif!1756815233449-8376767a-619f-4462-9c17-21e238dd89db.gif!1756815233513-507c6493-2e80-4cd1-864c-1925c2fbc8fd.gif!1756815233565-136e810a-b686-4733-9fcb-7853a6b2fe53.png

电梯直达![1756815233629-eda01d02-fec5-49d3-bb4c-397a0027178e.png

]() _1_ !1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-1 08:55_|只看该作者|只看大图!1756815233739-560f0bdd-4b5e-45e0-ae36-7fee1dd48742.gif

这里先引用一下tanel poder大师的图：

　　什么是log file sync等待事件呢？在一个提交（commit）十分频繁的数据库中，一般会出现log file sync等待事件，当这个等待事件出现在top5中，这个时侯我们需要针对log file sync等待事件进行优化，一定要尽快分析并解决问题，否则当log file sync等待时间从几毫秒直接到20几毫秒可能导致系统性能急剧下降，甚至会导致短暂的挂起。

　　我们一起来看下面几个关于log file sync等待事件的问题，欢迎大家一起来揭秘，相互学习，共同进步，彻底搞懂redo的机制。。。

****

1、log file sync的原凶到底是什么？

2、log file sync平均等待事件时间到7毫秒算正常情况？评估log file sync等待事件的指标是什么？

3、log file sync等待事件与log file parallel write等待事件之间有什么关系？（下面的图来自于awr报告中的等待事件，有没有发现什么？）

4、log file sync等待会导致buffer busy waits等待吗？

5、在实际的项目中碰到了大量的log file sync等待事件，如何优化呢？

****

Oracle

感谢vage 、 htyansp 、coloredice、yixin0358、westzq1984、yangfeng40 、MyDBNews、mlx_861201、zhouyf605_cu、nannan5000介绍了log file sync的等待事件。

这里特别感谢vage大师，总结的非常彻底！

非常感谢大家的积极参与，下面我挑出比较精彩的部分：

yixin0358

1、log file sync的原凶到底是什么？

频繁commit/rollback或磁盘I/O有问题，大量物理读写争用

westzq1984

2、log file sync平均等待事件时间到7毫秒算正常情况？评估log file sync等待事件的指标是什么？

对于OLTP，还算正常。但是对于批量处理，有点慢

指标是平均等待时间，以及AWR后续的Wait Event Histogram

vage

3、log file sync等待事件与log file parallel write等待事件之间有什么关系？（下面的图来自于awr报告中的等待事件，有没

有发现什么？）

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。

mlx_861201

4、log file sync等待会导致buffer busy waits等待吗?

我觉得还是有可能的，我假设一种情况，一个大事务commit，采用的是延迟提交，一个进程要读取延迟提交的块，需要修改数据

块事务槽提交和锁定状态，数据行的锁定状态，这个过程需要产生redo日志，假设此时log file sync 等待，同时另一个进程读取

同一个数据块，就产生了buffer busy waits等待事件，所以log file sync等待会导致buffer busy waits。

该解答未进过实验验证，只是一个假设，不是真理。

**（1）优化了redo日志的I/O性能，尽量使用快速磁盘，不要把redo log file存放在raid 5的磁盘上；

（2）加大日志缓冲区(log buffer)；

（3）使用批量提交，减少提交的次数；

（4）部分经常提交的事务设置为异步提交；

（5）适当使用NOLOGGING/UNRECOVERABLE等选项；

（6）采用专用网络，正确设置网络UDP buffer参数；

（7）安装最新版本数据库避免bug，具体bug修复的版本参考文档；

—

[本版精华]()

[使用道具]() [举报]()

_ 回复

nannan5000 ![1756815234021-7b282bb1-7198-4a4b-99e9-be47ab728d74.jpg

](http://www.itpub.net/home.php?mod=space&uid=16313247)多个岗位招聘..!1756815234095-c05b594c-65eb-439d-99d5-de28e6d7e0b4.gif!1756815234167-3cf846ac-da37-42fc-af88-aebb329cbcda.gif!1756815234243-bab87059-bcd3-479f-9bbc-44e8f52df0dc.gif!1756815234309-3a1d9bd0-b464-44ef-9311-02ef9b691e3c.gif!1756815234417-9c42f102-2aa2-44f0-8288-87bde63da501.gif!1756815234243-bab87059-bcd3-479f-9bbc-44e8f52df0dc.gif!1756815234506-694fb0b6-1ffe-4ca5-8ce1-e2ace83b8d63.gif!1756815234569-5a24fb73-686b-4178-934b-cc23b34e1153.gif!1756815234639-b9682bdc-609b-4753-8975-e5e3492a5a41.gif!1756815234715-ebee0bda-191d-4743-b61d-88a9ca83cb5f.gif

** [

**!1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-1 09:34_|只看该作者| 1、log file sync的原凶到底是什么？

频繁的commit

2、log file sync平均等待事件时间到7毫秒算正常情况？评估log file sync等待事件的指标是什么？

个人感觉小于10s，应用无压力即可。

应用有压力，就得根据实际情况分析了。

3、log file sync等待事件与log file parallel write等待事件之间有什么关系？（下面的图来自于awr报告中的等待事件，有没有发现什么？）

 总分关系，貌似开了并行写日志。

4、log file sync等待会导致buffer busy waits等待吗？

有可能性，毕竟lgwr最终是由磁头写上去，如果都在一个盘上必然受影响

5、在实际的项目中碰到了大量的log file sync等待事件，如何优化呢？

分析SQL，增加lgrw，增大redo

  具体案例具体分析

—

[使用道具]() [举报]()

mlx_861201 ![](http://www.itpub.net/home.php?mod=space&uid=11693228).!1756815234841-69d7d8a9-ad99-4c7c-91ef-7f5a66d9bb66.gif!1756815234891-7fa69046-0c22-40ba-91ca-5e4668b5fa2f.png

** [

**!1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-1 09:47_|只看该作者

粗略得回答下上述问题

1、log file sync的原凶到底是什么？

DBWTs进程将账数据写入到databuffer之前，会先将buffer cache数据写入到log file中，在写日志的时候DBWTS进程获得log file sync等待事件。

2、评估log file sync等待事件的指标是什么？

估算等待事件的指标是cpu时间片长短，在一个时间片内等待都属于正常范围。

3、log file sync等待事件与log file parallel write等待事件之间有什么关系？

DBWTs入到databuffer之前，会先将buffer cache数据写入到log file中，进程 LGWR写log buffer时log file sync等待事件

—

[使用道具]() [举报]()

zhouyf605_cu ![](http://www.itpub.net/home.php?mod=space&uid=20809130).

** [

**!1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-1 10:01_|只看该作者| 1、log file sync的原凶到底是什么？

磁盘I/O差,提交回滚频繁,redo buffer太大,日志量比较大

2、log file sync平均等待事件时间到7毫秒算正常情况？评估log file sync等待事件的指标是什么？

接近临界值,  系统是否有缓慢,有报错现象,是否出现在top 5,尽量不要超过10ms

3、log file sync等待事件与log file parallel write等待事件之间有什么关系？（下面的图来自于awr报告中的等待事件，有没有发现什么？）

一般会同时出现

4、log file sync等待会导致buffer busy waits等待吗？

5、在实际的项目中碰到了大量的log file sync等待事件，如何优化呢？

减少事务提交回滚,批量提交，将redo文件存放于高速硬盘,适当调整redo buffer,减少不必要的redo日志产生

—

[使用道具]() [举报]()

yangfeng40 ![1756815234951-2b110c6e-8afe-4e71-a261-3185bd843758.jpg

](http://www.itpub.net/home.php?mod=space&uid=7317332).!1756815235036-4cd1c0a9-2210-4dc7-aa83-23293f9d6b71.gif!1756815235102-94c7e42c-56d6-44cb-9fd2-859fe8a21944.gif!1756815235161-b9d072b3-bf36-4369-9584-0ddfdc4f2de8.gif!1756815235213-87c4c360-7865-4aa8-bdbc-ccce6b596439.gif!1756815235289-e70b93e9-828a-4c6e-9a58-9f515adfeb28.gif!1756815234243-bab87059-bcd3-479f-9bbc-44e8f52df0dc.gif!1756815235359-07e602ed-f94d-4fce-a840-d7315f6cd8ae.png

** [

**!1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-1 10:14_|只看该作者| 当user发出commit或rollback语句时会触发LGWR将重做记录写入redo log，这种触发LGWR的方式叫做同步写（sync writes）触发，而其他剩下的触发LGWR的方式叫做后台写（background writes）。log file sync等待事件只与sync writes有关，而log file parallel write等待事件只与background writes有关。

举例来说，一个user process可能进行一个非常大的事务，该事务会产生非常多的重做记录，从而引起很多的background writes。不过，用户session所运行的事务永远不会等待这些background writes完成以后才继续进行。一旦用户进程提交或回滚了事务，那么用户进程将触发LGWR，并且等待log file sync等待事件，一直等到LGWR将当前的重做记录，包括提交或回滚标记全都写入redo log里为止。在这个日志同步（log synchronization）的过程中（将log buffer中的重做记录写入redo log的过程通常也叫做日志同步过程），LGWR进程等待sync write结束，这时它的等待事件为：log file parallel write，而用户session也在等待sync write结束，而这时它等待的等待事件为：log file sync事件。

一旦进程开始等待log file sync事件，用两种方式退出该等待：

当log buffer里的重做记录都写入redo log以后，由LGWR触发，告诉前台进程。

当等待事件超时(通常是1秒)时，前台进程检查当前的log SCN，来判断当前进程的提交是否已经将重做记录写到了redo log里了。如果已经写好了，前台进程继续进行，否则前台进程继续等待log file sync事件。

通常，log file sync等待事件是可以不用过多考虑的。但是如果很多session都在等待该事件的话，就会影响系统的整体响应时间了

实际上，过于频繁的commit也正是log file sync等待事件出现的主要原因。而log file parallel write等待事件则总是会出现的，只要LGWR开始刷新log buffer，该进程就会等待log file parallel write等待事件，是不可避免的，不用过多关注该等待事件。同时，由于过多的commit，导致生成的重做记录的数量非常巨大

由此，要减小log file sync的主要方法就是减少commit或rollback的次数。

—

[使用道具]() [举报]()

westzq1984 ![](http://www.itpub.net/home.php?mod=space&uid=8242091)数据库管理员..!1756815235420-587c2c56-8061-4ea0-b660-806ee69fd3e3.gif!1756815233263-36174a5e-806a-409c-b999-f1c136e895ab.png!1756815235487-35ad9ac1-ac60-492c-af86-52bdb5f1c754.png!1756815235540-8cb2cd6f-ac18-4302-82c3-8ffeba39e654.png!1756815235604-e10d5b97-b288-405f-9920-48c988402ed2.gif!1756815235359-07e602ed-f94d-4fce-a840-d7315f6cd8ae.png!1756815235213-87c4c360-7865-4aa8-bdbc-ccce6b596439.gif!1756815235656-b31df21e-ac2a-4c2a-a111-a3e23ef80939.gif!1756815235714-fd26e531-7e84-471e-80a9-89686a095d7f.gif!1756815235767-13c42a3b-6513-4070-8753-b612aea8e8bb.gif

** [

**!1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-1 11:14_|只看该作者| 1、log file sync的原凶到底是什么？

主要是IO性能问题，过度的COMMIT蒋导致过碎的IO，放大log file sync

也可能是REDO BUFFER不够大，导致不能立刻分配出空间

也可能是主机CPU消耗尽，放大log file sync

2、log file sync平均等待事件时间到7毫秒算正常情况？评估log file sync等待事件的指标是什么？

对于OLTP，还算正常。但是对于批量处理，有点慢

指标是平均等待时间，以及AWR后续的Wait Event Histogram

3、log file sync等待事件与log file parallel write等待事件之间有什么关系？

log file parallel write 是后台等待事件，也就是LGWR的IO时间

log file sync 主要是前台进程等待事件，其是从COMMIT提出到确认COMMIT成功的时间。

其包含了IO时间，以及请求资源，CPU等时间

看看两个EVENT的平均等待时间，确定瓶颈是否在IO上

4、log file sync等待会导致buffer busy waits等待吗？

如果REDO与DATAFILE放在一起，那么DATAFILE读写的性能可能受到LGWR对磁盘写入的压力的影响，反过来也可能受到影响

如果分开放，应该不怎么会

5、在实际的项目中碰到了大量的log file sync等待事件，如何优化呢？

REDO单独存放在独立的IO设备上，使用裸设备，固态盘更好

优化应用，尝试减少物理读，减少COMMIT

导入LOB的时候可能考虑下COMMIT_WRITE，生产环境还是不敢用

查下MOS，确认是否可能是其他配置导致

—

[使用道具]() [举报]()

yixin0358 ![1756815235819-10d86e91-fbe1-49c2-8191-46feaa8e6891.gif

](http://www.itpub.net/home.php?mod=space&uid=7384387).

** [

**!1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-1 13:15_|只看该作者| 1、log file sync的原凶到底是什么？

频繁commit/rollback或磁盘I/O有问题，大量物理读写争用

2、log file sync平均等待事件时间到7毫秒算正常情况？评估log file sync等待事件的指标是什么？

单纯看7毫秒不能说明有问题，应该观察log file sync是否进入top 5的等待事件，是否占用较多DB time，对整个DB是否造成较大影响，是否引起大量enq: TX竞争等，同时应该对比系统的AWR基线，看看是否有较大差异。

3、log file sync等待事件与log file parallel write等待事件之间有什么关系？（下面的图来自于awr报告中的等待事件，有没有发现什么？）

前台用户进程发出commit通知后台进程LGWR写logfile，开始等待log file sync，后台进程LGWR开始等待log file parallel write，LGWR需要获得redo write latch后，才能写logfile，此操作为独占操作，可能其他session发出commit或者后台LGWR自身被触发写logfile(日志条目1m，log buffer 1/3，每隔3s，DBWR促使等）已经取得redo write latch，此时必须等待其完成，才能获得redo write latch。获得redo write latch后还必须获得所有的redo copy latch，暂时停止各session从PGA拷贝临时redo条目到log buffer的操作，才能开始写logfile，此时还要看CPU是否繁忙，如果太忙，等待CPU调度，还要消耗时间，logfile写入完成后，LGWR停止等待log file parallel write，并通知前台用户进程，停止等待log file sync。所以频繁的commit，必然会增加log file sync的平均等待时间。

4、log file sync等待会导致buffer busy waits等待吗？

有这种可能，cur块修改后，必须要将相关的redo写入logfile，才能别的session使用，尤其在RAC环境，这种影响会更大。

5、在实际的项目中碰到了大量的log file sync等待事件，如何优化呢？

减少commit，可以使用批量commit，改为批量commit，调整应用逻辑减少不必要的rollback，检查是否有按commit刷新的物化视图过度刷新

减少大事务，避免长时间占用redo write latch

优化SQL，减少全表扫描，减少物理磁盘I/O，降低系统负载

磁盘I/O有问题的，找出问题并解决

—

[使用道具]() [举报]()

coloredice ![1756815235874-636e9962-1af0-4646-b7b8-2d09d86cc090.jpg

](http://www.itpub.net/home.php?mod=space&uid=23258421).!1756815235359-07e602ed-f94d-4fce-a840-d7315f6cd8ae.png!1756815234569-5a24fb73-686b-4178-934b-cc23b34e1153.gif!1756815234841-69d7d8a9-ad99-4c7c-91ef-7f5a66d9bb66.gif!1756815235951-ba239da3-7b3e-42e9-bdbe-b3c0178b6e67.png!1756815236001-2e391fc7-e831-491d-9d36-cf0b5eb59083.png!1756815236054-99297926-8ca3-4749-b7a4-51fe42f5edb0.png!1756815236112-c60c1ede-cbe9-4857-9404-0a83af26494c.png!1756815236179-e425b30b-caae-4c1c-95fd-27a4a06f165c.png!1756815236245-58a9d7b7-24cc-4c04-bc86-a6213d13c97f.png

** [

**!1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-1 13:16_|只看该作者

当一个用户提交(commits)或者回滚(rollback),session的redo信息需要写出到redo logfile中

用户进程将通知LGWR执行写出操作,LGWR完成任务以后会通知用户进程.

这个等待事件就是指用户进程等待LGWR的写完成通知.

log file sync过程：

1.当你的session发出commit命令后，通知lgwr去写

LGWR 收集要写的相关redo信息

LGWR 开写

LGWR 写完，通知前台进程/session我写完了

唤醒前台

其中第一步可以分为：

1、LGWR正在写，等待LGWR把当前的写完

2、LGWR没有写则准备开始写，这里应该有个准备时间

3、LGWR接受写命令，检查要写的redo是不是别的session在写，如果在写则等待其写完

4、等待CPU调用，开写

1、log file sync的原凶到底是什么？

一般都是频繁的commit/rollback，io慢，从上面的步骤看也可能是其他的，比如操作系统的问题，进程过多，压力大之类的。

2、log file sync平均等待事件时间到7毫秒算正常情况？评估log file sync等待事件的指标是什么？

一般来说小于10毫秒都是正常的，个人感觉没什么指标，应用无压力怎么地都行，具体问题具体分享

—

[使用道具]() [举报]()

vage ![](http://www.itpub.net/home.php?mod=space&uid=321157).!1756815236306-3327e022-fb50-44b8-9af9-f51bca8ff9a5.png!1756815236363-0e931c8e-fb28-47ed-9dca-9c735b1e2910.gif!1756815236423-97168782-c9dd-47aa-a0dd-33f7021a08a0.png!1756815236478-84785de8-b8a2-478d-beda-1410c02439df.png!1756815233263-36174a5e-806a-409c-b999-f1c136e895ab.png!1756815235951-ba239da3-7b3e-42e9-bdbe-b3c0178b6e67.png!1756815235951-ba239da3-7b3e-42e9-bdbe-b3c0178b6e67.png!1756815235487-35ad9ac1-ac60-492c-af86-52bdb5f1c754.png!1756815236560-57b853e7-acec-436b-b686-713a50a57725.png!1756815236619-f54b9865-7bc2-4c40-b34b-3f841f79cb15.png

** [

**!1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-3 09:10_|只看该作者

1、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缓慢，拖慢了提交的过程。

2、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竞争一些会加巨的。

3、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。

4、控制文件I/O有可能影响log file sync。

此问题还没来得及深入研究，只是以前在阿里的数据库中观察到这一现象。

5、Log File Sycn和Buffer Busy Waits。

没有直接关系。是其他原因，比如Redo相关的Latch，导致了Log File Sync和Buffer Busy Waits同时出现。此时Log File Sync和Buffer Busy Waits都不是原凶，真正的原凶是Log Buffer访问性能下降。

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

Redo是Oracle重要的优化对象，DBWR的工作原理我已经破译的差不多了，下一目标就是LGWR，可惜还没来得及搞，以后有时间再为大家详细总结。

—

[使用道具]() [举报]()

guoyJoe ![1756815232778-83e5ce7f-3b78-4993-acff-4c339ebbb9a8.jpg

](http://www.itpub.net/home.php?mod=space&uid=28460966)!1756815232853-52045885-dd94-41cd-b8b0-812a38437e58.png

** [

**!1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-3 16:35_|只看该作者

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

—

[使用道具]() [举报]()

guoyJoe ![1756815232778-83e5ce7f-3b78-4993-acff-4c339ebbb9a8.jpg

](http://www.itpub.net/home.php?mod=space&uid=28460966)!1756815232853-52045885-dd94-41cd-b8b0-812a38437e58.png

** [

**!1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-3 17:03_|只看该作者

****

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.

—

[使用道具]() [举报]()

guoyJoe ![1756815232778-83e5ce7f-3b78-4993-acff-4c339ebbb9a8.jpg

](http://www.itpub.net/home.php?mod=space&uid=28460966)!1756815232853-52045885-dd94-41cd-b8b0-812a38437e58.png

** [

**!1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-3 17:15_|只看该作者

****

—

[使用道具]() [举报]()

htyansp ![](http://www.itpub.net/home.php?mod=space&uid=24636982).!1756815235036-4cd1c0a9-2210-4dc7-aa83-23293f9d6b71.gif!1756815235289-e70b93e9-828a-4c6e-9a58-9f515adfeb28.gif!1756815234569-5a24fb73-686b-4178-934b-cc23b34e1153.gif!1756815234506-694fb0b6-1ffe-4ca5-8ce1-e2ace83b8d63.gif!1756815234841-69d7d8a9-ad99-4c7c-91ef-7f5a66d9bb66.gif!1756815235604-e10d5b97-b288-405f-9920-48c988402ed2.gif!1756815235359-07e602ed-f94d-4fce-a840-d7315f6cd8ae.png!1756815236752-251d7997-884f-4414-a4fa-0687b955f2c4.gif!1756815236814-0247ebe4-7fde-4cc1-8373-31577cedb43a.gif!1756815236814-0247ebe4-7fde-4cc1-8373-31577cedb43a.gif

** [

**!1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-3 21:17_|只看该作者| log file sync 导致 buffer busy wait 和 gc buffer busy

来自maclean

OLTP类型的小DML操作一般都会是immediate block cleanout的，这要求在commit之前对block做change kcbchg

在commit kcrf_commit_force完成前都不会释放对该block buffer的buffer pin

由上述2点造成的buffer pin最终会影响select和其他insert/update/delete 形成buffer busy wait

由于慢的lgwr写redo log会造成 kcrf_commit_force commit的缓慢，表现在等待事件上就是log file sync

由于block cleanout时pin block buffer且commit 慢，则会导致更长时间的buffer busy wait

若log file sync是由lgwr 写redo log慢(log file parallel write)引起的，则它的另一个效应就是buffer busy wait增多

若看到AWR中log file sync+buffer busy wait是主要等待事件，则优先解决log file sync ，因为buffer busy wait实际可能是受害者

gc buffer busy/gcs log flush sync与log file sync

http://www.askmaclean.com/archiv … -log-file-sync.html

RAC中的gc current block busy与redo log flush

As Maclean Said:

gc current block busy 等待是RAC中global cache全局缓存当前块的争用等待事件，该等待事件时长由三个部分组成：

Time to process current block request in the cache= (pin time + flush time + send time)

gc current block flush time

The current block flush time is part of the service (or processing) time for a current block. The pending redo needs to be flushed to the log file by LGWR before LMS sends it. The operation is asynchronous in that LMS queues the request, posts LGWR, and continues processing. The LMS would check its log flush queue for completions and then send the block, or go to sleep and be posted by LGWR. The redo log write time and redo log sync time can influence the overall service time significantly.

flush time 是Oracle为了保证Instance Recovery实例恢复机制，而要求每一个current block在本地节点local instance被修改后(modify/update) 必须要将该current block相关的redo 写入到logfile 后（要求LGWR必须完成写入后才能返回)，才能由LMS进程传输给其他节点使用。

而gc buffer busy acquire/release 往往是 gc current block busy的衍生产品，当同一实例内的多个进程并发地访问同一个数据块时，首先发起的进程将进入 gc current block busy的等待，而在 buffer waiter list 上的后续进程会陷入gc buffer busy acquire/release 等待(A user on the same instance has started a remote operation on the same resource and the request has not completed yet or the block was requested by another node and the block has not been released by the local instance when the new local access was made)，这里存在一个排队效应，即 gc current block busy是缓慢的，那么在排队的gc buffer busy acquire/release就会更慢：

Pin time = (time to read the block into cache) + (time to modify/process the buffer)

Busy time = (average pin time) * (number of interested users waiting ahead of me)

不局限于current block （reference AWR Avg global cache current block flush time (ms)), cr block(Avg global cache cr block flush time (ms)) 也存在flush time。

可以通过设置_cr_server_log_flush to false(LMS are/is waiting for LGWR to flush the pending redo during CR fabrication. Without going too much in to details, you can turn off the behaviour by setting _cr_server_log_flush to false.) 来禁止cr server flush redo log，但是该参数对于current block的flush time无效，也强烈不推荐使用。

以上告诉我们 IO 在RAC中是十分重要的，特别是log file的write性能，其重要性不亚于CPU 和 Interconnect network。

—

[使用道具]() [举报]()

tolilong ![](http://www.itpub.net/home.php?mod=space&uid=24237320)数据库管理员.!1756815232853-52045885-dd94-41cd-b8b0-812a38437e58.png

..!1756815236939-67de63da-8f90-439d-8cf1-900dbd80ccc5.gif!1756815236990-4ea79d7e-b1a2-427c-a3ee-ef1fa050a107.png!1756815237076-6d89a82a-aae3-4144-a889-c7dddc683d98.gif!1756815237138-cef957e8-f12c-44f6-80ba-a0864dd7a814.png!1756815237205-dc049369-02bc-4592-9a2b-1382bc7849e4.gif!1756815236423-97168782-c9dd-47aa-a0dd-33f7021a08a0.png!1756815235487-35ad9ac1-ac60-492c-af86-52bdb5f1c754.png!1756815237272-f2b87a23-d986-44c4-a1aa-c296e38421d7.png!1756815237272-f2b87a23-d986-44c4-a1aa-c296e38421d7.png!1756815237338-fca16e0e-7304-4de8-aa73-741ec77ba21d.gif

_2_ !1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-1 09:12_|只看该作者| 先抢个位置,!1756815237404-d2d41187-eac8-4544-804b-5c8b2f209e85.gif

—

[使用道具]() [举报]()

kkaaron ![1756815235819-10d86e91-fbe1-49c2-8191-46feaa8e6891.gif

](http://www.itpub.net/home.php?mod=space&uid=23190213).

_3_ !1756815233681-615a50cb-37e5-4504-9ed4-5015854c2130.gif_发表于 2013-4-1 09:16_|只看该作者| 占位再说

—