bitmap index 的研究 

简介: 今天在研究Bitmap Index internal的东东,不过刚开始就被卡住了,dump出来了bitmap index 根据DSI知道有个叫start rowid,end rowid的东东,却不能将rowid还原回file_id,block_id。

天在研究Bitmap Index internal的东东,不过刚开始就被卡住了,dump出来了bitmap index 根据DSI知道有个叫start rowid,end rowid的东东,却不能将rowid还原回file_id,block_id。现在终于搞懂了呵呵,写出来分享下。哎,前面的路还很长,很长..................

SQL> create table test(name varchar2(100),age number);

表已创建。

SQL> insert into test values('Robinson',20);

已创建 1 行。

SQL> insert into test values('Luobingsen',20);

已创建 1 行。

SQL> insert into test values('Luo, Bing-Sen',22);

已创建 1 行。

SQL> insert into test values('MR.Robinson',22);

已创建 1 行。

SQL> commit;

提交完成。

SQL> select distinct dbms_rowid.rowid_block_number(rowid) from test;

DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------
                                  30

可以看见这些数据都存储在同一个block中。

SQL> select dbms_rowid.rowid_relative_fno(rowid)file_id, dbms_rowid.rowid_block_number(rowid)block_id,dbms_rowid.rowid_row_number(rowid) row# from test;

   FILE_ID   BLOCK_ID       ROW#
---------- ---------- ----------
         6         30          0
         6         30          1
         6         30          2
         6         30          3

这些数据存储于datafile 6 blck 30中 并且为 0,1,2,3行

SQL> create bitmap index b_age on test(age);

索引已创建。

SQL> select segment_name,segment_type,file_id,block_id from dba_extents where segment_name='B_AGE';

SEGMENT_NA SEGMENT_TY    FILE_ID   BLOCK_ID
---------- ---------- ---------- ----------
B_AGE      INDEX               6         33

SQL> select segment_name,blocks from dba_segments where segment_name='B_AGE';

SEGMENT_NAME                                                                         BLOCKS
-------------------------------------------------------------------------------- ----------
B_AGE                                                                                     8

SQL> alter system dump datafile 6 block  min 33 block max  40;

系统已更改。
 部分DUMP文件
Leaf block dump
===============
header address 166208100=0x9e82264
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 4
kdxcosdc 0
kdxconro 2
kdxcofbo 40=0x28
kdxcofeo 7992=0x1f38
kdxcoavs 7952
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8036
row#0[8014] flag: ------, lock: 0, len=22
col 0; len 2; (2):  c1 15  ---这里表示20 
col 1; len 6; (6):  01 80 00 1e 00 00 -- 这里 表示start rowid
col 2; len 6; (6):  01 80 00 1e 00 07 -- 这里 表示end rowid
col 3; len 2; (2):  c8 03                     这个暂时不讨论 这篇博客是讲的 怎么讲 rowid还原回file_id,block_id,row#
row#1[7992] flag: ------, lock: 0, len=22
col 0; len 2; (2):  c1 17
col 1; len 6; (6):  01 80 00 1e 00 00
col 2; len 6; (6):  01 80 00 1e 00 07
col 3; len 2; (2):  c8 0c
----- end of leaf block dump -----

由前面可知 file_id应该是 6 block_id应该是30,如何将ROWID还原回去呢?

其实我们要知道ROWID的组成原理,这里的ROWID非标准的ROWID,这里的ROWID没有记录object#,只记录了file_id,

block_id,row#.

其实我们只需要取rowid的前八位就能得到file_id,block_id

SQL> select to_number('0180001e','xxxxxxxxxxxx') from dual;

TO_NUMBER('0180001E','XXXXXXXXXXXX')
------------------------------------
                            25165854

SQL> select dbms_utility.data_block_address_file('25165854') FILE_ID,dbms_utility.data_block_address_block('25165854') BLOCK_ID from dual;

   FILE_ID   BLOCK_ID
---------- ----------
         6         30

为什么这样就能够得到file_id,block_id呢,其实这个原理和DBA(data block address)的原理是一样的。通常我们dump一个block就能看见DBA(16位表示)信息,这个DBA信息就记录了file_id,block_id的信息,它是用前10位表示file_id,后22位表示block_id,所以这里还有种方法可以将rowid还原回file_id,block_id。方法就是将01 80 00 转换为2进制,取二进制前10位换算成十进制就是6,后面的22位就是30



前一篇blog探讨了 bitmap index 的 start rowid,end rowid  是怎么存储的,现在 继续研究 bitmap index

 

SQL> create table test as select * from dba_objects where 1=2;

Table created

SQL> insert into test select * from dba_objects where rownum<=100;

100 rows inserted

SQL> commit;

Commit complete

SQL> select distinct status from test;

STATUS

-------

VALID

SQL> select min(object_id),max(object_id) from test;

MIN(OBJECT_ID) MAX(OBJECT_ID)

-------------- --------------

             2            101

SQL> update test set status='INVALID' where object_id>11 and object_id<22;

10 rows updated

SQL> commit;

Commit complete

SQL> select dbms_rowid.rowid_relative_fno(rowid)file_id, dbms_rowid.rowid_block_number(rowid)block_id,

  2  dbms_rowid.rowid_row_number(rowid) row# from test where object_id>11 and object_id<22;

   FILE_ID   BLOCK_ID       ROW#

---------- ---------- ----------

         6         28          0

         6         28          3

         6         28         10

         6         28         11

         6         28         18

         6         28         19

         6         28         22

         6         28         32

         6         28         37

         6         28         43

10 rows selected

这里我们知道这10行存储在file_id 6 block_id 28,行0,3 ......37,43等等

SQL> create bitmap index b_status on test(status) ;

Index created

SQL> select file_id,block_id from dba_extents where segment_name='B_STATUS';

   FILE_ID   BLOCK_ID

---------- ----------

         6         33

这里我们知道ORACLE用了一个区来存储bitmap b_status,由于测试环境是10g,我采用的是本地管理的表空间,那么从第33个block开始到35个block是

位图管理的信息,所以本实验不dump这些block.

SQL> select blocks from dba_segments where segment_name='B_STATUS';

    BLOCKS

----------

         8

SQL> alter system dump datafile 6 block min 36 block max 40;

System altered

部分dump信息

Leaf block dump

===============

header address 142746212=0x8822264

kdxcolev 0

KDXCOLEV Flags = - - -

kdxcolok 0

kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y

kdxconco 4

kdxcosdc 0

kdxconro 2

kdxcofbo 40=0x28

kdxcofeo 7964=0x1f1c

kdxcoavs 7924

kdxlespl 0

kdxlende 0

kdxlenxt 0=0x0

kdxleprv 0=0x0

kdxledsz 0

kdxlebksz 8036

row#0[8004] flag: ------, lock: 0, len=32

col 0; len 7; (7):  49 4e 56 41 4c 49 44  --- 这一行表示索引key值 ,将其还原表示 INVALID 具体转换过程见下面

col 1; len 6; (6):  01 80 00 1c 00 00     ---这一行表示start rowid 取0180001c将其转换为 file_id=6,block_id=28,00 00 表示 start row#为0

col 2; len 6; (6):  01 80 00 1c 00 2f     ---这一行表示end rowid ,取0180001c将其转换为file_id=6,block_id=28,2f表示end row#为 47

col 3; len 7; (7):  cd 09 0c 4c 00 21 08  ---这一行表示 bitmap segment,用1表示这一行存在,0表示不存在,具体解释见下面

row#1[7964] flag: ------, lock: 0, len=40

col 0; len 5; (5):  56 41 4c 49 44        

col 1; len 6; (6):  01 80 00 1c 00 00     

col 2; len 6; (6):  01 80 00 1d 00 07     

col 3; len 17; (17):  cf f6 f3 b3 ff de f7 ff ff cb ff ff ff 0f f8 4b ff

----- end of leaf block dump -----

buffer tsn: 7 rdba: 0x01800025 (6/37)

scn: 0x0000.0008f5c1 seq: 0x01 flg: 0x06 tail: 0xf5c10601

frmt: 0x02 chkval: 0xa5ba type: 0x06=trans data

Hex dump of block: st=0, typ_found=1

还原dump值的存储过程

SQL> declare n varchar2(2000);

  2       begin

  3       dbms_stats.convert_raw_value('494e56414c4944',n);

  4       dbms_output.put_line(n);

  5       end;

  6  /

INVALID

根据rowid得到file_id,block_id

SQL> select to_number('0180001c','xxxxxxxxxxxx') from dual;

TO_NUMBER('0180001C','XXXXXXXX

------------------------------

                      25165852

SQL> select dbms_utility.data_block_address_file('25165852') FILE_ID,dbms_utility.data_block_address_block('25165852') BLOCK_ID from dual;

   FILE_ID   BLOCK_ID

---------- ----------

         6         28

SQL> select to_number('2f','xx') from dual;

TO_NUMBER('2F','XX')

--------------------

                  47

bitmap segment 信息,首先将其转换为2进制,注意,hex_to_bin函数是我自己写的

SQL> select hex_to_bin('cd090c4c002108') from dual;

HEX_TO_BIN('CD090C4C002108')

--------------------------------------------------------------------------------

1100 1101 0000 1001 0000 1100 0100 1100 0000 0000 0010 0001 0000 1000

根据DSI 042上面关于bitmap index的描述 每八位 组成一个chunk,阅读的时候从右到左,首八位不表示位图信息,那么转换的结果如下

10010000      00110000       00110010             00000000 10000100      00010000  注意,这里row#信息以0开始

row#0,row#3,  row#10,row11, row#18,row#19,row#22    无     row#32,row#37  row#43

ok,现在各位能明白bitmap index 了吧,rowid 里面记录的 file_id,block_id是准确的,要想定位某一行必须通过bitmap segment来定位

下面继续实验

SQL> select distinct dbms_rowid.rowid_block_number(rowid)block_id from test;

  BLOCK_ID

----------

        28

        29

可以看到这个表用了两个block

SQL> select object_id,status from test where dbms_rowid.rowid_block_number(rowid)=29;

 OBJECT_ID STATUS

---------- -------

        94 VALID

        95 VALID

        96 VALID

        97 VALID

        98 VALID

        99 VALID

       100 VALID

       101 VALID

8 rows selected

SQL> update test set status='INVALID' where object_id=94;

1 row updated

SQL> commit;

Commit complete

SQL> select dbms_rowid.rowid_relative_fno(rowid)file_id, dbms_rowid.rowid_block_number(rowid)block_id,

  2   dbms_rowid.rowid_row_number(rowid) row# from test where object_id>11 and object_id=94;

   FILE_ID   BLOCK_ID       ROW#

---------- ---------- ----------

         6         29          0

SQL> alter system dump datafile 6 block min 36 block max 40;

System altered

部分dump信息

Leaf block dump

===============

header address 134357604=0x8022264

kdxcolev 0

KDXCOLEV Flags = - - -

kdxcolok 0

kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y

kdxconco 4

kdxcosdc 0

kdxconro 2

kdxcofbo 40=0x28

kdxcofeo 7890=0x1ed2

kdxcoavs 7922

kdxlespl 0

kdxlende 0

kdxlenxt 0=0x0

kdxleprv 0=0x0

kdxledsz 0

kdxlebksz 8036

row#0[7930] flag: ------, lock: 2, len=34

col 0; len 7; (7):  49 4e 56 41 4c 49 44  ---这里表示INVALID

col 1; len 6; (6):  01 80 00 1c 00 00     ---start rowid 的 file_id 6,block_id 28, 起始row#为0

col 2; len 6; (6):  01 80 00 1d 00 07     ---end rowid 的   file_id 6,block_id 29  结束row#为7 ,要理解row#,它只是表示一个范围而已

col 3; len 9; (9):  cd 09 0c 4c 00 21 08 c0 3f ----具体分析步骤见下面

row#1[7890] flag: ------, lock: 2, len=40

col 0; len 5; (5):  56 41 4c 49 44

col 1; len 6; (6):  01 80 00 1c 00 00

col 2; len 6; (6):  01 80 00 1d 00 07

col 3; len 17; (17):  cf f6 f3 b3 ff de f7 ff ff cb ff ff ff 0f f8 4b fe

----- end of leaf block dump -----

根据rowid得到file_id,block_id

SQL> select to_number('0180001d','xxxxxxxxxxxx') from dual;

TO_NUMBER('0180001D','XXXXXXXX

------------------------------

                      25165853

SQL> select dbms_utility.data_block_address_file('25165853') FILE_ID,dbms_utility.data_block_address_block('25165853') BLOCK_ID from dual;

   FILE_ID   BLOCK_ID

---------- ----------

         6         29

bigmap segment的分析

SQL> select hex_to_bin('cd090c4c002108c03f') from dual;

 

HEX_TO_BIN('CD090C4C002108C03F')

----------------------------------------------------------------------------------------------------

1100 1101 0000 1001 0000 1100 0100 1100 0000 0000 0010 0001 0000 1000 1100 0000 0011 1111

同样首先将其转换为2进制,去掉首八位,得到00001001 00001100 01001100 00000000 00100001 00001000 11000000 11000000 00111111

然后以每八位为一个chunk,从右往左读,得到如下信息

1001000 00110000 00110010 00000000 10000100 00010000    00000011 11111100

   这前面的 就不用再算了     奶奶的这里不能理解了 看来还得继续研究 不再同一个block的情况

2010-03-22续

今天google了一下,发现bitmap index dump 出来的结果和oradebug出来的不一样 看来还得继续 研究oradebug了




天在研究Bitmap Index internal的东东,不过刚开始就被卡住了,dump出来了bitmap index 根据DSI知道有个叫start rowid,end rowid的东东,却不能将rowid还原回file_id,block_id。现在终于搞懂了呵呵,写出来分享下。哎,前面的路还很长,很长..................

SQL> create table test(name varchar2(100),age number);

表已创建。

SQL> insert into test values('Robinson',20);

已创建 1 行。

SQL> insert into test values('Luobingsen',20);

已创建 1 行。

SQL> insert into test values('Luo, Bing-Sen',22);

已创建 1 行。

SQL> insert into test values('MR.Robinson',22);

已创建 1 行。

SQL> commit;

提交完成。

SQL> select distinct dbms_rowid.rowid_block_number(rowid) from test;

DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------
                                  30

可以看见这些数据都存储在同一个block中。

SQL> select dbms_rowid.rowid_relative_fno(rowid)file_id, dbms_rowid.rowid_block_number(rowid)block_id,dbms_rowid.rowid_row_number(rowid) row# from test;

   FILE_ID   BLOCK_ID       ROW#
---------- ---------- ----------
         6         30          0
         6         30          1
         6         30          2
         6         30          3

这些数据存储于datafile 6 blck 30中 并且为 0,1,2,3行

SQL> create bitmap index b_age on test(age);

索引已创建。

SQL> select segment_name,segment_type,file_id,block_id from dba_extents where segment_name='B_AGE';

SEGMENT_NA SEGMENT_TY    FILE_ID   BLOCK_ID
---------- ---------- ---------- ----------
B_AGE      INDEX               6         33

SQL> select segment_name,blocks from dba_segments where segment_name='B_AGE';

SEGMENT_NAME                                                                         BLOCKS
-------------------------------------------------------------------------------- ----------
B_AGE                                                                                     8

SQL> alter system dump datafile 6 block  min 33 block max  40;

系统已更改。
 部分DUMP文件
Leaf block dump
===============
header address 166208100=0x9e82264
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 4
kdxcosdc 0
kdxconro 2
kdxcofbo 40=0x28
kdxcofeo 7992=0x1f38
kdxcoavs 7952
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8036
row#0[8014] flag: ------, lock: 0, len=22
col 0; len 2; (2):  c1 15  ---这里表示20 
col 1; len 6; (6):  01 80 00 1e 00 00 -- 这里 表示start rowid
col 2; len 6; (6):  01 80 00 1e 00 07 -- 这里 表示end rowid
col 3; len 2; (2):  c8 03                     这个暂时不讨论 这篇博客是讲的 怎么讲 rowid还原回file_id,block_id,row#
row#1[7992] flag: ------, lock: 0, len=22
col 0; len 2; (2):  c1 17
col 1; len 6; (6):  01 80 00 1e 00 00
col 2; len 6; (6):  01 80 00 1e 00 07
col 3; len 2; (2):  c8 0c
----- end of leaf block dump -----

由前面可知 file_id应该是 6 block_id应该是30,如何将ROWID还原回去呢?

其实我们要知道ROWID的组成原理,这里的ROWID非标准的ROWID,这里的ROWID没有记录object#,只记录了file_id,

block_id,row#.

其实我们只需要取rowid的前八位就能得到file_id,block_id

SQL> select to_number('0180001e','xxxxxxxxxxxx') from dual;

TO_NUMBER('0180001E','XXXXXXXXXXXX')
------------------------------------
                            25165854

SQL> select dbms_utility.data_block_address_file('25165854') FILE_ID,dbms_utility.data_block_address_block('25165854') BLOCK_ID from dual;

   FILE_ID   BLOCK_ID
---------- ----------
         6         30

为什么这样就能够得到file_id,block_id呢,其实这个原理和DBA(data block address)的原理是一样的。通常我们dump一个block就能看见DBA(16位表示)信息,这个DBA信息就记录了file_id,block_id的信息,它是用前10位表示file_id,后22位表示block_id,所以这里还有种方法可以将rowid还原回file_id,block_id。方法就是将01 80 00 转换为2进制,取二进制前10位换算成十进制就是6,后面的22位就是30

bitmap index 的研究 


前一篇blog探讨了 bitmap index 的 start rowid,end rowid  是怎么存储的,现在 继续研究 bitmap index

 

SQL> create table test as select * from dba_objects where 1=2;

Table created

SQL> insert into test select * from dba_objects where rownum<=100;

100 rows inserted

SQL> commit;

Commit complete

SQL> select distinct status from test;

STATUS

-------

VALID

SQL> select min(object_id),max(object_id) from test;

MIN(OBJECT_ID) MAX(OBJECT_ID)

-------------- --------------

             2            101

SQL> update test set status='INVALID' where object_id>11 and object_id<22;

10 rows updated

SQL> commit;

Commit complete

SQL> select dbms_rowid.rowid_relative_fno(rowid)file_id, dbms_rowid.rowid_block_number(rowid)block_id,

  2  dbms_rowid.rowid_row_number(rowid) row# from test where object_id>11 and object_id<22;

   FILE_ID   BLOCK_ID       ROW#

---------- ---------- ----------

         6         28          0

         6         28          3

         6         28         10

         6         28         11

         6         28         18

         6         28         19

         6         28         22

         6         28         32

         6         28         37

         6         28         43

10 rows selected

这里我们知道这10行存储在file_id 6 block_id 28,行0,3 ......37,43等等

SQL> create bitmap index b_status on test(status) ;

Index created

SQL> select file_id,block_id from dba_extents where segment_name='B_STATUS';

   FILE_ID   BLOCK_ID

---------- ----------

         6         33

这里我们知道ORACLE用了一个区来存储bitmap b_status,由于测试环境是10g,我采用的是本地管理的表空间,那么从第33个block开始到35个block是

位图管理的信息,所以本实验不dump这些block.

SQL> select blocks from dba_segments where segment_name='B_STATUS';

    BLOCKS

----------

         8

SQL> alter system dump datafile 6 block min 36 block max 40;

System altered

部分dump信息

Leaf block dump

===============

header address 142746212=0x8822264

kdxcolev 0

KDXCOLEV Flags = - - -

kdxcolok 0

kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y

kdxconco 4

kdxcosdc 0

kdxconro 2

kdxcofbo 40=0x28

kdxcofeo 7964=0x1f1c

kdxcoavs 7924

kdxlespl 0

kdxlende 0

kdxlenxt 0=0x0

kdxleprv 0=0x0

kdxledsz 0

kdxlebksz 8036

row#0[8004] flag: ------, lock: 0, len=32

col 0; len 7; (7):  49 4e 56 41 4c 49 44  --- 这一行表示索引key值 ,将其还原表示 INVALID 具体转换过程见下面

col 1; len 6; (6):  01 80 00 1c 00 00     ---这一行表示start rowid 取0180001c将其转换为 file_id=6,block_id=28,00 00 表示 start row#为0

col 2; len 6; (6):  01 80 00 1c 00 2f     ---这一行表示end rowid ,取0180001c将其转换为file_id=6,block_id=28,2f表示end row#为 47

col 3; len 7; (7):  cd 09 0c 4c 00 21 08  ---这一行表示 bitmap segment,用1表示这一行存在,0表示不存在,具体解释见下面

row#1[7964] flag: ------, lock: 0, len=40

col 0; len 5; (5):  56 41 4c 49 44        

col 1; len 6; (6):  01 80 00 1c 00 00     

col 2; len 6; (6):  01 80 00 1d 00 07     

col 3; len 17; (17):  cf f6 f3 b3 ff de f7 ff ff cb ff ff ff 0f f8 4b ff

----- end of leaf block dump -----

buffer tsn: 7 rdba: 0x01800025 (6/37)

scn: 0x0000.0008f5c1 seq: 0x01 flg: 0x06 tail: 0xf5c10601

frmt: 0x02 chkval: 0xa5ba type: 0x06=trans data

Hex dump of block: st=0, typ_found=1

还原dump值的存储过程

SQL> declare n varchar2(2000);

  2       begin

  3       dbms_stats.convert_raw_value('494e56414c4944',n);

  4       dbms_output.put_line(n);

  5       end;

  6  /

INVALID

根据rowid得到file_id,block_id

SQL> select to_number('0180001c','xxxxxxxxxxxx') from dual;

TO_NUMBER('0180001C','XXXXXXXX

------------------------------

                      25165852

SQL> select dbms_utility.data_block_address_file('25165852') FILE_ID,dbms_utility.data_block_address_block('25165852') BLOCK_ID from dual;

   FILE_ID   BLOCK_ID

---------- ----------

         6         28

SQL> select to_number('2f','xx') from dual;

TO_NUMBER('2F','XX')

--------------------

                  47

bitmap segment 信息,首先将其转换为2进制,注意,hex_to_bin函数是我自己写的

SQL> select hex_to_bin('cd090c4c002108') from dual;

HEX_TO_BIN('CD090C4C002108')

--------------------------------------------------------------------------------

1100 1101 0000 1001 0000 1100 0100 1100 0000 0000 0010 0001 0000 1000

根据DSI 042上面关于bitmap index的描述 每八位 组成一个chunk,阅读的时候从右到左,首八位不表示位图信息,那么转换的结果如下

10010000      00110000       00110010             00000000 10000100      00010000  注意,这里row#信息以0开始

row#0,row#3,  row#10,row11, row#18,row#19,row#22    无     row#32,row#37  row#43

ok,现在各位能明白bitmap index 了吧,rowid 里面记录的 file_id,block_id是准确的,要想定位某一行必须通过bitmap segment来定位

下面继续实验

SQL> select distinct dbms_rowid.rowid_block_number(rowid)block_id from test;

  BLOCK_ID

----------

        28

        29

可以看到这个表用了两个block

SQL> select object_id,status from test where dbms_rowid.rowid_block_number(rowid)=29;

 OBJECT_ID STATUS

---------- -------

        94 VALID

        95 VALID

        96 VALID

        97 VALID

        98 VALID

        99 VALID

       100 VALID

       101 VALID

8 rows selected

SQL> update test set status='INVALID' where object_id=94;

1 row updated

SQL> commit;

Commit complete

SQL> select dbms_rowid.rowid_relative_fno(rowid)file_id, dbms_rowid.rowid_block_number(rowid)block_id,

  2   dbms_rowid.rowid_row_number(rowid) row# from test where object_id>11 and object_id=94;

   FILE_ID   BLOCK_ID       ROW#

---------- ---------- ----------

         6         29          0

SQL> alter system dump datafile 6 block min 36 block max 40;

System altered

部分dump信息

Leaf block dump

===============

header address 134357604=0x8022264

kdxcolev 0

KDXCOLEV Flags = - - -

kdxcolok 0

kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y

kdxconco 4

kdxcosdc 0

kdxconro 2

kdxcofbo 40=0x28

kdxcofeo 7890=0x1ed2

kdxcoavs 7922

kdxlespl 0

kdxlende 0

kdxlenxt 0=0x0

kdxleprv 0=0x0

kdxledsz 0

kdxlebksz 8036

row#0[7930] flag: ------, lock: 2, len=34

col 0; len 7; (7):  49 4e 56 41 4c 49 44  ---这里表示INVALID

col 1; len 6; (6):  01 80 00 1c 00 00     ---start rowid 的 file_id 6,block_id 28, 起始row#为0

col 2; len 6; (6):  01 80 00 1d 00 07     ---end rowid 的   file_id 6,block_id 29  结束row#为7 ,要理解row#,它只是表示一个范围而已

col 3; len 9; (9):  cd 09 0c 4c 00 21 08 c0 3f ----具体分析步骤见下面

row#1[7890] flag: ------, lock: 2, len=40

col 0; len 5; (5):  56 41 4c 49 44

col 1; len 6; (6):  01 80 00 1c 00 00

col 2; len 6; (6):  01 80 00 1d 00 07

col 3; len 17; (17):  cf f6 f3 b3 ff de f7 ff ff cb ff ff ff 0f f8 4b fe

----- end of leaf block dump -----

根据rowid得到file_id,block_id

SQL> select to_number('0180001d','xxxxxxxxxxxx') from dual;

TO_NUMBER('0180001D','XXXXXXXX

------------------------------

                      25165853

SQL> select dbms_utility.data_block_address_file('25165853') FILE_ID,dbms_utility.data_block_address_block('25165853') BLOCK_ID from dual;

   FILE_ID   BLOCK_ID

---------- ----------

         6         29

bigmap segment的分析

SQL> select hex_to_bin('cd090c4c002108c03f') from dual;

 

HEX_TO_BIN('CD090C4C002108C03F')

----------------------------------------------------------------------------------------------------

1100 1101 0000 1001 0000 1100 0100 1100 0000 0000 0010 0001 0000 1000 1100 0000 0011 1111

同样首先将其转换为2进制,去掉首八位,得到00001001 00001100 01001100 00000000 00100001 00001000 11000000 11000000 00111111

然后以每八位为一个chunk,从右往左读,得到如下信息

1001000 00110000 00110010 00000000 10000100 00010000    00000011 11111100

   这前面的 就不用再算了     奶奶的这里不能理解了 看来还得继续研究 不再同一个block的情况

2010-03-22续

今天google了一下,发现bitmap index dump 出来的结果和oradebug出来的不一样 看来还得继续 研究oradebug了



相关文章
|
1天前
|
人工智能 运维 安全
|
4天前
|
SpringCloudAlibaba 负载均衡 Dubbo
微服务架构下Feign和Dubbo的性能大比拼,到底鹿死谁手?
本文对比分析了SpringCloudAlibaba框架下Feign与Dubbo的服务调用性能及差异。Feign基于HTTP协议,使用简单,适合轻量级微服务架构;Dubbo采用RPC通信,性能更优,支持丰富的服务治理功能。通过实际测试,Dubbo在调用性能、负载均衡和服务发现方面表现更出色。两者各有适用场景,可根据项目需求灵活选择。
377 124
微服务架构下Feign和Dubbo的性能大比拼,到底鹿死谁手?
|
6天前
|
人工智能 JavaScript 测试技术
Qwen3-Coder入门教程|10分钟搞定安装配置
Qwen3-Coder 挑战赛简介:无论你是编程小白还是办公达人,都能通过本教程快速上手 Qwen-Code CLI,利用 AI 轻松实现代码编写、文档处理等任务。内容涵盖 API 配置、CLI 安装及多种实用案例,助你提升效率,体验智能编码的乐趣。
626 107
|
3天前
|
Java 数据库 数据安全/隐私保护
Spring 微服务和多租户:处理多个客户端
本文介绍了如何在 Spring Boot 微服务架构中实现多租户。多租户允许单个应用实例为多个客户提供独立服务,尤其适用于 SaaS 应用。文章探讨了多租户的类型、优势与挑战,并详细说明了如何通过 Spring Boot 的灵活配置实现租户隔离、动态租户管理及数据源路由,同时确保数据安全与系统可扩展性。结合微服务的优势,开发者可以构建高效、可维护的多租户系统。
199 127
|
3天前
|
Web App开发 前端开发 API
在折叠屏应用中,如何处理不同屏幕尺寸和设备类型的样式兼容性?
在折叠屏应用中,如何处理不同屏幕尺寸和设备类型的样式兼容性?
225 124
|
3天前
|
人工智能 数据可视化 测试技术
Coze平台指南(3):核心功能-创建智能体与设计角色
Coze 智能体是由大语言模型驱动,通过提示词设定角色,并借助知识库、插件和工作流扩展能力,以执行特定任务的AI助手。对测试工程师而言,精心设计的智能体可显著提升测试效率与质量,关键是要准确理解测试需求,并将其转化为智能体的角色设定和功能配置。建议进一步学习知识库与工作流,以深化应用。