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

yuwhich · 发表于 2012-3-2 10:47

好文好文

vage · 发表于 2012-3-2 14:00

sunyunyi 发表于 2012-3-2 10:06
buffer busy waits 由两种情况引起，1：需要被访问的数据块正在被读入内存 2：buffer lock 存在不兼容模式。 ...

有一点可能是没说清楚，没有发现DML，并不等于没有DML。
这涉及到buffer busy waits的另外一个问题，也就是你所提到的第二点：

2：buffer lock 存在不兼容模式。

此处的不兼容模式，如果只理解为读、写（也就是共享与独占），或是写、写（独占与独占）之间的不兼容，就太简单了点。这已经是多年前无数前辈已经验证的观念了。但，是多年前。
Oracle在进步，9i, 10g, 11g, 12c（还不确定），这么多年来，这么多版本下来，Oracle内部的改动，已经不是一点半点。你看Larry Ellision像是吃老本的人吗。拿以前的理论，来推论现在的问题，是有点危险的。其实软件的进步，我们不能只学习操作层面的东西，内核的变动才是关键。

比如这个Buffer busy waits，在10G以后的版本做个测试便知。
比如在会话1运行如下脚本：
declare
j number;
begin
for i in 1..3000000 loop
select id into j from a1 where rowid='AAAChqAAEAAAAAMAAA';
end loop;
end;
/

反复读取某一行。
在会话2如下脚本：
begin
for i in 1..300 loop
update a1 set id=id+0 where rowid='AAAChqAAEAAAAAMAAA';
end loop;
commit;
end;
/

然后在V$SESSION_EVENT中查看两个Session的Buffer busy waits等待。

会话1反复查询一行，会话2反复更新同一行300次，两个会话应该各有少许的Buffer busy waits，对吧。
但实际情况不是这样的。会话2一般不会有，只有会话1会有Buffer busy wait等待。

Buffer Lock（内存的锁，称为Pin更合适，很多老外也是这么称乎的，我在下面称其为Buffer pin）的兼容模式为：
1、写、写互相阻塞。
2、写阻塞读。
3、读不阻塞写。

另外，在做上面的测试，偶而也会有写被读阻塞，而产生的Buffer busy wait，但这个很少见。这是由于IMU机制产生的影响。我会在后面的文章中，详细讨论。不过，可能会有点太深入，需要一些基础才能阅读。

sunyunyi · 发表于 2012-3-2 15:49

3、读不阻塞写.
buffer lock 只有s 和x 模式，s---s 兼容，其他三种都是不兼容的，读也是会阻塞写的。
只要出现buffer lock不兼容模式就可能出现 buffer busy wait 事件。
我是这样理解的，不知道对不？

vage · 发表于 2012-3-2 22:21

sunyunyi 发表于 2012-3-2 15:49
3、读不阻塞写.
buffer lock 只有s 和x 模式，s---s 兼容，其他三种都是不兼容的，读也是会阻塞写的。
...

10G后，在已经使用IMU的情况下，已经不是这样的了，写会阻塞读，但读不会阻塞写。
所以，如果有DML和Select操作同一块，只会看到Select有Buffer busy waits等待。
我后面会整理详细的验证此点的测试步骤

sunyunyi · 发表于 2012-3-3 22:02

我们看一下oracle 官方资料
Buffer Modes:
KCBMNEW : New buffer for exclusive access
KCBMSHR : Current buffer for shared access
KCBMEXL : Current buffer for exclusive access
KCBMCR : CR buffer for shared access
KCBMCRX : Variant of CR mode
KCBMNULL : Used to keep a reference to the buffer
Mode Compatibilities:
                           requested mode
                  new shr  exl  cr  crx null
held    null    y       y y    y    y    y
         shr    n    y    n    y    y    n
         exl    n    n    n    n    n    n

Getting Current Buffers
Searching for current buffers:
Scan the hash chain to which the RDBA maps.
For each buffer in the chain:
Ignore buffers that do not match RDBA
Wait for READING buffer and return them
Skip CR (consistent read) buffers
If the CUR (current) buffer is held in a compatible mode, then use it
Otherwise if all other users are CR state objects
– Make it a CR copy and create a new EXLCUR copy of the buffer
– Or wait for the current buffer to be released
If no usable buffers exist in cache, read from disk
Attach a state object to the buffer header
Return pointer to data area
Buffer busy waits
The buffer we want is either being read into the buffer cache by another process, or it is in an incompatible mode and is being modified. Normally the wait time is one second, except in the case if this is the second wait for an exclusive block, in which case the wait is three seconds. This event is the indication for data block contention, the same buffer is requested by more than one process at any given time. Reducing waits on this event depends on the block type (data, segment header, undo).

buffer busy wait  和 IMU 没有什么关系，IMU只是在 imu commit 时批量提REDO。

vage · 发表于 2012-3-4 12:56

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

反复读取某一行。
在会话2如下脚本：
begin
for i in 1..300 loop
update a1 set id=id+0 where rowid='AAAChqAAEAAAAAMAAA';
end loop;
commit;
end;
/
用这两个存储过程，反复访问同一块。在IMU下和非IMU下区别是非常明显的。
非IMU下，Select和Update都有Buffer busy waits，在IMU下，Update下就没有（也有可能只有少量，但原因是没有使用成IMU）Buffer busy waits。
可以试一下。

引入IMU对数据库的改变还是很大的，不仅仅只是imu commit 时批量提REDO 。也不仅仅是将UNDO信息放入共享池。对Buffer Busy Waits影响就是一例。你可以测一下。