itl在被覆蓋之前被儲存了下來！

究竟是被儲存在覆蓋它的這個事務所使用的undo的chain的end block還是start block中這個例子中沒有得到論證，改天再驗證。這裡先臨時記錄一下。[@more@]

session 1:
SQL> create table t1(id int) initrans 1;

表已建立。

SQL> insert into t1 values(1);

已建立 1 行。

SQL> select id,rowid from t1;

ID ROWID
---------- ------------------
1 AAAC49AABAAAIIaAAA

SQL> select id,dbms_rowid.rowid_relative_fno(rowid) fno,dbms_rowid.rowid_block_n
umber(rowid) bno from t1;

ID FNO BNO
---------- ---------- ----------
1 1 33306

SQL> commit;

提交完成。

SQL> alter system dump datafile 1 block 33306;

系統已更改。
--============================
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0010.017.00000983 0x01c0005c.18a8.42 --U- 1 fsc 0x0000.018e374f
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
--============================
--這裡插入2開啟的事務僅僅是為了佔用一個（第二個）itl，
不過為啥建表時制定的itl是1，可從dump的結果來看itl卻是2個
SQL> insert into t1 values(2);

已建立 1 行。

SQL>
--================================
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0010.017.00000983 0x01c0005c.18a8.42 --U- 1 fsc 0x0000.018e374f
0x02 0x000b.024.00000993 0x01c0000b.196d.01 ---- 1 fsc 0x0000.00000000
--================================
session 2:
SQL> variable i refcursor;
SQL> exec open :i for select * from t1;

PL/SQL 過程已成功完成。

SQL>
session 3:
SQL> select * from t1;

ID
----------
1

SQL> update t1 set id=3;

已更新 1 行。

SQL> select id , rowid from t1;

ID ROWID
---------- ------------------
3 AAAC49AABAAAIIaAAA

SQL> select id,dbms_rowid.rowid_relative_fno(rowid) fno,dbms_rowid.rowid_block_n
umber(rowid) bno from t1;

ID FNO BNO
---------- ---------- ----------
3 1 33306

SQL> alter system dump datafile 1 block 33306;

系統已更改。
--==================================
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0011.01e.00000976 0x01c00022.180d.02 ---- 1 fsc 0x0000.00000000
0x02 0x000b.024.00000993 0x01c0000b.196d.01 ---- 1 fsc 0x0000.00000000
--==================================
--很顯然itl：0x01已經被覆蓋了。
那麼此時在session 2中執行print i是結果咋樣呢？
session 2：
PL/SQL 過程已成功完成。

SQL> print i;

ID
----------
1

SQL>
--結果又找到了，結果id：1是如何被從undo中構造出來的呢？
我們想session 2如果能輸出id=1此時一定需要被session 3中事務
覆蓋的itl，那麼這個itl在被覆蓋之前究竟被存在哪裡呢？
在itl中存在uba，我們看看session 3中的事務使用的itl的uba：
SQL> select dbms_utility.data_block_address_file(to_number('01c00022','xxxxxxxx'
)) from dual;

DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(TO_NUMBER('01C00022','XXXXXXXX'))
----------------------------------------------------------------------
7

SQL> select dbms_utility.data_block_address_block(to_number('01c00022','xxxxxxxx
')) from dual;

DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(TO_NUMBER('01C00022','XXXXXXXX'))
-----------------------------------------------------------------------
34
SQL> alter system dump datafile 7 block 34;

系統已更改。
dump這個undo block看看是否在其中儲存了session 2所需要的itl：
從dump的內容來看這個undo block中存在2個rec，其中session 3中的
事務使用的rec值是2(0x01c00022.180d.02)
--===============
* Rec #0x2 slt: 0x1e objn: 11837(0x00002e3d) objd: 11837 tblspc: 0(0x00000000)
* Layer: 11 (Row) opc: 1 rci 0x00
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
rdba: 0x00000000
*-----------------------------
uba: 0x01c00022.180d.01 ctl max scn: 0x0000.018e33db prv tx scn: 0x0000.018e33e3
txn start scn: scn: 0x0000.018e37e0 logon user: 0
prev brb: 29360240 prev bcl: 0
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0010.017.00000983 uba: 0x01c0005c.18a8.42
flg: C--- lkc: 0 scn: 0x0000.018e374f
Array Update of 1 rows:
tabn: 0 slot: 0(0x0) flag: 0x2c lock: 0 ckix: 9
ncol: 1 nnew: 1 size: 0
KDO Op code: 21 row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x0040821a hdba: 0x00408219
itli: 1 ispac: 0 maxfr: 4863
vect = 0
col 0: [ 2] c1 02
--================
在這個rec 2中我們找到了session 2中需要的itl：
xid: 0x0010.017.00000983 uba: 0x01c0005c.18a8.42
flg: C--- lkc: 0 scn: 0x0000.018e374f
如果這個itl被覆蓋的話那麼在session 2中執行print i時就會報ora-01555錯誤，但是
此時在session 2中執行print i；oracle需要構造consistent get，
這個consistent get的過程暫時沒有搞清楚。