log file sync（ 日志文件同步）
当一个用户提交或回滚数据时， LGWR 将会话期的重做由 Log Buffer 写入到重做日志中，
LGWR 完成任务以后会通知用户进程。 日志文件同步等待（ Log File Sync） 就是指进程等待LGWR 写完成这个过程； 对于回滚操作，该事件记录从用户发出 rollback 命令到回滚完成的时间。
如果该等待过多，可能说明 LGWR 的写出效率低下，或者系统提交过于频繁。 针对该问
题，可以关注 log file parallel write 等待事件，或者通过 user commits,user rollback 等统计信息观察提交或回滚次数。
可能的解决方案主要有：
（1）提高 LGWR 性能， 尽量使用快速磁盘，不要把 redo log file 存放在 RAID5 的磁盘上；
（2）使用批量提交；
（3）适当使用 NOLOGGING/UNRECOVERABLE 等选项。
可以通过如下公式计算平均 Redo 写大小：
avg.redo write size = (Redo block written/redo writes)*512 bytes
如果系统产生 Redo 很多，而每次写的较少，一般说明 LGWR 被过于频繁地**了。 可
能导致过多的 Redo 相关 Latch 的竞争， 而且 Oracle 可能无法有效地使用 piggyback 的功能。从一个 Statspack 报告中提取一些数据来研究一下这个问题。
Report 概要信息如下
注意以上输出信息，这里 log file sync 和 db file parallel write 等等待事件同时出现，那么
可能的一个原因是 I/O 竞争导致了性能问题， 实际用户环境正是日志文件和数据文件同时存放在 RAID5 的磁盘上，存在性能问题需要调整。
（RAID 5不对数据进行备份，而是把数据和与其相对应的奇偶校验信息存储到组成RAID5的各个磁盘上，并且奇偶校验信息和相对应的数据分别存储于不同的磁盘上。当RAID5的一个磁盘数据损坏后，利用剩下的数据和相应的奇偶校验信息去恢复被损坏的数据。）
统计信息如下：
-------------------------------------------------------------
根据统计信息可以计算平均日志写大小：
avg.redo write size = (Redo block written/redo writes)*512 bytes
= ( 93,853 / 14,572 )*512
= 3KB
这个平均值过小了，说明系统的提交过于频繁。从以上的统计信息中， 可以看到平均每
秒数据库的提交数量是 9.6 次。 如果可能， 在设计应用时应该选择合适的提交批量，从而提高数据库的效率。
由于过度频繁的提交， LGWR 过度频繁的**，看到这里出现了 redo writing 的 latch 竞
争。以下是一则 ASH 报告中显示的 Log File Sync 等待信息，注意到其 Parameter 1 是 Buffer#，Parameter 2 代表 Sync SCN，也就是同步的 SCN。 Log File Sync 以 SCN 为节点，以 Buffer 号为起始，不断将 Log Buffer 的内容写出到日志文件上来：
Oracle 11g 中新特性
Adaptive Log File Sync - 自适应的Log File Sync
关于 Log File Sync 等待的优化，在Oracle数据库中一直是常见问题，LOG FILE的写出性能一旦出现波动，该等待就可能十分突出。
在Oracle 11.2.0.3 版本中，Oracle 将隐含参数 _use_adaptive_log_file_sync 的初始值设置为 TRUE，由此带来了很多 Log File Sync 等待异常的情况，这个问题虽然由来已久，但是仍然有很多Oracle的用户并不知情。
当前台进程提交事务（commit）后，LGWR需要执行日志写出操作，而前台进程因此进入 Log File Sync 等待周期。
在以前版本中，LGWR 执行写入操作完成后，会通知前台进程，这也就是 Post/Wait 模式；在11gR2 中，为了优化这个过程，前台进程通知LGWR写之后，可以通过定时获取的方式来查询写出进度，这被称为 Poll 的模式，在11.2.0.3中，这个特性被默认开启。这个参数的含义是：数据库可以在自适应的在 post/wait 和 polling 模式间选择和切换。
_use_adaptive_log_file_sync 参数的解释就是： Adaptively switch between post/wait and polling ，正是由于这个原因，带来了很多Bug，反而使得 Log File Sync 的等待异常的高，如果你在 11.2.0.3 版本中观察到这样的表征，那就极有可能与此有关。
在遇到问题是，通常将 _use_adaptive_log_file_sync 参数设置为 False，回归以前的模式，将会有助于问题的解决。
关闭：
SQL> alter system set parallel_adaptive_multi_user=false scope=both;
System altered.
SQL> show parameter adaptive;
NAME TYPE
------------------------------------ ----------------------
VALUE
------------------------------
parallel_adaptive_multi_user boolean
FALSE