概述

undo trace文件的内容可能比较难理解，刚好最近有这块的问题分析，所以顺便用案例来做一下介绍。

环境准备

找一个undo回滚段，dump一下，然后拿他的trace文件来分析就行。

--查找undo回滚段 select * from v$rollname; --dump undo segment ALTER SYSTEM DUMP UNDO HEADER '_SYSSMU8_1131636851$'; --查看DUMP文件位置： select * from v$diag_info WHERE name='Default Trace File';

分析UDNO段头块的日志

接下来就是重点了，如何看懂这个dump出来的文件：

1、Extent Control Header

******************************************************************************** Undo Segment: _SYSSMU8_1131636851$ (8) ******************************************************************************** Extent Control Header ----------------------------------------------------------------- Extent Header:: spare1: 0 spare2: 0 #extents: 339 #blocks: 1299087 last map 0x00000000 #maps: 0 offset: 4080 Highwater:: 0x00dd3c5e ext#: 336 blk#: 2014 ext size: 8192 #blocks in seg. hdr's freelists: 0 #blocks below: 0 mapblk 0x00000000 offset: 336 Unlocked Map Header:: next 0x00000000 #extents: 339 obj#: 0 flag: 0x40000000

undo清理条件（超详细的UNDO段头块格式解剖）(1)

相关SQL验证

--通过v$rollname视图查出是8号UNDO回滚段 SQL> select * from v$rollname; -通过dba_extents视图查出一共有5个区，共8 8 8192 8192 8192=24592个块 SQL> select extent_id,file_id,block_id,blocks,bytes from dba_extents where segment_name='_SYSSMU8_1131636851$'; --通过dba_segments视图查出UNDO段头块，即3号文件的240号块是UNDO段头块（#blocks: 1299087） SQL> select header_file,header_block from dba_segments where segment_name='_SYSSMU8_1131636851$';

undo清理条件（超详细的UNDO段头块格式解剖）(2)

undo清理条件（超详细的UNDO段头块格式解剖）(3)

undo清理条件（超详细的UNDO段头块格式解剖）(4)

2、Extent Map

Extent Map ----------------------------------------------------------------- 0x00c000f1 length: 7 0x0c8015c0 length: 8 0x00c4b380 length: 128 0x0c859780 length: 128 ....... 0x0c85a400 length: 128 0x00c4c080 length: 128 0x0c85a480 length: 128 0x00c4c100 length: 128 0x0c85a500 length: 128 0x00c4c180 length: 128 0x0c85a580 length: 128 0x00c4c200 length: 128 0x0c85a600 length: 128 0x00c4c280 length: 128 0x0c85a680 length: 1024 0x00c4c300 length: 1024 ........ 0x0c85c280 length: 1024 0x00c61580 length: 1024 0x0c85c680 length: 1024 0x00c61980 length: 1024 0x0c85ef80 length: 1024 0x0c860380 length: 1024 0x00d75a00 length: 1024 0x0c860780 length: 1024 .................. 0x0c983880 length: 1024 0x00e09400 length: 1024 0x0c9ca580 length: 1024 0x00e09800 length: 1024 0x0c9dd980 length: 1024 0x00e0b800 length: 1024 0x0c977980 length: 512 0x00e0bc00 length: 1024 0x0c978700 length: 128 0x00e0c000 length: 1024 0x0c9f0080 length: 1024 .......... 0x0c8f5b00 length: 4096 0x00d01c80 length: 8192 0x0c902e80 length: 8192 0x00d0e280 length: 8192 ....... 0x0c9a9c80 length: 8192 0x00dc3100 length: 8192 0x0c9bd880 length: 8192 0x00dd3480 length: 8192 0x00d74280 length: 128 0x00d74400 length: 128

8号UNDO回滚段的区地图一共有339个区： 第一个区对应的是3号文件240号块、241号块、242号块、243号块、244号块、245号块、246号块，共7个UNDO BLOCK

第二个区对应的是3号文件247号块、248号块、249号块、250号块、251号块、252号块、253号块，254号块，共8个UNDO BLOCK

3、Retention Table

Retention Table ----------------------------------------------------------- Extent Number:0 Commit Time: 1565382657 Extent Number:1 Commit Time: 1565341949 Extent Number:2 Commit Time: 0 Extent Number:3 Commit Time: 0 Extent Number:4 Commit Time: 0 Extent Number:5 Commit Time: 0 Extent Number:6 Commit Time: 0 ......... Extent Number:334 Commit Time: 1565657875 Extent Number:335 Commit Time: 1565663037 Extent Number:336 Commit Time: 1565663037 Extent Number:337 Commit Time: 1565379450 Extent Number:338 Commit Time: 1565382657

区的提交时间戳，是从1970年1月1号零晨开始的（以秒为单位记录）

4、TRN CTL（事务控制）

TRN CTL:: seq: 0xdeb6 chd: 0x001f ctl: 0x0009 inc: 0x00000000 nfb: 0x0001 mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe) uba: 0x00dd3c0c.deb6.16 SCN: 0x0012.22391fbf

说明：

seq: 0xdeb6表示此事务修改前的值所在的UNDOBLOCK块被覆盖了57014次，与下面的uba: 0x00dd3c0c.deb6.16中的deb6对应。

chd: 0x001f表示发生一个新的事务，此时会在下面的TRNTBL::（事务表）的index=0x001f槽中放入新事务信息，即事务表的链头或叫入口。

ctl: 0x0009表示事务表的链尾（实际上可以去TRN TBL::看index=0x0009,它对应的SCN=0x0012.223ad9d4是本事务表中最大的SCN，即此事务槽最后才会被覆盖）

nfb: 0x0001 表示UNDO块在空闲池的空闲块数，0x0001表示池中有1个空闲UNDO块,即FREE BLOCKPOOL::有1个空闲的块。

flg: 0x0001 表示该块的用途，1=KTUUNDO HEADER(2=KTU UNDO BLOCK等等)

uba: 0x00dd3c0c.deb6.16 表示新事务的第一条UNDO记录（由三部分组成：undo块的地址、UNDO块被重用的次数、在UNDO块的第几条记录）

undo清理条件（超详细的UNDO段头块格式解剖）(5)

5、FREE BLOCK POOL

FREE BLOCK POOL:: uba: 0x00dd3c0c.deb6.16 ext: 0x150 spc: 0xc6a uba: 0x00000000.dd64.32 ext: 0x34 spc: 0x1da uba: 0x00000000.dd64.0d ext: 0x34 spc: 0x18ac uba: 0x00000000.cb78.03 ext: 0x4 spc: 0x1edc uba: 0x00000000.c84b.01 ext: 0x2 spc: 0x1f84

UNDO块的空闲池，当事务做了提交会把此事务所在的UNDO块加入空闲池中。

uba: 由三部分组成undo块的地址、UNDO块被重用的次数、在UNDO块的第几条记录，当undo块的地址为0说明UNDO块不是空闲的，即0x00000000

ext: UNDO块是在哪个区（extent）

spc: UNDO块中多少空闲空间，单位字节 从上面的UNDO空闲池中看，有空闲的UNDO块。

6、TRN TBL

TRN TBL:: index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt ------------------------------------------------------------------------------------------------ 0x00 9 0x00 0x22f5651 0x0009 0x0012.223ac908 0x00dd3c0c 0x0000.000.00000000 0x00000001 0x00000000 1565664182 0x01 9 0x00 0x22fad80 0x001c 0x0012.223aa674 0x00dd3c0c 0x0000.000.00000000 0x00000001 0x00000000 1565664175 0x02 9 0x00 0x22f8a2f 0x000e 0x0012.223aa762 0x00dd3c0c 0x0000.000.00000000 0x00000001 0x00000000 1565664178 0x03 9 0x00 0x22e46be 0x000f 0x0012.22394949 0x00dd3b83 0x0000.000.00000000 0x00000001 0x00000000 1565664131 ....... 0x17 9 0x00 0x22fdcca 0x0004 0x0012.2239c2e4 0x00dd3b83 0x0000.000.00000000 0x00000001 0x00000000 1565664141 0x18 9 0x00 0x22ceea9 0x0001 0x0012.223aa5c4 0x00dd3c0c 0x0000.000.00000000 0x00000001 0x00000000 1565664173 ....... 0x1f 9 0x00 0x22fbcd2 0x0003 0x0012.22392f3e 0x00dd3b83 0x0000.000.00000000 0x00000001 0x00000000 1565664129 0x20 9 0x00 0x22f9d41 0x000d 0x0012.223a9896 0x00dd3c0c 0x0000.000.00000000 0x00000001 0x00000000 1565664162 0x21 9 0x00 0x22e3ca0 0x0017 0x0012.22397686 0x00dd3b83 0x0000.000.00000000 0x00000001 0x00000000 1565664135

undo清理条件（超详细的UNDO段头块格式解剖）(6)

TRN TBL::（事务表）是UNDO段头块最重要的，下面解释每个字段的意思：

undo清理条件（超详细的UNDO段头块格式解剖）(7)

篇幅有限，关于undo段的跟踪文件就介绍到这了，其他实际上也可以类似分析的，后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~

undo清理条件（超详细的UNDO段头块格式解剖）(8)

,