Oracle Block浅析2：ITL(Interested Transaction List)
一.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 找到數據的前鏡像了。
?
轉載于:https://www.cnblogs.com/polestar/archive/2013/03/11/2953716.html
總結
以上是生活随笔為你收集整理的Oracle Block浅析2：ITL(Interested Transaction List)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 忘不了的昨天是什么歌？
- 下一篇： 技术人生：码农必读