事務提交時itl上flag標記U測試！

The U stands for "upper bound commit", meaning that the SCN is an upper bound for the time at which it committed. Note that the U flag in the ITL is also set for a fast commit, but the two cases can be distinguished by the presence or absence of row-level locks.

本例中測試的僅僅是fast commit

[@more@]

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

ID FNO BNO
---------- ---------- ----------
1 1 32962
2 1 32962
3 1 32962
4 1 32962
5 1 32962
6 1 32962

已選擇6行。

SQL> alter system dump datafile 1 block 32962;

系統已更改。
--=======================
Start dump data blocks tsn: 0 file#: 1 minblk 32962 maxblk 32962
buffer tsn: 0 rdba: 0x004080c2 (1/32962)
scn: 0x0000.018ee45f seq: 0x01 flg: 0x06 tail: 0xe45f0601
frmt: 0x02 chkval: 0x8864 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x08602200 to 0x08604200
..................省去無關資訊
Block header dump: 0x004080c2
Object id on Block? Y
seg/obj: 0x2eab csc: 0x00.18ee454 itc: 2 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0013.001.0000099d 0x01c00077.18aa.09 --U- 1 fsc 0x0000.018ee455
0x02 0x000c.00a.0000099e 0x01c00012.198f.09 --U- 1 fsc 0x0000.018ee45f

data_block_dump,data header at 0x860225c
===============
tsiz: 0x1fa0
hsiz: 0x1e
pbl: 0x0860225c
bdba: 0x004080c2
76543210
flag=--------
ntab=1
nrow=6
frre=-1
fsbo=0x1e
fseo=0x1f7c
avsp=0x1f4c
tosp=0x1f4c
0xe:pti[0] nrow=6 offs=0
0x12:pri[0] offs=0x1f9a
0x14:pri[1] offs=0x1f94
0x16:pri[2] offs=0x1f8e
0x18:pri[3] offs=0x1f88
0x1a:pri[4] offs=0x1f82
0x1c:pri[5] offs=0x1f7c
block_row_dump:
tab 0, row 0, @0x1f9a
tl: 6 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 2] c1 02
tab 0, row 1, @0x1f94
tl: 6 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 2] c1 03
tab 0, row 2, @0x1f8e
tl: 6 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 2] c1 04
tab 0, row 3, @0x1f88
tl: 6 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 2] c1 05
tab 0, row 4, @0x1f82
tl: 6 fb: --H-FL-- lb: 0x1 cc: 1
col 0: [ 2] c1 06
tab 0, row 5, @0x1f7c
tl: 6 fb: --H-FL-- lb: 0x2 cc: 1
col 0: [ 2] c1 07
end_of_block_dump
End dump data blocks tsn: 0 file#: 1 minblk 32962 maxblk 32962
*** 2009-03-22 07:39:50.718
--=======================
--表上面沒有事務，但是我們發現最後2行資料的lock byte(lb)沒有清除，
分別是0x1和0x2(0x1,0x2代表的是itl的編號，表示這行資料受使用這個itl的事務
所影響)，說明事務commit之後只是釋放了undo的slot和data block中的itl，但是
並沒有清楚每一個的鎖標記(lb),可能是為了節約時間吧，此時itl中的FLAG的第三
位是'U'，這裡U所表示的意思是fast commit

SQL> select to_number('018ee45f','xxxxxxxx') from dual;

TO_NUMBER('018EE45F','XXXXXXXX')
--------------------------------
26141791

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
26215065

SQL> insert into t values(1);

已建立 1 行。

SQL> alter system dump datafile 1 block 32962;

系統已更改。
--==========================
Start dump data blocks tsn: 0 file#: 1 minblk 32962 maxblk 32962
buffer tsn: 0 rdba: 0x004080c2 (1/32962)
scn: 0x0000.0190029d seq: 0x01 flg: 0x00 tail: 0x029d0601
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x08602200 to 0x08604200
................省去無關資訊！
Block header dump: 0x004080c2
Object id on Block? Y
seg/obj: 0x2eab csc: 0x00.190029d itc: 2 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x000f.007.000009a0 0x01c00058.18f7.21 ---- 1 fsc 0x0000.00000000
0x02 0x000c.00a.0000099e 0x01c00012.198f.09 C--- 0 scn 0x0000.018ee45f

data_block_dump,data header at 0x860225c
===============
tsiz: 0x1fa0
hsiz: 0x20
pbl: 0x0860225c
bdba: 0x004080c2
76543210
flag=--------
ntab=1
nrow=7
frre=-1
fsbo=0x20
fseo=0x1f76
avsp=0x1f41
tosp=0x1f41
0xe:pti[0] nrow=7 offs=0
0x12:pri[0] offs=0x1f9a
0x14:pri[1] offs=0x1f94
0x16:pri[2] offs=0x1f8e
0x18:pri[3] offs=0x1f88
0x1a:pri[4] offs=0x1f82
0x1c:pri[5] offs=0x1f7c
0x1e:pri[6] offs=0x1f76
block_row_dump:
tab 0, row 0, @0x1f9a
tl: 6 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 2] c1 02
tab 0, row 1, @0x1f94
tl: 6 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 2] c1 03
tab 0, row 2, @0x1f8e
tl: 6 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 2] c1 04
tab 0, row 3, @0x1f88
tl: 6 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 2] c1 05
tab 0, row 4, @0x1f82
tl: 6 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 2] c1 06
tab 0, row 5, @0x1f7c
tl: 6 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 2] c1 07
tab 0, row 6, @0x1f76
tl: 6 fb: --H-FL-- lb: 0x1 cc: 1
col 0: [ 2] c1 02
end_of_block_dump
End dump data blocks tsn: 0 file#: 1 minblk 32962 maxblk 32962
--==========================
SQL> select to_number('0190029d','xxxxxxxx') from dual;

TO_NUMBER('0190029D','XXXXXXXX')
--------------------------------
26215069

SQL>
--上面提到沒有清除的lb什麼時候清除呢？到下一次事務出現時（
可能是吧或者是下次事務使用這個block時，都是猜測），這樣做的目的
應該是為了節約commit的時間吧。我們插入了一條資料發現資料行上
之前沒有清除的鎖標記(lb)被清楚了，同時itl上的flag標記的第一位變成了C,
C表示的意思我想就是徹底提交的意思吧。