ORACLE空间管理实验8：数据块格式分析--DUMP结合BBED
2014-01-28 13:30
609 查看
使用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
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> 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
####################实验准备步骤：
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 477Block 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空间管理实验7：块管理之MMSM--为什么SYSTEM/UNDO/TEMP是MMSM管理？
- Maven仓库中添加Oracle驱动包
- oracle 成绩分段 存储过程实现
- oracle 10g cluvfy bug Could not find a suitable set of interfaces for VIPs.
- ORA-01841: (完整) 年份值必须介于 -4713 和 +9999 之间, 且不为 0
- oracle行转列和列转行
- Oracle V$SESSION详解
- oracle killed会话不释放的问题
- oracle tool
- Oracle System密码忘记 密码修改、删除账号锁定lock
- oracle分区表之hash分区表的使用及扩展
- Oracle学习教程：动态SQL与游标详解
- Oracle8i到Oracle11g的主要变化
- How to Install Oracle Java JDK on Ubuntu Linux
- ORACLE空间管理实验6：块管理之ASSM下插入操作--高水位的影响及大并发插入的性能问题
- ORACLE空间管理实验5：块管理之ASSM下高水位的影响--删除和查询
- ORACLE空间管理实验4：块管理之ASSM三级位图结构
- ORACLE空间管理实验3：区管理之大区小区对I/O性能的影响
- ORACLE空间管理实验2：区的管理与分配
- ORACLE空间管理实验1：探索LMT表空间管理下数据文件头的结构及位图中区的记录方式