继ORACLE 11Gr2下redo里的轨迹之UPDATE(一)未完成的东西进行学习和分析
chang vector中涉及到很多事务的信息记录,这里会跳过
在分析过程中发现从change vector 1到change vector 4其中SCN记录递减的,按照日志顺序写的法则,应该是递增.
1、redo header信息:
REDO RECORD – Thread:1 RBA: 0x0000d5.00000003.0010 LEN: 0x024c VLD: 0x05
SCN: 0x0000.0021f662 SUBSCN: 1 12/23/2015 17:04:28
(LWN RBA: 0x0000d5.00000003.0010 LEN: 0002 NST: 0001 SCN: 0x0000.0021f661)
REDO RECORD – Thread:1 RBA: 0x0000d5.00000003.0010 LEN: 0x024c VLD: 0x05
说明了是线程1,seq号为213,3号块的16bytes处;
这条轨迹很重要,是寻找redo entires的地址
SQL> select l.thread#,l.sequence#,l.members,l.status,f.member
2 from v$log l,v$logfile f
3 where f.group#=l.group#;
THREAD# SEQUENCE# MEMBERS STATUS MEMBER
———- ———- ———- —————- ————————————————————
1 213 1 CURRENT /oradata/TRSEN/onlinelog/o1_mf_3_c6wp4qm5_.log
LEN:是针对此条redo entires的长度而非change vector的长度,转化成10进制单位 bytes,这里的长度是怎么计算的,估计只有oracle工程师清楚
VLD:REDO ENTRIES HEADER的大小
SCN:System Change Number at this RBA.
SUBSCN:Sequence at this SCN
SCN: 0x0000.0021f662 SUBSCN: 1 12/23/2015 17:04:28
时间记录这个scn+seq一般对应着数据块头的scn+seq,这个信息在恢复时很重要,因为会去找entries记录,就这相当于时间和地点
从实际中验证可能分如下情况:
1)、update数据后commit时,data block scn+seq是和commit的redo header相同:
update时操作redo header信息
EDO RECORD – Thread:1 RBA: 0x0000eb.00000002.0010 LEN: 0x0284 VLD: 0x05
SCN: 0x0000.0022fb4d SUBSCN: 1 12/24/2015 14:31:11==================》》》》》
(LWN RBA: 0x0000eb.00000002.0010 LEN: 0002 NST: 0001 SCN: 0x0000.0022fb4c)
CHANGE #1 TYP:0 CLS:35 AFN:3 DBA:0x00c00110 OBJ:4294967295 SCN:0x0000.0022fb3a SEQ:1 OP:5.2 ENC:0 RBL:0
ktudh redo: slt: 0x000b sqn: 0x00002915 flg: 0x0012 siz: 248 fbi: 0
commit时redo header信息
REDO RECORD – Thread:1 RBA: 0x0000eb.00000003.00a4 LEN: 0x00a4 VLD: 0x01
SCN: 0x0000.0022fb4e SUBSCN: 1 12/24/2015 14:31:11
CHANGE #1 TYP:0 CLS:35 AFN:3 DBA:0x00c00110 OBJ:4294967295 SCN:0x0000.0022fb4d SEQ:1 OP:5.4 ENC:0 RBL:0=====》》》》
ktucm redo: slt: 0x000b sqn: 0x00002915 srt: 0 sta: 9 flg: 0x2 ktucf redo: uba: 0x00c003e4.04e8.07 ext: 2 spc: 7324 fbi: 0
CHANGE #2 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:0 OP:24.4 ENC:0
disk data block信息
Block dump from disk:
buffer tsn: 4 rdba: 0x01000083 (4/131)
scn: 0x0000.0022fb4e seq: 0x01 flg: 0x06 tail: 0xfb4e0601======》》》》》
frmt: 0x02 chkval: 0xfab0 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00002AD0D829BA00 to 0x00002AD0D829DA00
2)、update数据后,db直接发生了checkpoint or dbwr写脏数据,data block scn+seq是和update操作轨迹的redo header相同:
update时操作redo header信息
REDO RECORD – Thread:1 RBA: 0x0000ef.00000002.0010 LEN: 0x027c VLD: 0x05
SCN: 0x0000.0022fee5 SUBSCN: 1 12/24/2015 14:54:18
(LWN RBA: 0x0000ef.00000002.0010 LEN: 0002 NST: 0001 SCN: 0x0000.0022fee4)
CHANGE #1 TYP:0 CLS:35 AFN:3 DBA:0x00c00110 OBJ:4294967295 SCN:0x0000.0022fec8 SEQ:1 OP:5.2 ENC:0 RBL:0
ktudh redo: slt: 0x0005 sqn: 0x00002914 flg: 0x0012 siz: 232 fbi: 0
uba: 0x00c00180.04e9.07 pxid: 0x0000.000.00000000
CHANGE #2 TYP:0 CLS:36 AFN:3 DBA:0x00c00180 OBJ:4294967295 SCN:0x0000.0022fec7 SEQ:3 OP:5.1 ENC:0 RBL:0
…省略….
disk data block信息
Block dump from disk:
buffer tsn: 4 rdba: 0x01000083 (4/131)
scn: 0x0000.0022fee5 seq: 0x01 flg: 0x04 tail: 0xfee50601===============》》》》
frmt: 0x02 chkval: 0xa1d4 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00002B7C5AB95A00 to 0x00002B7C5AB97A00
change vector 1信息:
CHANGE #1 TYP:0 CLS:35 AFN:3 DBA:0x00c00110 OBJ:4294967295 SCN:0x0000.0021f64a SEQ:1 OP:5.2 ENC:0 RBL:0
ktudh redo: slt: 0x0010 sqn: 0x000027df flg: 0x0012 siz: 204 fbi: 0
uba: 0x00c03a27.04ab.04 pxid: 0x0000.000.00000000
TYP: Type of the block. 0-Normal, 1-New block 2-Delayed logging etc
CLS: Class of the block. This field is same as x$bh.class column except for undo blocks/undo header.
AFN:绝对文件编号
DBA:相对数据块地址,转化成10进制为12583184
对于AFN和DBA可利用如下信息进行校验
SQL> select name from v$datafile where file#=3;
NAME
——————————————————————————–
/oradata/TRSENDB/datafile/o1_mf_undotbs1_c6ntyh03_.dbf
SQL> select dbms_utility.data_block_address_file(12583184) rfile,
2 dbms_utility.data_block_address_block(12583184) block
3 from dual;
RFILE BLOCK
———- ———-
3 272
SQL> select owner,segment_name from dba_segments where header_file=3 and header_block=272 and relative_fno=3;
OWNER SEGMENT_NAME
———————– ———————————-
SYS _SYSSMU10_817032100$
OP:5.2:Update rollback segment header即首先获取一个undo segment header
change vector 2信息:
CHANGE #2 TYP:0 CLS:36 AFN:3 DBA:0x00c03a27 OBJ:4294967295 SCN:0x0000.0021f649 SEQ:4 OP:5.1 ENC:0 RBL:0
ktudb redo: siz: 204 spc: 7312 flg: 0x0012 seq: 0x04ab rec: 0x04
xid: 0x000a.010.000027df
ktubl redo: slt: 16 rci: 0 opc: 11.1 [objn: 73316 objd: 73316 tsn: 4]
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00c03a27.04ab.01
prev ctl max cmt scn: 0x0000.0021f59c prev tx cmt scn: 0x0000.0021f5a8
txn start scn: 0xffff.ffffffff logon user: 49 prev brb: 12597782 prev bcl: 0 BuExt idx: 0 flg2: 0
KDO undo record:
KTB Redo
op: 0x03 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: Z
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x01000083 hdba: 0x01000082
itli: 3 ispac: 0 maxfr: 4858
tabn: 0 slot: 5(0x5) flag: 0x2c lock: 0 ckix: 0
ncol: 4 nnew: 1 size: 0
col 0: [ 1] 54==================》》》》》》》
记录对3号文件14887块进行修改,此块为undo块,即为在undo块里创建需要修改块的数据
查看修改前16进制信息如下:
SQL> select dump(‘T’,16) from dual;
DUMP(‘T’,16)
—————-
Typ=96 Len=1: 54
change vector 3信息:
CHANGE #3 TYP:2 CLS:1 AFN:4 DBA:0x01000083 OBJ:73316 SCN:0x0000.0021f5f4 SEQ:1 OP:11.5 ENC:0 RBL:0============》》》这SCN对应了data blockSCN
KTB Redo
op: 0x11 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: F xid: 0x000a.010.000027df uba: 0x00c03a27.04ab.04
Block cleanout record, scn: 0x0000.0021f662 ver: 0x01 opt: 0x02, entries follow…
itli: 2 flg: 2 scn: 0x0000.0021f5f4
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x01000083 hdba: 0x01000082
itli: 3 ispac: 0 maxfr: 4858
tabn: 0 slot: 5(0x5) flag: 0x2c lock: 3 ckix: 0
ncol: 4 nnew: 1 size: 0
col 0: [ 1] 41===========》》》》》
查看修改后16进制信息如下:
SQL> select dump(‘A’,16) from dual;
DUMP(‘A’,16)
—————-
Typ=96 Len=1: 41
change vector 4信息:
CHANGE #4 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:0 OP:5.20 ENC:0
session number = 148
serial number = 1817
transaction name =
version 186647552
audit sessionid 90710
Client Id =
login username = TRSEN
上面信息反映了Transaction continue audit log record,从OP操作码可清楚了解到