UNDO段头块格式深度解析

原创: 2016-06-07 15:28:18 833浏览

下面我对UNDO段头块的格式做一个全面深入的解析。有助于我们了解事务的本质。好，为了方便测试，我来创建一个很小的UNDO表空间，如下操作: gyj@OCM create undo tablespace undotbs4 datafile /u01/app/oracle/oradata/ocm/undotbs04.dbf size 192k;Tablesp

下面我对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.

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 BLOCK

Retention 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）。