什么是10202trace event？10202：consistent read block header

即是用来分析consistent read的，在深入区的一个大家讨论的帖子中提到一个问题，为什么一个index full scan的10202 trace event中看不到读root block呢？

http://www.itpub.net/thread-1231064-1-1.html
《请问如何解释10202 event的内容？》

    顺着这样的问题我做了几个实验，最后得出来两个结论：

1.index full scan和index range scan是肯定会读index root block的。（这貌似是废话。。）

用index full scan为例：

env：

compatible                           string      10.2.0.4
optimizer_features_enable            string      10.2.0.4

create table haotest4 as select object_id,object_name from dba_objects;
create unique index haotestidx4 on haotest4(object_id);
select DATA_OBJECT_ID from dba_objects where OBJECT_NAME='HAOTEST4';
40664
select DATA_OBJECT_ID from dba_objects where OBJECT_NAME='HAOTESTIDX4';
40665

alter session set events '10202 trace name context forever';
----- begin tree dump
branch: 0x2801eb9 41950905 (0: nrow: 23, level: 1)
   leaf: 0x40dd23 4250915 (-1: nrow: 520 rrow: 520)
   leaf: 0x40dd24 4250916 (0: nrow: 513 rrow: 513)
   leaf: 0x2801eba 41950906 (1: nrow: 513 rrow: 513)
   leaf: 0x2801ebb 41950907 (2: nrow: 513 rrow: 513)
   leaf: 0x2801ebc 41950908 (3: nrow: 513 rrow: 513)
   leaf: 0x40dd25 4250917 (4: nrow: 513 rrow: 513)
   leaf: 0x40dd26 4250918 (5: nrow: 513 rrow: 513)
   leaf: 0x40dd27 4250919 (6: nrow: 513 rrow: 513)
   leaf: 0x40dd28 4250920 (7: nrow: 513 rrow: 513)
   leaf: 0x40dd29 4250921 (8: nrow: 513 rrow: 513)
   leaf: 0x2801ebd 41950909 (9: nrow: 513 rrow: 513)
   leaf: 0x2801ebe 41950910 (10: nrow: 513 rrow: 513)
   leaf: 0x2801ebf 41950911 (11: nrow: 513 rrow: 513)
   leaf: 0x2801ec0 41950912 (12: nrow: 513 rrow: 513)
   leaf: 0x2801ec1 41950913 (13: nrow: 513 rrow: 513)
   leaf: 0x2801ec2 41950914 (14: nrow: 513 rrow: 513)
   leaf: 0x2801ec3 41950915 (15: nrow: 513 rrow: 513)
   leaf: 0x2801ec4 41950916 (16: nrow: 486 rrow: 486)
   leaf: 0x2801ec5 41950917 (17: nrow: 478 rrow: 478)
   leaf: 0x2801ec6 41950918 (18: nrow: 479 rrow: 479)
   leaf: 0x40dd2a 4250922 (19: nrow: 478 rrow: 478)
   leaf: 0x40dd2b 4250923 (20: nrow: 478 rrow: 478)
   leaf: 0x40dd2c 4250924 (21: nrow: 302 rrow: 302)
----- end tree dump

SQL> select DBMS_UTILITY.data_block_address_file(TO_NUMBER(LTRIM('0x2801eb9','0x'),'xxxxxxxx')) rfile#,
  2  DBMS_UTILITY.data_block_address_block(TO_NUMBER(LTRIM('0x2801eb9','0x'),'xxxxxxxx')) block# from dual;
    RFILE#     BLOCK#
---------- ----------
        10       7865

可见10，7865就是root/1 level branch block。
查看buffer header被touch的次数：

SQL> select DBARFIL,DBABLK,CLASS,TCH from x$bh where BJ=40665 order by 1,2;
   DBARFIL     DBABLK      CLASS        TCH
---------- ---------- ---------- ----------
         1      56611          1         10
         1      56612          1          6
         1      56613          1          6
         1      56614          1          6
         1      56615          1          6
         1      56616          1          6
         1      56617          1          6
         1      56618          1          6
         1      56619          1          6
         1      56620          1          6
        10       7864          4          3
        10       7865          1         11
        10       7866          1          6
        10       7867          1          6
        10       7868          1          6
        10       7869          1          6
        10       7870          1          6
        10       7871          1          6
        10       7872          1          6
        10       7873          1          6
        10       7874          1          6
        10       7875          1          6
        10       7876          1          6
        10       7877          1          6
        10       7878          1          6
25 rows selected.

run一下：
select /*+index(t haotestidx4)*/ object_id from haotest4 t where object_id<100;

由于返回肯定不到100行，所以猜测只需扫描一个index leaf block就足够了。
因为前面trea dump出来每个leaf block存储500多行。

SQL> /
   DBARFIL     DBABLK      CLASS        TCH
---------- ---------- ---------- ----------
         1      56611          1         11
         1      56612          1          6
         1      56613          1          6
         1      56614          1          6
         1      56615          1          6
         1      56616          1          6
         1      56617          1          6
         1      56618          1          6
         1      56619          1          6
         1      56620          1          6
        10       7864          4          3
        10       7865          1         12
        10       7866          1          6
        10       7867          1          6
        10       7868          1          6
        10       7869          1          6
        10       7870          1          6
        10       7871          1          6
        10       7872          1          6
        10       7873          1          6
        10       7874          1          6
        10       7875          1          6
        10       7876          1          6
        10       7877          1          6
        10       7878          1          6

果然，根据x$bh,root block和第一个leaf block都被读了一次。



2.10202不会显示index full scan/index range scan的root block的consistent read。

alter session set events '10202 trace name context forever';
select /*+index(t haotestidx4)*/ object_id from haotest4 t where object_id<100;

grep "^Block header dump" 10202.trc | uniq
Block header dump:  0x0040dd23

SQL> select DBMS_UTILITY.data_block_address_file(TO_NUMBER(LTRIM('0x0040dd23','0x'),'xxxxxxxx')) rfile#,
  2  DBMS_UTILITY.data_block_address_block(TO_NUMBER(LTRIM('0x0040dd23','0x'),'xxxxxxxx')) block# from dual;
    RFILE#     BLOCK#
---------- ----------
         1      56611

可见，10202 trace结果只显示一个consistent read，这个就是第一个leaf block的读。
并没有显示root block。但实际肯定需要读root block的。

同样的实验也应用于index range scan。所以结论一样。