下面我对UNDO段头块的格式做一个全面深入的解析。有助于我们了解事务的本质。
好,为了方便测试,我来创建一个很小的UNDO表空间,如下操作:
gyj@OCM> create undo tablespace undotbs4 datafile '/u01/app/oracle/oradata/ocm/undotbs04.dbf' size 192k; Tablespace created. gyj@OCM> alter system set undo_tablespace=undotbs4; System altered.
查找UNDO回滚段,有一个17号UNDO回滚段,我们就拿这个回滚段做测试。
gyj@OCM> select * from v$rollname; USN NAME ---------- ------------------------------ 0 SYSTEM 17 _SYSSMU17_3012809736$
发生一个事务:
gyj@OCM> update gyj_test set name='guoyJoe' where id=1;
1 row updated.
转储UNDO段头块:
gyj@OCM> alter system dump undo header"_SYSSMU17_3012809736$";
System altered.
找到DUMP的UNDO段头块的跟踪日志:
gyj@OCM> select * from v$diag_info wherename='Default Trace File';
INST_ID NAME VALUE
---------- ----------------------------------------------------------------------------
1Default Trace File /u01/app/oracle/diag/rdbms/ocm/ocm/trace/ocm_ora_6151.trc
分析UDNO段头块的日志
[root@mydb ~]# more/u01/app/oracle/diag/rdbms/ocm/ocm/trace/ocm_ora_6151.trc******************************************************************************** Undo Segment: _SYSSMU17_3012809736$ (17) ******************************************************************************** Extent Control Header ----------------------------------------------------------------- Extent Header:: spare1: 0 spare2: 0 #extents: 2 #blocks: 15 last map 0x00000000 #maps: 0 offset: 4080 Highwater:: 0x0280000a ext#: 0 blk#: 1 ext size: 7 #blocks in seg. hdr's freelists: 0 #blocks below: 0 mapblk 0x00000000 offset: 0 Unlocked Map Header:: next 0x00000000 #extents: 2 obj#: 0 flag: 0x40000000
#extents: 2 表示17号UNDO段有两个区
#blocks: 15 表示17号UNDO回滚段两个区中有15个UNDO BLOCK可用。(为什么不是16个UNDO BLOCK块呢,去掉一个UNDO段头块)
ext#: 0 表示这个事务发生在第1个区(从0开始)
blk#: 1 表示这个事务发生在第1个区的第1个块上。
ext size: 7 表示1个区上有7个UNDO BLOCK可用
通过v$rollname视图查出是17号UNDO回滚段
gyj@OCM> select * from v$rollname;
USN NAME
---------- ------------------------------
0 SYSTEM
17 _SYSSMU17_3012809736$
通过dba_extents视图查出一共有两个区,共16个块
gyj@OCM> select extent_id,file_id,block_id,blocks,bytes fromdba_extents where segment_name='_SYSSMU17_3012809736$';
EXTENT_ID FILE_ID BLOCK_ID BLOCKS BYTES
---------- ---------- ---------- ---------- ----------
0 10 8 8 65536
1 10 16 8 65536
通过dba_segments视图查出UNDO段头块,即10号文件的8号块是UNDO段头块(所以#blocks:15)
gyj@OCM> select header_file,header_block from dba_segments wheresegment_name='_SYSSMU17_3012809736$';
HEADER_FILE HEADER_BLOCK
----------- ------------
10 8
Extent Map ----------------------------------------------------------------- 0x02800009 length: 7 0x02800010 length: 8
17号UNDO回滚段的区地图一共有两个区:
第一个区对应的是10号文件1号块、2号块、3号块、4号块、5号块、6号块、7号块,共7个UNDO BLOCK
第一个区对应的是10号文件9号块、10号块、11号块、12号块、13号块、14号块、15号块,16号块,共8个UNDO BLOCKRetention Table ----------------------------------------------------------- Extent Number:0 Commit Time: 1389838948 Extent Number:1 Commit Time: 1389838948
区的提交时间戳,是从1970年1月1号零晨开始的(以秒为单位记录)TRN CTL:: seq: 0x000d chd: 0x000a ctl: 0x000b inc: 0x00000000 nfb: 0x0000 mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe) uba: 0x0280000a.000d.2e scn: 0x0000.0028a2af
事务控制:
seq: 0x000d 表示此事务修改前的值所在的UNDOBLOCK块被覆盖了13次,与下面的uba: 0x0280000a.000d.2e中的000d对应。
chd:0x000a 表示发生一个新的事务,此时会在下面的TRNTBL::(事务表)的index=0x000a槽中放入新事务信息,即事务表的链头或叫入口。
ctl: 0x000b 表示事务表的链尾(实际上大家可以去TRN TBL::看index=0x000b,它对应的SCN=0x0000.0028a4d5是本事务表中最大的SCN,即此事务槽最后才会被覆盖)
nfb: 0x0000 表示UNDO块在空闲池的空闲块数,0x0000表示池中没有空闲UNDO块了,即FREE BLOCKPOOL::没空闲的块了。
flg: 0x0001 表示该块的用途,1=KTUUNDO HEADER(2=KTU UNDO BLOCK等等)
uba: 0x0280000a.000d.2e 表示新事务的第一条UNDO记录(由三部分组成undo块的地址、UNDO块被重用的次数、在UNDO块的第几条记录)
undo块的地址: 0x0280000a 即10号文件的10号块
UNDO块被重用的次数: 000d 即UNDO块被覆盖了13次
在UNDO块的第几条记录 2e 即在UNDO块的第46条
scn: 0x0000.0028a2af 表示17号UNDO段头块中最小的提交的SCN。实际上这个SCN就是事务表中最小的SCN所对应的事务槽上的SCN
注:下面的事务控制,是我在发生事务前(即做update gyj_test set name='GGGGG' where id=1;前所DUMP的事务控制)
TRN CTL:: seq: 0x000d chd: 0x0017 ctl: 0x000b inc: 0x00000000 nfb:0x0001
mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x0280000a.000d.2b scn: 0x0000.0028a26a
OK,我们从chd: 0x0017,找到事务表中的INDEX=0x0017
TRN TBL::
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x17 9 0x00 0x001c 0x000a 0x0000.0028a2af 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1389839441
有没有发现上面的scn=0x0000.0028a2af,是不是就是我们事务控制中所记录的SCN,明白了吧,实在不明白的来ORACLE DSI群讨论(群号127149411)
FREE BLOCK POOL:: uba: 0x00000000.000d.2d ext: 0x0 spc: 0x8b8 uba: 0x00000000.000d.0d ext: 0x0 spc: 0x19e8 uba: 0x00000000.0009.08 ext: 0x0 spc: 0x932 uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0 uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0
UNDO块的空闲池,当事务做了提交会把此事务所在的UNDO块加入空闲池中。
uba: 由三部分组成undo块的地址、UNDO块被重用的次数、在UNDO块的第几条记录,当undo块的地址为0说明UNDO块不是空闲的,即0x00000000
ext: UNDO块是在哪个区(extent)
spc: UNDO块中多少空闲空间,单位字节
从上面的UNDO空闲池中看,没有空闲的UNDO块。TRN TBL:: index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt ------------------------------------------------------------------------------------------------ 0x00 9 0x00 0x001d 0x001f 0x0000.0028a444 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984044 9 0x01 9 0x00 0x001d 0x000e 0x0000.0028a454 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984044 9 0x02 9 0x00 0x001d 0x0003 0x0000.0028a448 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984044 9 0x03 9 0x00 0x001d 0x0005 0x0000.0028a44a 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984044 9 0x04 9 0x00 0x001d 0x000b 0x0000.0028a4d3 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138984076 2 0x05 9 0x00 0x001d 0x001d 0x0000.0028a44c 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984044 9 0x06 9 0x00 0x001d 0x000d 0x0000.0028a493 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138984061 2 0x07 9 0x00 0x001d 0x0008 0x0000.0028a452 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984044 9 0x08 9 0x00 0x001d 0x0001 0x0000.0028a453 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984044 9 0x09 9 0x00 0x001d 0x0016 0x0000.0028a457 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984044 9 0x0a 9 0x00 0x001c 0x0020 0x0000.0028a2e3 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138983956 2 0x0b 9 0x00 0x001d 0xffff 0x0000.0028a4d5 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138984076 2 0x0c 9 0x00 0x001d 0x0006 0x0000.0028a459 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138984044 9 0x0d 9 0x00 0x001d 0x0012 0x0000.0028a495 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138984061 2 0x0e 9 0x00 0x001c 0x0009 0x0000.0028a455 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984044 9 0x0f 9 0x00 0x001d 0x0011 0x0000.0028a498 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138984061 2 0x10 9 0x00 0x001d 0x0014 0x0000.0028a4c3 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138984073 7 0x11 9 0x00 0x001d 0x0010 0x0000.0028a499 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138984061 2 0x12 9 0x00 0x001d 0x000f 0x0000.0028a497 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138984061 2 0x13 9 0x00 0x001d 0x0004 0x0000.0028a4d1 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138984076 2 0x14 9 0x00 0x001d 0x0013 0x0000.0028a4c8 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138984074 0 0x15 9 0x00 0x001c 0x0019 0x0000.0028a2f9 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138983956 2 0x16 9 0x00 0x001a 0x000c 0x0000.0028a458 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984044 9 0x17 10 0x80 0x001d 0x0000 0x0000.0028a4f7 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 0 0x18 9 0x00 0x001c 0x0021 0x0000.0028a3de 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984016 1 0x19 9 0x00 0x001c 0x001c 0x0000.0028a31e 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138983966 3 0x1a 9 0x00 0x001c 0x001e 0x0000.0028a35f 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138983984 8 0x1b 9 0x00 0x001c 0x0007 0x0000.0028a450 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984044 9 0x1c 9 0x00 0x001c 0x001a 0x0000.0028a35e 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138983984 8 0x1d 9 0x00 0x001b 0x001b 0x0000.0028a44e 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984044 9 0x1e 9 0x00 0x001c 0x0018 0x0000.0028a3dc 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984016 1 0x1f 9 0x00 0x001c 0x0002 0x0000.0028a446 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984044 9 0x20 9 0x00 0x001b 0x0015 0x0000.0028a2ee 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 138983956 2 0x21 9 0x00 0x001c 0x0000 0x0000.0028a3e0 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 138984016 1
TRN TBL::(事务表)是UNDO段头块最重要的。我们一一来解释每个字段的意思:
index 表示事务表中槽号,只是一个序列而已,从0x00开始到0x21结束,11g的版本有34个槽。
state 表示事务状态:9代表事务不活动,10代表事务正在活动,从这里我们看出16进制第0x17号槽上的事务正在活动。大家有没有发现,我们在发生事务前,Oracle会找事务控制列表中的chd=0x0017,说白了就是重从index=0x17的槽,存放当前最新的事务:
注:下面的事务控制,是我在发生事务前(即做update gyj_test set name='GGGGG' where id=1;前所DUMP的事务控制)
TRN CTL:: seq: 0x000d chd: 0x0017 ctl: 0x000b inc: 0x00000000 nfb:0x0001
mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x0280000a.000d.2b scn: 0x0000.0028a26a
cflags 表示正在使用穿上事务槽的事务的状态:0x00表示非活动事务、0x80表示活动事务、0x10表示死事务、0x90表示被回滚的死事务
平时我们看到的最多就是0x00表示非活动事务、0x80表示活动事务,后面的很少发生。
wrap# 表示事务表上的事务槽被重用的次数,它是XID的一部分。0x001d表示此时事务槽被重用了29次。
uel 表示当前活动事务所在事务槽的下一个事务槽的指针(即如果又发生一个新的事务,此时就会用到UEL指向的事务槽上的index)。
scn 表示务事启动、提交、回滚的SCN.
dba 表示uba:第一部分的undo块地址,这个DBA是(rollback)回滚的起始点,也就是说是记录事务修改的最后一条记录所在UNDO块的地址。
nub 表示当前事务所用到的UNDO块的个数。
cmt 表示最接近当前的提交时间戳,是从1970年1月1号零晨开始的(以秒为单位记录)。0表示事务正在活动。
先说到这儿,后继会对UNDO块格式,REDO块格式继续进行分析。最后通过一个事务的例子,把REDO块、UNDO段头块、UNDO块、DATA块串起来一起分析。