数据块中col number如何对应实际的列名

etl2007

借用斑竹的实验结果一用
ODM TEST:

SQL> create table t_row(t1 int) tablespace users;

Table created.

SQL> insert into t_row values(1);

1 row created.

SQL> commit;

Commit complete.

SQL> alter system checkpoint;

System altered.


SQL> select dbms_rowid.rowid_relative_fno(rowid) "FILE NUMBER",
  2         dbms_rowid.rowid_block_number(rowid) "BLOCK NUMBER"
  3    from t_row;

FILE NUMBER BLOCK NUMBER
----------- ------------
          4       589862

SQL> alter system dump datafile 4 block 589862;

System altered.

SQL> oradebug setmypid;
Statement processed.
SQL> oradebug tracefile_name;
/s01/admin/G10R21/udump/g10r21_ora_24962.trc


Start dump data blocks tsn: 4 file#: 4 minblk 589862 maxblk 589862
buffer tsn: 4 rdba: 0x01090026 (4/589862)
scn: 0x0000.010d299b seq: 0x01 flg: 0x06 tail: 0x299b0601
frmt: 0x02 chkval: 0x81db type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x0000000006B88600 to 0x0000000006B8A600


Block header dump:  0x01090026
Object id on Block? Y
seg/obj: 0xde25  csc: 0x00.10d2999  itc: 2  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x1090021 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0003.00b.00000df1  0x02003f22.04a0.1b  --U-    1  fsc 0x0000.010d299b
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000

data_block_dump,data header at 0x6b88664
===============
tsiz: 0x1f98
hsiz: 0x14
pbl: 0x06b88664
bdba: 0x01090026
     76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x1f92
avsp=0x1f7b
tosp=0x1f7b
0xe:pti[0]      nrow=1  offs=0
0x12:pri[0]     offs=0x1f92
block_row_dump:
tab 0, row 0, @0x1f92
tl: 6 fb: --H-FL-- lb: 0x1  cc: 1

col  0: [ 2]  c1 02

end_of_block_dump
End dump data blocks tsn: 4 file#: 4 minblk 589862 maxblk 589862



SQL> select dump(1,16) from dual;

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


我的问题是
col  0 是如何映射到表 t_row 中 t1 这个列名的呢？

Maclean Liu(刘相兵

Column Specification

The column definitions must be specified in the order the columns are stored in the segment, that is ordered by col$.segcol#. This is not necessarily the same order as the columns where specified in the create table statement. Cluster columns are moved to the front, longs to the end. Columns added to the table with alter table command, are always stored last.


create table col$                                            /* column table */
( obj#          number not null,             /* object number of base object */
  col#          number not null,                 /* column number as created */
  segcol#       number not null,                 /* column number in segment */
  segcollength  number not null,             /* length of the segment column */
  offset        number not null,                         /* offset of column */
  name          varchar2("M_IDEN") not null,               /* name of column */
  type#         number  not null,                     /* data type of column */
                                           /* for ADT column, type# = DTYADT */
  length        number  not null,               /* length of column in bytes */
  fixedstorage  number  not null,   /* flags: 0x01 = fixed, 0x02 = read-only */
  precision#    number,                                         /* precision */
  scale         number,                                             /* scale */
  null$         number not null,                     /* 0 = NULLs permitted, */
                                                /* > 0 = no NULLs permitted  */
  deflength     number,              /* default value expression text length */
  default$      long,                       /* default value expression text */

  /*
   * If a table T(c1, addr, c2) contains an ADT column addr which is stored
   * exploded, the table will be internally stored as
   *              T(c1, addr, C0003$, C0004$, C0005$, c2)
   * Of these, only c1, addr and c2 are user visible columns. Thus, the
   * user visible column numbers for (c1, addr, C0003$, C0004$, C0005$, c2)
   * will be 1,2,0,0,0,3. And the corresponding internal column numbers will
   * be 1,2,3,4,5,6.
   *
   * Some dictionary tables like icol$, ccol$ need to contain intcol# so
   * that we can have indexes and constraints on ADT attributes. Also, these
   * tables also need to contain col# to maintain backward compatibility.
   * Most of these tables will need to be accessed by col#, intcol# so
   * indexes are created on them based on (obj#, col#) and (obj#, intcol#).
   * Indexes based on col# have to be non-unique if ADT attributes might
   * appear in the table. Indexes based on intcol# can be unique.
   */
  intcol#       number not null,                   /* internal column number */
  property      number not null,           /* column properties (bit flags): */
                /* 0x0001 =       1 = ADT attribute column                   */
                /* 0x0002 =       2 = OID column                             */
                /* 0x0004 =       4 = nested table column                    */
                /* 0x0008 =       8 = virtual column                         */
                /* 0x0010 =      16 = nested table's SETID$ column           */
                /* 0x0020 =      32 = hidden column                          */
                /* 0x0040 =      64 = primary-key based OID column           */
                /* 0x0080 =     128 = column is stored in a lob              */
                /* 0x0100 =     256 = system-generated column                */
                /* 0x0200 =     512 = rowinfo column of typed table/view     */
                /* 0x0400 =    1024 = nested table columns setid             */
                /* 0x0800 =    2048 = column not insertable                  */
                /* 0x1000 =    4096 = column not updatable                   */
                /* 0x2000 =    8192 = column not deletable                   */
                /* 0x4000 =   16384 = dropped column                         */
                /* 0x8000 =   32768 = unused column - data still in row      */
            /* 0x00010000 =   65536 = virtual column                         */
            /* 0x00020000 =  131072 = place DESCEND operator on top          */
            /* 0x00040000 =  262144 = virtual column is NLS dependent        */
            /* 0x00080000 =  524288 = ref column (present as oid col)        */
            /* 0x00100000 = 1048576 = hidden snapshot base table column      */
            /* 0x00200000 = 2097152 = attribute column of a user-defined ref */
            /* 0x00400000 = 4194304 = export hidden column,RLS on hidden col */
            /* 0x00800000 = 8388608 = string column measured in characters   */
           /* 0x01000000 = 16777216 = virtual column expression specified    */
           /* 0x02000000 = 33554432 = typeid column                          */
           /* 0x04000000 = 67108864 = Column is encrypted                    */
          /* 0x20000000 = 536870912 = Column is encrypted without salt       */

  /* The spares may be used as the column's NLS character set,
   * the number of distinct column values, and the column's domain.
   */
  /* the universal character set id maintained by NLS group */
  charsetid     number,                              /* NLS character set id */
  /*
   * charsetform
   */
  charsetform   number,
  /* 1 = implicit: for CHAR, VARCHAR2, CLOB w/o a specified set */
  /* 2 = nchar: for NCHAR, NCHAR VARYING, NCLOB */
  /* 3 = explicit: for CHAR, etc. with "CHARACTER SET ..." clause */
  /* 4 = flexible: for PL/SQL "flexible" parameters */
  spare1        number,                      /* fractional seconds precision */
  spare2        number,                  /* interval leading field precision */
  spare3        number,            /* maximum number of characters in string */
  spare4        varchar2(1000),          /* NLS settings for this expression */
  spare5        varchar2(1000),
  spare6        date
)
cluster c_obj#(obj#)
/

Maclean Liu(刘相兵

dc_columns  即 dictionary cache columns是 shared pool 中 dictionary cache(row cache)的一部分， 它的数据来源于  col$ 字典基础表，  col$ 基础表记录了 每一个object 相关的col 信息 包括了 col的type 。

Oracle instance启动时会读取 col$ 填充 dictionary cache， 在生成  sql plan 时只需要 reference DC_COLUMNS 就可以知道 block中列相关的信息 。

psufnxk2000

create table t_b(t1 int,t2 varchar2(10));

insert into t_b values (1,'aaa');
commit;
select dbms_rowid.rowid_relative_fno(rowid) fileno ,  dbms_rowid.rowid_block_number(rowid) blockid from t_b;
也把块dump出来，

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0005.029.000001f7  0x00808143.02d2.20  --U-    1  fsc 0x0000.7dc73904
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000

data_block_dump,data header at 0x7b82264
===============
tsiz: 0x1f98
hsiz: 0x14
pbl: 0x07b82264
bdba: 0x014005d6
     76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x1f8e
avsp=0x1f7a
tosp=0x1f7a
0xe:pti[0]        nrow=1        offs=0
0x12:pri[0]        offs=0x1f8e
block_row_dump:
tab 0, row 0, @0x1f8e
tl: 10 fb: --H-FL-- lb: 0x1  cc: 2
col  0: [ 2]  c1 02
col  1: [ 3]  61 61 61
end_of_block_dump
End dump data blocks tsn: 6 file#: 5 minblk 1494 maxblk 1494


上面的
col  0: [ 2]  c1 02
col  1: [ 3]  61 61 61
看起来像是 col 0 第一列
col 1  第二列
[ ] 中的是占的大小，  最后是值 。。