问题背景：

客户反馈数据库反映缓慢，各模块均不能使用

1> 查看awr报告

问题分析：

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

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

当一个用户提交(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等选项

4.检查redo log file足够大，确保redo log file每15到20分钟切换一次。

可以通过如下公式计算平均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

在以前版本中，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;

此客户问题最终解决：

尝试增加一个redolog，512m，加了几分钟没有成功，可以判断磁盘I/O出问题，客户自行调整磁盘问题