深入SecureFile—新一代LOB揭秘

实名ID

mark,抽空拜读一下！

yexichang

原帖由 Yong Huang 于 2011-1-20 06:59 发表
Very well written. Indeed http://www.orafan.net/blog/352.html is more readable. Please remove the duplicate part starting with "这比BasicFile空闲空篇博文".

I have a strong feeling event 45050 is related to what is called in-memory dispensers. The event may flush or dump those dispensers. But it's *very* undocumented and I can't get it to work. More about these dispensers can be found in patent:
http://www.freepatentsonline.com/7664799.html

It's interesting that Oracle calls this technology SecureFiles and SecureFile LOBs. But I bet most users care more about the compression part of the technology than the security part.

Yong Huang

Yong Huang老大太猛了，的确找到了45050的event，可以dump出secure file的的chunk分配信息

Yong Huang

原帖由 yexichang 于 2011-1-24 21:36 发表

Yong Huang老大太猛了，的确找到了45050的event，可以dump出secure file的的chunk分配信息

Good to know. Please share with us what you find about this event. How did you use it? What's in the dumped trace file? Thanks.

Yong Huang

wing hong

after setting the event, event="45050 trace name context forever, level 32768"
then do a test like this :
create table t1(c1 number,c2 clob)
lob (c2) store as securefile (
disable storage in row chunk 8192 RETENTION  NOCACHE LOGGING
);

ALTER TABLE t1 MODIFY LOB(c2) (COMPRESS high);

insert into t1 values( 1, 'ABCDEF');
commit;

In trace file , we will see things like :

ktsla_ins_chunk xid: 0x0006.00b.00048556
ktsla_split_chunk Begin Txn:  xid: 0x0006.010.00048831
ktsla_ins_chunk xid: 0x0006.010.00048831
Chunk Allocated: 0x1db4405 len:12 ctime:1
Chunk Allocated: 0x1db4462 len:1 ctime:0

the information particular interesting is:
"Chunk Allocated: 0x1db4462 ", which is the chunk used by this lob.

wing hong

But I confused on this :
db version 11.2.0.1 ,

for this lob locator:
####
col  9: [47]
00 54 00 01 02 0c 00 80 00 01 00 00 00 01 00 00 09 48 df 55 00 1b 40 92 00
05 00 0e 31 81 05 0c 47 31 00 2c 91 01 00 01 01 83 94 1f 01 2c 91
LOB
Locator:
  Length:        84(47)
  Version:        1
  Byte Length:    1
  LobID: 00.00.00.01.00.00.09.48.df.55
  Flags[ 0x02 0x0c 0x00 0x80 ]:
    Type: CLOB
    Storage: SecureFile
    Characterset Format: IMPLICIT
    Partitioned Table: No
    Options: ReadWrite
  SecureFile Header:
    Length:   27
    Old Flag: 0x40 [ SecureFile ]
    Flag 0:   0x92 [ COMPR INODE Valid ]
    Layers:
      Lengths Array: COMPR:5 INODE:14
      COMPR:
        Version           :  1
        Compression Level :  High
        Flags             :  0x81
        Size              :  5
        Head CU           :  Yes
        Compressed Len    :  3143
        Head CU Len       :  3143
      INODE:
        31 00 2c 91 01 00 01 01 83 94 1f 01 2c 91

########
Everything up to the byte (0c 47 ) is clear , i.e from "00 54 00 01 02 0c 00 80 00 01 00 00 00 01 00 00 09 48 df 55 00 1b 40 92 00  05 00 0e 31 81 05 0c 47 ".  ( 0c 47 is len ( 3143) ) .

but I can't figure out how to interpret the INODE information , "31 00 2c 91 01 00 01 01 83 94 1f 01 2c 91".

"01 83 94 1f" is the RDBA of the chunk allocated for lob data storage. the "01" after that , maybe means just 1 block.
but what 's the meaning of "2c 91" afterwards ? and what's the meaning of "31 00 2c 91 01 00 01" ?

wing hong

Ok . "2c 91" is the length of uncompressed version. Though still don't understand why it appears twice.

wing hong

In comparison, the basic file version of the same lob is much easier to read   ( it has a DBA Array)

col  9: [56]
00 54 00 01 02 0c 00 00 00 01 00 00 00 01 00 00 09 c1 46 27 00 24 05 00 00
00 00 04 17 03 00 00 00 00 00 03 02 26 76 23 02 26 76 24 02 26 76 25 02 26
76 26 02 26 76 27
LOB
Locator:
  Length:        84(56)
  Version:        1
  Byte Length:    1
  LobID: 00.00.00.01.00.00.09.c1.46.27
  Flags[ 0x02 0x0c 0x00 0x00 ]:
    Type: CLOB
    Storage: BasicFile
    Enable Storage in Row
    Characterset Format: IMPLICIT
    Partitioned Table: No
    Options: ReadWrite
  Inode:
    Size:     36
    Flag:     0x05 [ Valid InodeInRow(ESIR) ]
    Future:   0x00 (should be '0x00')
    Blocks:   4
    Bytes:    5891
    Version:  00000.0000000003
    DBA Array[5]:
      0x02267623 0x02267624 0x02267625 0x02267626
      0x02267627
col 10: [ 7]  78 6e 06 12 18 32 38

sundog315

vage

好文，

carlos。zh

新版本咋不直接将BasicFile 去掉呢？
是否意味着basicfile与securefile对比还有可取的地方呢？