ITPub博客

首页 > Linux操作系统 > Linux操作系统 > logfile的dump undo头的change vector是单独的record?

logfile的dump undo头的change vector是单独的record?

原创 Linux操作系统 作者:wei-xh 时间:2013-06-25 11:33:15 0 删除 编辑
insert into a values(1);
commit
 
对上面的一个简单事物进行LOGFILE的dump
 
 
REDO RECORD - Thread:1 RBA: 0x00044d.00000002.0010 LEN: 0x0230 VLD: 0x05
SCN: 0x0000.041b921c SUBSCN:  1 06/25/2013 11:27:32
(LWN RBA: 0x00044d.00000002.0010 LEN: 0002 NST: 0001 SCN: 0x0000.041b921c)
CHANGE #1 TYP:0 CLS:51 AFN:3 DBA:0x00c04c80 OBJ:4294967295 SCN:0x0000.041b91d1 SEQ:1 OP:5.2 ENC:0 RBL:0
ktudh redo: slt: 0x0016 sqn: 0x00002bee flg: 0x0012 siz: 136 fbi: 0
            uba: 0x00d1a78d.0068.2c    pxid:  0x0000.000.00000000
CHANGE #2 TYP:0 CLS:52 AFN:3 DBA:0x00d1a78d OBJ:4294967295 SCN:0x0000.041b91cf SEQ:1 OP:5.1 ENC:0 RBL:0
ktudb redo: siz: 136 spc: 2188 flg: 0x0012 seq: 0x0068 rec: 0x2c
            xid:  0x0012.016.00002bee 
ktubl redo: slt: 22 rci: 0 opc: 11.1 [objn: 15750 objd: 15750 tsn: 4]
Undo type:  Regular undo        Begin trans    Last buffer split:  No
Temp Object:  No
Tablespace Undo:  No
             0x00000000  prev ctl uba: 0x00d1a78d.0068.2b
prev ctl max cmt scn:  0x0000.041b9075  prev tx cmt scn:  0x0000.041b9077
txn start scn:  0xffff.ffffffff  logon user: 35  prev brb: 13739916  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: DRP row dependencies Disabled
  xtype: XA flags: 0x00000000  bdba: 0x024002c5  hdba: 0x024002c2
itli: 2  ispac: 0  maxfr: 4858
tabn: 0 slot: 1(0x1)
CHANGE #3 TYP:2 CLS:1 AFN:9 DBA:0x024002c5 OBJ:15750 SCN:0x0000.041b916a SEQ:1 OP:11.2 ENC:0 RBL:0
KTB Redo
op: 0x01  ver: 0x01 
compat bit: 4 (post-11) padding: 1
op: F  xid:  0x0012.016.00002bee    uba: 0x00d1a78d.0068.2c
KDO Op code: IRP row dependencies Disabled
  xtype: XA flags: 0x00000000  bdba: 0x024002c5  hdba: 0x024002c2
itli: 2  ispac: 0  maxfr: 4858
tabn: 0 slot: 1(0x1) size/delt: 6
fb: --H-FL-- lb: 0x2  cc: 1
null: -
col  0: [ 2]  c1 02
 
REDO RECORD - Thread:1 RBA: 0x00044d.00000004.0010 LEN: 0x00d0 VLD: 0x05
SCN: 0x0000.041b921e SUBSCN:  1 06/25/2013 11:27:34
(LWN RBA: 0x00044d.00000004.0010 LEN: 0001 NST: 0001 SCN: 0x0000.041b921d)
CHANGE #1 TYP:0 CLS:51 AFN:3 DBA:0x00c04c80 OBJ:4294967295 SCN:0x0000.041b921c SEQ:1 OP:5.4 ENC:0 RBL:0
ktucm redo: slt: 0x0016 sqn: 0x00002bee srt: 0 sta: 9 flg: 0x2 ktucf redo: uba: 0x00d1a78d.0068.2c ext: 104 spc: 2050 fbi: 0
CHANGE #2 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:0 OP:24.4 ENC:0
 
看到一共产生了2个REDO RECORD
第一个REDO RECORD包含了:
CHANGE #1 :undo头块的修改,记录事物开始 OP:5.2
CHANGE #2 :undo块的修改 OP:5.1
CHANGE #3 :数据块的修改 OP:11.2
 
第二个REDO RECORD包含了:
CHANGE #1 :undo头块的修改,记录事物结束 OP:5.4
 
可见记录事物开始的undo头块的修改,是打包进了第一个REDO RECORD,不像事物结束的REDO RECORD是单独存在的。
 
我测试的环境,IMU是关闭的。
 
如果IMU打开的话,我的整个事物,就只有一个REDO RECORD。
 
需要指出的是,在imu打开的情况下,如果你修改了commit_logging为immediate而非默认的batch,那么事物结束的REDO RECORD也是单独存在,而非打包进最后一个REDO RECORD里

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22034023/viewspace-764755/,如需转载,请注明出处,否则将追究法律责任。

上一篇: ASM空间虚假耗尽
请登录后发表评论 登录
全部评论
Oracle ACE组成员,DBGeeK用户组发起人。曾在DTCC、ORACLE技术嘉年华、Gdevops等公开场合做过数据库技术专题分享,2017年应Oracle邀请在世界最大的数据库会议OOW上做技术分享。组织翻译了《拨云见日,解密Oracle ASM内核》一书。

注册时间:2009-07-04

  • 博文量
    422
  • 访问量
    2302247