1：bitmap 索引是分段存储的，也就是说很多条记录可能是分做了N段来存储，也就是有N个begin/end ,基本来说应该按照 extent 来分，若一个extent 很大是否会分，没测试
当新的记录 insert 而使用以前未曾使用过的物理地址的时候，会产生一个bitmap 段来存储，就算只有一条记录
2： 当删除一条记录的时候,在bitmap 索引上做了一个delete 的标记并用一新的记录来标记了,下面请看具体的演示
3: 当 dml发生的时候，会lock住某个值的存储bit的那一rowid所在的记录，参考下面的 row 中 lock ,这样显然会影响并发
SQL create table tn(a number, b number);
Table created.
SQL insert into tn select rownum,mod(rownum,5) from all_objects where rownum < 21;
20 rows created.
SQL commit;
Commit complete.
SQL create bitmap index tn_bitmap on tn(b);
Index created.
SQL exec show_space('tn_bitmap',user,'INDEX');
Free Blocks.............................0
Total Blocks............................16
Total Bytes.............................131072
Unused Blocks...........................14
Unused Bytes............................114688
Last Used Ext FileId....................3
Last Used Ext BlockId...................1954
Last Used Block.........................2
PL/SQL procedure successfully completed.
SQL select * from tn;
A
B
---------- ----------
1
1
2
2
3
3
4
4
5
0
6
1
7
2
8
3
9
4
10
0
11
1
A
B
---------- ----------
12
2
13
3
14
4
15
0
16
1
17
2
18
3
19
4
20
0
20 rows selected.
SQL alter system dump datafile 3 block 1955;
System altered.
Block header dump:
0x00c007a3
Object id on Block? Y
seg/obj: 0x66da
csc: 0x00.18a0d77
itc: 2
flg: -
typ: 2 - INDEX
fsl: 0
fnx: 0x0 ver: 0x01
Itl
Xid
Uba
Flag
Lck
Scn/Fsc
0x01
xid:
0x0000.000.00000000
uba: 0x00000000.0000.00
----
0
fsc 0x0000.00000000
0x02
xid:
0x0002.040.000000ea
uba: 0x00000000.0000.00
----
0
fsc 0x0000.00000000
Leaf block dump
===============
header address 125987932=0x7826c5c
kdxcolev 0
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 4
kdxcosdc 0
kdxconro 5
kdxcofbo 46=0x2e
kdxcofeo 7918=0x1eee
kdxcoavs 7872
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8036
row#0[8013] flag: -----, lock: 0
col 0; len 1; (1):
80
---表示值为0
col 1; len 6; (6):
00 c0 7e 03 00 00
---rowid 起点的block和行号
col 2; len 6; (6):
00 c0 7e 03 00 17
---rowid 结束的block和行号,注意17 = 16+7 = 23 ,也就是下面转换后的有效位置截止到23bit
col 3; len 4; (4):
ca 10 42 08
---把该值按照16进制数转化为 11001010 (首字节不表示rowid信息)
00010000 01000010 00001000 ,
凡是从起点到结束点内的1表示该值存在，这里有 一个必须要注意的问题是，这样转化后的位置并不是真实的物理位置，在每个字节内部bit还要颠倒一下顺序,首字节不表示位置信息
也就是说上面的应该转换为 00001000 01000010 00010000 ，发现正好每5个存在一个值为0的记录
row#1[7990] flag: -----, lock: 0
col 0; len 2; (2):
c1 02
---表示值为1
col 1; len 6; (6):
00 c0 7e 03 00 00
col 2; len 6; (6):
00 c0 7e 03 00 0f
---注意这里是f,也就是一共只有16位，因为1是第一条记录开始的，在16的位置就已经有5条了
col 3; len 3; (3):
c9 21 84 注意这里的 21
84 正好16位，根据上面描述的规则转换后就是 10000100 00100001,4个1正好表示记录
row#2[7966] flag: -----, lock: 0
col 0; len 2; (2):
c1 03
---表示值为2
col 1; len 6; (6):
00 c0 7e 03 00 00
col 2; len 6; (6):
00 c0 7e 03 00 17
col 3; len 4; (4):
ca 42 08 01
row#3[7942] flag: -----, lock: 0
col 0; len 2; (2):
c1 04
---表示值为3
col 1; len 6; (6):
00 c0 7e 03 00 00
col 2; len 6; (6):
00 c0 7e 03 00 17
col 3; len 4; (4):
ca 84 10 02
row#4[7918] flag: -----, lock: 0
col 0; len 2; (2):
c1 05
---表示值为4
col 1; len 6; (6):
00 c0 7e 03 00 00
col 2; len 6; (6):
00 c0 7e 03 00 17
col 3; len 4; (4):
ca 08 21 04
----- end of leaf block dump -----
End dump data blocks tsn: 2 file#: 3 minblk 1955 maxblk 1955
SQL delete from tn where a = 2;
1 row deleted.
SQL commit;
Commit complete.
SQL alter system dump datafile 3 block 1955;
System altered.
SQL
Block header dump:
0x00c007a3
Object id on Block? Y
seg/obj: 0x66da
csc: 0x00.18a0d77
itc: 2
flg: -
typ: 2 - INDEX
fsl: 0
fnx: 0x0 ver: 0x01
Itl
Xid
Uba
Flag
Lck
Scn/Fsc
0x01
xid:
0x0000.000.00000000
uba: 0x00000000.0000.00
----
0
fsc 0x0000.00000000
0x02
xid:
0x0003.047.000000e9
uba: 0x00800dba.00d9.1f
--U-
2
fsc 0x001a.018a0d7d
Leaf block dump
===============
header address 125987932=0x7826c5c
kdxcolev 0
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 4
kdxcosdc 0
kdxconro 6
kdxcofbo 48=0x30
kdxcofeo 7894=0x1ed6
kdxcoavs 7846
kdxlespl 0
kdxlende 1
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8036
row#0[8013] flag: -----, lock: 0
col 0; len 1; (1):
80
col 1; len 6; (6):
00 c0 7e 03 00 00
col 2; len 6; (6):
00 c0 7e 03 00 17
col 3; len 4; (4):
ca 10 42 08
row#1[7990] flag: -----, lock: 0
col 0; len 2; (2):
c1 02
col 1; len 6; (6):
00 c0 7e 03 00 00
col 2; len 6; (6):
00 c0 7e 03 00 0f
col 3; len 3; (3):
c9 21 84
row#2[7894] flag: -----, lock: 2
---这是删除后的拷贝,我们发现删除的时候该行已经加锁
lock
: 2
col 0; len 2; (2):
c1 03
col 1; len 6; (6):
00 c0 7e 03 00 00
col 2; len 6; (6):
00 c0 7e 03 00 17
col 3; len 4; (4):
ca 40 08 01
---我们发现 ca 42
已经变成
ca
40 ,也就是已经少掉一位bit了,正好是删除的那一条记录
row#3[7966] flag: ---D-, lock: 2
---这里我们发现值为2的记录已经有删除过的 ---D- ，D表示delete
col 0; len 2; (2):
c1 03
col 1; len 6; (6):
00 c0 7e 03 00 00
col 2; len 6; (6):
00 c0 7e 03 00 17
col 3; len 4; (4):
ca 42 08 01
row#4[7942] flag: -----, lock: 0
col 0; len 2; (2):
c1 04
col 1; len 6; (6):
00 c0 7e 03 00 00
col 2; len 6; (6):
00 c0 7e 03 00 17
col 3; len 4; (4):
ca 84 10 02
row#5[7918] flag: -----, lock: 0
col 0; len 2; (2):
c1 05
col 1; len 6; (6):
00 c0 7e 03 00 00
col 2; len 6; (6):
00 c0 7e 03 00 17
col 3; len 4; (4):
ca 08 21 04
----- end of leaf block dump -----
End dump data blocks tsn: 2 file#: 3 minblk 1955 maxblk 1955
