Bitmap Index 的一點探究
2024-07-21 02:37:59
供稿：網友
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
