本文转自：http://space.itpub.net/17203031/viewspace-716353
关于ITL事务槽的定义，参考我的博客：http://blog.csdn.net/changyanmanman/article/details/7081699
http://blog.csdn.net/changyanmanman/article/details/7312988
在Oracle中，数据块block上存在记录事务信息的ITL（Interest Transaction List）。当一个数据库事务涉及到数据块对应的数据时，就会在当前数据块块头（block head）后面的ITL中记录上相应的信息。
本篇从数据块逻辑结构角度入手，分析ITL中所包括的内容和与事务对应的信息。
1、环境准备
在这里，我们准备一个简单的数据表作为实验对象。
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
SQL> create table t2 (id number, vname varchar2(10));
Table created
SQL> insert into t2 values (1, 'id');
1 row inserted
SQL> insert into t2 values (2, 'iddf');
1 row inserted
SQL> commit;
Commit complete
此时，对应的数据段信息如下：
SQL> select HEADER_FILE, HEADER_BLOCK, BYTES, BLOCKS, EXTENTS from dba_segments where owner='SYS' and segment_name='T2';
HEADER_FILE HEADER_BLOCK BYTES BLOCKS EXTENTS
----------- ------------ ---------- ---------- ----------
4 563 65536 8 1
从数据字典信息看，Oracle为该数据段T分配了一个extents分区，其中包括8个数据块。
2、无事务状态下的ITL事务槽
首先，我们需要知道各个数据行对应的物理位置。我们可以使用dbms_rowid的包方法解析数据行rowid信息。Rowid中实际包括几个组成部分：相对文件编号、对象编号、数据块号和行slot号。
SQL> select id,dbms_rowid.rowid_relative_fno(rowid) fno,dbms_rowid.rowid_block_n
umber(rowid) bno,dbms_rowid.rowid_row_number(rowid) row_num from t2;
ID FNO BNO ROW_NUM
---------- ---------- ---------- ----------
1 4 566 0
2 4 566 1
两个数据行均在文件4的566数据块上。我们接下来使用dump数据块的方法，将该块的逻辑结构dump到当前会话对应的跟踪文件中。
SQL> alter system dump datafile 4 block 566;
System altered
--获取trace跟踪文件位置名称
SQL> select f_get_trace_name from dual;
F_GET_TRACE_NAME
---------------------------------------------------------------------
D:\ORACLE\PRODUCT\10.1.0\ADMIN\ORCL\UDUMP\orcl_ora_3736.trc
这个f_get_trace_name是一个函数，其代码如下（注意此函数只能在sys用户下完成创建）：
create or replace function F_GET_TRACE_NAME return varchar2 is
Result varchar2(1000);
begin
SELECT d.VALUE
|| '\'
|| LOWER (RTRIM (i.INSTANCE, CHR (0)))
|| '_ora_'
|| p.spid
|| '.trc' trace_file_name
into result
FROM (SELECT p.spid
FROM v$mystat m, v$session s, v$process p
WHERE m.statistic# = 1 AND s.SID = m.SID AND p.addr = s.paddr) p,
(SELECT t.INSTANCE
FROM v$thread t, v$parameter v
WHERE v.NAME = 'thread'
AND (v.VALUE = 0 OR t.thread# = TO_NUMBER (v.VALUE))) i,
(SELECT VALUE
FROM v$parameter
WHERE NAME = 'user_dump_dest') d;
return(Result);
end F_GET_TRACE_NAME;
我们打开跟踪文件，可以找到对应的itl信息片段：
*** 2012-09-15 10:29:13.984
Start dump data blocks tsn: 4 file#: 4 minblk 566 maxblk 566
buffer tsn: 4 rdba: 0x01000236 (4/566)
scn: 0x0000.00a480fc seq: 0x01 flg: 0x00 tail: 0x80fc0601
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Block header dump: 0x01000236
Object id on Block? Y
seg/obj: 0xe357 csc: 0x00.a47f64 itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x1000231 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0004.021.000039df 0x0080078c.1916.18 --U- 1 fsc 0x0000.00a47f7b
0x02 0x0004.018.000039e0 0x0080078f.1916.0c ---- 1 fsc 0x0000.00000000
data_block_dump,data header at 0x41d0264
===============
tsiz: 0x1f98
hsiz: 0x16
pbl: 0x041d0264
bdba: 0x01000236
76543210
flag=--------
ntab=1
nrow=2
frre=-1
fsbo=0x16
fseo=0x1f84
avsp=0x1f6e
tosp=0x1f6e
0xe:pti[0] nrow=2 offs=0
0x12:pri[0] offs=0x1f8f
0x14:pri[1] offs=0x1f84
block_row_dump:
tab 0, row 0, @0x1f8f
tl: 9 fb: --H-FL-- lb: 0x1 cc: 2
col 0: [ 2] c1 02
col 1: [ 2] 69 64
tab 0, row 1, @0x1f84
tl: 11 fb: --H-FL-- lb: 0x2 cc: 2
col 0: [ 2] c1 03
col 1: [ 4] 69 64 64 66
end_of_block_dump
End dump data blocks tsn: 4 file#: 4 minblk 566 maxblk 566
对每一个数据块，都是包括ITL列表，用于描述当前数据块上进行的事务信息。在创建数据段对象的时候，包括initrans参数（默认值为1），就是表示该数据表对象的数据块创建时候初始ITL事务槽的个数。Initrans参数在10g之后，基本上就失去了其效果的场景。Oracle对数据块，初始都是创建两个事务槽对象。当并发事务操作较多的时候，会进行自动的拓展，拓展到最大值255。
从上面的片段，我们可以看到该数据块中，有两个itl事务槽。Itl列表示连接的事务槽编号。
Xid是由三列使用十六进制编码的数字列表示，该列表示对应的事务编号。在Oracle中，标识一个事务是通过 usn.slot.sqn 表示。事务槽起作用的时候，每一个事务槽都与一个事务相关联。
Uba应当为undo block address的缩写。多版本一致读是Oracle保证读操作不会被事务阻塞的重要特性。当Server Process需要查询一个正在被事务修改，但是尚未提交的数据时，就根据ITL上的uba定位到对应Undo前镜像数据位置。
Flag对应的是当前事务槽的状态信息，标志着不同的事务状态（下表信息引自网络资料）。
| Flag取值 |
含义 |
| ----- |
事务是活动的，或者在块清除前提交事务 |
| C--- |
事务已经提交并且清除了行锁定 |
| -B-- |
this undo record contains the undo for this ITL entry |
| --U- |
事务已经提交（SCN已经是最大值），但是锁定还没有清除（快速清除） |
| ---T |
当块清除的SCN被记录时，该事务仍然是活动的，块上如果有已经提交的事务，那么在clean ount的时候，块会被进行清除，但是这个块里面的事务不会被清除。 |
|
|
|
Lck表示该事务槽涉及到的记录数目。Scn/Fsc：表示快速提交和已经提交的SCN编号。
从上面的ITL片段表示两条记录对应的事务已经提交，并且对应最大的SCN取值。
3、启动单会话事务
我们首先观察一下，当启动一个会话事务的时候，ITL状态情况。
SQL> select sid from v$mystat where rownum<2;
SID
----------
162
SQL> update t2 set vname='d' where id=1;
1 row updated
此时，对应事务信息为。
SQL> select addr,xidusn,xidslot,xidsqn from v$transaction;
ADDR XIDUSN XIDSLOT XIDSQN
-------- ---------- ---------- ----------
6C278F2C 4 26 14820
这时候，我们尝试dump出数据块：
SQL> alter system dump datafile 4 block 566;
系统已更改。
情况如下：
Dump file d:\oracle\product\10.1.0\admin\orcl\udump\orcl_ora_7692.trc
Sat Sep 15 11:13:33 2012
ORACLE V10.1.0.2.0 - Production vsnsta=0
vsnsql=13 vsnxtr=3
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
Windows XP Version V5.1 Service Pack 3
CPU : 2 - type 586, 2 Physical Cores
Process Affinity: 0x00000000
Memory (A/P) : PH:772M/2042M, PG:1903M/3935M, VA:1733M/2047M
Instance name: orcl
Redo thread mounted by this instance: 1
Oracle process number: 12
Windows thread id: 7692, image: ORACLE.EXE (SHAD)
*** 2012-09-15 11:13:33.078
*** ACTION NAME:() 2012-09-15 11:13:33.015
*** MODULE NAME:(SQL*Plus) 2012-09-15 11:13:33.015
*** SERVICE NAME:(SYS$USERS) 2012-09-15 11:13:33.015
*** SESSION ID:(162.13) 2012-09-15 11:13:33.015
Start dump data blocks tsn: 4 file#: 4 minblk 566 maxblk 566
buffer tsn: 4 rdba: 0x01000236 (4/566)
scn: 0x0000.00a48c9b seq: 0x01 flg: 0x04 tail: 0x8c9b0601
frmt: 0x02 chkval: 0x7b0c type: 0x06=trans data
Block header dump: 0x01000236
Object id on Block? Y
seg/obj: 0xe357 csc: 0x00.a48c78 itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x1000231 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0004.010.000039e4 0x008007a3.1916.22 C--- 0 scn 0x0000.00a48c5d
0x02 0x0004.01a.000039e4 0x008007a3.1916.29 ---- 1 fsc 0x0000.00000000
data_block_dump,data header at 0x40e0264
===============
tsiz: 0x1f98
hsiz: 0x16
pbl: 0x040e0264
bdba: 0x01000236
76543210
flag=--------
ntab=1
nrow=2
frre=-1
fsbo=0x16
fseo=0x1f7c
avsp=0x1f6e
tosp=0x1f6e
0xe:pti[0] nrow=2 offs=0
0x12:pri[0] offs=0x1f7c
0x14:pri[1] offs=0x1f84
block_row_dump:
tab 0, row 0, @0x1f7c
tl: 8 fb: --H-FL-- lb: 0x2 cc: 2
col 0: [ 2] c1 02
col 1: [ 1] 64
tab 0, row 1, @0x1f84
tl: 11 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 2] c1 03
col 1: [ 4] 69 64 64 66
end_of_block_dump
End dump data blocks tsn: 4 file#: 4 minblk 566 maxblk 566
第二行事务槽，锁定影响记录数量为1。对应的xid为 0x0004.01a.000039e4 。分析下转换为十进制后分别为：4，26和14820。与v$transaction中对应的事务标识一致。说明0x02事务槽对应的是我们会话事务。
4、启动第二个会话事务
当我们启动第二个会话事务时，观察情况。
SQL> select sid from v$mystat where rownum<2;
SID
----------
151
SQL> update t2 set vname='fk' where id=2;
1 row updated
事务信息和锁信息如下：
SQL> select addr,xidusn,xidslot,xidsqn from v$transaction;
ADDR XIDUSN XIDSLOT XIDSQN
-------- ---------- ---------- ----------
6C2A1314 5 34 3361
SQL> select addr, kaddr, sid, type, id1, id2, lmode from v$lock where sid=151 or sid=162 order by sid;
ADDR KADDR SID TY ID1 ID2 LMODE
-------- -------- ---------- -- ---------- ---------- ----------
6C2A1314 6C2A1428 151 TX 327716 3361 6
6C237F30 6C237F48 151 TM 58199 0 3
6C278F2C 6C279040 162 TX 262152 14821 6
6C237E9C 6C237EB4 162 TM 58199 0 3
两个事务同时作用在相同的数据块上。我们dump出数据块查看ITL。
*** 2012-09-15 11:38:06.921
*** ACTION NAME:() 2012-09-15 11:38:06.875
*** MODULE NAME:(SQL*Plus) 2012-09-15 11:38:06.875
*** SERVICE NAME:(SYS$USERS) 2012-09-15 11:38:06.875
*** SESSION ID:(151.12329) 2012-09-15 11:38:06.875
Start dump data blocks tsn: 4 file#: 4 minblk 566 maxblk 566
buffer tsn: 4 rdba: 0x01000236 (4/566)
scn: 0x0000.00a48fa4 seq: 0x01 flg: 0x04 tail: 0x8fa40601
frmt: 0x02 chkval: 0xfd0b type: 0x06=trans data
Block header dump: 0x01000236
Object id on Block? Y
seg/obj: 0xe357 csc: 0x00.a48f48 itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x1000231 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0005.024.00000d21 0x00800017.09f1.19 ---- 1 fsc 0x0000.00000000
0x02 0x0004.008.000039e5 0x008007a6.1916.0d ---- 1 fsc 0x0000.00000000
data_block_dump,data header at 0x65a0264
===============
tsiz: 0x1f98
hsiz: 0x16
pbl: 0x065a0264
bdba: 0x01000236
76543210
flag=--------
ntab=1
nrow=2
frre=-1
fsbo=0x16
fseo=0x1f73
avsp=0x1f70
tosp=0x1f70
0xe:pti[0] nrow=2offs=0
0x12:pri[0] offs=0x1f7c
0x14:pri[1] offs=0x1f73
block_row_dump:
tab 0, row 0, @0x1f7c
tl: 8 fb: --H-FL-- lb: 0x2 cc: 2
col 0: [ 2] c1 02
col 1: [ 1] 64
tab 0, row 1, @0x1f73
tl: 9 fb: --H-FL-- lb: 0x1 cc: 2
col 0: [ 2] c1 03
col 1: [ 2] 66 6b
end_of_block_dump
End dump data blocks tsn: 4 file#: 4 minblk 566 maxblk 566
两条ITL被占据。
5、第三个会话事务开启
当我们启动第三个会话事务，情况如何呢？
SQL> select sid from v$mystat where rownum<2;
SID
----------
149
SQL> insert into t2 values (3,'kl');
1 row inserted
锁定情况如下：
SQL> select addr, kaddr, sid, type, id1, id2, lmode from v$lock where sid=149 or sid=151 or sid=162 order by sid;
ADDR KADDR SID TY ID1 ID2 LMODE
-------- -------- ---------- -- ---------- ---------- ----------
6C27349C 6C2735B0 149 TX 393221 2958 6
6C238058 6C238070 149 TM 58199 0 3
6C2A1314 6C2A1428 151 TX 327716 3361 6
6C237F30 6C237F48 151 TM 58199 0 3
6C278F2C 6C279040 162 TX 262152 14821 6
6C237E9C 6C237EB4 162 TM 58199 0 3
已选择6行。
--对应v$transaction情况；
SQL> select addr,xidusn,xidslot,xidsqn from v$transaction;
ADDR XIDUSN XIDSLOT XIDSQN
-------- ---------- ---------- ----------
6C27349C 6 5 2958
6C278F2C 4 8 14821
6C2A1314 5 36 3361
事务开启，新插入的数据依然在当前研究数据块中。
SQL> select id, dbms_rowid.rowid_relative_fno(rowid) fno, dbms_rowid.rowid_block_number(rowid) bno, dbms_rowid.rowid_row_number(rowid) row_num from t2;
ID FNO BNO ROW_NUM
---------- ---------- ---------- ----------
1 1 65266 0
2 1 65266 1
3 1 65266 2
事务槽dump结果。
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0003.017.000085eb 0x008005d6.351e.11 ---- 1 fsc 0x0002.00000000
0x02 0x0009.019.000085e2 0x00800c4e.306a.2c ---- 1 fsc 0x0000.00000000
0x03 0x0002.008.000085fe 0x00800166.3192.0b ---- 1 fsc 0x0000.00000000
当当前准备的事务槽个数小于数据块进行的事务个数时，会进行事务槽自动拓展。
6、事务清理
当事务结束，事务槽清理。
SQL> alter system dump datafile 4 block 566;
System altered
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0007.02a.000085d4 0x00800ca8.35fc.09 C--- 0 scn 0x078c.7f2ddad3
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
7、结论
在Oracle数据块上，ITL是一个重要的部分。它与会话、事务、多版本一致度等特性密切相关
