Home  >  Article  >  Database  >  ORACLE空间管理实验8:数据块格式分析

ORACLE空间管理实验8:数据块格式分析

WBOY
WBOYOriginal
2016-06-07 15:50:431456browse

使用DUMP 数据块式结合BBED进行查看。 #################### 实验准备步骤 : BYS@ bys3create table test6(aa int,bb varchar2(10)); Table created. BYS@ bys3insert into test6 values(89,'bys'); 1 row created. BYS@ bys3insert into test6 values(69,'h

使用DUMP 数据块格式结合BBED进行查看。
####################实验准备步骤
BYS@ bys3>create table test6(aa int,bb varchar2(10));
Table created.
BYS@ bys3>insert into test6 values(89,'bys');
1 row created.
BYS@ bys3>insert into test6 values(69,'hello');
1 row created.
BYS@ bys3>commit;
Commit complete.
BYS@ bys3>alter system checkpoint;
System altered.
BYS@ bys3>select dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid) block#,aa,bb from test6;
     FILE#     BLOCK#         AA BB
---------- ---------- ---------- ----------
         4        477         89 bys
         4        477         69 hello
BYS@ bys3>alter system dump datafile 4 block 477;
System altered.
BYS@ bys3>select value from v$diag_info where name like 'De%';
VALUE
----------------------------------------------------------------------------------------------------

/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_8109.trc

DUMP数据块的信息解读

Start dump data blocks tsn: 4 file#:4 minblk 477 maxblk 477
Block dump from cache:  --这段信息来自buffer cache,详见: 详解Buffer Header--DUMP buffer结合X$BH视图各字段
Dump of buffer cache at level 4 for tsn=4 rdba=16777693
BH (0x22be4e74) file#: 4 rdba: 0x010001dd (4/477) class: 1 ba: 0x2286e000
  set: 3 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
  dbwrid: 0 obj: 23326 objn: 23326 tsn: 4 afn: 4 hint: f
  hash: [0x227e6b54,0x2a7f74ac] lru: [0x217ee3d4,0x20ff4e64]
  ckptq: [NULL] fileq: [NULL] objq: [0x217ee3ec,0x20ff4e7c] objaq: [0x217ee3f4,0x20ff4e84]
  st: XCURRENT md: NULL fpin: 'ktspbwh2: ktspfmdb' tch: 3
  flags: block_written_once redo_since_read
  LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [1]
  ###########################################数据块头部分
Block dump from disk:   --下面的信息才是来自数据文件中的块。
buffer tsn: 4 rdba: 0x010001dd (4/477)  --数据块中4-8字节是RDBA--下面BBED部分可以看到
scn: 0x0000.00874dbb seq: 0x01 flg: 0x06 tail: 0x4dbb0601
frmt: 0x02 chkval: 0xeb56 type: 0x06=trans data   --第四个字节对应
---flg:0x01 (新建块)0x2(数据块延迟清洗推进scn和seq) 0X04(设置校验和) 0x08(临时块)     type:0x06(表/索引块)
--frmt:  0x01(v7)  0x02(v8)   --与第三字节A2对应,表示8I以上版本

Hex dump of block: st=0, typ_found=1
Dump of memory from 0xB68A9200 to 0xB68AB200
B68A9200 0000A206 010001DD 00874DBB 06010000  [.........M......]   ---这一行的信息可以与块头中的SCN TYPE之类对应的。
B68A9210 0000EB56 00130001 00005B1E 00874DB6  [V........[...M..]
B68A9220 1FE80000 00321F02 010001D8 001A0002  [......2.........]
B68A9230 00001382 00C00B70 00070569 00002002  [....p...i.... ..]
………………………………
B68AB1D0 54415453 4D5F5355 454B5241 71780752  [STATUS_MARKER.xq]
B68AB1E0 2618100B 012C021E 46C10202 6C656805  [...&..,....F.hel]
B68AB1F0 012C6F6C 5AC10202 73796203 4DBB0601  [lo,....Z.bys...M]
##########################################下面是ITL
Block header dump:  0x010001dd
 Object id on Block? Y
 seg/obj: 0x5b1e  csc: 0x00.874db6  itc: 2  flg: E  typ: 1 - DATA      --数据类型是DATA。  
 -- seg/obj: 0x5b1e--对应的是dba_objects.data_object_id,未TRUNCATE操作过的表data_object_id与object_id相等。格式化也就是在块上写入这个seg/obj:
--csc: 0x00.874db6 延迟块清除时的SCN--查询时、第三次提交时--三个ITL会做延迟块清除
--flg: E   --指用的是ASSM,如果是O表示用的是free list
--typ: 1 - DATA 事务型的数据块(并且:数据块头的type:0x06),存放表和索引数据。

     brn: 0  bdba: 0x10001d8 ver: 0x01 opc: 0     
     inc: 0  exflg: 0
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0002.01a.00001382  0x00c00b70.0569.07  --U-    2  fsc 0x0000.00874dbb
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
--11G默认用快速提交,Flag是U,正常提交是C。
--Itl: ITL事务槽号的流水编号
--Xid:transac[X]tion identified(事务ID),由und的段号+undo的槽号+undo槽号的覆盖次数三部分组成
--Uba:undo block address记录了最近一次的该记录的前镜像(修改前的值)
--Flag:C是提交,U是快速提交,---是未提交(Flg C=Committed  U=Commit Upper Bound T=Active at CSC)
--Lck:锁住了几行数据,对应有几个行锁
--Scn/Fsc:Scn=SCN of commited TX; Fsc=Free space credit(bytes)
--这里fsc 0x0000.00874dbb是指提交的scn,这个值大于上次清除块时的scn=csc: 0x00.874db6(此scn是这个块中最小的SCN of commited)
--SCN WRAP:如果事务已提交并完成清洗,该字段保存事务提交SCN的SCN WRAP部分,否则该字段保存空闲预支字节数(FSC).比如删除了一行数据10个字节,在事务提前前,这10个字节就属于fsc(即会写到SCN WRAP),只有事务提交后,才能正式返回到空闲空间。


#################################################用户数据头
bdba: 0x010001dd  --当前数据块的DBA
data_block_dump,data header at 0xb68a9264
===============
tsiz: 0x1f98  块的total总可用空间 1f98--8088字节
hsiz: 0x16  --数据头部占的字节数-不固定

pbl: 0xb68a9264
     76543210
flag=--------
ntab=1              --数据块属于一个表, cluster表时不是1
nrow=2             --行数
frre=-1               --The first free row entry in the row directory 要加1
fsbo=0x16        --Free space begin offset  叫起始空间:可以存放数据空间的起始位置(即定义了数据层中空闲空间的起始offset)
fseo=0x1f82     -- Free space end offset  叫结束空间:可以存放数据空间的结束位置(即定义了数据层中空闲空间的结束offset)插入数据从此处开始--从后往前用
avsp=0x1f6c    -- --Available space for new entries  叫空闲空间:定义了数据层中空闲空间的字节数
tosp=0x1f6c     -- --Total space   叫最终空闲空间:定义了ITL中事务提交后,数据层中空闲空间的字节数
0xe:pti[0]      nrow=2  offs=0   --Table directory,整个表的开始,共2行数据 ,定义了该表在行索引中使用的插槽数
0x12:pri[0]     offs=0x1f8e   -Row index,叫行索引,定义了该块中包含的所有行数据的位置

0x14:pri[1]     offs=0x1f82

#######################################用户数据

block_row_dump:
tab 0, row 0, @0x1f8e  --1个表,第1行,@0x1f8e该表在行索引中的起始插槽号 8078
tl: 10 fb: --H-FL-- lb: 0x1  cc: 2
--fb: (Flag byte)--H-FL指H(Head piece of row)F(First data piece) L(Last data piece)
--lb: 0x1 --Lock byte和上面的ITL的lck相对应,表示这行是否被lock了
col  0: [ 2]  c1 5a   --第一行的第一列,有两个字符
col  1: [ 3]  62 79 73 --第一行的第二列,有三个字符

tab 0, row 1, @0x1f82        ----------使用这个转换为十进制在BBED以此为偏移量来查看,需要加100(ORACEL预留100字节)
tl: 12 fb: --H-FL-- lb: 0x1  cc: 2
col  0: [ 2]  c1 46
col  1: [ 5]  68 65 6c 6c 6f
end_of_block_dump
End dump data blocks tsn: 4 file#: 4 minblk 477 maxblk 477
最后四字节tail: 0xa3eb0601=scnBASE+flg+seq,如果不相等会报块损坏
###################

使用BBED查看数据块,与上一步DUMP信息进行对应

要节约篇幅哈哈,BBED中只讲与DUMP中的对应及一些重要字段的意义,不太重要的就要在上一步的DUMP中看了。
##########################
BBED> set file 4 block 477
        FILE#           4
        BLOCK#          477
BBED> dump
 File: /u01/oradata/bys3/user01.dbf (4)
 Block: 477              Offsets:    0 to  511           Dba:0x010001dd
------------------------------------------------------------------------
 06a20000 dd010001 bb4d8700 00000106 56eb0000 01001300 1e5b0000 b64d8700
 从BBED的第一行信息,因为大小端的问题,这里要两位两位倒着看。
 16进制中两个字符表示1bytes,所以要以2个16进制字符为单位(1byte)来进行转换:
 前面的个字节是:0000 a206  0100 01dd,可以看到和DUMP数据块中第一行前8个字节是一样的,

#####
BBED> map
 File: /u01/oradata/bys3/user01.dbf (4)
 Block: 477                                   Dba:0x010001dd
------------------------------------------------------------
 KTB Data Block (Table/Cluster)
 struct kcbh, 20 bytes                      @0      
 struct ktbbh, 72 bytes                     @20     
 struct kdbh, 14 bytes                      @100    
 struct kdbt[1], 4 bytes                    @114    
 sb2 kdbr[2]                                @118    
 ub1 freespace[8044]                        @122    
 ub1 rowdata[22]                            @8166   
 ub4 tailchk                                @8188 

##############################3
BBED> print kcbh   ---这里面信息全部可以与DUMP中的对应上。对应图中 cache layer层
struct kcbh, 20 bytes                       @0       
   ub1 type_kcbh                            @0        0x06  --块类型。。。。ub4--代表:unsign bytes 4--是字节数
   ub1 frmt_kcbh                            @1        0xa2  --版本8I以上
   ub1 spare1_kcbh                          @2        0x00  
   ub1 spare2_kcbh                          @3        0x00
   ub4 rdba_kcbh                            @4        0x010001dd -DBA
   ub4 bas_kcbh                             @8        0x00874dbb -SCN低位
   ub2 wrp_kcbh                             @12       0x0000     -SCN高位
   ub1 seq_kcbh                             @14       0x01    --序号
   ub1 flg_kcbh                             @15       0x06 (KCBHFDLC, KCBHFCKV)
   ub2 chkval_kcbh                          @16       0xeb56  --DUMP中chkval
   ub2 spare3_kcbh                          @18       0x0000


BBED> print ktbbh    ---与ITL 事务信息对应
struct ktbbh, 72 bytes          @20      
   ub1 ktbbhtyp                 @20       0x01 (KDDBTDATA)  --块类型
   union ktbbhsid, 4 bytes      @24         ---seg/obj:0x5b1e
      ub4 ktbbhsg1              @24       0x00005b1e
      ub4 ktbbhod1              @24       0x00005b1e
   struct ktbbhcsc, 8 bytes     @28        --csc: 0x00.874db6
      ub4 kscnbas               @28       0x00874db6
      ub2 kscnwrp               @32       0x0000
   sb2 ktbbhict                 @36       7938  --itc: 2我这里没对上
   ub1 ktbbhflg                 @38       0x32 (NONE) --flg: E
   ub1 ktbbhfsl                 @39       0x00
   ub4 ktbbhfnx                 @40       0x010001d8 --bdba:
   struct ktbbhitl[0], 24 bytes @44 --对应事务编号Xid:0x0002.01a.00001382   
      struct ktbitxid, 8 bytes  @44      
         ub2 kxidusn            @44       0x0002 -usn undo segment number
         ub2 kxidslt            @46       0x001a  --事务表第几行
         ub4 kxidsqn            @48       0x00001382 --行被重用次数
      struct ktbituba, 8 bytes  @52  --对应事务UBA 0x00c00b70.0569.07    
         ub4 kubadba            @52       0x00c00b70 --UNDO DBA
         ub2 kubaseq            @56       0x0569  --
         ub1 kubarec            @58       0x07
      ub2 ktbitflg              @60       0x2002 (KTBFUPB)
      union _ktbitun, 2 bytes   @62      
         sb2 _ktbitfsc          @62       0
         ub2 _ktbitwrp          @62       0x0000
      ub4 ktbitbas              @64       0x00874dbb
   struct ktbbhitl[1], 24 bytes @68      
      struct ktbitxid, 8 bytes  @68      
         ub2 kxidusn            @68       0x0000
         ub2 kxidslt            @70       0x0000
         ub4 kxidsqn            @72       0x00000000
      struct ktbituba, 8 bytes  @76      
         ub4 kubadba            @76       0x00000000
         ub2 kubaseq            @80       0x0000
         ub1 kubarec            @82       0x00
      ub2 ktbitflg              @84       0x0000 (NONE)
      union _ktbitun, 2 bytes   @86      
         sb2 _ktbitfsc          @86       0
         ub2 _ktbitwrp          @86       0x0000
      ub4 ktbitbas              @88       0x00000000

BBED> print kdbh  --对应的用户数据头
struct kdbh, 14 bytes     @100     
   ub1 kdbhflag           @100      0x00 (NONE)
   sb1 kdbhntab           @101      1  --对应DUMP中:ntab=1
   sb2 kdbhnrow           @102      2 --对应DUMP中:nrow=2
   sb2 kdbhfrre           @104     -1 --对应DUMP中:frre=-1
   sb2 kdbhfsbo           @106      22 --对应DUMP中:fsbo=0x16
   sb2 kdbhfseo           @108      8066 --对应DUMP中:fseo=0x1f82 插数据从此处开始
   sb2 kdbhavsp           @110      8044 --对应DUMP中avsp=0x1f6c
   sb2 kdbhtosp           @112      8044 --对应DUMP中tosp=0x1f6c
   
BBED> print kdbr  --对应的行索引信息
sb2 kdbr[0]    @118      8078  --对应DUMP中0x12:pri[0]     offs=0x1f8e
sb2 kdbr[1]    @120      8066  --对应DUMP中0x14:pri[1]     offs=0x1f82
##########
BBED> dump offset 8166  --这里DUMP出来的是行中的具体信息  第一行8078 第二行 8066 加100,从8166开始DUMP
 File: /u01/oradata/bys3/user01.dbf (4)
 Block: 477              Offsets: 8166 to 8191           Dba:0x010001dd
------------------------------------------------------------------------
 2c010202 c1460568 656c6c6f 2c010202 c15a0362 79730106 bb4d
02 c15a 03  62 7973  对应的第一行的值:  03是三个字节,
col  0: [ 2]  c1 5a
col  1: [ 3]  62 79 73

02 c14605  68 656c6c6f对应第二行的值:05是五个字节
col  0: [ 2]  c1 46
col  1: [ 5]  68 65 6c 6c 6f

BBED> print tailchk    --与DUMP中数据块最后四个字节对应4DBB0601,是数据块的校验值。
ub4 tailchk          @8188     0x4dbb0601




Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn