oracle快照太旧含义,全解ORA-1555快照太旧错误原理及解决方案
作者：?|【轉載時請以超鏈接形式標明文章和信息】
鏈接：
回滾機制的深入研究：
如果大家有興趣深入了解一下回滾段的機制，那么請跟隨我將前面的例子進一步深化。
1. 從DML更新事務開始：
重新來看這個更新語句：
sys@TQGZS11G> conn scott/tiger
Connected.
scott@TQGZS11G> select * from emp;
EMPNO ENAME?????????? JOB??????????????????? MGR HIREDATE?????????????? SAL?????? COMM???? DEPTNO
---------- --------------- --------------- ---------- --------------- ---------- ---------- ----------
7369 SMITH?????????? CLERK???????????????? 7902 17-DEC-80????????????? 800??????????????????? 20
7499 ALLEN?????????? SALESMAN????????????? 7698 20-FEB-81???????????? 1600??????? 300???????? 30
7521 WARD??????????? SALESMAN????????????? 7698 22-FEB-81???????????? 1250??????? 500???????? 30
7566 JONES?????????? MANAGER?????????????? 7839 02-APR-81???????????? 2975??????????????????? 20
7654 MARTIN????????? SALESMAN????????????? 7698 28-SEP-81???????????? 1250?????? 1400???????? 30
7698 BLAKE?????????? MANAGER?????????????? 7839 01-MAY-81???????????? 2850??????????????????? 30?????7782 CLARK?????????? MANAGER?????????????? 7839 09-JUN-81???????????? 2450??????????????????? 10??????7788 SCOTT?????????? ANALYST?????????????? 7566 19-APR-87???????????? 3000??????????????????? 20????? 7839 KING??????????? PRESIDENT????????????????? 17-NOV-81???????????? 5000??????????????????? 10
7844 TURNER????????? SALESMAN????????????? 7698 08-SEP-81???????????? 1500????????? 0???????? 30
7876 ADAMS?????????? CLERK???????????????? 7788 23-MAY-87???????????? 1100??????????????????? 20
7900 JAMES?????????? CLERK???????????????? 7698 03-DEC-81????????????? 950??????????????????? 30
7902 FORD??????????? ANALYST?????????????? 7566 03-DEC-81???????????? 3000??????????????????? 20
7934 MILLER????????? CLERK???????????????? 7782 23-JAN-82???????????? 1300??????????????????? 10
14 rows selected.
scott@TQGZS11G> update emp set sal=4000 where empno=7788;
1 row updated.
先不提交這個事務，在另外窗口新口Session，使用SYS用戶查詢相關信息，進行進一步分析研究。
2.獲得事務信息：
從事務表中可以獲得關于這個事務的信息，該事務位于6號回滾段(XIDUSN)，在6號回滾段上，該事務位于第0號事務槽(XIDSLOT)：
sys@TQGZS11G> select xidusn,xidslot,xidsqn,ubablk,ubafil,ubarec from v$transaction;
XIDUSN??? XIDSLOT???? XIDSQN???? UBABLK???? UBAFIL???? UBAREC
---------- ---------- ---------- ---------- ---------- ----------
6????????? 0??????? 898????? 20650????????? 3???????? 23
從V$ROLLSTAT視圖中也可以獲得事務信息，XACTS字段代表的是活動事務的數量，同樣看到該事務位于6號回滾段：
sys@TQGZS11G> select usn,writes,rssize,xacts,hwmsize,shrinks,wraps from v$rollstat;
USN???? WRITES???? RSSIZE????? XACTS??? HWMSIZE??? SHRINKS????? WRAPS
---------- ---------- ---------- ---------- ---------- ---------- ----------
0?????? 5408???? 385024????????? 0???? 385024????????? 0????????? 0
1????? 35358?? 52617216????????? 0?? 52617216????????? 0????????? 0
2????? 59510??? 2285568????????? 0??? 2285568????????? 0????????? 1
3????? 26232?? 61530112????????? 0?? 61530112????????? 0????????? 0
4????? 46336??? 2220032????????? 0??? 2220032????????? 0????????? 0
5????? 27252?? 38723584????????? 0?? 38723584????????? 0????????? 0
6????? 23784?? 31580160????????? 1?? 31580160????????? 0????????? 0
7????? 26116??? 3268608????????? 0??? 3268608????????? 0????????? 0
8????? 29098?? 40689664????????? 0?? 40689664????????? 0????????? 0
9????? 27214??? 1236992????????? 0??? 1236992????????? 0????????? 0
10????? 31534??? 2285568????????? 0??? 2285568????????? 0????????? 0
11 rows selected.
3. 獲得回滾段名稱并轉儲段頭信息：
查詢V$ROLLNAME視圖獲得回滾段名稱，并轉儲回滾段頭信息：
sys@TQGZS11G> select * from v$rollname where usn=6;
USN NAME
---------- --------------------------------------------------
6?_SYSSMU6_1186132793$
sys@TQGZS11G> alter system dump undo header '_SYSSMU6_1186132793$';
System altered.
生成的跟蹤文件如下：
sys@TQGZS11G> @gettrcname.sql
TRACE_FILE
--------------------------------------------------------------------------------
/oracle/diag/rdbms/tqgzs11g/tqgzs11g/trace/tqgzs11g_ora_10642.trc
4. 獲得跟蹤文件信息：
注意這就是前邊多次提到過的回滾段頭的信息，其中包括事務表信息，從以下的跟蹤文件中，可以清晰地看到這些內容：
********************************************************************************
Undo Segment:? _SYSSMU6_1186132793$ (6)
********************************************************************************
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0????? spare2: 0????? #extents: 122??? #blocks: 3855
last map? 0x00000000? #maps: 0????? offset: 4080
Highwater::? 0x00c050aa? ext#: 116??? blk#: 33???? ext size: 128
#blocks in seg. hdr's freelists: 0
#blocks below: 0
mapblk? 0x00000000? offset: 116
Unlocked
Map Header:: next? 0x00000000? #extents: 122? obj#: 0????? flag: 0x40000000
Extent Map
-----------------------------------------------------------------
0x00c0005a? length: 7
0x00c07d01? length: 8
0x00c07f09? length: 8
0x00c06289? length: 128
0x00c06671? length: 8
0x00c06709? length: 128
Retention Table
-----------------------------------------------------------
Extent Number:0? Commit Time: 1248914085
Extent Number:1? Commit Time: 1248914087
Extent Number:2? Commit Time: 1248914087
Extent Number:3? Commit Time: 1248914087
Extent Number:119? Commit Time: 1248914063
Extent Number:120? Commit Time: 1248914069
Extent Number:121? Commit Time: 1248914085
TRN CTL:: seq: 0x02d5 chd: 0x0010 ctl: 0x0013 inc: 0x00000000 nfb: 0x0000
mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x00c050aa.02d5.17 scn: 0x0000.0010603b
Version: 0x01
FREE BLOCK POOL::
uba: 0x00000000.02d5.16 ext: 0x74 spc: 0x14d6
uba: 0x00000000.02d5.05 ext: 0x74 spc: 0xc48
uba: 0x00000000.02d4.38 ext: 0x73 spc: 0x6f6
uba: 0x00000000.0000.00 ext: 0x0? spc: 0x0
uba: 0x00000000.0000.00 ext: 0x0? spc: 0x0
TRN TBL::
index? state cflags? wrap#??? uel???????? scn??????????? dba??????????? parent-xid??? nub???? stmt_num??? cmt
------------------------------------------------------------------------------------------------
0x00???10??? 0x80? 0x0382? 0x0074? 0x0000.0010633d??0x00c050aa? 0x0000.000.00000000? 0x00000001?? 0x00000000? 0?? 0x01??? 9??? 0x00? 0x0381? 0x000b? 0x0000.001061aa? 0x00c050a9? 0x0000.000.00000000? 0x00000001?? 0x00000000? 1
261838661
0x02??? 9??? 0x00? 0x0381? 0x001a? 0x0000.00106276? 0x00c050aa? 0x0000.000.00000000? 0x00000002?? 0x00000000? 1
261838662
回顧前面的事務信息，該事務正好占用的是第0號事務槽(0x00)，狀態(state)為10代表是活動事務。
5. 轉儲前鏡像信息：
再來看DBA(Data Block Address)，這個DBA指向的就是包含這個事務的前鏡像的數據地址0x00c050aa。看一下這個地址如何換算：DBA代表數據塊的存儲地址，由10位文件號＋22位數據塊(Block)組成。將0x00c050aa轉換為二進制就是：0000 0000 1100 0000 0101 0000 1010 1010。
前10位代表文件號為3，后22位代表Block號為20650。經過轉換后，該前鏡像信息位于file 3 block 20650。這與從事務表中查詢得到的數據完全一致：
sys@TQGZS11G> select xidusn,xidslot,xidsqn,ubablk,ubafil,ubarec from v$transaction;
XIDUSN??? XIDSLOT???? XIDSQN???? UBABLK???? UBAFIL???? UBAREC
---------- ---------- ---------- ---------- ---------- ----------
6????????? 0??????? 898????? 20650????????? 3???????? 23
提示：
很多深入研究的內容在數據庫內部都有完整的體現，不過通常我們很少注意，只有將兩者結合起來學習、研究和理解，我們才能深刻地理解到Oracle的本質。希望大家在閱讀這部分內容的時候能夠耐心、細致并有所收獲。
為了同時說明一些其它內容，繼續先前的SCOTT用戶的事務，再更新2條記錄：
scott@TQGZS11G> update emp set sal=4000 where empno=7788;
1 row updated.
scott@TQGZS11G> update emp set sal=4000 where empno=7782;
1 row updated.
scott@TQGZS11G> update emp set sal=4000 where empno=7698;
1 row updated.
然后將回滾段中的這個Block轉儲出來：
sys@TQGZS11G> alter system dump datafile 3 block 20650;
System altered.
這是跟蹤文件開始部分的信息：
sys@TQGZS11G> @gettrcname.sql
TRACE_FILE
--------------------------------------------------------------------------------
/oracle/diag/rdbms/tqgzs11g/tqgzs11g/trace/tqgzs11g_ora_10642.trc
*** 2009-12-26 23:10:20.230
Start dump data blocks tsn: 2 file#:3 minblk 20650 maxblk 20650
Block dump from cache:
Dump of buffer cache at level 4 for tsn=2, rdba=12603562
BH (0x247e5adc) file#: 3 rdba: 0x00c050aa (3/20650) class: 28 ba: 0x24442000
set: 3 bsz: 8192 bsi: 0 sflg: 0 pwc: 0, 25 lid: 0x00000000,0x00000000
dbwrid: 0 obj: -1 objn: 0 tsn: 2 afn: 3
hash: [0x24bf433c,0x323ad5b4] lru: [0x247e50ac,0x247e4e3c]
obj-flags: object_ckpt_list
ckptq: [0x243f1380,0x25ff1d40] fileq: [0x327dc7cc,0x26ff4858] objq: [0x26ff480c,0x303aa140]
st: XCURRENT md: NULL tch: 8
flags: buffer_dirty block_written_once redo_since_read
gotten_in_current_mode
LRBA: [0x37.1378.0] LSCN: [0x0.106841] HSCN: [0x0.10684c] HSUB: [1]
cr pin refcnt: 0 sh pin refcnt: 0
buffer tsn: 2 rdba: 0x00c050aa (3/20650)
scn: 0x0000.0010684c seq: 0x01 flg: 0x00 tail: 0x684c0201
frmt: 0x02 chkval: 0x0000 type: 0x02=KTU UNDO BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x24442000 to 0x24444000
24442000 0000A202 00C050AA 0010684C 00010000? [.....P..Lh......]
24442010 00000000 00000006 00000382 191902D5? [................]
24442020 1FE80000 1EE81F74 1DDC1E74 1CF01D78? [....t...t...x...]
24443FD0 C5480C10 B4AF0FAE 891FD92E FC98F37F? [..H.............]
24443FE0 1CA71084 28AEF9CD 11049EAA 5BB894EF? [.......(.......[]
24443FF0 2001136C 0C6D7807 182D081A 684C0201? [l.. .xm...-...Lh]
********************************************************************************
UNDO BLK:
xid: 0x0006.000.00000382? seq: 0x2d5 cnt: 0x19? irb: 0x19? icl: 0x0?? flg: 0x0000
注意這部分信息中有一個參數irb: 0x19，irb指的是回滾段中記錄的最近未提交變更開始之處，如果開始回滾，這是起始的搜索點。
接下來是回滾信息的偏移量，最后一個地址正好0x19的信息：
Rec Offset????? Rec Offset????? Rec Offset????? Rec Offset????? Rec Offset
---------------------------------------------------------------------------
0x01 0x1f74???? 0x02 0x1ee8???? 0x03 0x1e74???? 0x04 0x1ddc???? 0x05 0x1d78
0x06 0x1cf0???? 0x07 0x1bcc???? 0x08 0x1b64???? 0x09 0x1b0c???? 0x0a 0x1ab8
0x0b 0x1a5c???? 0x0c 0x19e8???? 0x0d 0x198c???? 0x0e 0x1938???? 0x0f 0x189c
0x10 0x1814???? 0x11 0x1788???? 0x12 0x1720???? 0x13 0x1690???? 0x14 0x1608
0x15 0x157c???? 0x16 0x1514???? 0x17 0x1490???? 0x18 0x1434???? 0x19 0x13d8
從接下來的信息中找到0x19信息：
*-----------------------------
* Rec #0x19? slt: 0x00? objn: 69515(0x00010f8b)? objd: 69515? tblspc: 4(0x00000004)
*?????? Layer:? 11 (Row)?? opc: 1???rci 0x18
Undo type:? Regular undo?? Last buffer split:? No
Temp Object:? No
Tablespace Undo:? No
rdba: 0x00000000
*-----------------------------
KDO undo record:
KTB Redo
op: 0x02? ver: 0x01
compat bit: 4 (post-11) padding: 1
op: C? uba: 0x00c050aa.02d5.18
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000? bdba: 0x0100001f? hdba: 0x0100001b
itli: 2? ispac: 0? maxfr: 4858
tabn: 0 slot: 5(0x5) flag: 0x2c lock: 0 ckix: 0
ncol: 8 nnew: 1 size: 1
col? 5: [ 3]??c2 1d 33
c2 1d 33轉換為十進制就是2850(關于數字值的內部存儲及轉換方式請參考)。這是最后更新記錄的前鏡像，Oracle就是這樣通過回滾段保留前鏡像信息的：
update emp set sal=4000 where empno=7698;
注意在這條UNDO記錄上，還記錄一個數據rci，該參數代表的就是UNDO Chain(同一事務中的多次修改，根據Chain鏈接關聯)的下一個偏移量，此處為rci 0x18。找到0x18這條UNDO記錄：
*-----------------------------
* Rec #0x18? slt: 0x00? objn: 69515(0x00010f8b)? objd: 69515? tblspc: 4(0x00000004)
*?????? Layer:? 11 (Row)?? opc: 1???rci 0x17
Undo type:? Regular undo?? Last buffer split:? No
Temp Object:? No
Tablespace Undo:? No
rdba: 0x00000000
*-----------------------------
KDO undo record:
KTB Redo
op: 0x02? ver: 0x01
compat bit: 4 (post-11) padding: 1
op: C? uba: 0x00c050aa.02d5.17
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000??bdba: 0x0100001f? hdba: 0x0100001b
itli: 2? ispac: 0? maxfr: 4858
tabn: 0 slot: 6(0x6) flag: 0x2c lock: 0 ckix: 0
ncol: 8 nnew: 1 size: 1
col? 5: [ 3]??c2 19 33
這里記錄的c2 19 33轉換為十進制就是2450，是第二條更新的前鏡像數據：
update emp set sal=4000 where empno=7782;
這里的rci指向下一條記錄rci 0x17，找到0x17：
*-----------------------------
* Rec #0x17? slt: 0x00? objn: 69515(0x00010f8b)? objd: 69515? tblspc: 4(0x00000004)
*?????? Layer:? 11 (Row)?? opc: 1???rci 0x00
Undo type:? Regular undo??? Begin trans??? Last buffer split:? No
Temp Object:? No
Tablespace Undo:? No
rdba: 0x00000000Ext idx: 0
flg2: 0
*-----------------------------
uba: 0x00c050aa.02d5.14 ctl max scn: 0x0000.00106005 prv tx scn: 0x0000.0010603b
txn start scn: scn: 0x0000.00000000 logon user: 81
prev brb: 12603560 prev bcl: 0
KDO undo record:
KTB Redo
op: 0x03? ver: 0x01
compat bit: 4 (post-11) padding: 1
op: Z
KDO Op code: URP row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080??bdba: 0x0100001f? hdba: 0x0100001b
itli: 2? ispac: 0? maxfr: 4858
tabn: 0 slot: 7(0x7) flag: 0x2c lock: 0 ckix: 0
ncol: 8 nnew: 1 size: 0
Vector content:
col? 5: [ 2]??c2 1f
這里c2 1f轉換為十進制是3000，正是第一條更新的前鏡像記錄：
update emp set sal=4000 where empno=7788;
這是這個事務中最老(遠)一條更新的數據，所以其UNDO Chain的指針為rci 0x00，表示這是最后一條記錄，也可以從x$bh中找到這些數據塊：
sys@TQGZS11G> select b.segment_name,a.file#,a.dbarfil,a.dbablk,a.class,a.state
2? from x$bh a,dba_extents b where b.relative_fno=a.dbarfil
3? and b.block_id <= a.dbablk and b.block_id + b.blocks > a.dbablk
4? and b.owner='SCOTT' and b.segment_name='EMP';
SEGMENT_NAME????????????? FILE#??? DBARFIL???? DBABLK????? CLASS????? STATE
-------------------- ---------- ---------- ---------- ---------- ----------
EMP?????????????????????????? 4????????? 4???????? 31????????? 1????????? 1
EMP?????????????????????????? 4????????? 4???????? 28????????? 1????????? 1
EMP?????????????????????????? 4????????? 4???????? 30????????? 1????????? 1
EMP?????????????????????????? 4????????? 4???????? 27????????? 4????????? 1
EMP?????????????????????????? 4????????? 4???????? 32????????? 1????????? 1
EMP?????????????????????????? 4????????? 4???????? 29????????? 1????????? 1
6 rows selected.
注意class為4的是段頭，class為1、塊號為31的為數據塊。如果此時在其他進程查詢scott.emp表，Oracle需要構造一致性讀，通過前鏡像把變化前的數據展現給用戶：
sys@TQGZS11G> select * from scott.emp;
EMPNO ENAME?????????? JOB??????????????????? MGR HIREDATE?????????????? SAL?????? COMM???? DEPTNO
---------- --------------- --------------- ---------- --------------- ---------- ---------- ----------
7369 SMITH?????????? CLERK???????????????? 7902 17-DEC-80????????????? 800??????????????????? 20
7499 ALLEN?????????? SALESMAN????????????? 7698 20-FEB-81???????????? 1600??????? 300???????? 30
7521 WARD??????????? SALESMAN????????????? 7698 22-FEB-81???????????? 1250??????? 500???????? 30
7566 JONES?????????? MANAGER?????????????? 7839 02-APR-81???????????? 2975??????????????????? 20
7654 MARTIN????????? SALESMAN????????????? 7698 28-SEP-81???????????? 1250?????? 1400???????? 30
7698 BLAKE?????????? MANAGER?????????????? 7839 01-MAY-81???????????? 2850??????????????????? 30
7782 CLARK?????????? MANAGER?????????????? 7839 09-JUN-81???????????? 2450??????????????????? 10
7788 SCOTT?????????? ANALYST?????????????? 7566 19-APR-87???????????? 3000??????????????????? 20????? 7839 KING??????????? PRESIDENT????????????????? 17-NOV-81???????????? 5000??????????????????? 10
7844 TURNER????????? SALESMAN????????????? 7698 08-SEP-81???????????? 1500????????? 0???????? 30
7876 ADAMS?????????? CLERK???????????????? 7788 23-MAY-87???????????? 1100??????????????????? 20
7900 JAMES?????????? CLERK???????????????? 7698 03-DEC-81????????????? 950??????????????????? 30
7902 FORD??????????? ANALYST?????????????? 7566 03-DEC-81???????????? 3000??????????????????? 20
7934 MILLER????????? CLERK???????????????? 7782 23-JAN-82???????????? 1300??????????????????? 10
14 rows selected.
再來查詢：
sys@TQGZS11G> select b.segment_name,a.file#,a.dbarfil,a.dbablk,a.class,a.state,
2? decode(bitand(flag,1),0,'N','Y') DIRTY
3? from x$bh a,dba_extents b where b.relative_fno=a.dbarfil
4? and b.block_id <= a.dbablk and b.block_id + b.blocks > a.dbablk
5? and b.owner='SCOTT' and b.segment_name='EMP';
SEGMENT_NAME????????????? FILE#??? DBARFIL???? DBABLK????? CLASS????? STATE DIR
-------------------- ---------- ---------- ---------- ---------- ---------- ---
EMP?????????????????????????? 4????????? 4???????? 31????????? 1????????? 3 N
EMP?????????????????????????? 4????????? 4???????? 31????????? 1????????? 3 N
EMP?????????????????????????? 4????????? 4???????? 31????????? 1????????? 1 Y
EMP?????????????????????????? 4????????? 4???????? 28????????? 1????????? 1 N
EMP?????????????????????????? 4????????? 4???????? 30????????? 1????????? 1 N
EMP?????????????????????????? 4????????? 4???????? 27????????? 4????????? 1 N
EMP?????????????????????????? 4????????? 4???????? 32????????? 1????????? 1 N
EMP?????????????????????????? 4????????? 4???????? 29????????? 1????????? 1 N
8 rows selected.
注意到此時，Buffer Cache中多出兩個數據塊，也就是31存在3份，其中STATE為3的就是一致性讀構造的前鏡像。
6. 轉儲數據塊信息：
在前鏡像信息中，Oracle還記錄了前鏡像對應的數據塊地址，用戶可以從bdba記錄中獲得這部分信息，以先前的一個數據為例，bdba: 0x0100001f記錄了更改數據塊的地址，0x0100001f經過轉換為二進制就是：0000 0001 0000 0000 0000 0000 0001 1111，也正是file 4 block 31。
再將數據表中的Block轉儲出來，看看其中記錄了什么樣的信息：
sys@TQGZS11G> alter system dump datafile 4 block 31;
System altered.
檢查跟蹤文件，獲取數據塊信息：
Start dump data blocks tsn: 4 file#:4 minblk 31 maxblk 31
*** 2009-12-27 02:33:59.457
Block dump from cache:
Dump of buffer cache at level 4 for tsn=4, rdba=16777247
Block dump from disk:
buffer tsn: 4 rdba: 0x0100001f (4/31)
scn: 0x0000.0010982d seq: 0x01 flg: 0x04 tail: 0x982d0601
frmt: 0x02 chkval: 0x68eb type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00B34600 to 0x00B36600
B34600 0000A206 0100001F 0010982D 04010000? [........-.......]
B34610 000068EB 00010001 00010F8B 0010982D? [.h..........-...]
B34620 1FE80000 00321F02 01000019 00120005? [......2.........]
B34630 00000223 00C05A9A 00410170 00008000? [#....Z..p.A.....]
B365D0 0204C202 002C1FC1 4AC20308 4D530546? [......,....JF.SM]
B365E0 05485449 52454C43 50C2034B B4770703? [ITH.CLERK..P..w.]
B365F0 0101110C 09C20201 15C102FF 982D0601? [..............-.]
Block header dump:? 0x0100001f
Object id on Block? Y
seg/obj: 0x10f8b? csc: 0x00.10982d? itc: 2? flg: E? typ: 1 - DATA
brn: 0? bdba: 0x1000019 ver: 0x01 opc: 0
inc: 0? exflg: 0
Itl?????????? Xid????????????????? Uba???????? Flag? Lck??????? Scn/Fsc
0x01?? 0x0005.012.00000223? 0x00c05a9a.0170.41? C---??? 0? scn 0x0000.0007eab2
0x02?? 0x0006.000.00000382? 0x00c050aa.02d5.19? ----??? 3? fsc 0x0002.00000000
bdba: 0x0100001f
data_block_dump,data header at 0xb34664
這里存在ITL事務槽信息，ITL事務槽指Interested Transaction List(ITL)，事務必須獲得一個ITL事務槽才能夠進行數據修改。ITL內容主要包括xid(Transaction ID)、Uba(Undo Block Address)和Lck(Lock Status)。
xid=Undo.Segment.Number+Transaction.Table.Slot.Number+Wrap
在以上輸出中，看到Itl2(0x02)上存在活動事務。將xid=0x0006.000.00000382分解一下：該事務指向6號回滾段，Slot號為0x00(轉換為十進制正好是0)，wrap#為0x0382，正是dump回滾段看到的那個事務。
index? state cflags? wrap#??? uel???????? scn??????????? dba??????????? parent-xid??? nub???? stmt_num??? cmt
------------------------------------------------------------------------------------------------
0x00?? 10??? 0x80? 0x0382? 0x0074? 0x0000.0010633d? 0x00c050aa? 0x0000.000.00000000? 0x00000001?? 0x00000000? 0
可以看到，在數據塊上同樣存在指向回滾段的事務信息。UBA代表的是Undo Block Address，指向具體的回滾段，可以看到該ITL上Uba＝0x00c050aa.02d5.19。將這個UBA進行分解，其中0x00c050aa正好是前鏡像的地址，seq：02d5是順序號，19是UNDO記錄的開始地址(irb信息)。
UBA的內容和UNDO中的信息完全相符：
UNDO BLK:
xid: 0x0006.000.00000382? seq: 0x2d5 cnt: 0x19? irb: 0x19? icl: 0x0?? flg: 0x0000
繼續向下可以找到這3條被修改的記錄，鎖定位信息LB指向0x2號ITL事務槽：
tab 0, row 5, @0x1d11
tl: 40 fb: --H-FL--?lb: 0x2? cc: 8
col? 0: [ 3]? c2 4d 63
col? 1: [ 5]? 42 4c 41 4b 45
col? 2: [ 7]? 4d 41 4e 41 47 45 52
col? 3: [ 3]? c2 4f 28
col? 4: [ 7]? 77 b5 05 01 01 01 01
col? 5: [ 2]? c2 29
col? 6: *NULL*
col? 7: [ 2]? c1 1f
tab 0, row 6, @0x1d39
tl: 40 fb: --H-FL--?lb: 0x2? cc: 8
col? 0: [ 3]? c2 4e 53
col? 1: [ 5]? 43 4c 41 52 4b
col? 2: [ 7]? 4d 41 4e 41 47 45 52
col? 3: [ 3]? c2 4f 28
col? 4: [ 7]? 77 b5 06 09 01 01 01
col? 5: [ 2]? c2 29
col? 6: *NULL*
col? 7: [ 2]? c1 0b
tab 0, row 7, @0x1e4c
tl: 40 fb: --H-FL--?lb: 0x2? cc: 8
col? 0: [ 3]? c2 4e 59
col? 1: [ 5]? 53 43 4f 54 54
col? 2: [ 7]? 41 4e 41 4c 59 53 54
col? 3: [ 3]? c2 4c 43
col? 4: [ 7]? 77 bb 04 13 01 01 01
col? 5: [ 2]? c2 29
col? 6: *NULL*
col? 7: [ 2]? c1 15
至此，整個事務過程被完全解析。最后總結一下這個事務的內部流程。
⑴ 首先當一個事務開始時，需要在回滾段事務表上分配一個事務槽。
⑵ 在數據塊頭部獲取一個ITL事務槽，該事務槽指向回滾段頭的事務槽。
⑶ 在修改數據之前，需要記錄前鏡像信息，這個信息以UNDO RECORD的形式存儲在回滾段中，回滾段頭事務槽指向該記錄。
⑷ 鎖定修改行，修改行鎖定位(lb-lock byte)指向ITL事務槽。
⑸ 數據修改可以進行。
這就是一個事務的基本流程。
7. 塊清除(Block Cleanouts)：
當發出提交(commit)之后，Oracle怎樣來處理。通過前面的日志可以知道，Oracle需要寫出Redo來保證故障時數據可以被恢復；我們也知道Oracle并不需要在提交時就寫出變更的數據塊。那么在提交時，Oracle需要對數據塊進行哪些操作呢？
回憶一下上文，可以知道，在事務需要修改數據時，必須分配ITL事務槽，必須鎖定行，必須分配回滾段事務槽和回滾空間記錄前鏡像。當事務提交時，Oracle需要將回滾段上的事務表信息標記為非活動，以便空間可以重用；那么還有ITL事務信息和鎖定信息需要清除，以記錄提交。
由于Oracle在數據塊上存儲了ITL和鎖定等事務信息，所以Oracle必須在事務提交之后清除這些事務數據。這就是塊清除。塊清除主要要清除的數據有行級鎖和ITL信息(包括提交標志、SCN等)。
如果提交時修改過的數據塊仍然在Buffer Cache之中，那么Oracle可以清除ITL信息，這叫作快速塊清除(Fast Block Cleanout)，快速塊清除還有一個限制，當修改的塊數量超過Buffer Cache約10％，則對超出部分不再進行快速塊清除。
如果提交事務的時候，修改過的數據塊已經被寫回到數據文件上(或大量修改超出Buffer Cache 10％的部分)，再次讀出該數據塊進行修改，顯然成本過于高昂，對于這種情況，Oracle選擇延遲塊清除(Delayed Block Cleanout)，等到下一次訪問該Block時再來清除ITL鎖定信息，這就是延遲塊清除。Oracle通過延遲塊清除來提高數據庫性能，加快提交操作。
快速提交是最普遍的情況，來看一下延遲塊清除的處理。繼續前面的測試：
scott@TQGZS11G> update emp set sal=4000 where empno=7788;
1 row updated.
scott@TQGZS11G> update emp set sal=4000 where empno=7782;
1 row updated.
scott@TQGZS11G> update emp set sal=4000 where empno=7698;
1 row updated.
更新完成之后，強制刷新Buffer Cache，將Buffer Cache中的數據都寫出到數據文件：
sys@TQGZS11G> alter session set events = 'immediate trace name flush_cache';
Session altered.
此時再提交事務：
scott@TQGZS11G> commit;
Commit complete.
由于此時更新過的數據已經寫出到數據文件，Oracle將執行延遲塊清除，將此時的數據塊和回滾段轉儲出來：
sys@TQGZS11G> alter system dump datafile 4 block 31;??? --數據塊
System altered.
sys@TQGZS11G> alter system dump undo header '_SYSSMU6_1186132793$';??? --回滾段頭
System altered.
sys@TQGZS11G> alter system dump datafile 3 block 20650;??????? --回滾段塊
System altered.
研究一下，查看數據塊上的信息，ITL事務信息仍然存在：
Start dump data blocks tsn: 4 file#:4 minblk 31 maxblk 31
*** 2009-12-27 03:18:33.727
Block dump from cache:
Dump of buffer cache at level 4 for tsn=4, rdba=16777247
Block dump from disk:
buffer tsn: 4 rdba: 0x0100001f (4/31)
scn: 0x0000.0010982d seq: 0x01 flg: 0x04 tail: 0x982d0601
frmt: 0x02 chkval: 0x68eb type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00B34600 to 0x00B36600
B34600 0000A206 0100001F 0010982D 04010000? [........-.......]
B34610 000068EB 00010001 00010F8B 0010982D? [.h..........-...]
B34620 1FE80000 00321F02 01000019 00120005? [......2.........]
B365D0 0204C202 002C1FC1 4AC20308 4D530546? [......,....JF.SM]
B365E0 05485449 52454C43 50C2034B B4770703? [ITH.CLERK..P..w.]
B365F0 0101110C 09C20201 15C102FF 982D0601? [..............-.]
Block header dump:? 0x0100001f
Object id on Block? Y
seg/obj: 0x10f8b? csc: 0x00.10982d? itc: 2? flg: E? typ: 1 - DATA
brn: 0? bdba: 0x1000019 ver: 0x01 opc: 0
inc: 0? exflg: 0
Itl?????????? Xid????????????????? Uba???????? Flag? Lck??????? Scn/Fsc
0x01?? 0x0005.012.00000223? 0x00c05a9a.0170.41? C---??? 0? scn 0x0000.0007eab2
0x02?? 0x0006.000.00000382? 0x00c050aa.02d5.19? ----??? 3? fsc 0x0002.00000000
bdba: 0x0100001f
data_block_dump,data header at 0xb34664
數據塊的鎖定信息仍然存在：
tab 0, row 5, @0x1d11
tl: 40 fb: --H-FL--?lb: 0x2? cc: 8
col? 0: [ 3]? c2 4d 63
col? 1: [ 5]? 42 4c 41 4b 45
col? 2: [ 7]? 4d 41 4e 41 47 45 52
col? 3: [ 3]? c2 4f 28
col? 4: [ 7]? 77 b5 05 01 01 01 01
col? 5: [ 2]? c2 29
col? 6: *NULL*
col? 7: [ 2]? c1 1f
tab 0, row 6, @0x1d39
tl: 40 fb: --H-FL--?lb: 0x2? cc: 8
col? 0: [ 3]? c2 4e 53
col? 1: [ 5]? 43 4c 41 52 4b
col? 2: [ 7]? 4d 41 4e 41 47 45 52
col? 3: [ 3]? c2 4f 28
col? 4: [ 7]? 77 b5 06 09 01 01 01
col? 5: [ 2]? c2 29
col? 6: *NULL*
col? 7: [ 2]? c1 0b
tab 0, row 7, @0x1e4c
tl: 40 fb: --H-FL--?lb: 0x2? cc: 8
col? 0: [ 3]? c2 4e 59
col? 1: [ 5]? 53 43 4f 54 54
col? 2: [ 7]? 41 4e 41 4c 59 53 54
col? 3: [ 3]? c2 4c 43
col? 4: [ 7]? 77 bb 04 13 01 01 01
col? 5: [ 2]? c2 29
col? 6: *NULL*
col? 7: [ 2]? c1 15
再來看回滾段的信息：
index? state cflags? wrap#??? uel???????? scn??????????? dba??????????? parent-xid??? nub???? stmt_num??? cmt
------------------------------------------------------------------------------------------------
0x00??? 9??? 0x00? 0x0382? 0x0010? 0x0000.0010b963? 0x00c050aa? 0x0000.000.00000000? 0x00000001?? 0x00000000? 1261854823
事務提交，事務表已經釋放。如果此時查詢SCOTT.EMP表，數據庫將產生延遲塊清除：
sys@TQGZS11G> set autotrace on
sys@TQGZS11G> select * from scott.emp;
EMPNO ENAME?????????? JOB??????????????????? MGR HIREDATE?????????????? SAL?????? COMM???? DEPTNO
---------- --------------- --------------- ---------- --------------- ---------- ---------- ----------
7369 SMITH?????????? CLERK???????????????? 7902 17-DEC-80????????????? 800??????????????????? 20
7499 ALLEN?????????? SALESMAN????????????? 7698 20-FEB-81???????????? 1600??????? 300???????? 30
7521 WARD??????????? SALESMAN????????????? 7698 22-FEB-81???????????? 1250??????? 500???????? 30
7566 JONES?????????? MANAGER?????????????? 7839 02-APR-81???????????? 2975??????????????????? 20
7654 MARTIN????????? SALESMAN????????????? 7698 28-SEP-81???????????? 1250?????? 1400???????? 30
7698 BLAKE?????????? MANAGER?????????????? 7839 01-MAY-81???????????? 4000??????????????????? 30
7782 CLARK?????????? MANAGER?????????????? 7839 09-JUN-81???????????? 4000??????????????????? 10
7788 SCOTT?????????? ANALYST?????????????? 7566 19-APR-87???????????? 4000??????????????????? 20
7839 KING??????????? PRESIDENT????????????????? 17-NOV-81???????????? 5000??????????????????? 10
7844 TURNER????????? SALESMAN????????????? 7698 08-SEP-81???????????? 1500????????? 0???????? 30
7876 ADAMS?????????? CLERK???????????????? 7788 23-MAY-87???????????? 1100??????????????????? 20
7900 JAMES?????????? CLERK???????????????? 7698 03-DEC-81????????????? 950??????????????????? 30
7902 FORD??????????? ANALYST?????????????? 7566 03-DEC-81???????????? 3000??????????????????? 20
7934 MILLER????????? CLERK???????????????? 7782 23-JAN-82???????????? 1300??????????????????? 10
14 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 3956160932
--------------------------------------------------------------------------
| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
--------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT? |????? |??? 14 |?? 518 |???? 3?? (0)| 00:00:01 |
|?? 1 |? TABLE ACCESS FULL| EMP? |??? 14 |?? 518 |???? 3?? (0)| 00:00:01 |
--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
0? recursive calls
0? db block gets
9? consistent gets
6? physical reads
116? redo size
1420? bytes sent via SQL*Net to client
420? bytes received via SQL*Net from client
2? SQL*Net roundtrips to/from client
0? sorts (memory)
0? sorts (disk)
14? rows processed
注意到查詢在此時產生了物理讀和Redo，這個Redo就是因為延遲塊清除導致的。再次查詢，則不會繼續生成Redo了：
sys@TQGZS11G> /
EMPNO ENAME?????????? JOB??????????????????? MGR HIREDATE?????????????? SAL?????? COMM???? DEPTNO
---------- --------------- --------------- ---------- --------------- ---------- ---------- ----------
7369 SMITH?????????? CLERK???????????????? 7902 17-DEC-80????????????? 800??????????????????? 20
7499 ALLEN?????????? SALESMAN????????????? 7698 20-FEB-81???????????? 1600??????? 300???????? 30
……
14 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 3956160932
--------------------------------------------------------------------------
| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
--------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT? |????? |??? 14 |?? 518 |???? 3?? (0)| 00:00:01 |
|?? 1 |? TABLE ACCESS FULL| EMP? |??? 14 |?? 518 |???? 3?? (0)| 00:00:01 |
--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
0? recursive calls
0? db block gets
8? consistent gets
0? physical reads
0? redo size
1420? bytes sent via SQL*Net to client
420? bytes received via SQL*Net from client
2? SQL*Net roundtrips to/from client
0? sorts (memory)
0? sorts (disk)
14? rows processed
再次轉儲一下該Block來看看此時數據庫塊上的信息：
sys@TQGZS11G> alter system dump datafile 4 block 31;??? --數據塊
System altered.
看到此時ITL事務信息已經清除，但是注意，這里的Xid和Uba信息仍然存在：
Start dump data blocks tsn: 4 file#:4 minblk 31 maxblk 31
Block dump from cache:
Dump of buffer cache at level 4 for tsn=4, rdba=16777247
BH (0x25bf891c) file#: 4 rdba: 0x0100001f (4/31) class: 1 ba: 0x25b2a000
set: 3 bsz: 8192 bsi: 0 sflg: 0 pwc: 0, 25 lid: 0x00000000,0x00000000
dbwrid: 0 obj: 69515 objn: 69515 tsn: 4 afn: 4
hash: [0x323a7804,0x323a7804] lru: [0x257f64ec,0x253f60dc]
ckptq: [NULL] fileq: [NULL] objq: [0x253f613c,0x303c4140]
st: XCURRENT md: NULL tch: 2
flags: only_sequential_access block_written_once redo_since_read
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [1]
cr pin refcnt: 0 sh pin refcnt: 0
buffer tsn: 4 rdba: 0x0100001f (4/31)
scn: 0x0000.0010bca8 seq: 0x01 flg: 0x04 tail: 0xbca80601
frmt: 0x02 chkval: 0x771a type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x25B2A000 to 0x25B2C000
25B2A000 0000A206 0100001F 0010BCA8 04010000? [................]
25B2A010 0000771A 00010001 00010F8B 0010BCA8? [.w..............]
25B2A020 1FE80000 00321F02 01000019 00120005? [......2.........]
25B2BFD0 0204C202 002C1FC1 4AC20308 4D530546? [......,....JF.SM]
25B2BFE0 05485449 52454C43 50C2034B B4770703? [ITH.CLERK..P..w.]
25B2BFF0 0101110C 09C20201 15C102FF BCA80601? [................]
Block header dump:? 0x0100001f
Object id on Block? Y
seg/obj: 0x10f8b? csc: 0x00.10bca8? itc: 2? flg: E? typ: 1 - DATA
brn: 0? bdba: 0x1000019 ver: 0x01 opc: 0
inc: 0? exflg: 0
Itl?????????? Xid????????????????? Uba???????? Flag? Lck??????? Scn/Fsc
0x01?? 0x0005.012.00000223? 0x00c05a9a.0170.41? C---??? 0? scn 0x0000.0007eab2
0x02?? 0x0006.000.00000382? 0x00c050aa.02d5.19? C---??? 0? scn 0x0000.0010b963bdba: 0x0100001f
data_block_dump,data header at 0x25b2a064
數據行的鎖定位也已經清除：
sys@TQGZS11G> alter system dump undo header '_SYSSMU6_1186132793$';??? --回滾段頭
System altered.
tab 0, row 5, @0x1d11
tl: 40 fb: --H-FL--?lb: 0x0? cc: 8
col? 0: [ 3]? c2 4d 63
col? 1: [ 5]? 42 4c 41 4b 45
col? 2: [ 7]? 4d 41 4e 41 47 45 52
col? 3: [ 3]? c2 4f 28
col? 4: [ 7]? 77 b5 05 01 01 01 01
col? 5: [ 2]? c2 29
col? 6: *NULL*
col? 7: [ 2]? c1 1f
tab 0, row 6, @0x1d39
tl: 40 fb: --H-FL--?lb: 0x0? cc: 8
col? 0: [ 3]? c2 4e 53
col? 1: [ 5]? 43 4c 41 52 4b
col? 2: [ 7]? 4d 41 4e 41 47 45 52
col? 3: [ 3]? c2 4f 28
col? 4: [ 7]? 77 b5 06 09 01 01 01
col? 5: [ 2]? c2 29
col? 6: *NULL*
col? 7: [ 2]? c1 0b
tab 0, row 7, @0x1e4c
tl: 40 fb: --H-FL--?lb: 0x0? cc: 8
col? 0: [ 3]? c2 4e 59
col? 1: [ 5]? 53 43 4f 54 54
col? 2: [ 7]? 41 4e 41 4c 59 53 54
col? 3: [ 3]? c2 4c 43
col? 4: [ 7]? 77 bb 04 13 01 01 01
col? 5: [ 2]? c2 29
col? 6: *NULL*
col? 7: [ 2]? c1 15
8. 提交之后的UNDO信息：
當提交事務之后，回滾段事務表標記事務為非活動，繼續再來看一下回滾段數據塊的信息。可以看到這里irb指向了0x3a，此前的事務已經不可回滾。
Start dump data blocks tsn: 2 file#:3 minblk 20650 maxblk 20650
Block dump from cache:
Dump of buffer cache at level 4 for tsn=2, rdba=12603562
BH (0x247e5adc) file#: 3 rdba: 0x00c050aa (3/20650) class: 28 ba: 0x24442000
set: 3 bsz: 8192 bsi: 0 sflg: 0 pwc: 0, 25 lid: 0x00000000,0x00000000
dbwrid: 0 obj: -1 objn: 0 tsn: 2 afn: 3
hash: [0x323ad5b4,0x323ad5b4] lru: [0x257e7aec,0x24bf30ec]
lru-flags: on_auxiliary_list
ckptq: [NULL] fileq: [NULL] objq: [NULL]
st: FREE md: NULL tch: 0 lfb: 33
flags:
cr pin refcnt: 0 sh pin refcnt: 0
Buffer contents not dumped
Block dump from disk:
buffer tsn: 2 rdba: 0x00c050aa (3/20650)
scn: 0x0000.0010bb59 seq: 0x03 flg: 0x04 tail: 0xbb590203
frmt: 0x02 chkval: 0xc30c type: 0x02=KTU UNDO BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00BEA600 to 0x00BEC600
BEA600 0000A202 00C050AA 0010BB59 04030000? [.....P..Y.......]
BEA610 0000C30C 00010006 00000382 3A3A02D5? [..............::]
BEA620 1FE80000 1EE81F74 1DDC1E74 1CF01D78? [....t...t...x...]
********************************************************************************
UNDO BLK:
xid: 0x0006.001.00000382? seq: 0x2d5 cnt: 0x3a??irb: 0x3a? icl: 0x0?? flg: 0x0000
偏移量列表也已經新增到信息0x3a 0x0198：
Rec Offset????? Rec Offset????? Rec Offset????? Rec Offset????? Rec Offset
---------------------------------------------------------------------------
0x01 0x1f74???? 0x02 0x1ee8???? 0x03 0x1e74???? 0x04 0x1ddc???? 0x05 0x1d78
0x06 0x1cf0???? 0x07 0x1bcc???? 0x08 0x1b64???? 0x09 0x1b0c???? 0x0a 0x1ab8
0x0b 0x1a5c???? 0x0c 0x19e8???? 0x0d 0x198c???? 0x0e 0x1938???? 0x0f 0x189c
0x10 0x1814???? 0x11 0x1788???? 0x12 0x1720???? 0x13 0x1690???? 0x14 0x1608
0x15 0x157c???? 0x16 0x1514???? 0x17 0x1490???? 0x18 0x1434???? 0x19 0x13d8
0x1a 0x1350???? 0x1b 0x12f4???? 0x1c 0x126c???? 0x1d 0x11f0???? 0x1e 0x1188
0x1f 0x1100???? 0x20 0x1084???? 0x21 0x101c???? 0x22 0x0f34???? 0x23 0x0ecc
0x24 0x0e74???? 0x25 0x0de4???? 0x26 0x0d90???? 0x27 0x0cf4???? 0x28 0x0c48
0x29 0x0b9c???? 0x2a 0x0af0???? 0x2b 0x0a44???? 0x2c 0x0998???? 0x2d 0x08ec
0x2e 0x0840???? 0x2f 0x0790???? 0x30 0x06e0???? 0x31 0x0630???? 0x32 0x05c4
0x33 0x0558???? 0x34 0x04a8???? 0x35 0x043c???? 0x36 0x03d0???? 0x37 0x0340
0x38 0x0258???? 0x39 0x01f0???? 0x3a 0x0198
至于前鏡像0x17、0x18、0x19的信息，仍然存在：
*-----------------------------
* Rec #0x17? slt: 0x00? objn: 69515(0x00010f8b)? objd: 69515? tblspc: 4(0x00000004)
*?????? Layer:? 11 (Row)?? opc: 1?? rci 0x00
Undo type:? Regular undo??? Begin trans??? Last buffer split:? No
Temp Object:? No
Tablespace Undo:? No
rdba: 0x00000000Ext idx: 0
flg2: 0
*-----------------------------
uba: 0x00c050aa.02d5.14 ctl max scn: 0x0000.00106005 prv tx scn: 0x0000.0010603b
txn start scn: scn: 0x0000.00000000 logon user: 81
prev brb: 12603560 prev bcl: 0
KDO undo record:
KTB Redo
op: 0x03? ver: 0x01
compat bit: 4 (post-11) padding: 1
op: Z
KDO Op code: URP row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080? bdba: 0x0100001f? hdba: 0x0100001b
itli: 2? ispac: 0? maxfr: 4858
tabn: 0 slot: 7(0x7) flag: 0x2c lock: 0 ckix: 0
ncol: 8 nnew: 1 size: 0
Vector content:
col? 5: [ 2]? c2 1f
*-----------------------------
* Rec #0x18? slt: 0x00? objn: 69515(0x00010f8b)? objd: 69515? tblspc: 4(0x00000004)
*?????? Layer:? 11 (Row)?? opc: 1?? rci 0x17
Undo type:? Regular undo?? Last buffer split:? No
Temp Object:? No
Tablespace Undo:? No
rdba: 0x00000000
*-----------------------------
KDO undo record:
KTB Redo
op: 0x02? ver: 0x01
compat bit: 4 (post-11) padding: 1
op: C? uba: 0x00c050aa.02d5.17
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000? bdba: 0x0100001f? hdba: 0x0100001b
itli: 2? ispac: 0? maxfr: 4858
tabn: 0 slot: 6(0x6) flag: 0x2c lock: 0 ckix: 0
ncol: 8 nnew: 1 size: 1
col? 5: [ 3]? c2 19 33
*-----------------------------
* Rec #0x19? slt: 0x00? objn: 69515(0x00010f8b)? objd: 69515? tblspc: 4(0x00000004)
*?????? Layer:? 11 (Row)?? opc: 1?? rci 0x18
Undo type:? Regular undo?? Last buffer split:? No
Temp Object:? No
Tablespace Undo:? No
rdba: 0x00000000
*-----------------------------
KDO undo record:
KTB Redo
op: 0x02? ver: 0x01
compat bit: 4 (post-11) padding: 1
op: C? uba: 0x00c050aa.02d5.18
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000? bdba: 0x0100001f? hdba: 0x0100001b
itli: 2? ispac: 0? maxfr: 4858
tabn: 0 slot: 5(0x5) flag: 0x2c lock: 0 ckix: 0
ncol: 8 nnew: 1 size: 1
col? 5: [ 3]? c2 1d 33
可以猜想，雖然這個事務已經提交，不可以回滾了，但是在覆蓋之前，這個前鏡像信息仍然存在，通過某種手段，我們應該仍然可以獲得這個信息。這個猜想顯然是成立的。
總結
以上是生活随笔為你收集整理的oracle快照太旧含义,全解ORA-1555快照太旧错误原理及解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： php 订单状态描述,获取不同状态订单列
- 下一篇： lock object oracle,o