原贴地址：http://www.itpub.net/thread-1777234-1-1.html 谢谢
这里先引用一下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等待事件，如何优化呢？
讨论时间：2013.4.1--2013.4.16
活动奖励：活动接受后将会抽取三位会员赠送《Oracle DBA手记3 --数据库性能优化与内部原理解析》一本。
感谢vage 、 htyansp 、coloredice、yixin0358、westzq1984、yangfeng40 、MyDBNews、mlx_861201、zhouyf605_cu、nannan5000介绍了log file sync的等待事件。
这里特别感谢vage大师，总结的非常彻底！
本次活动中奖者是：westzq1984、mlx_861201、yixin0358
非常感谢大家的积极参与，下面我挑出比较精彩的部分：
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。
该解答未进过实验验证，只是一个假设，不是真理。
5、最后我总结了大家对log file sync等待事件的优化方案：
（1）优化了redo日志的I/O性能，尽量使用快速磁盘，不要把redo log file存放在raid 5的磁盘上；
（2）加大日志缓冲区(log buffer)；
（3）使用批量提交，减少提交的次数；
（4）部分经常提交的事务设置为异步提交；
（5）适当使用NOLOGGING/UNRECOVERABLE等选项；
（6）采用专用网络，正确设置网络UDP buffer参数；
（7）安装最新版本数据库避免bug，具体bug修复的版本参考文档；
来自白大师（白鳝）对log file sync等待事件优化的总结，供各位puber们学习参考：
一、 log file
sync平均等待事件时间超过7ms，如果等待时间过长，说明log
write每次写入的时间过长，如果能够优化redo日志文件存储，使之存放在更快的磁盘上，就可以减少这个等待事件的单次等待时间。（RAID
5--> RAID 10）
当无法通过优化redo日志的I/O性能来解决问题，或者优化了redo日志的I/O性能后还是无法达到我们的预期，那么该如何处理呢？
二、 有经验的DBA可能会建议加大日志缓冲区（log
buffer）。提到加大日志缓冲区，可能有些朋友就会感到疑惑，redo日志文件写等待时间长怎么会和日志缓存冲区直接关联起来呢？实际上这个问题解释起来一点也不难，如果数据文件的I/O性能有问题，平均单块读的等待时间偏长，那么通过加大db
cache来减少I/O总次数，从而达到优化I/O的效果。加大日志缓存区的原理也是一样的，这样可以使
日志缓存中的存储更多的redo日志数据，从而减少由于redo日志缓存区不足而产生lgwr写操作的数量，使平均每次写入redo日志文件
的redo字节数增加，从而减少redo的I/O次数，进而达到优化log file sync等待事件的目的。
三、如果上述两种方法都不行时，还有一种方法：就是减少提交的次数。如果提交过于频繁，那么无论怎么优化都无法彻底解决问题。
通过加大一次提交记录的数量，减少提交批次，可以有效地减少log file sync等待时间。采用此方法就意味着需要对应进行较大的调整，甚至要对应用架构做出修改，这种修改的代价将十分巨大。
四、还有一个方案可以优化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.