讨厌香草冰激凌的汽车与Buffer busy wiats的故事

vage

oracledba 发表于 2012-5-11 09:09
只反复操作同一个块可能会加剧buffer busy wait啊，dbwr可能因为select用户进程找不到reusable的块或者ckpt ...

这样反复修改、查询内存中的同一个块，一定会有buffer busy wait。
在这样的测试中，Redo IO的快慢，对于buffer busy wait影响还是很大的。
具体是不是log  buffer space等等哪个待等事件的问题，这个我之前也没注意，还需要再测试。

我主要想根据这样一个简单的测试，两个会话反复修改、查询内存中的同一个块（主要的等待将是buffer busy wait和CBC Latch），观察将Redo FIle放在快或慢的设备中，Redo IO对buffer busy wait的影响。

oracledba

如果你说IO对bbw有影响，这是100%对的，你遇到的问题，我肯定是IO的问题，但是说如果单纯的redo io慢会导致bbw，这肯定是不对的，牵强的说redo io慢而redo buffer小会导致问题，这个我觉得没问题，而且我觉得如果真的是redo buffer小而redo io慢，那么再没传递到buffer busy wait以前，应该很多问题都爆发了，比如我随便说的log buffer space，觉得还会有相关latch的竞争，比如redo copy，redo allocation等，但是绝对不只是是buffer busy wait在top 5里。如果你的假设成立只因为redo io慢，会导致对比较热的共享资源的使用要付出更大量级的成本，那Oracle这个软件有点可怕了，因为redo是必须要做的而且是超级昂贵的。

vicky987654321

vicky987654321

shentao19890909

佩服楼主的精神，如果有时间的话，仔细去研究oracle技术是一间非常幸福的事情

vage

oracledba 发表于 2012-5-12 17:50
如果你说IO对bbw有影响，这是100%对的，你遇到的问题，我肯定是IO的问题，但是说如果单纯的redo io慢会导致 ...

我遇到的问题其实就是Buffer Busy Waits、CBC Latch有点高，调调SQL就好了。
查看ASH中的资料，发现每次日志切换时，Buffer Busy Waits更高。但调SQL后，已经不影响应用了，客户也已经很满意了。

后面是我对Buffer Busy Waits的进一步分析，我发现Buffer Pin的流程是这样的：
（1）、加Cache buffers chains latch(下文中简称为CBC Latch)
（2）、加Buffer Pin
（3）、释放CBC Latch。
（4）、将Redo信息拷贝到共享池的公有Redo区，或Log Buffer中。
（5）、修改Buffer中的内容
（6）、加CBC Latch
（7）、释放Buffer Pin
（8）、释放CBC Latch
在这8步环节中，我觉得第4步“拷贝Redo信息到共享池的公有Redo区，或Log Buffer中”，是可以优化一下的。
最简单的优化方式就是使用更快的设备存放Redo文件。通过减少log buffer space，加快第4步的操作，从而缩短从加Buffer Pin到释放Buffer Pin的时间。

另外，一个进程因为Log Buffer Space而等待，说明它已经加上了Buffer Pin没有释放，所有查询、修改同一内存块的进程都会因为Buffer Pin而等待Buffer Busy Waits。
假设应用的访问在某一时间比较集中。很可能出现这样的情况，一个进程等待Log Buffer Space，它的Buffer Pin阻塞了10个进程对相同内存块的访问。按照Oracle的统计方式，那么，Log Buffer Space就只有一次，Buffer Busy Waits会有10次。所以，在某些时间Buffer Busy Waits很高，Log Buffer Space不明显是很正常的。

oracledba

我就怕列一二三的，就像你自己说的，这些都是你自己发现的，咋发现的？一个DML的过程，绝对比你发现的复杂的多的多，buffer busy wait高是IO的问题，如果按照你说的一个块那么热那肯定CBC也很高了，一个cbc latch也不只是保护一个块，您怎么不能按照别人的思路想一想呢，我肯定你的问题是IO的问题引起的，跟单纯提高redo IO没关系，如果redo io快了，数据还很慢，照样出这样的问题，你说的一个等待导致别的进程一起buffer busy wait，首先每个事件都有time out吧，其次难道一个获得不了资源的进程，正好会挡住别人的都停在这一个进程上嘛？再多的buffer busy wait是不是在TOP 5里也还是一行啊？您玩蝴蝶效应呢？如果真的redo造成的问题，肯定在top 5里会有redo的问题，你这这个awr的top 5都能猜出来，第一第二肯定是log file syn和db file sequential read，第三是CPU time，第四或者第五buffer busy wait，如果有别的你肯定印象会很深刻。从更高的角度想，我在以前发的也说过了，如果在别的资源充足，但是因为redo io慢而导致整体系统的dml都出问题，这个oracle是不是有巨大的问题啊？如果在这个过程中有别的资源成为了瓶颈，那awr肯定能看出来，这就是很早的时候说的为什么说3m log buffer就够了的观点是错误的。
您先整实验吧，把log buffer开够了，数据文件不要有io瓶颈，日志文件存在瓶颈，看看什么结果吧，肯定和你想的不一样，咱俩别空谈了，从非技术角度讲，我觉得解决问题的方法最好简单化，因为如果自己把解决过程和分析人为的复杂化，对快速解决问题是不利的，DBA是实践的科学，我们不是科学家，就算是，也不是研究或者猜别人产品机制的科学家，起码我不是，我只是一个支持企业运营的DBA，我年轻时和一个年纪很大的美国的oracle on site support聊过，他在oracle做support很久，真正接触过就知道他对产品的理解的高度是多高，我跟他说我看过DSI，他就浑身哆嗦着笑，说他从8以后的就没看过了，因为没啥意义。。。我最佩服的就是Tom，从来没看见过他用一些稀奇的trace dump和隐含参数什么的把整个东西说的高深莫测的，但是结果呢？所有的问题都是深入而浅出，这就是对一个产品的理解的高度，这个就是我想达到的境界。极致不是极端。真正的oracle internal你我连皮毛都搞不清，还是从表象出发，简单思考，快速解决问题，这才是做DBA的王道。

oracledba

吃饭的时候又想起一个bbw的问题，记得很早在一个10的系统上遇到过大量的bbw，而且看awr里每秒的consistent read要高block change非常非常多，也问过做系统的，证明肯定系统不会有大量的并发更改，也因为版本的问题，也不可能是并发load cache导致的，因为10以后应该是read by other sessions，我唯一能改的就是dbwr，但是当时不确定，因为Oracle一直吹的就是写不阻碍一直读，而且我肯定用户进程的写不会阻碍用户进程的读，bbw只是一个事件而不是统计，如果理想情况下，这个可以是趋于0，改完dbwr后，发现bbw消失了，所以当时深刻的印象是dbwr的操作是昂贵的，他会阻碍读，直到很久以后没事看asktom的时候，又想起以前那次，http://asktom.oracle.com/pls/ape ... 1860222500346889715，reading sessions would not experience a buffer busy wait due to a write - but they can experience buffer busy waits (the cache might be full and dbwr needs to clean it out a bit for example, or read by other session)，所以如果dbwr低效工作，对系统影响是巨大的，针对这个帖子的问题，我还是那个观点，dbwr的行为是不适当的，但是把redo file放到别的地方，分散了io压力，歪打正着提高了dbwr。

vage

oracledba 发表于 2012-5-13 20:00
吃饭的时候又想起一个bbw的问题，记得很早在一个10的系统上遇到过大量的bbw，而且看awr里每秒的consistent  ...

DBWR以及数据文件设备的快慢对Buffer Busy Waits有影响这是确定的。关键是Redo对Buffer Busy Waits的影响，这个测试我已经做过了，但现在我手边没有快速些的存储设备，无法再重做这个测试，测试方法如下：

脚本1：
declare
      j number;
begin
for i in 1..3000000 loop
      select id into j from a1 where rowid='AAAChqAAEAAAAAMAAA';
end loop;
end;
/

脚本2：
反复Update的脚本：
begin
for i in 1..3000000 loop
      update a1 set id=id+0 where rowid='AAAChqAAEAAAAAMAAA';
end loop;
commit;
end;
/

两个脚本，脚本1反复查询一行，脚本2反复修改同一块、同一行（也可以修改同一块中不同行）。

以上两个脚本在不同会话中同时执行，然后，将Redo放在不同速度的存储中，观察v$sessin_event中的Buffer Busy Waits。
我以前做的，Redo在快速些的存储设备中，Buffer Busy Waits会减少。减少的比例，跟Redo存储的快慢有关。

如果有环境，可以试一下。如果说Redo文件写的快慢和Buffer Busy Waits无关，哪上面这个测试如何解释？

另外，“Oracle一直吹的就是写不阻碍一直读”，起码在Buffer Cache中，对同一个Buffer来说，是正好相反的，读不阻塞写，写马上会阻塞读。

oracledba

我服你了，你的lgwr写的凶会使iowait变高，如果你把数据文件也放在一起肯定会有影响的，你把awr放上来吧，而且lgwr只是后台进程，用过进程正常的不会触发lgwr，如果buffer够，也不会等lgwr，对不对？如果用户进程对lgwr写有依赖，那对性能的影响是巨大的，这道理简单吗？
而且你说的写马上阻碍读是啥意思？用户写会阻碍别的用户进程的读？？？