一.ITL(Interested Transaction List)：
ITL(Interested Transaction List)是Oracle数据块内部的一个组成部分，位于数据块头（block header），itl由xid，uba，flag，lck和scn/fsc组成，
用来记录该块所有发生的事务，一个itl可以看作是一条事务记录
当发出一条sql语句时，ORACLE会记录下这个时刻(SCN),然后在buffer cache中查找需要的BLOCK,或者从磁盘上读。当别的会话修改了数据，或者正在修改数据，就会在相应的block上记录ITL,此时ORACLE发现ITL中记录的SCN(Scn/Fsc)大于SELECT时刻的SCN，那么ORACLE就会根据ITL中的Uba找到UNDO信息获得该block的前镜像，然后在buffer cache 中构造出CR(consistent read)块，此时ORALCE 也会检查构造出来的BLOCK中ITL记录的SCN(Scn/Fsc)，如果SCN(Scn/Fsc)还大于select时刻的SCN，那么一直重复构造前镜像，然后ORACLE找到前镜像BLOCK中的ITL的SCN是否小于select的SCN,同时检查这个事物有没有提交或者回滚，如果没有，那么继续构造前镜像，直到找到需要的BLOCK，如果在构造前镜像的过程中所需的UNDO信息被覆盖了，就会报快照过旧的错误。
二.ITL Cleanout和Delayed block cleanout.
在接触ITL Cleanout和Delayed block cleanout之前先了解一个概念--快速提交：在事务提交（commit）前，会在数据块的头部记录下这个Cleanout SCN(Csc)号、Undo Block Address(Uba)和Transaction ID(Xid)；并且在在对应Interested Transaction List(Itl)中设置锁标志，记录这个事务在这数据块中产生的锁的数目；同时在对应修改的数据记录上打上行级锁标志，并映射到对应的Itl去。当提交时，并不会一一清除掉所有锁标志，而是给对应的Itl打上相应标志，告诉后面访问该数据块的事务，相应的事务已经提交。这就叫做快速提交（Fast Commit）。
2.1导出block信息：
1 SQL> select * from t; 2 3 ID NAME 4 ---------- ------------------------------ 5 1 oracle 6 2 oracle 7 3 noslq 8 SQL> update t set name='mysql' where id=2; 9 10 1 row updated. 11 12 SQL> select 13 2 dbms_rowid.rowid_relative_fno(rowid) REL_FNO, 14 3 dbms_rowid.rowid_block_number(rowid) BLOCK_NO 15 4 from t; 16 17 REL_FNO BLOCK_NO 18 ---------- ---------- 19 1 61186 20 1 61186 21 1 61186 22 23 SQL> alter system dump datafile 1 block 61186; 24 25 System altered. 26 27 SQL> oradebug setmypid; 28 Statement processed. 29 SQL> oradebug tracefile_name 30 /u01/admin/sun/udump/sun_ora_1832.trc 31 SQL> !vi /u01/admin/sun/udump/sun_ora_1832.trc
2.2查看trace文件(commit前)：
1 -------------------- 2 3 Itl Xid Uba Flag Lck Scn/Fsc 4 0x01 0x0001.026.00000150 0x008003c0.0113.17 ---- 1 fsc 0x0000.00000000 5 0x02 0x0005.013.00000190 0x0080004b.013a.17 ---- 1 fsc 0x0001.00000000 6 -------------------- 7 block_row_dump: 8 tab 0, row 0, @0x1f6e 9 tl: 13 fb: --H-FL-- lb: 0x0 cc: 2 10 col 0: [ 2] c1 02 11 col 1: [ 6] 6f 72 61 63 6c 65 12 tab 0, row 1, @0x1f55 13 tl: 12 fb: --H-FL-- lb: 0x2 cc: 2 --对应itl 0x02 14 col 0: [ 2] c1 03 15 col 1: [ 5] 6d 79 73 71 6c 16 tab 0, row 2, @0x1f61 17 tl: 13 fb: --H-FL-- lb: 0x1 cc: 2 18 col 0: [ 2] c1 04 19 col 1: [ 6] 6f 72 61 63 6c 65 20 end_of_block_dump
2.3 查看trace文件(commit后)：即产生快速提交
1 ---------------- 2 Start dump data blocks tsn: 0 file#: 1 minblk 61186 maxblk 61186 3 buffer tsn: 0 rdba: 0x0040ef02 (1/61186) 4 scn: 0x0000.000d206f seq: 0x01 flg: 0x02 tail: 0x206f0601 5 frmt: 0x02 chkval: 0x0000 type: 0x06=trans data 6 ---------------- 7 Itl Xid Uba Flag Lck Scn/Fsc 8 0x01 0x0001.026.00000150 0x008003c0.0113.17 ---- 1 fsc 0x0000.00000000 9 0x02 0x0005.013.00000190 0x0080004b.013a.17 --U- 1 fsc 0x0001.000d206f 10 11 ----------------- 12 block_row_dump: 13 tab 0, row 0, @0x1f6e 14 tl: 13 fb: --H-FL-- lb: 0x0 cc: 2 15 col 0: [ 2] c1 02 16 col 1: [ 6] 6f 72 61 63 6c 65 17 tab 0, row 1, @0x1f55 18 tl: 12 fb: --H-FL-- lb: 0x2 cc: 2 --对应itl 0x02 19 col 0: [ 2] c1 03 20 col 1: [ 5] 6d 79 73 71 6c 21 tab 0, row 2, @0x1f61 22 tl: 13 fb: --H-FL-- lb: 0x1 cc: 2 23 col 0: [ 2] c1 04 24 col 1: [ 6] 6f 72 61 63 6c 65 25 end_of_block_dump
对比两次ITL(快速提交前后)信息发现：ITL为0x02的 Flag由‘----’变成‘--U-',即事物有活动变为已提交(Scn/Fsc也发生了变化) 。但我们可以看到Lck还是1，也就是说行上的锁还未释放。--U-什么时候会变成C---呢？只有当oracle在该块上发生了itl cleanout或者delayed block cleanout时才会将之变成C---。
什么是itl cleanout：
一个新的事务过来时，它首先会选择一个itl槽，首先oracle采用C---状态的事务，如果没有C---状态的事务，oracle就会发生一次itl cleanout，检查所有的ITL相关的事务，如果确认事务已经提交了，就将之修改为C---状态了。
此时再来一个事务后，可以发现其状态变为：
1 Itl Xid Uba Flag Lck Scn/Fsc 2 0x01 0x0001.026.00000150 0x008003c0.0113.17 ---- 1 fsc 0x0000.00000000 3 0x02 0x0005.013.00000190 0x0080004b.013a.17 C--- 0 scn 0x0000.000d206f
delayed block cleant有两种情况下会发生：
1.如果一个transaction修改的block超过db cache的10%.
2.当一个事务未提交时，其修改过的block就已经写到硬盘上去了。此时事务提交了，并不会修改数据块上的状态。
导出block信息：
1 SQL> select * from t; 2 3 ID NAME 4 ---------- ------------------------------ 5 1 oracle 6 2 mysql 7 3 noslq 8 9 SQL> update t set name='informax' where id=1; 10 11 1 row updated. 12 13 SQL> select 14 2 dbms_rowid.rowid_relative_fno(rowid) REL_FNO, 15 3 dbms_rowid.rowid_block_number(rowid) BLOCK_NO 16 4 from t; 17 18 REL_FNO BLOCK_NO 19 ---------- ---------- 20 1 61186 21 1 61186 22 1 61186 23 24 SQL>
25 26 --27 28 SQL> alter system flush buffer_cache; --在未提交的情况下，将数据写如此盘 29 30 System altered. 31 32 SQL>
--查看trace文件(commit前)
1 Start dump data blocks tsn: 0 file#: 1 minblk 61186 maxblk 61186 2 buffer tsn: 0 rdba: 0x0040ef02 (1/61186) 3 scn: 0x0000.000d32c3 seq: 0x01 flg: 0x04 tail: 0x32c30601 4 frmt: 0x02 chkval: 0x05fb type: 0x06=trans data 5 6 Itl Xid Uba Flag Lck Scn/Fsc 7 0x01 0x0001.001.00000153 0x00800164.0118.19 ---- 1 fsc 0x0000.00000000 8 0x02 0x0005.013.00000190 0x0080004b.013a.17 C--- 0 scn 0x0000.000d206f
--提交
1 SQL>commit;--正常情况下，会修改block里的scn，但在此种情况下oracle并未修改，oracle只更新undo segment header slot。
--查看trace文件(commit后)
1 Start dump data blocks tsn: 0 file#: 1 minblk 61186 maxblk 61186 2 buffer tsn: 0 rdba: 0x0040ef02 (1/61186) 3 scn: 0x0000.000d32c3 seq: 0x01 flg: 0x04 tail: 0x32c30601 4 frmt: 0x02 chkval: 0x05fb type: 0x06=trans data 5 6 Itl Xid Uba Flag Lck Scn/Fsc 7 0x01 0x0001.001.00000153 0x00800164.0118.19 ---- 1 fsc 0x0000.00000000 8 0x02 0x0005.013.00000190 0x0080004b.013a.17 C--- 0 scn 0x0000.000d206f
在提交之前buffer cache中的脏数据已经被DBwn进程写回，那么Itl中的事务标志就不会被更新，并且数据块的Itl列表也不会记录下事务的Commit SCN 。后面的事务或查询语句访问该数据块时，为了检测是否需要进行一致性读（如果数据块的Itl中记录的提交事务的Commit SCN 大于当前访问该数据块的SCN，则需要进行一致性读），就需要通过Undo Block Address和Transaction ID到回滚段的事务信息表中去检查前面事务的状态和它的Commit SCN，确定是否做一致性读，最后将前面事务在该数据块上的标志做一次Cleanout。
--查询
1 SQL> select * from t; 2 3 ID NAME 4 ---------- ------------------------------ 5 1 informax 6 2 mysql 7 3 noslq 8 SQL>
--查看trace文件
1 Start dump data blocks tsn: 0 file#: 1 minblk 61186 maxblk 61186 2 buffer tsn: 0 rdba: 0x0040ef02 (1/61186) 3 scn: 0x0000.000d35df seq: 0x01 flg: 0x00 tail: 0x35df0601 4 frmt: 0x02 chkval: 0x0000 type: 0x06=trans data 5 6 Itl Xid Uba Flag Lck Scn/Fsc 7 0x01 0x0001.001.00000153 0x00800164.0118.19 C--- 0 scn 0x0000.000d3322 8 0x02 0x0005.013.00000190 0x0080004b.013a.17 C--- 0 scn 0x0000.000d206f
对比两次ITL 0x01中的Flag,lck,Scn/Fsc的值，即可发现其变化
三.根据ITL找数据的前镜像
--前面提到了ITL 保存了SCN 和Unto的信息。 在这里，我们就测试一下通过ITL 找到对应的Undo 内容
3.1.1 准备测试数据
1 --查看t表的记录 2 SQL> select * from t; 3 4 ID NAME 5 ---------- ------------------------------ 6 1 oracle 7 2 oracle 8 3 noslq 9 10 SQL> 11 12 -- 查看id=1 记录存储的数据块位置 13 SQL> select 14 2 dbms_rowid.rowid_relative_fno(rowid) file_id, 15 3 dbms_rowid.rowid_block_number(rowid) block_id 16 4 from t where id=3; 17 18 FILE_ID BLOCK_ID 19 ---------- ---------- 20 1 61186 21 22 SQL> 23 24 --更新id=1的数据库，不要提交。此时相应的ITL中会产生一个SCN(Scn/Fsc) 25 SQL> update t set name='oracle' where id=3; 26 1 row updated. 27 SQL> 28 29 -- dump 该数据块（新建会话） 30 SQL> alter system dump datafile 1 block 61186; 31 32 System altered. 33 34 SQL> 35 36 --使用oradebug 查看当前trace 文件位置 37 SQL> oradebug setmypid; 38 Statement processed. 39 SQL> oradebug tracefile_name 40 /u01/admin/sun/udump/sun_ora_1764.trc 41 SQL> 42 43 --在trace 文件里找到我们的ITL： 44 45 Itl Xid Uba Flag Lck Scn/Fsc 46 0x01 0x0001.026.00000150 0x008003c0.0113.17 ---- 1 fsc 0x0000.00000000 47 0x02 0x0007.02c.00000141 0x0080006d.00de.01 C--- 0 scn 0x0000.000d1951 48 49 --因为我们执行了一条update 操作，并且没有commit，那么这里的lock 为1，即Lck值为1. 即对应我们ITL 值为0x01 的记录。 50 51 52 SQL> select xidusn,xidslot,xidsqn,ubafil,ubablk,ubasqn,ubarec from v$transaction; 53 54 XIDUSN XIDSLOT XIDSQN UBAFIL UBABLK UBASQN UBAREC 55 ---------- ---------- ---------- ---------- ---------- ---------- ---------- 56 1 38 336 2 960 275 23
3.1.2 验证XID
1 --ITL中的XID的格式为: usn#.slot#.wrap# 2 --ITL 为0x01中的XID=0x0001.026.00000150 3 4 SQL> select to_number('0001','XXXXX') from dual; 5 6 TO_NUMBER('0001','XXXXX') 7 ------------------------- 8 1 9 10 SQL> select to_number('026','XXXXX') from dual; 11 12 TO_NUMBER('026','XXXXX') 13 ------------------------ 14 38 15 16 SQL> select to_number('00000150','XXXXXXXXX')from dual; 17 18 TO_NUMBER('00000150','XXXXXXXXX') 19 --------------------------------- 20 336 21 22 这个和V$TRANSACTION中记录的XIDUSN,XIDSLOT,XIDSQN相同。
3.1.3 验证uba
1 --UBA的格式为：DBA.seq#.rec# 2 --ITL为0x01记录中的UBA=0x008003c0.0113.17， 其中0x008003c0表示的DBA（Data Block Address）的地址。 3 4 --将DBA（Data Block Address）解析成file_id 和 block_id. 5 SQL> select 6 2 dbms_utility.data_block_address_file(to_number('008003c0','xxxxxxxxxxxx')) file_id, 7 3 dbms_utility.data_block_address_block(to_number('008003c0','xxxxxxxxxxxx')) block_id 8 4 from dual; 9 10 FILE_ID BLOCK_ID 11 ---------- ---------- 12 2 960 13 14 --将seq#转化成 UBASQN 15 SQL> select to_number('0113','xxxx') from dual; 16 17 TO_NUMBER('00DE','XXXX') 18 ------------------------ 19 275 20 21 --将rec#转化成 UBAREC 22 SQL> select to_number('17','xxxx') from dual; 23 24 TO_NUMBER('17','XXXX') 25 ---------------------- 26 23 27 28 这个和v$transaction相同。
3.1.5 dump undo回滚段，找到更改的前镜像
1 -- dump undo block 2 SQL> alter system dump datafile 2 block 960; 3 System altered. 4 5 --get trace file 6 SQL> oradebug setmypid 7 Statement processed. 8 SQL> oradebug tracefile_name 9 /u01/admin/sun/udump/sun_ora_1629.trc 10 SQL> 11 在dump 文件中找到xid 为 0x0001.026.00000150 的记录。 12 --小技巧： 13 --这个文件很大，查找很麻烦，我们可以使用vi 的查找功能来实现。 14 -- （1）vi /opt/oracle/diag/rdbms/nwom/nwom/trace/nwom_ora_13900.trc 15 -- （2）输入：/0x0001.026.00000150 16 -- （3）如果只有一条记录，一次就能匹配到，如果有多条记录，我们按字母n，查找下一条，知道找到结果位置。 17 -- 18 19 --查找的信息如下： 20 ******************************************************************************** 21 UNDO BLK: 22 xid: 0x0001.026.00000150 seq: 0x113 cnt: 0x17 irb: 0x17 icl: 0x0 flg: 0x0000 23 24 --该数据块的uba=0x008003c0.0113.17。 25 --uba的格式：DBA.seq#.rec#。 26 --这个的cnt对应uba中的rec#。根据这个cnt序列号，我们查找对应的具体内容： 27 28 *----------------------------- 29 * Rec #0x17 slt: 0x26 objn: 52737(0x0000ce01) objd: 52737 tblspc: 0(0x00000000) 30 * Layer: 11 (Row) opc: 1 rci 0x00 31 Undo type: Regular undo Begin trans Last buffer split: No 32 Temp Object: No 33 Tablespace Undo: No 34 rdba: 0x00000000 35 *----------------------------- 36 uba: 0x008003c0.0113.16 ctl max scn: 0x0000.000d12f4 prv tx scn: 0x0000.000d133f 37 txn start scn: scn: 0x0000.000d189d logon user: 0 38 prev brb: 8389563 prev bcl: 0 39 KDO undo record: 40 KTB Redo 41 op: 0x04 ver: 0x01 42 op: L itl: xid: 0x000a.021.0000013e uba: 0x00800011.00f1.2a 43 flg: C--- lkc: 0 scn: 0x0000.000d1240 44 KDO Op code: URP row dependencies Disabled 45 xtype: XA flags: 0x00000000 bdba: 0x0040ef02 hdba: 0x0040ef01 46 itli: 1 ispac: 0 maxfr: 4863 47 tabn: 0 slot: 2(0x2) flag: 0x2c lock: 0 ckix: 12 48 ncol: 2 nnew: 1 size: -1 49 col 1: [ 5] 6e 6f 73 6c 71 50 51 End dump data blocks tsn: 1 file#: 2 minblk 960 maxblk 960 52 53 54 SQL> set serveroutput on 55 SQL> declare n varchar2(20); 56 2 begin 57 3 dbms_stats.convert_raw_value('6e6f736c71',n); 58 4 dbms_output.put_line(n); 59 5 end; 60 6 / 61 noslq 62 63 PL/SQL procedure successfully completed. 64 65 SQL> 66 --通过这个测试，清楚了Oracle 通过ITL 找到数据的前镜像了。