关于Oracle位图索引内部浅论

我们都知道Oracle位图索引适用于字段不同值很少的情况,同时修改DML会导致整个同样的值全部被锁定,这严重影响了并发性,所以不建议OLTP系统大量使用位图索引。
但是具体位图索引的内部是如何排列和组织的呢?如下将进行探讨,由于水平有限可能有一定错误。
首先认识BITMAP索引的组织方式,首先看一下ORACLE给出的这张图

关于Oracle位图索引内部浅论

可以看到本图中实际上有4种颜色蓝色、绿色、红色、黄色,BITMAP 索引也是B-TREE的格式,但是其页节点存储的是键值+ROWID范围+位图键的方式,这样一来可以很明显的感知到BITMAP所以在键值很少的时候其空间比较B-TREE索引是小很多的,而在位图键方面使用一连串的0和1来表示是否存在相应的值,这样一来ORACLE就能快速的进行是否有值的定位。

接下来我们进行DUMP,先建立测试表

建立这样一张表
SQL> select id,count(*) from testt_bit group by id;
          ID  COUNT(*)
 ----------- ----------
          1    100000
          2    100000
          3    100000
同时在分布上是连续的,1是1-100000行,2是100001-200000行,3是剩下的
 在ID列上建立BIT MAP索引
create bitmap index TEST_BIT_IND on TESTT_BIT (ID)

首先进行BITMAP索引的结构DUMP如下:
SQL> oradebug setmypid
 Statement processed.
 SQL> oradebug tracefile_name
 /ora11g/diag/rdbms/test/test/trace/test_ora_5604.trc
 SQL> alter session set events 'immediate trace name treedump level 76306';

*** 2015-03-18 00:40:35.111
 ----- begin tree dump
 branch: 0x1000333 16778035 (0: nrow: 8, level: 1)
    leaf: 0x1000334 16778036 (-1: nrow: 2 rrow: 2)
    leaf: 0x1000335 16778037 (0: nrow: 2 rrow: 2)
    leaf: 0x1000336 16778038 (1: nrow: 2 rrow: 2)
    leaf: 0x1000337 16778039 (2: nrow: 2 rrow: 2)
    leaf: 0x1000338 16778040 (3: nrow: 2 rrow: 2)
    leaf: 0x1000339 16778041 (4: nrow: 2 rrow: 2)
    leaf: 0x100033a 16778042 (5: nrow: 2 rrow: 2)
    leaf: 0x100033b 16778043 (6: nrow: 1 rrow: 1)
 ----- end tree dump
这里清楚的看到了这个位图索引的层次,首先它只有2层,1个根节点8个页节点,每个叶节点包含2个索引条目(最后一个节点除外)

接下来我们DUMP根节点:
 根据DBA(block adress)16778035进行换算
SQL>  select dbms_utility.data_block_address_file(16778035),
  2  dbms_utility.data_block_address_block(16778035) from dual;
 DBMS_UTILITY.DATA_BLOCK_ADDRES DBMS_UTILITY.DATA_BLOCK_ADDRES
 ------------------------------ ------------------------------
                              4                            819
然后alter system dump datafile 4 block 819进行DUMP

header address 47810796042828=0x2b7bd183ba4c
 kdxcolev 1
 KDXCOLEV Flags = - - -
 kdxcolok 0
 kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
 kdxconco 4
 kdxcosdc 0
 kdxconro 7
 kdxcofbo 42=0x2a
 kdxcofeo 7972=0x1f24
 kdxcoavs 7930
 kdxbrlmc 16778036=0x1000334
 kdxbrsno 0
 kdxbrbksz 8056
 kdxbr2urrc 0
关于这一部分引用一个文档(作者不详)
 其中的kdxcolev表示索引层级号,这里由于我们转储的是根节点,所以其层级号为1。对叶子节点来说该值为0;
 kdxcolok表示该索引上是否正在发生修改块结构的事务;kdxcoopc表示内部操作代码;kdxconco表示索引条目中列的数量;
 kdxcosdc表示索引结构发生变化的数量,当你修改表里的某个索引键值时,该值增加;kdxconro表示当前索引节点中索引条目的数量,但是注意,不包括kdxbrlmc指针;kdxcofbo表示当前索引节点中可用空间的起始点相对当前块的位移量;
 kdxcofeo表示当前索引节点中可用空间的最尾端的相对当前块的位移量;kdxcoavs表示当前索引块中的可用空间总量,也就是用kdxcofeo减去kdxcofbo得到的。kdxbrlmc表示分支节点的地址,该分支节点存放了索引键值小于row#0(在转储文档后半部分显示) 所含有的最小值的所有节点信息;kdxbrsno表示最后一个被修改的索引条目号,这里看到是0,表示该索引是新建的索引;
kdxbrbksz表示可用数据块的空间大小。实际从这里已经可以看到,即便是PCTFREE设置为0,也不能用足8192字节。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/4e23e85f00f6b5e000a53f9eb9447db3.html