深入解析bufferbusywaits(二)

比较奇怪，居然没有出现应该出现的buffer busy waits等待事件。难道读和写不会出现这个等待吗 ？
我们先保留这个疑问，继续测试写和写的并发是否会产生buffer busy waits。
4. 模拟2个会话并发同时写

---Session 1
www.killdb.com>declare
2    c number;
3  begin
4    for i in 1 .. 500000 loop
5      update  t_buffer_busy_waits set object_id=99 where object_id=99;
6    end loop;
7  end;
8  /
PL/SQL procedure successfully completed.
--Session 2
www.killdb.com>declare
2    c number;
3  begin
4    for i in 1 .. 500000 loop
5      update  t_buffer_busy_waits set object_id=111 where object_id=111;
6    end loop;
7  end;
8  /
PL/SQL procedure successfully completed.

ok，下面我们来看下第3个监控会话的结果：

www.killdb.com>l
1* select event,count(1) from v$session where wait_class#<>6 group by event
www.killdb.com>/
EVENT                                                              COUNT(1)
---------------------------------------------------------------- ----------
SQL*Net message to client                                                 1
buffer busy waits                                                         1
latch: cache buffers chains                                               1
www.killdb.com>/
EVENT                                                              COUNT(1)
---------------------------------------------------------------- ----------
SQL*Net message to client                                                 1
buffer busy waits                                                         1
latch: cache buffers chains                                               1
www.killdb.com>select sid,username,p1,p2,p3,event from v$session where event like 'buffer%';
SID USERNAME           P1         P2         P3 EVENT
---------- ---------- ---------- ---------- ---------- ----------------------------
523 ROGER               5      28909          1 buffer busy waits

ok，终于出现了我们希望的结果了，这个buffer busy waits来的不容易。这里我们需要说明一点，从oracle 10.1版本开始，
这里的p3 不再是像之前的数据库版本中那样，用来表示buffer busy waits的reason了，这里表示的是所等待的block的数据块
类型。很明显，这里的p3为1，那么也就是说block type 为1，表示data block，这一点不用多说了吧！
大家看Oracle AWR，我想也经常看到buffer waits，其实也会出现在其他的block 类型上，不仅仅是data block。
只不过数据块的争用更为常见一些。如果你查询文档你会发现，有下面的一些block type类型。
?

1 data block        7 extent map    13 file header block
2 sort block        8 1st level bmb 14 unused
3 save undo block   9 2nd level bmb 15+2*x undo header block(x=usn#)
4 segment header   10 3rd level bmb 16+2*x undo block(x=usb#)
5 save undo header 11 bitmap block
6 free list        12 bitmap index block

既然有可能是其他类型的block也会出现，那么按理说读和写是不兼容的，也应该出现，难道我们的测试有问题？
可能是并发不够，这里我再次测试了第2个测试：

Session 1：
www.killdb.com>declare
2    c number;
3  begin
4    for i in 1 .. 500000 loop
5      update  t_buffer_busy_waits set object_id=105 where object_id=105;
6    end loop;
7  end;
8  /
session 2：
www.killdb.com>declare
2    c number;
3  begin
4    for i in 1 .. 500000 loop
5      update  t_buffer_busy_waits set object_id=106 where object_id=106;
6    end loop;
7  end;
8  /
session 3:
www.killdb.com>declare
2    c number;
3  begin
4    for i in 1 .. 500000 loop
5      update  t_buffer_busy_waits set object_id=107 where object_id=107;
6    end loop;
7  end;
8  /
Session 4:
www.killdb.com>declar