原因3：用户提交过于频繁导致log file sync
在这种情况下，过多的 commit 活动可能会导致性能问题，因为把 redo 从日志缓冲区刷新到重做日志可能会导致等待’log file sync’。
如果’log file sync’的平均等待时间比’log file parallel write’高很多，这意味着大部分时间等待不是由于等待 redo 的写入，因而问题的原因不是 IO 慢导致。，其他时间可能是 CPU 活动竞争，而且是过多的 commit 导致的最常见的竞争。此外，如果’log file sync’的平均等待时间低，但等待次数高，那么应用程序可能 commit 过于频繁。
在 AWR 或 Statspack 报告中，如果每次 commit/rollback 的平均 user calls（”user calls/(user commits+user rollbacks)”） 小于 30， 表明 commit 过于频繁。
建议
- 如果有很多短事务，看是否可能把这些事务组合在一起，从而减少 commit 操作。 因为每一个 commit 都必须收到相关 REDO 已写到磁盘上的确认，额外的 commit 会显著的增加开销。虽然 Oracle 可以将某些 commit 组合在一起，通过事务的批处理来减少commit的总体数量还是可以带来非常有益的效果。
- 看看是否有操作可以使用 COMMIT NOWAIT 选项 （使用前应明白该选项会带来的后果）。
- 看看是否有操作可以使用 NOLOGGING/ UNRECOVERABLE 选项完成（在不追求可恢复的情况下）。
经过已经分析，大概可以得出一个思路，尽量结合与lgwr有关的等待事件一起结合起来定位问题，此时应该检查awr或者statspack的等待事件。
11g新特性：
在oracle 11.2版本中引入了 Adaptive Log File sync，由参数_use_adaptive_log_file_sync控制，该参数在11.2.0.1和11.2.0.2默认设置为 false。
从 11.2.0.3 开始默认是 true。 当启用时，Oracle 可以在两种方法之间切换：
Post/wait，传统发布写重做日志完成的方法
Polling，一种新的方法，其中前台进程会检查 LGWR 是否已写完成。
该特性在一定情况下也会造成log file sync等待大量增加。
当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进程传输给其他节点使用。
