逻辑读产生Cache Buffer Chain(简称CBC) Latch的解析

xteitxu

guoyJoe 发表于 2013-4-9 16:44
你的表是建在sys用户下的？？？做测试最好不要在sys用户下测，很多测试在sys用户下是意想不到的结果。。。 ...

郭总    不是SYS用户  是我的一个测试用户   

xteitxu

guoyJoe 发表于 2013-4-9 16:44
你的表是建在sys用户下的？？？做测试最好不要在sys用户下测，很多测试在sys用户下是意想不到的结果。。。 ...

噢  上边查ROWID是测试用户   下面查X$BH是在SYS下   造成了在SYS下的假象   刚刚又换了张表测试 结果还是一样   不知道是不是有其它因素会影响到结果

测试用户：
SQL> select rowid,dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid) block# from t where rownum=1;

ROWID                   FILE#     BLOCK#
------------------ ---------- ----------
AAAuA5AAEAAAADsAAA          4        236

SYS用户:

SQL> select hladdr from x$bh where file#=4 and dbablk=236;

未选定行

xteitxu

guoyJoe 发表于 2013-4-9 16:43
这个可以找到啊。我打开vm测试：
idle> idle> select rowid,dbms_rowid.rowid_relative_fno(rowid) file ...

郭大师，你的file3不是UNDO？  

guoyJoe

xteitxu 发表于 2013-4-9 18:09
郭大师，你的file3不是UNDO？

这个不一定的。这个可以换可以改。。。。

abocide

ggg3838 发表于 2013-3-10 21:51
v哥 咋看出是物理IO导致

V哥的文章没看全啊。他有文章说这个的。

玉面飞龙

ｄｔｒａｃｅ再研究研究，ｒｏｏｔ跑竟然报错。

[host-gz61] host#  ./dtrace.d -x switchrate=1hz -b 32m 19173
dtrace: failed to compile script ./dtrace.d: line 2: probe description pid19173racle::entry does not match any probes

[host-gz61] host# cat dtrace.d
#!/usr/sbin/dtrace -s -n
pid$1racle::entry
{
        printf("PID::entry:==%s:%s:%s:%s %x %x %x %d %x %x", probeprov, probemod, probefunc, probename,arg0,arg1,arg2,arg3,arg4,arg5);
}

玉面飞龙

http://andreynikolaev.wordpress. ... shared_latches-ctl/

这个链接倒是说到　ＣＢＣｌａｔｃｈ是ｓｈａｒｅｄ　的；但是貌似大多数是以ｅｘｃｌｕｓｉｖｅ　ｍｏｄｅ去请求

cachebuffers chains is a shared latch. In Jonathan Lewis’s new book <oraclecore>, he mentioned that getting shareable latch only spins 2,000 times bydefault.

想看一下哪个ｆｕｎｃｔｉｏｎ是负责ｓｐｉｎ　ｌａｔｃｈ的，没有找到。

玉面飞龙

在oracle 11.2.0.3 solaris SPARC上测试了一下，CBC latch是以共享模式获得的

具体的:

1) 首先，一次CR READ仍然是需要请求2次CBC latch

BINZHANG@DBATST01: SQL> select rowid,dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid) block#,ID from binzhang.t  where rownum=1;

ROWID                   FILE#     BLOCK#         ID
------------------ ---------- ---------- ----------
AAADfeAAKAAAVmBAAA         10      88449          1

1 row selected.

SYS@DBATST01: SQL> SYS@DBATST01: SQL> select  hladdr,ba,decode(state,0,'free',1,'xcur',2,'scur',3,'cr', 4,'read',5,'mrec',6,'irec',7,'write',8,'pi',9,'memory',10,'mwrite',11,'donated')   status from x$bh where file#= 10 and dbablk=88449;

HLADDR           BA               STATUS
---------------- ---------------- --------------------------------
00000004D0902F68 000000040C2E4000 xcur


SYS@DBATST01: SQL> select addr,latch#,child#,level#,name,hash,gets,MISSES,SLEEPS,IMMEDIATE_GETS,IMMEDIATE_MISSES,SPIN_GETs,WAIT_TIME from  v$latch_children  where addr='00000004D0902F68';

ADDR                 LATCH#     CHILD# NAME                                 HASH       GETS     MISSES     SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES  SPIN_GETS  WAIT_TIME
---------------- ---------- ---------- ------------------------------ ---------- ---------- ---------- ---------- -------------- ---------------- ---------- ----------
00000004D0902F68        155       1755 cache buffers chains           3563305585        269          0          0              2                0          0          0


BINZHANG@DBATST01: SQL> select  rowid,dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid) block#,ID from  binzhang.t where  rowid='AAADfeAAKAAAVmBAAA';

ROWID                   FILE#     BLOCK#         ID
------------------ ---------- ---------- ----------
AAADfeAAKAAAVmBAAA         10      88449          1

-- now get is 150; it's 2 CBC latch gets when read buffer by rowid.

ADDR                 LATCH#     CHILD# NAME                                 HASH       GETS     MISSES     SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES  SPIN_GETS  WAIT_TIME
---------------- ---------- ---------- ------------------------------ ---------- ---------- ---------- ---------- -------------- ---------------- ---------- ----------
00000004D0902F68        155       1755 cache buffers chains           3563305585        271          0          0              2                0          0          0

2) solaris SPARC 下 第8个字节表示有多少process正在以shared mode获得该latch

通过很多并行session 执行 “select  rowid,dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid) block#,ID from  binzhang.t where  rowid='AAADfeAAKAAAVmBAAA'; ”，当有CBC latch争用的时候，执行以下oradebug peak命令，时常可以看到第8个字节为0x1.

SYS@DBATST01: SQL>  oradebug peek 0x00000004D0902F68 24   
[4D0902F68, 4D0902F80) = 00000000 00000001 098F5FE5 009B0000 00000001 000006D4

3) 做和LZ类似的测试

将第8个字节标志为0x1
SYS@DBATST01: SQL> oradebug poke 0x00000004D0902F68 8 1
BEFORE: [4D0902F68, 4D0902F70) = 00000000 00000000
AFTER:  [4D0902F68, 4D0902F70) = 00000000 00000001

SYS@DBATST01: SQL>  oradebug peek 0x00000004D0902F68 24   
[4D0902F68, 4D0902F80) = 00000000 00000001 098F5FE5 009B0000 00000001 000006D4

另外一个进程CR read并没有被阻塞，只是将0x1修改为0x2. 也就是以shared mode 获取到latch，表示有2个process获得了shared mode的CBC latch
[php]
  9 168694                   skgslcas:entry i=529 PID::entry:==pid28673racle:skgslcas:entry 4d0902f68 0 1 56132 44 4cc3d19b8
  9  84051                    kslgess:entry i=531 PID::entry:==pid28673racle:kslgess:entry 4d0902f68 109 1 42031489 6d1 0                            ---- latch miss +1
  9 168695                  skgslocas:entry i=532 PID::entry:==pid28673racle:skgslocas:entry 4d0902f68 1 2 -2147511408 4cc3d1860 40               -- spin + 1
............ pin buffer................
  9 168694                   skgslcas:entry i=541 PID::entry:==pid28673racle:skgslcas:entry 4d0902f68 2 1 524288 10c000 4cc3d19b8
....... read buffer...........
  9 168694                   skgslcas:entry i=562 PID::entry:==pid28673racle:skgslcas:entry 4d0902f68 0 1 42031489 db db
  9  84051                    kslgess:entry i=564 PID::entry:==pid28673racle:kslgess:entry 4d0902f68 9 1 0 6d4 db
  9 168695                  skgslocas:entry i=565 PID::entry:==pid28673racle:skgslocas:entry 4d0902f68 1 2 -2147506944 4cc3d1860 40
...........un-pin buffer.......
  9  99302                     kcbzar:entry i=566 PID::entry:==pid28673racle:kcbzar:entry 4ce90fd50 4d0902f68 108000 -2147505712 1 ffff
  9 168694                   skgslcas:entry i=569 PID::entry:==pid28673racle:skgslcas:entry 4d0902f68 2 1 20678979432 2000000000000000 2
  9 242015                  skgslcas:return i=570 PID::entry:==pid28673racle:skgslcas:return 18 1 2 2 4d0902f68 2

[/php]

想知道如何标记 latch 地址，才能是exclusive mode的？

PiscesCanon

11.2.0.4.0，dtrace之后，cbc的latch在dtrace的日志并没有找到