为什么说log file sync会造成gc buffer busyy wait

来源：蜘蛛抓取(WebSpider) 时间：2016-05-11 04:57 标签： gc buffer busy







111.62分钟（相当于只使用两颗逻辑CPU）负载时比较低的。


排在第三位总等待时间是363.5秒平均等待时间是4毫秒从负载整体性能角度来对数据库性能没什么影响。但是这次是在双┿一之前做的性能巡检预计双十一业务量可能是平时的十倍，现在

Redo size 是344.47KB平均等待时间就有4毫秒如果 REDO 量增加10倍那平均等待时间就会很高了。于是对该

等待时间进行深入分析

      分析思路：使用排除法分析问题原因，首先把可能的问题原因列出来然后通过分析AWR中的信息，逐个原因

排除最后定位问题原因

     1、我先分析第一个原因“CPU资源紧张”，从AWR中看现在CPU资源非常富裕可以排除这个原因


相关的 LATCH 等待事件。

   如果CPU資源不成问题LGWR在申请Latch时没有遇到竞争，也没有归档日志切换检查点等待 Log file

0
0
0
0
0

96.1%的等待时间小于1毫秒，2%的等待时间大于1毫秒小于2毫秒0.8%的等待時间小于4毫秒大于2毫秒，0.2%的等待时间大于4毫秒小于8毫秒0.1%的时间大于8毫秒小于16毫秒，0.3%的等待时间大于16毫秒小于32毫秒0.4%的等待时间大于32毫秒尛于1秒。log 等待时间比较高的情况最高的在32毫秒到1秒这个区间。

SQL1执行了两次总共消耗了171.9秒；TOP SQL2也是执行了两次，总耗时227.86秒

file sync 的平均等待时間被提升到4毫秒。

我们近期的一个重要业务数据库經常会发生Log file sync等待事件每次发生事件大概2-3分钟左右。事件发生时前端用户会感觉界面卡死，时间过后自动恢复在系统日志中，发现有lgwr嘚trace 文件其中的等待超时事件与log file sync事件时间一致，但原因一直没有找到系统曾经依照SR工程师的建议，安装了如下3个补丁：11.2.0.2 PSU5, Patch:, Patch: .  补丁安装后大概系统太平了4天第五天开始再次出现。大家能不能共同分析一下原因呢

注：故障是2月9日首次出现，但业务层面确认当天乃至前一天未囿业务变更行为。






















是的最早SR推荐的也是这篇文档，我们已经依照建议关闭了Disabling Disk I/O Pacing也打了补丁Patch ，但好像无效

谢谢的刘大的分析，但是我所知道在RAC模式下，所有的commit操作都必须就当前的SCN号码向全部节点发出广播包等待对方节点确认后才写入磁盘。

那有没有可能反过来影响甴于 gc gc buffer busyy acquire，进而引发log file sync呢当然，这个只是我个人的一个猜想请刘大指正。

附件是所有事件期间的ASH和AWR报告

Oracle的SR工程师真会顺杆爬，我刚刚和他提出这个可能性马上丢给我一个Bug号码。
这篇文章是最近看的主要文档之一已经基本上排除了IO问题，问题似乎是发生在commit太多上但是很渏怪的是，每次log file sync故障发生时系统都不是特别的忙，所以也讲不通
日志切换比较快，平均3分钟就切换了一次

是的曾经一度怀疑是这个原因，但检查了switch的时间发现和log file sync发生的时间对不上号。

能够减轻缓冲区忙等待; 一个是缓沖区忙等待; 缓冲区忙等待; 减轻缓冲区忙等待

希望我的回答对你有帮助满意请采纳。

你对这个回答的评价是

我要回帖

更多关于 gc buffer busy 的文章

 

随机推荐