buffer busy waits，我的看法

wei-xh

不好意思，估计是系统BUG，第一次发的始终看不到，就又写了一次。
现在可以看到了。
下面的忽略，请看上一帖。
buffer pin一定是有队列的，只是不知道是不是FIFO的
buffer pin 不是latch,不是mutxt，它不会去自旋spin，一旦获取不了资源，就加入队列。
证明有这个队列的办法很容易。


select dbms_rowid.ROWID_RELATIVE_FNO(rowid) fn, dbms_rowid.rowid_block_number(rowid) bl, wxh_tbd.object_id,rowid from wxh_tbd where rownum<4;

        FN         BL  OBJECT_ID ROWID
---------- ---------- ---------- ------------------
         7     906227         20 AAAF2kAAHAADdPzAAA
         7     906227         46 AAAF2kAAHAADdPzAAB
         7     906227         28 AAAF2kAAHAADdPzAAC
新开3个SESSION :
test@DLSP>begin
  2  for i in 1 ..40000000 loop
  3  UPDATE  wxh_tbd SET object_name=28 where rowid='AAAF2kAAHAADdPzAAC';
  4  commit;
  5  end loop;
  6  end;
  7  /
  
test@DLSP>begin
  2  for i in 1 ..40000000 loop
  3  UPDATE  wxh_tbd SET object_name=20 where rowid='AAAF2kAAHAADdPzAAA';
  4  commit;
  5  end loop;
  6  end;
  7  /


test@DLSP>begin
  2  for i in 1 ..40000000 loop
  3  UPDATE  wxh_tbd SET object_name=46 where rowid='AAAF2kAAHAADdPzAAB';
  4  commit;
  5  end loop;
  6  end;
  7  /

alter system dump datafile 7 block 906227;
这个操作执行N次。可能一次或捕获不到。

我们再看看跟踪文件。
BH (0xa37d8c9b8) file#: 7 rdba: 0x01cdd3f3 (7/906227) class: 1 ba: 0xa33c7e000
  set: 182 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 0,0
  dbwrid: 1 obj: 23972 objn: 23972 tsn: 4 afn: 7 hint: f
  hash: [0xa37d8c5a8,0xadfdd5188] lru: [0xa37d8c5e0,0xae63edb58]
  ckptq: [NULL] fileq: [NULL] objq: [NULL] objaq: [NULL]
use: [0xae5f89658,0xae5f89658] wait: [NULL] fast-cr-pins: 1  st: CR md: SHR tch: 0
  cr: [scn: 0x0.8a4a8801],[xid: 0x0.0.0],[uba: 0x0.0.0],[cls: 0x0.8a4a8801],[sfl: 0x0],[lc: 0x0.8a4a8801]
  flags: only_sequential_access

BH (0x9f7ebfa68) file#: 7 rdba: 0x01cdd3f3 (7/906227) class: 1 ba: 0x9f5cd0000
  set: 184 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 0,0
  dbwrid: 3 obj: 23972 objn: 23972 tsn: 4 afn: 7 hint: f
  hash: [0x9ffea3908,0xadfdd5188] lru: [0x9f7ebf0a0,0x9f7ebef70]
  obj-flags: object_ckpt_list
  ckptq: [0x9f7ebee88,0x9f7ebf0e8] fileq: [0xae64a4100,0xae64a4100] objq: [0xab46b0220,0xab46b0220] objaq: [0xab46b0200,0xab46b0200]
  use: [0xae5f89658,0xae5f89658] wait: [0xaf5ef8e28,0xaf5ef8e28]  st: XCURRENT md: EXCL fpin: 'kdswh11: kdst_fetch' tch: 7
  flags: buffer_dirty mod_started block_written_once redo_since_read
          flush_after_writing
  change state: COMPLETE
  change count: 1
  LRBA: [0x44d.49bdc.0] LSCN: [0x0.8ad148b0] HSCN: [0x0.8ada8c13] HSUB: [2]

BH (0xa37db0618) file#: 7 rdba: 0x01cdd3f3 (7/906227) class: 1 ba: 0xa34042000
  set: 184 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 0,0
  dbwrid: 3 obj: 23972 objn: 23972 tsn: 4 afn: 7 hint: f
  hash: [0xadfdd5188,0xadfdd5188] lru: [0xa37db0830,0xa37db05d0]
  ckptq: [NULL] fileq: [NULL] objq: [0xab46b0210,0xa37db05f8] objaq: [0xab46b0200,0xa37db0608]
  st: XCURRENT md: NULL fpin: 'kdswh11: kdst_fetch' tch: 85
  flags: only_sequential_access
  LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
Block dump from disk:
标红的部分就是队列。
有时候会有use队列，有时候use wait队列。
有时候你人品不好，没抓到，就什么队列都没有。

vage

wei-xh 发表于 2013-7-11 09:56
buffer pin一定是有队列的，至于这个队列是不是跟enq锁一样，有FIFO我不确定。
buffer pin不是latch，不 ...

我估计，这是把所有正在等待的进程都记录下来，等Buffer Pin被释放了，随机选择一个唤醒，不保证排在前面的一定可以先得到Buffer Pin。

名字上，ckptq,fileq,等都有Q，这里的wait不是waitq，当然这个只是根据瞎猜。

vage

试了一下，果然有Use和Wait这两个东西，wait的变化规律:
无进程等时：    [NULL]
有一个进程等时：[A,A]
有二个进程等时：[B,A]
有三个进程等时：[C,B]
有四个进程等时：[B,A]

这种规律，不符合队列的变化方式。队列保存个头尾就可以了。

设计了个测试，可以证明Buffer Pin阻塞后是无规律唤醒进程。

wei-xh

vage 发表于 2013-7-11 11:39
试了一下，果然有Use和Wait这两个东西，wait的变化规律:
无进程等时：    [NULL]
有一个进程等时：[A,A]
...

我还是倾向于是记录了整个队列。dump出来的并没有显示真实的内容。
Buffer locks are taken normally in shared and exclusive modes. The buffer headers
implement a two-way linked list of the buffer handles for sessions that are using the buffer,
and another for the buffer handles of sessions that are waiting for the buffer.
查看9I的DIS，里面用的词是列表，第一个列表是use，第二个列表是wait。

mike79

buffer pin是有队列的，x$bh的US_*是bh pin的owner队列，WA*是waiter队列。
但是这个队列不是严格的FIFO的，说不定是惊群机制

vage

可以这样测试一下，在11GR2 64位下，如下步骤：
BH开头偏移量向下64字节处，记录独占Buffer Pin。使用如下的命令，可以加Buffer Pin：
oradebug poke (bh+64字节) 4 0x02000101

然后再开几个会话，对同一行更新，它们都会被Hang住，等待事件当然就是BBW了，再用如下方式释放Buffer Pin
oradebug poke (bh+64字节) 4 0x00000101
或
oradebug poke (bh+64字节) 4 0x00040101

看哪些进程被激活。

我的测试结果，不一定哪个进程被激，随机的，不是按队列方式。

wei-xh

vage 发表于 2013-7-11 12:06
可以这样测试一下，在11GR2 64位下，如下步骤：
BH开头偏移量向下64字节处，记录独占Buffer Pin。使用如下 ...

OK,我下午把这个作为补充，加到原文后面

vage

mike79 发表于 2013-7-11 11:45
buffer pin是有队列的，x$bh的US_*是bh pin的owner队列，WA*是waiter队列。
但是这个队列不是严格的FIFO的 ...

嗯对，我觉得应该是这样的。惊群机制。

wei-xh

mike79 发表于 2013-7-11 11:45
buffer pin是有队列的，x$bh的US_*是bh pin的owner队列，WA*是waiter队列。
但是这个队列不是严格的FIFO的 ...

隐藏的高人啊

vage

wei-xh 发表于 2013-7-11 12:10
OK,我下午把这个作为补充，加到原文后面

，没事加不加都行，对于大部分人来说，这有点太Inertnal了。

期待华仔也加入到DTrace Mdb/Gdb陈营。

早期Oracle原理探索大部分只为满足好奇心，因为只能隔靴搔痒、雾里看花。
现在已经不同了，这么多牛B的调试工具，已经都把Oracle看的一清二楚了，一些个等待事件的意义、v$systat中的资料，使用调试工具可以发掘的非常清楚。这对于根据AWR报告判断问题还是很有帮助的。