關於ITL以及UNDO SEGMENT HEADER 事物表(tx table)闡述
由於水平有限難免出現錯誤，全部觀點僅代表作者觀點
大家都知道在資料塊的頭部包含了一個事物層，其中包含了多個ITL。
我這裡做了2次DELETE 一直不COMMIT 用於觀察如下：
SQL> delete from testmyt where username='DIP';
1 row deleted
SQL> delete from testmyt where username='SCOTT';
1 row deleted
關於DUMP資料塊和UNDO SEGMENT HEADER的語法如下：
alter system dump datafile 1 block 91361;
alter system dump undo header '_SYSSMU12_3031818529$';
其格式大致為如下：
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0xffff.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0000.001f83a8
0x02 0x000c.00a.00000014 0x00c000fc.0018.1e ---- 2 fsc 0x00e4.00000000
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
所有討論圍繞
0x02 0x000c.00a.00000014 0x00c000fc.0018.1e ---- 2 fsc 0x00e4.00000000
展開
分別做下解釋：
1、XID
Identifier of the transaction owning the ITL, composed of three items:
usn#.slot#.wrap#
這部分XID實際對應了V$TRANSACTION中的
XIDUSN XIDSLOT XIDSQN
------- ---------- ----------
12 10 20
USN對應了dba_rollback_segs中的segment_id
xidsolt及事物表中的槽號可以檢視
select * from x$ktuxe where ktuxeusn=12或者DUMP SEGMENT HEADR找到其槽號對應的資訊如下
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
.....
0x0a 10 0x80 0x0014 0x0000 0x0000.001f83b0 0x00c000fc 0x0000.000.00000000 0x00000001 0x00000000 0
.....
wrap#表示這個槽重用的多少次每次重用+1，（根據事物表的分析可以發現每次重用槽位的WRAP#必然是最小值同時commit scn最小值等會觀察事物表的時候在進行分析）
我這裡是從用的第20次，同樣x$ktuxe或者DUMP SEGMENT HEADR也能找到相應的資訊。
2、Uba
Undo block address (UBA) of the record in the undo segment: DBA.seq#.rec#
這部分是對應了UNDO塊的地址資訊
DBA對應的是塊的地址。
seq#對應的是這個塊重用的次數，每次重用都會相應的增加，這個值和UNDO的重用機制有關，UNDO的重用必須選取小於新一輪SEQ值的塊。
rec#最後一次使用到UNDO塊中的位置，這個值會和事物表控制資訊(ktuxc)中的KTUXCUBA形成對比這個值是事物的開始的位置。
3、Flag
事物狀態值
—- = transaction is active, or committed pending cleanout
C— = transaction has been committed and locks cleaned out
-B– = this undo record contains the undo for this ITL entry
–U- = transaction committed (maybe long ago); SCN is an upper bound
—T = transaction was still active at block cleanout SCN
4、LCK
Number of locks held by the transaction in the block
應該理解為本事物導致了多少個行級鎖，我這裡一個事物同時更改了2條資料，所以是2
5、Scn/Fsc
If the transaction has been committed, the SCN of the transaction,If the
transaction has not been committed, the free space credits owned by this
transaction (if any)
可以看到這個值實際上是2個值，如果事物提交就是其COMMIT SCN，如果沒有提交就是
快中空閒空間的位置。
關於這一部分我們來看2個ORACLE 給出的圖解
接下來我們來看一下和ITL息息相關的UNDO SEGMENT HEADER的事物表(Transaction Table Header KTUXE)
以及事物表頭(Transaction Table Header KTUXC)
TRN CTL:: seq: 0x0018 chd: 0x0007 ctl: 0x0021 inc: 0x00000000 nfb: 0x0000
mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x00c000fc.0018.1d scn: 0x0000.001f74de
......
TRN TBL::
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x00 9 0x00 0x0014 0x0002 0x0000.001f805f 0x00c000fc 0x0000.000.00000000 0x00000002 0x00000000 1426827612
0x01 9 0x00 0x0014 0x0000 0x0000.001f8047 0x00c000fb 0x0000.000.00000000 0x00000001 0x00000000 1426827611
0x02 9 0x00 0x0014 0x0003 0x0000.001f8091 0x00c000fc 0x0000.000.00000000 0x00000001 0x00000000 1426827627
0x03 9 0x00 0x0014 0x0004 0x0000.001f8122 0x00c000fc 0x0000.000.00000000 0x00000001 0x00000000 1426827926
0x04 9 0x00 0x0014 0x0005 0x0000.001f8204 0x00c000fc 0x0000.000.00000000 0x00000001 0x00000000 1426828526
0x05 9 0x00 0x0014 0x0008 0x0000.001f8210 0x00c000fc 0x0000.000.00000000 0x00000001 0x00000000 1426828526
0x06 9 0x00 0x0014 0x0021 0x0000.001f8240 0x00c000fc 0x0000.000.00000000 0x00000001 0x00000000 1426828526
0x07 9 0x00 0x0013 0x000b 0x0000.001f74ef 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426820746
0x08 9 0x00 0x0014 0x001e 0x0000.001f821c 0x00c000fc 0x0000.000.00000000 0x00000001 0x00000000 1426828526
0x09 9 0x00 0x0014 0x0006 0x0000.001f8234 0x00c000fc 0x0000.000.00000000 0x00000001 0x00000000 1426828526
0x0a 10 0x80 0x0014 0x0000 0x0000.001f83b0 0x00c000fc 0x0000.000.00000000 0x00000001 0x00000000 0
0x0b 9 0x00 0x0013 0x000e 0x0000.001f74fc 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426820746
0x0c 9 0x00 0x0013 0x000f 0x0000.001f7516 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426820746
0x0d 9 0x00 0x0013 0x001b 0x0000.001f7b87 0x00c000fb 0x0000.000.00000000 0x00000001 0x00000000 1426824647
0x0e 9 0x00 0x0013 0x000c 0x0000.001f7509 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426820746
0x0f 9 0x00 0x0013 0x0010 0x0000.001f7523 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426820746
0x10 9 0x00 0x0013 0x0011 0x0000.001f7530 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426820746
0x11 9 0x00 0x0013 0x0012 0x0000.001f76f2 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426821946
0x12 9 0x00 0x0013 0x0014 0x0000.001f77e0 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426822546
0x13 9 0x00 0x0013 0x0016 0x0000.001f7a4f 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426824047
0x14 9 0x00 0x0013 0x0015 0x0000.001f78d5 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426823202
0x15 9 0x00 0x0013 0x0013 0x0000.001f7a21 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426824045
0x16 9 0x00 0x0013 0x0017 0x0000.001f7a5b 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426824047
0x17 9 0x00 0x0013 0x0018 0x0000.001f7a67 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426824047
0x18 9 0x00 0x0013 0x0019 0x0000.001f7a73 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426824047
0x19 9 0x00 0x0013 0x001a 0x0000.001f7a7f 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426824047
0x1a 9 0x00 0x0013 0x000d 0x0000.001f7a9d 0x00c000fb 0x0000.000.00000000 0x00000002 0x00000000 1426824053
0x1b 9 0x00 0x0013 0x001c 0x0000.001f7c54 0x00c000fb 0x0000.000.00000000 0x00000001 0x00000000 1426825247
0x1c 9 0x00 0x0013 0x001d 0x0000.001f7c61 0x00c000fb 0x0000.000.00000000 0x00000001 0x00000000 1426825247
0x1d 9 0x00 0x0013 0x001f 0x0000.001f7cc3 0x00c000fb 0x0000.000.00000000 0x00000001 0x00000000 1426825498
0x1e 9 0x00 0x0013 0x0009 0x0000.001f8228 0x00c000fc 0x0000.000.00000000 0x00000001 0x00000000 1426828526
0x1f 9 0x00 0x0013 0x0020 0x0000.001f7e8e 0x00c000fb 0x0000.000.00000000 0x00000001 0x00000000 1426826447
0x20 9 0x00 0x0013 0x0001 0x0000.001f7f03 0x00c000fb 0x0000.000.00000000 0x00000001 0x00000000 1426826748
0x21 9 0x00 0x0013 0xffff 0x0000.001f826b 0x00c000fc 0x0000.000.00000000 0x00000001 0x00000000 1426828610
關於TRN CTL及事物表頭(Transaction Table Header KTUXC)我們著重關注4個值
In the above slide, the important fields in protecting a given transaction are SCN,
UBA, CHD, and CTL.
For a transaction, a transaction slot is allocated during bind phase, which is at
transaction begin time. The CHD points to the next Tx slot to allocate. To preserve the
data within this Tx slot, the Tx commit SCN is saved in KTUXCSCN, the
KTUXCUBA field will identify the undo block to protect the changes to KTUXC,
and the CHD and CTL will be updated to reflect the next Tx slot to be reused, and the
latest committed slot within the transaction table respectively. These changes are
required to ensure rollback of the transaction, and read consistency of the Tx table
header.
The header of the Tx table (KTUXC) is modified:
? KTUXCSCN updated with the SCN of the reused slot
? KTUXCCHD points to the new oldest committed Tx
? KTUXCCTL points to the newest committed Tx
? KTUXCUBA points to the undo record created to protect the begin transaction
associated with the first change of the Tx
KTUXCHD就是下一次事物將使用的事物操，而他實際上是最老的記錄的COMMIT的SCN的事物槽，我這裡指向了chd: 0x0007，我們可以看一下他的完整資訊
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x07 9 0x00 0x0013 0x000b 0x0000.001f74ef 0x00c000fa 0x0000.000.00000000 0x00000001 0x00000000 1426820746
可以看到他的SCN 實際上是0000.001f74ef，雖然這個值是16進位制的但是很容易在整個事物表中發現他是整個事物表中COMMIT SCN最老的一個事物操
而他的WRAP#為13，所以下次從用的必然就是他
KTUXCTL表示的最新的COMMIT SCN 的事物槽的位置，我這裡指向了ctl: 0x0021，其完整資訊如下：
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x21 9 0x00 0x0013 0xffff 0x0000.001f826b 0x00c000fc 0x0000.000.00000000 0x00000001 0x00000000 1426828610
同樣0x0000.001f826b是最新的COMMIT SCN，注意這裡是COMMIT SCN 雖然0x0a行才是最新的但實際上他是ACTIVE 狀態的，還沒有COMMIT
KTUXCSCN表示最近一次從用事物表記錄的COMMIT SCN，及被重用條目的COMMIT SCN，我這裡是scn: 0x0000.001f74de，說明這個COMMIT SCN的
事物表條目被重用了，應該就是0x0a原有的COMMIT SCN
KTUXCUBA這個值代表了整個事物表中最老的一個事物的第一條更改的位置，我這裡是uba: 0x00c000fc.0018.1d，當然我這裡也只有一個事物，
這裡和ITL中的0x00c000fc.0018.1e（這個值代表是最後一個更改所在的位置）有一定對比性但並不是總是如此，一個UNDO SEGMENT可能
包含很多TRANSACTION，當然一個事物會盡量使用一個UNDO SEGMENT，按照呂海波ORACLE核心揭祕一書中關於UNDO的描述當UNDO TBALESPACE
可用空間降低到50%左右的時候，一個UNDO SEGMENT會包含多個事物。
這樣也就闡明瞭事物表條目重用的規則，他總是選取COMMIT SCN最老的值進行重用，重用後WRAP#增加1。
接下來我們看一下事物表(Transaction Table Header KTUXE)
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
......
0x09 9 0x00 0x0014 0x0006 0x0000.001f8234 0x00c000fc 0x0000.000.00000000 0x00000001 0x00000000 1426828526
0x0a 10 0x80 0x0014 0x0000 0x0000.001f83b0 0x00c000fc 0x0000.000.00000000 0x00000001 0x00000000 0
......
這裡擷取兩個條目就可以了，分別說明
INDEX：事物表槽號
STATE：條目狀態 9是非活動 10代表活動
CFLAGS：標記位，0x00表示無實物，0x10死事物，0x80活動事物，0x90正在被回滾的死事物
WRAP#：如前所說是一個計數器
UEL：Used to store starting extent of an active transaction, or the next pointer in the
list of committed transactions if transaction inactive 這部分所謂的指標還不太清楚有
何用。還需要繼續學習
scn：System commit number for prepare/commit ，對於提交的事物是COMMIT SCN，對已沒有提交的事物是開始SCN，這裡可以從V$TRAINSACTION中得到證明
對於這個事物我V$TRANSACT的值是
START_TIME START_SCNB START_SCNW
-------------------- ---------- ----------
03/20/15 13:31:57 2065328 0
SQL> select to_number('1f83b0','xxxxxxxxxxx') from dual;
TO_NUMBER('1F83B0','XXXXXXXXXX
------------------------------
2065328
可以看到是能夠對應上的。
dba：就是最後一個UNDO塊所在的地址，這個值在ITL也有。
PTX (Par XID): Parent XID, for PDML
NUB：當前事物使用的UNDO塊數
stmt_num:未知
cmt：記錄一個COMMIT時間，從1970年1月1日以來的秒。
本塊資訊實際也可以通過X$KTUXE進行檢視
select indx,ktuxesta,ktuxecfl,ktuxesqn wrap#,ktuxescnw scnw,ktuxescnb scnb,ktuxerdbf dba_file,ktuxerdbb dba_block,ktuxesiz nub from x$ktuxe where ktuxeusn=12;
這裡還要著重強調一下，本文中包含了2個計數器
一個是
usn#.slot#.wrap# 中的WRAP#也就是V$TRANSACTION中的XIDSQN
一個是
DBA.seq#.rec#中的seq#。
他們都是計數器但是作用範圍不一樣，一個是事物表條目中的計數器，一個是UNDO BLOCK中的計數器，他們和事物表條目或者UNDO BLOCK分配的機制相關，詳細參見本文，這也是
長久以來迷惑廣大DBA的地方，所以著重闡明。
最後吐槽一下學習核心的辛苦，每寫一篇文章，需要翻閱大量的文件資料，並且不一定完全正確，而且會消耗大量的時間，但是我堅信這個過程是寶貴的，長期堅持應該能讓對ORACLE
的認識達到一個新的高度。
本文參考資料
ORACLE 核心技術（JONATHAN LEWIS著）
ORACLE 核心技術揭祕（呂海波著）
DSI 402
DSI 402E
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7728585/viewspace-1709334/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- oracle undo segment header 事務表transaction table系列一OracleHeader
- 關於enq: TX - allocate ITL entry等待事件ENQ事件
- 關於enq: TX - allocate ITL entry的問題分析ENQ
- Oracle Undo SegmentOracle
- enq: TX - allocate ITL entryENQ
- TX:ITL LOCK(INITRANS,MAXINTRANS)
- dump轉儲undo segment header block回滾段頭塊小方法HeaderBloC
- [20140130]關於enq TX-allocate ITL entryENQ
- undo segment的建立、線上以及extent的分配原則。
- oracle ITL TX MODE 4問題Oracle
- table/segment/extent/block之間關係BloC
- ORA-600 [4000] trying to get dba of undo segment header block from usn-47456.1HeaderBloC
- undo segment的建立、online以及extent的分配原則
- undo 事物內部結構
- MySQL必知必會：簡介undo log、truncate、以及undo log如何幫你回滾事物MySql
- How to Shrink Undo Segment In Oracle DatabaseOracleDatabase
- enq: TX - allocate ITL entry等待事件分析ENQ事件
- 關於oracle with table as 建立臨時表的用法示例以及使用with as 的優點Oracle
- 闡述遊戲設計中的玩家角色&自我表達遊戲設計
- 闡述玩家社群對於遊戲成功的重要性遊戲
- zt_undo 事物內部結構
- 關於undo表空間的一些常用操作
- 從ITL到Undo前映象提取實驗
- 關於 TX 鎖的兩句sqlSQL
- [20150721]enq TX - allocate ITL entryENQ
- 4.3.2.4 關於CDB UNDO模式模式
- 關於Undo地實現
- UNDO SEGMENT的擴充套件和收縮套件
- Wooga CEO闡述專注於劇情主導遊戲的原因遊戲
- 關於量化交易機器人系統開發的闡述與智慧量化合約程式模型機器人模型
- 【MOS】 Troubleshooting waits for enq: TX - allocate ITL entry(1472175.1)AIENQ
- 【故障處理】佇列等待之TX - allocate ITL entry案例佇列
- 查詢user使用那些roll segment以及等待roll segment
- SMON: recover undo segment與並行事務恢復並行
- 關於oracle的undo_retentionOracle
- Flink Table & SQL API--動態表與Redo和UndoSQLAPI
- undo segment header中記錄的dba是該事務使用的單向連結串列中的頭(end block)!HeaderBloC
- 分散式賬本技術的闡述分散式