可以看到本图中实际上有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字节。

row#0[8044] dba: 16778037=0x1000335
?col 0; len 2; (2):? c1 02
?col 1; len 3; (3):? 01 00 03
?col 2; TERM
?row#1[8031] dba: 16778038=0x1000336
?col 0; len 2; (2):? c1 02
?col 1; len 4; (4):? 01 00 03 f8
?col 2; TERM
?row#2[8019] dba: 16778039=0x1000337
?col 0; len 2; (2):? c1 03
?col 1; len 3; (3):? 01 00 04
?col 2; TERM
?row#3[8006] dba: 16778040=0x1000338
?col 0; len 2; (2):? c1 03
?col 1; len 4; (4):? 01 00 04 bf
?col 2; TERM
?row#4[7998] dba: 16778041=0x1000339
?col 0; len 2; (2):? c1 04
?col 1; TERM
?row#5[7985] dba: 16778042=0x100033a
?col 0; len 2; (2):? c1 04
?col 1; len 4; (4):? 01 00 05 57
?col 2; TERM
?row#6[7972] dba: 16778043=0x100033b
?col 0; len 2; (2):? c1 04
?col 1; len 4; (4):? 01 00 05 f8
?col 2; TERM