ORACLE空间管理实验8:数据块格式分析--DUMP结合BBED

使用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




你可能感兴趣的:(ORACLE空间管理实验8:数据块格式分析--DUMP结合BBED)