log file sync等待事件

问题背景： 客户反馈数据库反映缓慢，各模块均不能使用 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出问题，客户自行调整磁盘问题