签到成功

知道了

CNDBA社区CNDBA社区

ORACLE数据块内部结构研究

2018-03-08 09:27 2472 0 原创 ORACLE
作者: Marvinn

Oracle 数据块的研究
最近,结合网上一些前辈的数据块内部结构剖析文章以及英文版的dissassembling_the_data_block资料对数据块进行学习了一下,如有不妥或不正之处,还请指教,谢谢…http://www.cndba.cn/Marvinn/article/2674http://www.cndba.cn/Marvinn/article/2674

http://www.cndba.cn/Marvinn/article/2674

数据块结构:块头+事务列表槽+表级目录+行级目录+自由空间+数据区+块尾http://www.cndba.cn/Marvinn/article/2674

创建表空间以及测试表
sqlplus / as sysdba
create tablespace test datafile '/u01/oracle/oradata/ORCL/datafile/test.dbf' size 10M autoextend on;
alter user scott default tablespace test;
conn scott/tiger;
create table T_7521 as select * from dba_objects;

查看数据文件号以及数据行记录所在数据块(这里测试取前10行)
SQL> select rowid,dbms_rowid.rowid_relative_fno(rowid) rel_fno,dbms_rowid.rowid_block_number(rowid) blockno from T_7521 where rownum<=10;

ROWID                 REL_FNO    BLOCKNO
------------------ ---------- ----------
AAAVg6AAIAAAACLAAA          8        139
AAAVg6AAIAAAACLAAB          8        139
AAAVg6AAIAAAACLAAC          8        139
AAAVg6AAIAAAACLAAD          8        139
AAAVg6AAIAAAACLAAE          8        139
AAAVg6AAIAAAACLAAF          8        139
AAAVg6AAIAAAACLAAG          8        139
AAAVg6AAIAAAACLAAH          8        139
AAAVg6AAIAAAACLAAI          8        139
AAAVg6AAIAAAACLAAJ          8        139

10 rows selected.

可以看到这十行数据都存在于8号数据文件和139号数据块中

转储dump数据块

SQL> alter system dump datafile 8 block 139;

System altered.

查看当前会话系统进程
SQL> select p.spid from v$process p,v$session s where p.addr=s.paddr and s.sid in (select sid from v$mystat);

SPID
------------------------------------------------
28961

打开trace文件所在目录user_dump_dest 
SQL> show parameter dump

NAME                                 TYPE
------------------------------------ ----------------------
VALUE
------------------------------
background_core_dump                 string
partial
background_dump_dest                 string
/u01/oracle/diag/rdbms/orcl/or
cl/trace
core_dump_dest                       string
/u01/oracle/diag/rdbms/orcl/or
cl/cdump
max_dump_file_size                   string

NAME                                 TYPE
------------------------------------ ----------------------
VALUE
------------------------------
unlimited
shadow_core_dump                     string
partial
user_dump_dest                       string
/u01/oracle/diag/rdbms/orcl/orcl/trace

oracle@test:/u01/oracle/diag/rdbms/orcl/orcl/trace>cd /u01/oracle/diag/rdbms/orcl/orcl/trace
oracle@test:/u01/oracle/diag/rdbms/orcl/orcl/trace>ls *28961.trc
orcl_ora_28961.trc
oracle@test:/u01/oracle/diag/rdbms/orcl/orcl/trace>vi orcl_ora_28961.trc
以下是数据块中的内容....

数据块头信息区

Block dump from disk:
buffer tsn: 9 rdba: 0x0200008b (8/139)
scn: 0x0000.00130a96 seq: 0x02 flg: 0x04 tail: 0x0a960602
frmt: 0x02 chkval: 0x5d7c type: 0x06=trans data
Hex dump of block: st=0, typ_found=1

------------------------------------------------------------
buffer tsn:9 --该快对应表空间号,当前是9号表空间

rdba: 0x0200008b (8/139) --表示相对数据10块的地址,表示该块在8号数据文件第139个块,用4个字节32位来表示(即每位数用4位二进制数表示),前10位为相对数据文件号,后22位为数据块号
0200008b = 0000 0010 0000 0000 0000 0000 1000 1011
可以看到前10位转换成十进制为8,后22位转换成十进制为139

scn: 0x0000.00130a96 --数据块头部SCN,总共占用6个字节,前2个字节表示SCN Wrap = 13,后4个字节表示SCN Base = 0a96,如果SCN Base达到了4个字节表示的最大值,SCN Wrap + 1,SCN Base 清 0

seq: 0x02 --Sequence number, incremented for every change made to the block at the same SCN。这里可以理解为数据块的版本

 flg: 0x04  --Flag:
                 0x01 新块
                 0x02 延迟修改的块
                 0x04 检查保留的块
                 0x08 临时块
 tail: 0x0a960602 --即 tail check, 存放于数据块的最后4个字节,用于数据块一致性检查
                 tail check组成:
                 SCN Base + type + seq 即tail:0x0a960602 =0a96 + 06 + 02
 frmt: 0x02     --块格式  01表示Oracle 7, 02表示Oracle 8+

 chkval: 0x5d7c  --块检查值,我们知道如果参数DB_BLOCK_CHECKSUM=TRUE,那么数据块在读入buffer和写入数据文件的之前都要做检查计算,如果计算值和数据块中chkval记录的值不匹配就会标记该块是坏块

 type: 0x06=trans data --块类型  trans=data 说明该块存储的是数据而非索引等其他数据对象
     参考表格:
     Header Block Types  
ID  Type  
01  Undo segment header  
02  Undo data block  
03  Save undo header  
04  Save undo data block  
05  Data segment header (temp, index, data and so on)  
06  KTB managed data block (with ITL)  
07  Temp table data block (no ITL)  
08  Sort Key  
09  Sort Run  
10  Segment free list block  
11  Data file heade

数据区、空闲区

http://www.cndba.cn/Marvinn/article/2674

数据区是真正存储数据的地方;空闲区是块内部自由空闲空间,用于INSERT以及UPDATE数据操作

Dump of memory from 0x00007FAE400DDA00 to 0x00007FAE400DFA00
7FAE400DDA00 0000A206 0200008B 00130A96 04020000  [................]
7FAE400DDA10 00005D7C 00000001 0001583A 00130A90  [|]......:X......]
7FAE400DDA20 00000000 00320003 02000088 0000FFFF  [......2.........]
7FAE400DDA30 00000000 00000000 00000000 00008000  [................]
7FAE400DDA40 00130A90 00000000 00000000 00000000  [................]
7FAE400DDA50 00000000 00000000 00000000 00000000  [................]
        Repeat 1 times
7FAE400DDA70 00000000 00000000 00000000 00580100  [..............X.]
7FAE400DDA80 00C2FFFF 03700432 00000370 1F330058  [....2.p.p...X.3.]
7FAE400DDA90 1E981EE4 1DFA1E4B 1D541DAC 1CB71D06  [....K.....T.....]
7FAE400DDAA0 1C0D1C69 1B741BC0 1ACF1B1E 1A331A81  [i.....t.......3.]
7FAE400DDAB0 199719E6 18FF194B 186118B0 17C81815  [....K.....a.....]
7FAE400DDAC0 172D1779 168B16DA 15E81636 154C159A  [y.-.....6.....L.]
7FAE400DDAD0 14AF14FE 140C1464 136C13BB 12CE131A  [....d.....l.....]
7FAE400DDAE0 12331280 119811E6 10FD1149 105F10AF  [..3.....I....._.]
7FAE400DDAF0 0FC61013 0F280F77 0E8A0ED9 0DED0E3C  [....w.(.....<...]
7FAE400DDB00 0D400D91 0C9E0CF0 0BFD0C4C 0B5B0BAC  [..@.....L.....[.]
7FAE400DDB10 0AC30B0F 0A230A76 097F09D2 08E0092C  [....v.#.....,...]
7FAE400DDB20 083C0891 07A007EE 07060752 066A06B8  [..<.....R.....j.]
7FAE400DDB30 05C8061A 05230576 048104CE 00000432  [....v.#.....2...]
7FAE400DDB40 00000000 00000000 00000000 00000000  [................]
        Repeat 53 times
7FAE400DDEA0 00000000 00000000 00000000 002C0000  [..............,.]
7FAE400DDEB0 5953030E 5F490753 4241544E C102FF31  [..SYS.I_NTAB1...]
7FAE400DDEC0 5AC1025A 444E4905 78075845 0C180871  [Z..Z.INDEX.xq...]
7FAE400DDED0 78072526 0C180871 32132526 2D333130  [&%.xq...&%.2013-]
7FAE400DDEE0 322D3830 31313A34 3A37333A 56053633  [08-24:11:37:36.V]
7FAE400DDEF0 44494C41 4E014E01 C1024E01 0E002C05  [ALID.N.N.N...,..]
7FAE400DDF00 53595303 41544E05 02FF2442 C10259C1  [.SYS.NTAB$...Y..]
7FAE400DDF10 41540503 07454C42 18087178 0725260C  [..TABLE.xq...&%.]
                .
                .
                .
            此处省略输出
                .
                .
                .
FAE400DF900 333A3733 41560535 0144494C 014E014E  [37:35.VALID.N.N.]
7FAE400DF910 02C1024E 030E002C 04535953 244E4F43  [N...,...SYS.CON$]
7FAE400DF920 1DC102FF 051DC102 4C424154 71780745  [........TABLE.xq]
7FAE400DF930 260C1808 71780724 350C1808 30321329  [...&$.xq...5).20]
7FAE400DF940 302D3331 34322D38 3A31313A 333A3733  [13-08-24:11:37:3]
7FAE400DF950 41560535 0144494C 014E014E 02C1024E  [5.VALID.N.N.N...]
7FAE400DF960 030E002C 07535953 53555F49 FF315245  [,...SYS.I_USER1.]
7FAE400DF970 022FC102 49052FC1 5845444E 08717807  [../../.INDEX.xq.]
7FAE400DF980 24260C18 08717807 24260C18 31303213  [..&$.xq...&$.201]
7FAE400DF990 38302D33 3A34322D 333A3131 35333A37  [3-08-24:11:37:35]
7FAE400DF9A0 4C415605 4E014449 4E014E01 2C05C102  [.VALID.N.N.N...,]
7FAE400DF9B0 53030E00 49055359 244C4F43 15C102FF  [...SYS.ICOL$....]
7FAE400DF9C0 0503C102 4C424154 71780745 260C1808  [....TABLE.xq...&]
7FAE400DF9D0 71780724 300C1808 30321326 302D3331  [$.xq...0&.2013-0]
7FAE400DF9E0 34322D38 3A31313A 333A3733 41560535  [8-24:11:37:35.VA]
7FAE400DF9F0 0144494C 014E014E 02C1024E 0A960602  [LID.N.N.N.......]

事务列表区http://www.cndba.cn/Marvinn/article/2674http://www.cndba.cn/Marvinn/article/2674

事务列表区包括了在这个数据块内的事务,也就是我们知道的ITL(interested transaction list),从中我们可以知道XID(transaction id),UBA(undo block address)等信息
事物列表区分析:

http://www.cndba.cn/Marvinn/article/2674

Block header dump:  0x0200008b     --rdba
 Object id on Block? Y           --该块是否属于某个对象
 seg/obj: 0x1583a  csc: 0x00.130a90  itc: 3  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x2000088 ver: 0x01 opc: 0
     inc: 0  exflg: 0

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0xffff.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.00130a90
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x03   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
bdba: 0x0200008b

seg/obj: 0x1583a  --该数据块中对象的object_id。前面我们dump的是表T_7521,下边来验证一下:

SQL> select to_number('1583a','xxxxxx') from dual;

TO_NUMBER('1583A','XXXXXX')
---------------------------
                      88122

SQL> col object_name for a30;
SQL> set linesize 9999
SQL> select object_id,object_name,object_type from dba_objects where object_id=88122;

 OBJECT_ID OBJECT_NAME                    OBJECT_TYPE
---------- ------------------------------ --------------------------------------
     88122 T_7521                         TABLE

csc: 0x00.130a90  --SCN at last Block CleanOut,表示最后一次块清除(Block CleanOut)时候的SCN。 
itc: 3   --块中ITL slot的数量,我们看下边的ITL,的确只有3个slot。 
flg: E  --flg: 0 表示此块被放置在自由列表(freelist)中
             E 表示ASSM管理 
typ: 1 - DATA  --类型1表示数据,类型2表示索引 
bdba  --Block relative data block address(RDBA)段头块,也就是对象的第一个块地址
ver    对象version
opc,inc 对象operation/insert count

下边我们重点看一下ITL事务槽。Oracle的每个数据块中都有一个或者多个事务槽,每一个对数据块的并发访问
事务都会占用一个事务槽。 
每个事务的ITL事务槽由槽位号、XID、Uba、Flag、Lck、Scn/Fsc几部分组成
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0xffff.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.00130a90
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x03   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000

Xid:事务id,在回滚段事务表中有一条记录和这个事务对应。
        Xid组成:回滚段编号(XIDUSN) + 事务槽编号(XIDSLOT) + 序号(XIDSQN)
                (同一个事务可能具有多个 SCN ,实际上每一个 DML 操作都有一个SCN)
Uba:回滚段地址,该事务对应的回滚段地址。
        Uba组成:回滚块地址[undo文件号(UBAFIL)和数据块号(UBABLK)]+回滚序列号(UBASQN)+回滚记录号(UBAREC) 
如上显示,可知当前dump块中,并没有占用事务槽编号以及lck为0,说明该块上不存在事务操作

Example:

     Itl           Xid                         Uba                          Flag   Lck        Scn/Fsc 
0x01   0x0006.020.00000271  0x00800205.0257.13  C---     0         scn 0x0000.001732c4 
0x02   0x0008.006.00000279  0x00800351.0278.15  ----      1         fsc 0x0000.00000000

SQL> select xidusn,xidslot,xidsqn,ubafil,ubablk,ubasqn,ubarec from v$transaction; 
    XIDUSN    XIDSLOT     XIDSQN     UBAFIL     UBABLK     UBASQN     UBAREC 
    ---------- ---------- ---------- ---------- ---------- ---------- ---------- 
         8          6        633         2       849          632           21

Flag:事务标志位。这个标志位就记录了这个事务的操作状态,各个标志的含义分别是
    ---- = 事务是活动的,或者在块清除前提交事务
    C = 事物已经提交(SCN已经是最大值),锁已经被清除 
    B = this undo record contains the undo for this ITL entry 
    U = 事物已经提交,但是锁还没有清除 
    T  = 当块清除的SCN被记录时,该事务仍然是活动的,块上如果有已经提交的事务,那么在clean ount的时候,块会被进行清除,但是这个块里面的事务不会被清除

Lck:表示这个事务所影响的行数
    我们看到01号事物槽Lck为0,因为该事物槽中的事务Flag为C,证明该事物已经提交,锁也被清楚掉了,该事物槽可以被重用了。Example示例中 02号事物槽Lck为1,是因为我对第一行做了一个更新,并且没有提交

Scn/Fsc:Commit SCN或者快速提交(Fast Commit Fsc)的SCN 
    每条记录中的行级锁对应Itl条目lb,对应于Itl列表中的序号,即那个事务在该记录上产生的锁    
(
    对于Oracle来说,对于一个事务,可以是快速提交、也可以是延迟提交,目的都是为了提高提交的速度。提交以后,oracle需要对ITL事务槽、每一行的锁定标记进行清除。如果是快速提交,那么在提交的时候,会将事务表和每一个数据块的ITL槽进行清除。但是锁定标记可能没有清除,等下次用到的时候再进行清除。如果是延迟提交,那么在提交的时候,只是将事务表进行清除,并没有对ITL事务槽进行清除,每一行的锁定标记也没有清除。因此C和U的情况特别多。块清除的过程并不包括每个行的锁定标记的清除,主要指的是ITL的清除。 
注意: 
    1、事务槽中首先记录的是Xid和Uba,只有在提交以后,当对这个数据块进行cleanout的时候,才会更新Flag和Scn。因此Oracle总是以事务表中对这个数据块的Scn以及Flag为准。 
    2、一个事务开始以后,在一个数据块上得到一个事务槽,那么在这个事务提交以前,这个事务槽会一直占用,直到这个事务提交释放这个事务槽。 
    3、只有在已经提交以后,这个itl事务槽中的scn才会有数值。 
    4、事务是否已经提交、事务对应的SCN,这些信息都是以回滚段事务表中的为主,事务槽中的不准确 
    5、事务槽中的事务id和uba地址是准确的 
    6、事务槽1中的事务id和回滚段中的事务id肯定不是一样的,不同回滚段中的事务id也一定不一样

)
关于事务槽ITL等待

中间插入一些关于ITL知识

ITL等待
      发生等待的场景:
     1.超过maxtrans配置的最大ITL数
      2.initrans不足,没有足够的free space来扩展ITL
      解决方法:
      1.maxtrans不足:这一情况是由高并发引起的:同一数据块上的事务量已经超出了其实际允许的ITL数。因此,要解决这类问题就需要从应用着手,减少事务的并发量;长事务,在保证数据完整性的前提下,增加commit的频率,修改为短事务,减少资源占用事件。而对于OLAP系统来说(例如,其存在高并发量的数据录入模块),可以考虑增大数据块大小。
      2.initrans不足:数据块上的ITL数量并没有达到MAX TRANS的限制,发生这种情况的表通常会被经常UPDATE,从而造成预留空间(PCTFREE)被填满。如果我们发现这类ITL等待对系统已经造成影响,可以通过增加表的INITRANS或者PCTFREE来解决(视该表上的并发事务量而定,通常,如果并发量高,建议优先增加INITRANS,反之,则优先考虑增加PCTFREE)。
  要注意的一点是,如果是使用ALTER TABLE的方式修改这2个参数的话,只会影响新的数据块,而不会改变已有数据的数据块——要做的这一点,需要将数据导出/导入、重建表。

ITL重用后如何实现前ITL读一致性:
     ORACLE通过ITL条目中记录的回滚段地址找到回滚段,实现读一致性,如果事务已提交,ITL就可以被重用,但是若前一个ITL被重用,前一个ITL的读一致性是如何实现的呢?
     假定block只有一个itl,假定第一个事务的时候产生了 ITL-0 

     第二个事务来了,产生了 ITL-1 ,ITL-1 里面的UBA 可以找到回滚段地址,回滚段中除了记录了 block用户数据的 before image 外还记录了  ITL-0 的信息。

     第三个事务来了,产生了 ITL-2  , ITL-2 中 UBA 指向回滚段,回滚段中 也记录了 ITL-1 的信息。

     这样当一个查询若需要ITL-0时候的信息,则找到当前block,发现是 ITL-2 ,根据UBA找到回滚段进行 roll 得到  变化前 block ,这个时候发现block中是 ITL-1 . 还不能满足需求。 于是再根据 ITL-1 中的 UBA 又去回滚段中找到数据来进行roll,得到一个block 数据,这个时候block中就有了 ITL-0。
     通过根据当前ITL进行递归的方式找到数据,实现之前ITL的独一致性。

数据块尾

块尾存储数据块的描述信息

data_block_dump,data header at 0x7fae400dda7c
===============
tsiz: 0x1f80                --Total Data Area Size (数据区的大小 单位/bytes)
hsiz: 0xc2                    --Data Header Size(数据块头大小 单位/bytes)
pbl: 0x7fae400dda7c            --ptr to buffer holding the block(指向这个数据块在内存中映象的指针)
bdba: 0x0200008b             --block dba / rdba(数据块地址
    76543210
flag=--------
ntab=1                        --number of tables (>1 is a cluster)
nrow=88                        --number of rows(块中数据记录行数)
frre=-1                        --first free row index entry,-1值说明表上没有创建索引(按需求看是否需要手动建索引)
fsbo=0xc2                    --free space begin offset(空闲空间起始位置)
fseo=0x432                    --free space end offset(空闲空间结束位置)
avsp=0x370                    --available space in the block(可用空间) 
tosp=0x370                    --total available space when all txs commit
0xe:pti[0]      nrow=88 offs=0        --该块初始位置,偏移量为0,块上总共有88条记录
0x12:pri[0]     offs=0x1f33            --第1条记录在偏移量为0x1f33的地方
0x14:pri[1]     offs=0x1ee4            --第2条记录在偏移量为0x1ee4的地方,下边行记录所在位置以此类推 
0x16:pri[2]     offs=0x1e98
0x18:pri[3]     offs=0x1e4b
0x1a:pri[4]     offs=0x1dfa
0x1c:pri[5]     offs=0x1dac
0x1e:pri[6]     offs=0x1d54
0x20:pri[7]     offs=0x1d06
0x22:pri[8]     offs=0x1cb7
0x24:pri[9]     offs=0x1c69
0x26:pri[10]    offs=0x1c0d
0x28:pri[11]    offs=0x1bc0
    .
    .
 此处省略输出
     .
     .
0xb0:pri[79]    offs=0x6b8
0xb2:pri[80]    offs=0x66a
0xb4:pri[81]    offs=0x61a
0xb6:pri[82]    offs=0x5c8
0xb8:pri[83]    offs=0x576
0xba:pri[84]    offs=0x523
0xbc:pri[85]    offs=0x4ce
0xbe:pri[86]    offs=0x481
0xc0:pri[87]    offs=0x432

数据块结构中行目录

block_row_dump:
tab 0, row 0, @0x1f33
tl: 77 fb: --H-FL-- lb: 0x0  cc: 14
col  0: [ 3]  53 59 53
col  1: [ 5]  49 43 4f 4c 24
col  2: *NULL*
col  3: [ 2]  c1 15
col  4: [ 2]  c1 03
col  5: [ 5]  54 41 42 4c 45
col  6: [ 7]  78 71 08 18 0c 26 24
col  7: [ 7]  78 71 08 18 0c 30 26
col  8: [19]  32 30 31 33 2d 30 38 2d 32 34 3a 31 31 3a 33 37 3a 33 35
col  9: [ 5]  56 41 4c 49 44
col 10: [ 1]  4e
col 11: [ 1]  4e
col 12: [ 1]  4e
col 13: [ 2]  c1 02

行数据详解
tl:    表示Row Size(number of bytes plus data)

fb:表示Flag Byte 
    K- Cluster key 
    H- head of row piece 
    D- Deleted row 
    F- first data piece   
    L- last data piece   
    P- First column cintinues from previous row 
    N- Last column cintinues in next piece    
当我们delete一行数据的时候,数据并不是物理的被删除,而是把该行标记为删除,这个时候fb应该是--HDFL-- 而不是原来的--H-FL--
当删除数据时显示HDFL,并不是真正的删除而是标志为删除。
如果一个row没有被删除,那么它就具有上面的3个属性,即Flag 表示为:--H-FL--. 这里的字母分别代表属性的首字母。其对应的值:32 + 8 + 4 =44 or 0x2c.
如果一个row 被delete了,那么row flag 就会更新,bitmask 里的deleted 被设置为16. 此时row flag 为: 32 + 16 + 8 + 4 = 60 or 0x3c.

lb:    表示lock byte,表示锁定该行的这个事务在itl的入口
    Example: 0x0 说明事物在该数据行上的锁已经被清除,并已提交
            0x2 说明事物在该数据行上的锁还没清除,并且该锁指向02号(也就是ITL中的0x02第二个事务槽)事物槽(提交方式为快速提交或者延迟提交)         -- 依次类推其他

cc: 表示number of columns in this Row piece(字段数) 当前为14个字段Col数

下面每行解释如上,输出结果省略.....
tab 0, row 1, @0x1ee4
tl: 79 fb: --H-FL-- lb: 0x0  cc: 14
col  0: [ 3]  53 59 53
col  1: [ 7]  49 5f 55 53 45 52 31
col  2: *NULL*
col  3: [ 2]  c1 2f
col  4: [ 2]  c1 2f
col  5: [ 5]  49 4e 44 45 58
col  6: [ 7]  78 71 08 18 0c 26 24
col  7: [ 7]  78 71 08 18 0c 26 24
col  8: [19]  32 30 31 33 2d 30 38 2d 32 34 3a 31 31 3a 33 37 3a 33 35
col  9: [ 5]  56 41 4c 49 44
col 10: [ 1]  4e
col 11: [ 1]  4e
col 12: [ 1]  4e
col 13: [ 2]  c1 05

        .
        .
        .

tab 0, row 87, @0x432
tl: 79 fb: --H-FL-- lb: 0x0  cc: 14
col  0: [ 3]  53 59 53
col  1: [ 7]  49 5f 4e 54 41 42 31
col  2: *NULL*
col  3: [ 2]  c1 5a
col  4: [ 2]  c1 5a
col  5: [ 5]  49 4e 44 45 58
col  6: [ 7]  78 71 08 18 0c 26 25
col  7: [ 7]  78 71 08 18 0c 26 25
col  8: [19]  32 30 31 33 2d 30 38 2d 32 34 3a 31 31 3a 33 37 3a 33 36
col  9: [ 5]  56 41 4c 49 44
col 10: [ 1]  4e
col 11: [ 1]  4e
col 12: [ 1]  4e
col 13: [ 2]  c1 05
end_of_block_dump
End dump data blocks tsn: 9 file#: 8 minblk 139 maxblk 139

至此数据块内部结构到此结束.

http://www.cndba.cn/Marvinn/article/2674

验证

http://www.cndba.cn/Marvinn/article/2674

关于行中的数据,我们以表T_7521第一行来验证一下:

SQL查询第一行的数据
SQL> col owner for a20;
SQL> col object_name for a20;
SQL> col SUBOBJECT_NAME for a20;
SQL> col OBJECT_TYPE for a20;
SQL> col TIMESTAMP for a20;
SQL> col EDITION_NAME for a20;
SQL> set linesize 9999
SQL> select * from SCOTT.T_7521 where rownum=1;

OWNER                OBJECT_NAME          SUBOBJECT_NAME        OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE          CREATED             LAST_DDL_TIME       TIMESTAMP        STATUS         TE GE SE  NAMESPACE EDITION_NAME
-------------------- -------------------- -------------------- ---------- -------------- -------------------- ------------------- ------------------- -------------------- -------------- -- -- -- ---------- --------------------
SYS                  ICOL$                                             20              2 TABLE                2013-08-24 11:37:35 2013-08-24 11:47:37 2013-08-24:11:37:35  VALID      N  N  N           1

表结构信息
SQL> DESC SCOTT.T_7521
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 OWNER                                              VARCHAR2(30)
 OBJECT_NAME                                        VARCHAR2(128)
 SUBOBJECT_NAME                                     VARCHAR2(30)
 OBJECT_ID                                          NUMBER
 DATA_OBJECT_ID                                     NUMBER
 OBJECT_TYPE                                        VARCHAR2(19)
 CREATED                                            DATE
 LAST_DDL_TIME                                      DATE
 TIMESTAMP                                          VARCHAR2(19)
 STATUS                                             VARCHAR2(7)
 TEMPORARY                                          VARCHAR2(1)
 GENERATED                                          VARCHAR2(1)
 SECONDARY                                          VARCHAR2(1)
 NAMESPACE                                          NUMBER
 EDITION_NAME                                       VARCHAR2(30)

数据块中显示:
col  0: [ 3]  53 59 53
col  1: [ 5]  49 43 4f 4c 24
col  2: *NULL*

col 0  (53 59 53):
SQL> select dump('SYS',16) from dual;

DUMP('SYS',16)
--------------------------------------------
Typ=96 Len=3: 53,59,53

col 1 (49 43 4f 4c 24):
SQL> select   OBJECT_NAME  from SCOTT.T_7521 where rownum=1;

OBJECT_NAME
--------------------------------------------------------------------------------
ICOL$

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

DUMP('ICOL$',16)
--------------------------------------------------------
Typ=96 Len=5: 49,43,4f,4c,24

col 2 (*NULL*):
SQL> select   SUBOBJECT_NAME from SCOTT.T_7521 where rownum=1;

SUBOBJECT_NAME
------------------------------------------------------------

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

DUMP('',
--------
NULL

至此验证通过....其他字段验证省略....

版权声明:本文为博主原创文章,未经博主允许不得转载。

用户评论
* 以下用户言论只代表其个人观点,不代表CNDBA社区的观点或立场
Marvinn

Marvinn

关注

路漫漫其修远兮、吾将上下而求索

  • 99
    原创
  • 0
    翻译
  • 2
    转载
  • 36
    评论
  • 访问:458370次
  • 积分:449
  • 等级:中级会员
  • 排名:第12名
精华文章
    最新问题
    查看更多+
    热门文章
      热门用户
      推荐用户
        Copyright © 2016 All Rights Reserved. Powered by CNDBA · 皖ICP备2022006297号-1·

        QQ交流群

        注册联系QQ