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

duiego

lz很强大，提供了一种新的思路解决问题

oracledba

如果把日志和数据文件放在一起的话，而且设备IO到了瓶颈的时候，而且有很多的physical writes的时候，日志的写肯定会和DBWR产生竞争，导致的结果肯定是buffer busy wait的发生增多，因为在DBWR写完以前用户进程是无法执行对块的修改，要等buffer busy wait，日志切换在dml高发的时候也会加剧buffer busy wait，因为日志切换会触发lazy ckpt，ckpt会触发DBWR推脏块。select也会导致块的变化，如果块在被写入被锁的时候，select肯定会被阻塞，所以要尽量保证DBWR在该工作的时候做适当量的工作，而且DBWR依赖的设备不要被别的繁忙进程共享，除非有足够的硬件带宽。

vage

oracledba 发表于 2012-5-10 17:13
如果把日志和数据文件放在一起的话，而且设备IO到了瓶颈的时候，而且有很多的physical writes的时候，日志的 ...

问题不单是这样，主要是修改块时，加上Buffer Pin后，要先将Redo拷贝到共享池或Log Buffer，完成这一步，再修改Buffer Cache中的块，然后再释放Buffer Pin。

特别是向Log Buffer中传递Redo时，如果Log Buffer没空间了，要先触发LGWR写Redo File，腾出空间，再向Log  Buffer中传递。这时，Buffer Pin要一直加着。

所以，加快LGWR写Redo File的性能，就是让LGWR写的更快，常常保持Log Buffer中有空余空间。从而缩短某些时候Buffer Pin的持有时间，从宏观上减少Buffer Busy Waits等待。

oracledba

是吗？那你也应该看到log buffer space也增加很多啊

vage

oracledba 发表于 2012-5-10 17:42
是吗？那你也应该看到log buffer space也增加很多啊

是的og buffer space也有，但不多。主要还是log file sync。
加Buffer Pin的时间包含了从PGA中拷贝日志数据这点，是我回来在测试库上分析的。

oracledba

看log buffer space的数量以及时间的相对比例啊，如果次数很多而且等待过长，当然就是了，如果不的话，肯定是还是资源争用导致的。

vage

oracledba 发表于 2012-5-10 17:59
看log buffer space的数量以及时间的相对比例啊，如果次数很多而且等待过长，当然就是了，如果不的话，肯定 ...

只能在我自己的模拟环境中测试了。
我可以再测一下。
因为后来的跟踪结果，已经很明确发现Buffer Pin的时间包含了从PGA中拷贝日志数据，也就没再继续观察Log Buffer Space等待。

oracledba

这些都是内存对内存的操作，和IO操作比都不是一个量级的，我都怀疑log buffer space不是在你top 5里，占有的DB Time估计都不到个位数。

vage

oracledba 发表于 2012-5-10 18:32
这些都是内存对内存的操作，和IO操作比都不是一个量级的，我都怀疑log buffer space不是在你top 5里，占有的 ...

对了，我都有点忘了。这是年初的时候帮朋友那里处理的一个问题。Log buffer space肯定还是有的，但不明显，因为他数据库性能还可以。我让他把Redo挪到更快的存储里，只是从宏观上，减少了Buffer Busy Wiats的等待次数和时间。要说这样做的效果，用户哪边也没太感觉出来。

后来我还专门测试了好久，结果有点忘了。
我是这样测的，找两个会话：
1、一个会话反复Update一行
2、另一个会话反复Select同一块中的行
然后，将Redo放在较慢的存储上，和放在较快的存储上。
最后，比较Redo在慢存储上时和快存储上时Buffer busy waits的变化。

变化还是有点大的。有兴趣可以试试。我现在找不到有快、慢LUN的测试环境。

因为都只反复操作同一个块，因此都是逻辑读，可以排除“等待的减少是IO互相影响的少了”这种情况。
我觉得，Log Buffer Space在Redo放在慢存储上时，一定会比快存储上要严重。

我的测试脚本很简单：
脚本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;
/

oracledba

只反复操作同一个块可能会加剧buffer busy wait啊，dbwr可能因为select用户进程找不到reusable的块或者ckpt incremental ckpt在thread里前置ckpt的位置，照样会和dml的用户进程互锁那个集中更改的块啊？不管几个块的写，最终都是要到共享的设备上吧，总之top 5里肯定是造成问题的根本原因，绝大多数情况下没在top 5里的肯定不是造成问题的根本原因，你把日志放到别的地方去了反而解决了共享设备竞争的问题，还有一点，就是你的log file sync还有datafile parallel write的平均时间就可以说明是不是因为IO慢导致整个系统性能下降的原因，buffer busy wait只是连带出来的问题而已。