bitmap 的一点探究

hanjs

根据10楼的例子，索引存放的是 F 或 M

这样对于得col0 是 F 或 M所对应的ascii

为何0 - 5 没有按ascii存放呢？

hanjs

一条一条处理，有点明白了，但是对于第一个批量插入20条的例子，对于1的处理

rowid的范围为何和其他的不一样呢？

hanjs

终于弄清楚每个索引是怎么存的了。



'M': 11100110001010
'F': 00011001110101

<< lines cut here >>
row#0[1866] flag: ----, lock: 0
col 0; len 1; (1): 46
col 1; len 6; (6): 01 00 00 0d 00 00
col 2; len 6; (6): 01 00 00 0d 00 0f
col 3; len 3; (3): c9 98 2b
row#1[1844] flag: ----, lock: 0
col 0; len 1; (1): 4d
col 1; len 6; (6): 01 00 00 0d 00 00
col 2; len 6; (6): 01 00 00 0d 00 0f
col 3; len 3; (3): c9 67 14
----- end of leaf block dump -----


对于M
11100110 001010
前八位反过来取，因为后插入的位要高，所以就有 67
同理，后六位为 14

这样对于F
00011001 110101 => 98 2b

hanjs

最初由 hanjs 发布
[B]一条一条处理，有点明白了，但是对于第一个批量插入20条的例子，对于1的处理

rowid的范围为何和其他的不一样呢？ [/B]

下面是我按biti的例子作的，下面的文件是先truncate table tn后dump的信息

*** 2007-11-10 09:19:12.000
Start dump data blocks tsn: 0 file#: 1 minblk 50762 maxblk 50762
buffer tsn: 0 rdba: 0x0040c64a (1/50762)
scn: 0x0000.000ce4a3 seq: 0x01 flg: 0x04 tail: 0xe4a30601
frmt: 0x02 chkval: 0x5018 type: 0x06=trans data
Block header dump:  0x0040c64a
Object id on Block? Y
seg/obj: 0x766b  csc: 0x00.ce4a3  itc: 2  flg: -  typ: 2 - INDEX
     fsl: 0  fnx: 0x0 ver: 0x01

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000

Leaf block dump
===============
header address 87691356=0x53a105c
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 4
kdxcosdc 0
kdxconro 0
kdxcofbo 36=0x24
kdxcofeo 8036=0x1f64
kdxcoavs 8000
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8036
----- end of leaf block dump -----
End dump data blocks tsn: 0 file#: 1 minblk 50762 maxblk 50762

在执行
insert into tn select rownum,mod(rownum,5) from all_objects where rownum < 21;
commit;
后dump的情况，有一点费解的地方，就是出现了row#5
[/COLOR]
*** 2007-11-10 09:19:58.000
Start dump data blocks tsn: 0 file#: 1 minblk 50762 maxblk 50762
buffer tsn: 0 rdba: 0x0040c64a (1/50762)
scn: 0x0000.000ce60c seq: 0x01 flg: 0x02 tail: 0xe60c0601
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Block header dump:  0x0040c64a
Object id on Block? Y
seg/obj: 0x766b  csc: 0x00.ce4a3  itc: 2  flg: -  typ: 2 - INDEX
     fsl: 0  fnx: 0x0 ver: 0x01

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x02   0x0004.002.00000380  0x0080003d.005e.10  --U-    6  fsc 0x0008.000ce60c

Leaf block dump
===============
header address 88089180=0x540225c
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 4
kdxcosdc 0
kdxconro 6
kdxcofbo 48=0x30
kdxcofeo 7912=0x1ee8
kdxcoavs 7864
kdxlespl 0
kdxlende 1
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8036
row#0[8007] flag: -----, lock: 2
col 0; len 1; (1):  80
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 17
col 3; len 4; (4):  ca 10 42 08
row#1[7984] flag: -----, lock: 2
col 0; len 2; (2):  c1 02
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 0f
col 3; len 3; (3):  c9 21 84
row#2[7960] flag: -----, lock: 2
col 0; len 2; (2):  c1 03
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 17
col 3; len 4; (4):  ca 42 08 01
row#3[7936] flag: -----, lock: 2
col 0; len 2; (2):  c1 04
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 17
col 3; len 4; (4):  ca 84 10 02
row#4[7912] flag: -----, lock: 2
col 0; len 2; (2):  c1 05
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 17
col 3; len 4; (4):  ca 08 21 04
row#5[8030] flag: ---D-, lock: 2
col 0; NULL
col 1; NULL
col 2; NULL
col 3; NULL
----- end of leaf block dump -----
End dump data blocks tsn: 0 file#: 1 minblk 50762 maxblk 50762
[/COLOR]

再插入 insert into tn values (21,1); commit; dump后

row#0[8007] flag: -----, lock: 0
col 0; len 1; (1):  80
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 17
col 3; len 4; (4):  ca 10 42 08
row#1[7984] flag: -----, lock: 2
col 0; len 2; (2):  c1 02
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 0f
col 3; len 3; (3):  c9 21 84
看到第一个存放1的bitmap认为已经满了，我是这样猜想的
在一次插入20条时，1对应的key
10000 10000 10000 10000
上LS的解释，插入的位越来越高，这样反转下
10000100 00100001 0000 => 21 84注意，后面的4位0，oracle认为没有必要存储了，因为一次commit的记录就这么多，所以认为这个已经满了，不知道大家是否认同这个说法？[/COLOR]
row#2[7891] flag: -----, lock: 2
col 0; len 2; (2):  c1 02
col 1; len 6; (6):  00 40 c6 42 00 10
col 2; len 6; (6):  00 40 c6 42 00 17
col 3; len 1; (1):  04
当在插入一条1时，oracle又新分配了一个entry，从col3可以看出，按前面yang版主的存放的是相对于00 40 c6 42 00 10
的rowid，第17行，也就是第一个entry满的rowid+1，我们可以看到
SQL> select dump(rowid,16) from tn where a=17;

DUMP(ROWID,16)
--------------------------------------------------------------------------------
Typ=69 Len=10: 0,0,76,6c,0,40,c6,42,0,10

就是00 40 c6 42 00 10

而新插入的rowid
SQL> select dump(rowid,16) from tn where a=21;

DUMP(ROWID,16)
--------------------------------------------------------------------------------
Typ=69 Len=10: 0,0,76,6c,0,40,c6,42,0,14

可以看出，后面14-10 = 04
[/COLOR]

row#3[7960] flag: -----, lock: 0
col 0; len 2; (2):  c1 03
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 17
col 3; len 4; (4):  ca 42 08 01
row#4[7936] flag: -----, lock: 0
col 0; len 2; (2):  c1 04
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 17
col 3; len 4; (4):  ca 84 10 02
row#5[7912] flag: -----, lock: 0
col 0; len 2; (2):  c1 05
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 17
col 3; len 4; (4):  ca 08 21 04
----- end of leaf block dump -----
End dump data blocks tsn: 0 file#: 1 minblk 50762 maxblk 50762




目前唯一的疑惑是，怎么看出entry存放的是 0，1，2，3，4，5的？？

hanjs

最初由 hanjs 发布
[B]根据10楼的例子，索引存放的是 F 或 M

这样对于得col0 是 F 或 M所对应的ascii

为何0 - 5 没有按ascii存放呢？ [/B]

唉，弄明白了，存放得是16进制的，dump了一下

SQL> select dump(1,16) from tb where a=1;

DUMP(1,16)
-----------------
Typ=2 Len=2: c1,2

SQL> select dump(0,16) from tb where a=1;

DUMP(0,16)
---------------
Typ=2 Len=1: 80

SQL> select dump('F',16) from dual;

DUMP('F',16)
----------------
Typ=96 Len=1: 46

SQL>

这回懂了，晕死！

romanyu

看得眼花缭乱

ycfyh

很好的贴子，有利于理解bitmap概念。

lsq_008

还是以前的帖子有技术含量啊，现在大师们都不怎么写了

Yong Huang

原帖由 lsq_008 于 2009-6-18 02:24 发表
还是以前的帖子有技术含量啊，现在大师们都不怎么写了

Nowadays people write their own notes in personal blog. (I don't have one, but I put them in static text or html files on my web site.)

By the way, overall Oracle skills in China have improved a lot in recent years. Don't you think?

Yong Huang

wangkxxe

打包，收藏！！！！