下面我对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
#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
第一个区对应的是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
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
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
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块串起来一起分析。
So stellen Sie den IE-Browser wieder her, um automatisch zu EDGE zu springen
Software für virtuelle Maschinen
So lösen Sie das Problem, dass Ethernet keine Verbindung zum Internet herstellen kann
Details zur Parameterkonfiguration des vivox100s
Download-Adresse der offiziellen Website der Yiou Exchange-App
Welches Format hat doc?
So bleiben Sie online auf TikTok unsichtbar
Detaillierte Erläuterung des Ereignisses onbeforeunload
