ITPub博客

首页 > 数据库 > Oracle > log file sync等待事件

log file sync等待事件

原创 Oracle 作者:DBA_每日记 时间:2019-11-14 13:10:01 0 删除 编辑

问题背景:

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


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出问题,客户自行调整磁盘问题


 


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/69950231/viewspace-2664077/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2019-10-09

  • 博文量
    75
  • 访问量
    30501