UNDO段頭塊格式深度解析

來源：九壹網(wǎng)

下面我對UNDO段頭塊的格式做一個全面深入的解析。有助于我們了解事務的本質。好，為了方便測試，我來創(chuàng)建一個很小的UNDO表空間，如下操作: gyj@OCM create undo tablespace undotbs4 datafile /u01/app/oracle/oradata/ocm/undotbs04.dbf size 192k;Tablesp

下面我對UNDO段頭塊的格式做一個全面深入的解析。有助于我們了解事務的本質。

好，為了方便測試，我來創(chuàng)建一個很小的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$

發(fā)生一個事務：

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段有兩個區(qū)

#blocks: 15 表示17號UNDO回滾段兩個區(qū)中有15個UNDO BLOCK可用。（為什么不是16個UNDO BLOCK塊呢，去掉一個UNDO段頭塊）

ext#: 0 表示這個事務發(fā)生在第1個區(qū)（從0開始）

blk#: 1 表示這個事務發(fā)生在第1個區(qū)的第1個塊上。

ext size: 7 表示1個區(qū)上有7個UNDO BLOCK可用

通過v$rollname視圖查出是17號UNDO回滾段

gyj@OCM> select * from v$rollname;

USN NAME

---------- ------------------------------

0 SYSTEM

17 _SYSSMU17_3012809736$

通過dba_extents視圖查出一共有兩個區(qū)，共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回滾段的區(qū)地圖一共有兩個區(qū)：

第一個區(qū)對應的是10號文件1號塊、2號塊、3號塊、4號塊、5號塊、6號塊、7號塊，共7個UNDO BLOCK

第一個區(qū)對應的是10號文件9號塊、10號塊、11號塊、12號塊、13號塊、14號塊、15號塊，16號塊，共8個UNDO BLOCK

Retention Table 
 -----------------------------------------------------------
 Extent Number:0 Commit Time: 138348
 Extent Number:1 Commit Time: 138348

區(qū)的提交時間戳，是從1970年1月1號零晨開始的（以秒為單位記錄）

TRN CTL:: seq: 0x000d chd: 0x000a ctl: 0x000b inc: 0x00000000 nfb: 0x0000
 mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 21474836 (0x7ffffffe)
 uba: 0x0280000a.000d.2e scn: 0x0000.0028a2af

事務控制：

seq: 0x000d 表示此事務修改前的值所在的UNDOBLOCK塊被覆蓋了13次，與下面的uba: 0x0280000a.000d.2e中的000d對應。

chd:0x000a 表示發(fā)生一個新的事務，此時會在下面的TRNTBL::（事務表）的index=0x000a槽中放入新事務信息，即事務表的鏈頭或叫入口。

ctl: 0x000b 表示事務表的鏈尾（實際上大家可以去TRN TBL::看index=0x000b,它對應的SCN=0x0000.0028a4d5是本事務表中最大的SCN，即此事務槽最后才會被覆蓋）

nfb: 0x0000 表示UNDO塊在空閑池的空閑塊數(shù)，0x0000表示池中沒有空閑UNDO塊了,即FREE BLOCKPOOL::沒空閑的塊了。

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

uba: 0x0280000a.000d.2e 表示新事務的第一條UNDO記錄（由三部分組成undo塊的地址、UNDO塊被重用的次數(shù)、在UNDO塊的第幾條記錄）

undo塊的地址： 0x0280000a 即10號文件的10號塊

UNDO塊被重用的次數(shù)： 000d 即UNDO塊被覆蓋了13次

在UNDO塊的第幾條記錄 2e 即在UNDO塊的第46條

scn: 0x0000.0028a2af 表示17號UNDO段頭塊中最小的提交的SCN。實際上這個SCN就是事務表中最小的SCN所對應的事務槽上的SCN

注：下面的事務控制，是我在發(fā)生事務前（即做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: 21474836 (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 13839441

有沒有發(fā)現(xiàn)上面的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塊被重用的次數(shù)、在UNDO塊的第幾條記錄，當undo塊的地址為0說明UNDO塊不是空閑的，即0x00000000

ext: UNDO塊是在哪個區(qū)（extent）

spc: UNDO塊中多少空閑空間，單位字節(jié)

從上面的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 1384044
9
 0x01 9 0x00 0x001d 0x000e 0x0000.0028a4 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1384044
9
 0x02 9 0x00 0x001d 0x0003 0x0000.0028a448 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1384044
9
 0x03 9 0x00 0x001d 0x0005 0x0000.0028a44a 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1384044
9
 0x04 9 0x00 0x001d 0x000b 0x0000.0028a4d3 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1384076
2
 0x05 9 0x00 0x001d 0x001d 0x0000.0028a44c 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1384044
9
 0x06 9 0x00 0x001d 0x000d 0x0000.0028a493 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1384061
2
 0x07 9 0x00 0x001d 0x0008 0x0000.0028a452 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1384044
9
 0x08 9 0x00 0x001d 0x0001 0x0000.0028a453 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1384044
9
 0x09 9 0x00 0x001d 0x0016 0x0000.0028a457 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1384044
9
 0x0a 9 0x00 0x001c 0x0020 0x0000.0028a2e3 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1383956
2
 0x0b 9 0x00 0x001d 0xffff 0x0000.0028a4d5 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1384076
2
 0x0c 9 0x00 0x001d 0x0006 0x0000.0028a459 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1384044
9
 0x0d 9 0x00 0x001d 0x0012 0x0000.0028a495 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1384061
2
 0x0e 9 0x00 0x001c 0x0009 0x0000.0028a455 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1384044
9
 0x0f 9 0x00 0x001d 0x0011 0x0000.0028a498 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1384061
2
 0x10 9 0x00 0x001d 0x0014 0x0000.0028a4c3 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1384073
7
 0x11 9 0x00 0x001d 0x0010 0x0000.0028a499 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1384061
2
 0x12 9 0x00 0x001d 0x000f 0x0000.0028a497 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1384061
2
 0x13 9 0x00 0x001d 0x0004 0x0000.0028a4d1 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1384076
2
 0x14 9 0x00 0x001d 0x0013 0x0000.0028a4c8 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1384074
0
 0x15 9 0x00 0x001c 0x0019 0x0000.0028a2f9 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1383956
2
 0x16 9 0x00 0x001a 0x000c 0x0000.0028a458 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1384044
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 1384016
1
 0x19 9 0x00 0x001c 0x001c 0x0000.0028a31e 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1383966
3
 0x1a 9 0x00 0x001c 0x001e 0x0000.0028a35f 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1383984
8
 0x1b 9 0x00 0x001c 0x0007 0x0000.0028a450 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1384044
9
 0x1c 9 0x00 0x001c 0x001a 0x0000.0028a35e 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1383984
8
 0x1d 9 0x00 0x001b 0x001b 0x0000.0028a44e 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1384044
9
 0x1e 9 0x00 0x001c 0x0018 0x0000.0028a3dc 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1384016
1
 0x1f 9 0x00 0x001c 0x0002 0x0000.0028a446 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1384044
9
 0x20 9 0x00 0x001b 0x0015 0x0000.0028a2ee 0x0280000a 0x0000.000.00000000 0x00000001 0x00000000 1383956
2
 0x21 9 0x00 0x001c 0x0000 0x0000.0028a3e0 0x02800009 0x0000.000.00000000 0x00000001 0x00000000 1384016
1

TRN TBL::（事務表）是UNDO段頭塊最重要的。我們一一來解釋每個字段的意思：

index 表示事務表中槽號，只是一個序列而已，從0x00開始到0x21結束,11g的版本有34個槽。

state 表示事務狀態(tài)：9代表事務不活動，10代表事務正在活動，從這里我們看出16進制第0x17號槽上的事務正在活動。大家有沒有發(fā)現(xiàn)，我們在發(fā)生事務前，Oracle會找事務控制列表中的chd=0x0017,說白了就是重從index=0x17的槽，存放當前最新的事務：

注：下面的事務控制，是我在發(fā)生事務前（即做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: 21474836 (0x7ffffffe)

uba: 0x0280000a.000d.2b scn: 0x0000.0028a26a

cflags 表示正在使用穿上事務槽的事務的狀態(tài)：0x00表示非活動事務、0x80表示活動事務、0x10表示死事務、0x90表示被回滾的死事務

平時我們看到的最多就是0x00表示非活動事務、0x80表示活動事務，后面的很少發(fā)生。

wrap# 表示事務表上的事務槽被重用的次數(shù)，它是XID的一部分。0x001d表示此時事務槽被重用了29次。

uel 表示當前活動事務所在事務槽的下一個事務槽的指針（即如果又發(fā)生一個新的事務，此時就會用到UEL指向的事務槽上的index）。

scn 表示務事啟動、提交、回滾的SCN.

dba 表示uba:第一部分的undo塊地址，這個DBA是(rollback)回滾的起始點，也就是說是記錄事務修改的最后一條記錄所在UNDO塊的地址。

nub 表示當前事務所用到的UNDO塊的個數(shù)。

cmt 表示最接近當前的提交時間戳，是從1970年1月1號零晨開始的（以秒為單位記錄）。0表示事務正在活動。

先說到這兒，后繼會對UNDO塊格式，REDO塊格式繼續(xù)進行分析。最后通過一個事務的例子，把REDO塊、UNDO段頭塊、UNDO塊、DATA塊串起來一起分析。

成熟丰满熟妇高潮XXXXX,人妻无码AV中文系列久久兔费 ,国产精品一国产精品,国精品午夜福利视频不卡麻豆

UNDO段頭塊格式深度解析