程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> Oracle數據庫 >> Oracle教程 >> ORA-01555錯誤總結(二)

ORA-01555錯誤總結(二)

編輯:Oracle教程

這篇文章緊接著上一篇“ORA-01555錯誤總結(一)”,主要描述延遲塊清除導致的ORA-01555錯誤。下面是一些簡單介紹(上一遍已經介紹過) ORA-01555錯誤是一種在oracle數據庫中非常常見的錯誤,甚至也可以說是一個非常經典的錯誤,只是由於oracle的發展越來越自動化(UNDO自動管理+加強),這個錯誤已經越來越少見,可能很多使用10g的DBA都沒有遇到過這個錯誤。 這個錯誤在9i之前的版本(UNDO手工管理)出現的最多,也是最常見的,甚至可以說怎麼樣處理和避免ORA-01555 錯誤是令每一個DBA曾頭痛,但是又必須面對的問題。從9i的undo自動管理,至現在的10g、11g中的undo auto tuning,使得ORA-01555錯誤越來越少,但是這個錯誤仍然不可避免,特別是那些分析型的系統中(OLTP)。
錯誤原因(一般有兩種) SQL語句執行時,需要讀取UNDO(前映像數據)來構造CR數據塊,完成一致性讀取。但是在讀取undo前映像數據時發現,undo信息已經被覆蓋(undo空間循環使用),不能構造一致性讀的CR塊,拋出ORA-01555錯誤SQL語句執行時,訪問到的數據塊,需要進行延遲塊清除,但是在進行延遲塊清除時,不能確定這個數據塊的事務提交時間與SQL執行開始時間的先後次序,從而拋出ORA-01555錯誤 備注:延遲塊清除是指前一個事務完成提交時(commit),由於修改塊已經刷新至磁盤等原因,未完成塊事務信息的清除(ILT,LB信息等等),在後續的SQL語句訪問該塊時,需要清除這些信息,這個動作即延遲塊清除。
第二種情況的解決方法(僅供參考) 增加UNDO空間,延緩UNDO信息被覆蓋,也可以理解為增加undo空間循環使用一次的時間,盡量避免延遲塊清除時需要的undo信息被覆蓋。優化拋出錯誤的SQL語句,減少SQL語句需要訪問的數據塊,可能避免出現ORA-01555,但是這個方法治標不治本,任何後續訪問該塊的SQL,都會拋出ORA-01555錯誤。加載buffer cache,盡量使事務提交時,能夠完成fast commit(直接清理快上的事務信息),這個方法基本也是過於理想,很難在實際中發揮作用。縮減事務大小,也盡量使事務提交時,執行fast commit。由於需要改造業務邏輯,基本也不現實,很難在實際中發揮作用。我們知道這類錯誤一般出現在OLAP類型的業務系統中,針對這種情況,最有效的方法是收集可能出現延遲塊清除並拋出ORA-01555錯誤的表,在業務邏輯中,完成事務後,針對這些表立即進行一次全表掃描(清理塊上的事務信息),避免後續訪問清理時出現的ORA-01555錯誤。如果業務邏輯修改較困難,可以根據業務規則,指定一個定時針對這些表的全表掃面任務,來規避延遲塊清除導致的ORA-01555錯誤 備注:針對第一情況的解決方法和示例請見我上一篇文章《ORA-01555錯誤總結(一)》。
注意事項 全表查詢中使用select count(*),避免使用select *,因為select count(*)的效率和速度遠遠高於select *;必須使用提示(full hint),避免使用索引快速掃面的執行計劃來統計行數(select count(*))不能使用並行提示(parallel),因為在表上進行並行查詢是,以DIRECT READ方式讀取表時不會清理數據塊上的事務信息11GR2中新特性,當表大小超過一定閥值時,使用direct path read代替db file scatter read掃描,必須避免這種情況。如果表實在太大,全表掃描的時間過長,可以將表分段(根據dba_extends轉化為rowid),進行分段查詢。 全表掃描語法 select /*+ full(a) */ count(*) from scott.emp a; 表分段語法(trunks變量表示將表分為幾段,owner和table_name變量分別表示表對象的用戶名和表名)(摘自老熊博客) select dbms_rowid.rowid_create(1, oid1, fid1, bid1, 0) rowid1,
dbms_rowid.rowid_create(1, oid2, fid2, bid2, 9999) rowid2
from (select a.*, rownum rn
from (select chunk_no,
min(oid1) oid1,
max(oid2) oid2,
min(fid1) fid1,
max(fid2) fid2,
min(bid1) bid1,
max(bid2) bid2
from (select chunk_no,
FIRST_VALUE(data_object_id) OVER(PARTITION BY chunk_no ORDER BY data_object_id, relative_fno, block_id ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) oid1,
LAST_VALUE(data_object_id) OVER(PARTITION BY chunk_no ORDER BY data_object_id, relative_fno, block_id ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) oid2,
FIRST_VALUE(relative_fno) OVER(PARTITION BY chunk_no ORDER BY data_object_id, relative_fno, block_id ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) fid1,
LAST_VALUE(relative_fno) OVER(PARTITION BY chunk_no ORDER BY data_object_id, relative_fno, block_id ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) fid2,
FIRST_VALUE(block_id) OVER(PARTITION BY chunk_no ORDER BY data_object_id, relative_fno, block_id ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) bid1,
LAST_VALUE(block_id + blocks - 1) OVER(PARTITION BY chunk_no ORDER BY data_object_id, relative_fno, block_id ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) bid2
from (select data_object_id,
relative_fno,
block_id,
blocks,
ceil(sum2 / chunk_size) chunk_no
from (select /*+ rule */ b.data_object_id,
a.relative_fno,
a.block_id,
a.blocks,
sum(a.blocks) over(order by b.data_object_id, a.relative_fno, a.block_id) sum2,
ceil(sum(a.blocks)
over() / &trunks) chunk_size
from dba_extents a, dba_objects b
where a.owner = b.owner
and a.segment_name = b.object_name
and nvl(a.partition_name, '-1') =
nvl(b.subobject_name, '-1')
and b.data_object_id is not null
and a.owner = upper('&owner')
and a.segment_name = upper('&table_name'))))
group by chunk_no
order by chunk_no) a);

塊延遲清除導致ORA-01555錯誤示例 (1)新建一個非常小的undo表空間,並切換至改表空間,同時新建兩個表dhtest1、dhtest2。 SQL> create undo tablespace undo2 datafile '/u01/test/test/undo2.dbf' size 2m autoextend off;
Tablespace created.
SQL> alter system set undo_tablespace='UNDO2';
System altered.
SQL> create table dhtest1 as select object_id,object_name from dba_objects;
Table created.
SQL> create table dhtest2 as select owner,table_name from dba_tables;
Table created.
SQL> SELECT
2 dbms_rowid.rowid_object(rowid) object_id,
3 dbms_rowid.rowid_relative_fno(rowid) REL_FNO,
4 dbms_rowid.rowid_block_number(rowid) BLOCKNO,
5 dbms_rowid.rowid_row_number(rowid) ROWNO,rowid,OWNER,TABLE_NAME
6 FROM dhtest2 WHERE table_name='DHTEST1';

OBJECT_ID REL_FNO BLOCKNO ROWNO ROWID OWNER TABLE_NAME
---------- ---------- ---------- ---------- ------------------ ------------------------------------------------------------
73431 4 957 83 AAAR7XAAEAAAAO9ABT DH DHTEST1 (2)開始測試,session A 更新表dhtest2上rowid='AAAR7XAAEAAAAO9ABT'的數據行 update dhtest2 set table_name='yyyyyy' where rowid='AAAR7XAAEAAAAO9ABT';
1 row updated. (3)dump 被更新數據行的數據塊(datafile 4,block 957) SQL> oradebug setmypid;
Statement processed.
SQL> oradebug tracefile_name;
/u01/oracle/diag/rdbms/test/test/trace/test_ora_26266.trc
SQL> alter system flush buffer_cache; --刷新內存,後續提交不會情況數據塊中的事務信息
System altered.
SQL> alter system dump datafile 4 block 957;
System altered.
Block header dump: 0x010003bd
Object id on Block? Y
seg/obj: 0x11ed7 csc: 0x00.fbdc3 itc: 3 flg: E typ: 1 - DATA
brn: 1 bdba: 0x10003b0 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0xffff.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0000.000fbdc3
0x02 0x0016.013.00000002 0x018000b4.0000.1b ---- 1 fsc 0x0001.00000000 ---lck為1 表示這個事務鎖定了該數據塊中的1行數據
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
bdba: 0x010003bd
data_block_dump,data header at 0x2b2cf3514a7c
.....省略一部分.......
tab 0, row 83, @0x4d1
tl: 13 fb: --H-FL-- lb: 0x2 cc: 2 --lb為2,表示這一行被對應itl中的第二個事務槽中的事務更新。
col 0: [ 2] 44 48
col 1: [ 6] 79 79 79 79 79 79 --轉換數據可以發現為 yyyyy ,與我們更新的一致
....後面省略............ (4)查詢事務的一些基本信息,例如usn,xidslot,xidsqn等等 SQL> set linesize 200
SQL> col start_scnw format a20
SQL> col start_scnb format a20
SQL> select xidusn,xidslot,xidsqn,ubablk,ubafil,ubarec,to_char(start_scnw,'xxxxxxxx') start_scnw,
2 to_char(start_scnb,'xxxxxxxx') start_scnb, start_scnb+start_scnw*power(2,32) start_scn
3 from v$transaction;
XIDUSN XIDSLOT XIDSQN UBABLK UBAFIL UBAREC START_SCNW START_SCNB START_SCN
---------- ---------- ---------- ---------- ---------- ---------- -------------------- -------------------- ----------
22 19 2 180 6 27 0 fbdcc 1031628
SQL> select name from v$rollname where usn=22;
NAME
------------------------------
_SYSSMU22$
SQL> select dbms_utility.data_block_address_file(to_number(substr(uba,3,8),'xxxxxxxxxxx')) undo_file#,
2 dbms_utility.data_block_address_block(to_number(substr(uba,3,8),'xxxxxxxxxxx')) blockno#,
3 to_number(substr(uba,12,4),'xxxxxxxxx') undo_seq,
4 to_number(substr(uba,17,2),'xxxxxxxxx') undo_record
5 from (select '0x018000b4.0000.1b' uba from dual);
UNDO_FILE# BLOCKNO# UNDO_SEQ UNDO_RECORD
---------- ---------- ---------- -----------
6 180 0 27 (5)根據步驟(4)查詢的基本信息,dump事務的undo段頭和undo塊 SQL> alter system dump undo header '_SYSSMU22$';
System altered.
SQL> alter system dump datafile 6 block 180;
System altered.
undo header trace 文件:
TRN CTL:: seq: 0x0000 chd: 0x0014 ctl: 0x0012 inc: 0x00000000 nfb: 0x0002
mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x018000b4.0000.1b scn: 0x0000.00000000 --uba對應事務表中最早使用的undo塊
Version: 0x01
FREE BLOCK POOL::
uba: 0x00000000.0000.1a ext: 0x0 spc: 0x1292
uba: 0x018000b3.0000.08 ext: 0x0 spc: 0x1c52
uba: 0x018000b2.0000.24 ext: 0x0 spc: 0x124e
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
------------------------------------------------------------------------------------------------
...........省略一部分...............
0x0f 9 0x00 0x0002 0x0010 0x0000.000fbe30 0x018000b4 0x0000.000.00000000 0x00000001 0x00000000 1399884492
0x10 9 0x00 0x0002 0x0011 0x0000.000fbe3f 0x018000b4 0x0000.000.00000000 0x00000001 0x00000000 1399884492
0x11 9 0x00 0x0002 0x0012 0x0000.000fbe45 0x018000b4 0x0000.000.00000000 0x00000001 0x00000000 1399884492
0x12 9 0x00 0x0002 0xffff 0x0000.000fbe5e 0x018000b4 0x0000.000.00000000 0x00000001 0x00000000 1399884492
0x13 10 0x80 0x0002 0x0000 0x0000.000fbdcc 0x018000b4 0x0000.000.00000000 0x00000001 0x00000000 0
0x14 9 0x00 0x0001 0x0015 0x0000.00000000 0x00000000 0x0000.000.00000000 0x00000000 0x00000000 0
state為10表示該事物為活動狀態
............後面省略.....................
undo block trace 文件:
UNDO BLK:
xid: 0x0016.013.00000002 seq: 0x0 cnt: 0x1b irb: 0x1b icl: 0x0 flg: 0x0000

Rec Offset Rec Offset Rec Offset Rec Offset Rec Offset
---------------------------------------------------------------------------
0x01 0x1f60 0x02 0x1efc 0x03 0x1eac 0x04 0x1e5c 0x05 0x1e28
0x06 0x1de0 0x07 0x1d80 0x08 0x1cc0 0x09 0x1c70 0x0a 0x1bec
0x0b 0x1b68 0x0c 0x1ae0 0x0d 0x1a80 0x0e 0x19f8 0x0f 0x1998
0x10 0x18ec 0x11 0x1840 0x12 0x1790 0x13 0x1724 0x14 0x16b8
0x15 0x1604 0x16 0x1554 0x17 0x14a4 0x18 0x13f4 0x19 0x1344
0x1a 0x12d8 0x1b 0x124c
.................省略一部分undo record................
*-----------------------------
* Rec #0x1b slt: 0x13 objn: 73431(0x00011ed7) objd: 73431 tblspc: 4(0x00000004) --------0xbl undo record中保存的前映像數據與我們知道的一致,為DHTEST1
* 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: 0x018000b4.0000.19 ctl max scn: 0x0000.00000000 prv tx scn: 0x0000.00000000
txn start scn: scn: 0x0000.000fbd45 logon user: 85
prev brb: 0 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: XA flags: 0x00000000 bdba: 0x010003bd hdba: 0x010003b2
itli: 2 ispac: 0 maxfr: 4858
tabn: 0 slot: 83(0x53) flag: 0x2c lock: 0 ckix: 1
ncol: 2 nnew: 1 size: 1
col 1: [ 7] 44 48 54 45 53 54 31
SQL> SELECT utl_raw.cast_to_varchar2(replace('44 48 54 45 53 54 31',' ')) value FROM dual;
VALUE
-------------------------------------------
DHTEST1 (6)提交事務,由於內存已經刷新,因此數據塊上的事務不應該被清除,dump數據塊查看,與我們期望的一致(事務未被清除) SQL> commit;
Commit complete.
DUMP block trace 文件:
Block header dump: 0x010003bd
Object id on Block? Y
seg/obj: 0x11ed7 csc: 0x00.fbdc3 itc: 3 flg: E typ: 1 - DATA
brn: 1 bdba: 0x10003b0 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0xffff.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0000.000fbdc3
0x02 0x0016.013.00000002 0x018000b4.0000.1b ---- 1 fsc 0x0001.00000000 --事務信息確實沒有被清除!
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
bdba: 0x010003bd
DUMP undo header 文件:
TRN CTL:: seq: 0x0000 chd: 0x0014 ctl: 0x0013 inc: 0x00000000 nfb: 0x0003
mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x018000b4.0000.1b scn: 0x0000.00000000
Version: 0x01
FREE BLOCK POOL::
uba: 0x018000b4.0000.1b ext: 0x0 spc: 0x1204
uba: 0x018000b3.0000.08 ext: 0x0 spc: 0x1c52
uba: 0x018000b2.0000.24 ext: 0x0 spc: 0x124e
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
------------------------------------------------------------------------------------------------
...........省略一部分...............
0x11 9 0x00 0x0002 0x0012 0x0000.000fbe45 0x018000b4 0x0000.000.00000000 0x00000001 0x00000000 1399884492
0x12 9 0x00 0x0002 0x0013 0x0000.000fbe5e 0x018000b4 0x0000.000.00000000 0x00000001 0x00000000 1399884492
0x13 9 0x00 0x0002 0xffff 0x0000.000fc00b 0x018000b4 0x0000.000.00000000 0x00000001 0x00000000 1399885369
0x14 9 0x00 0x0001 0x0015 0x0000.00000000 0x00000000 0x0000.000.00000000 0x00000000 0x00000000 0
0x15 9 0x00 0x0001 0x0016 0x0000.00000000 0x00000000 0x0000.000.00000000 0x00000000 0x00000000 0
0x16 9 0x00 0x0001 0x0017 0x0000.00000000 0x00000000 0x0000.000.00000000 0x00000000 0x00000000 0
0x17 9 0x00 0x0001 0x0018 0x0000.00000000 0x00000000 0x0000.000.00000000 0x00000000 0x00000000 0
............後面省略..................... undo事務表上的state已經從10變為9,表示事務已經提交 (7)在session B中發起游標查詢,查詢rowid='AAAR7XAAEAAAAO9ABT'的這一行 varible v_cur1 refcursor begin open :v_cur1 for select * from dhtest2 where rowid='AAAR7XAAEAAAAO9ABT'; end; / PL/SQL procedure successfully completed. (8)在session C中發起大量事務,將回滾段信息覆蓋,並且確保事務表也已經被覆蓋多次! SQL> update dhtest1 set object_name='DDDDDDDDDDDD' where rownum<99;
98 rows updated.
SQL> /
98 rows updated.
SQL> /
98 rows updated.
SQL> /
98 rows updated.
SQL> /
98 rows updated.
SQL> /
98 rows updated.
SQL> commit;
Commit complete.
SQL> update dhtest1 set object_name='DDDDDDDDDDDD' where rownum<99;
98 rows updated.
SQL> /
98 rows updated.
SQL> /
98 rows updated.
SQL> /
98 rows updated.
SQL> /
98 rows updated.
SQL> /
98 rows updated.
SQL> /
98 rows updated.
SQL> /
98 rows updated.
SQL> /
98 rows updated.
SQL> /
98 rows updated.
SQL> /
98 rows updated.
SQL> /
update dhtest1 set object_name='DDDDDDDDDDDD' where rownum<99
*
ERROR at line 1:
ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDO2'
SQL> commit
2 ;
Commit complete.
SQL>
SQL> begin
2 for i in 1..100000 loop
3 update dhtest1 set object_name='DDDDDDDDDDDD' where rownum<99;
4 commit;
5 end loop;
6 end;
7 /
PL/SQL procedure successfully completed. (9)dump 原先的回滾段頭和undo塊,發現信息已經被覆蓋 SQL> alter system dump undo header '_SYSSMU22$';
System altered.
SQL> alter system dump datafile 6 block 180;
System altered. undo header trace 文件:
TRN CTL:: seq: 0x07a9 chd: 0x0020 ctl: 0x001f inc: 0x00000000 nfb: 0x0001 --seq表示該回滾段上的事務表被重用了1961次。因此事務表已經被覆蓋多次
mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x018000bc.07a9.23 scn: 0x0000.00150d58 ------這個SCN是事務表中最近被重用的事務表記錄之前的事務的提交SCN,可以理解為已經被覆蓋的事務記錄中擁有最大的SCN值(事務表記錄重用是按照提交SCN從小到大的順序重用的)
Version: 0x01
FREE BLOCK POOL::
uba: 0x018000be.07a9.04 ext: 0x1 spc: 0xf12
uba: 0x00000000.07a3.05 ext: 0x1 spc: 0xa84
uba: 0x00000000.0000.24 ext: 0x0 spc: 0x124e
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 9 0x00 0x014b 0x0002 0x0000.00150e05 0x018000bf 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x01 9 0x00 0x014b 0x000b 0x0000.00150ecf 0x018000be 0x0000.000.00000000 0x00000002 0x00000000 1399886134
0x02 9 0x00 0x014b 0x0003 0x0000.00150e19 0x018000b1 0x0000.000.00000000 0x00000002 0x00000000 1399886134
0x03 9 0x00 0x014b 0x0005 0x0000.00150e2c 0x018000b3 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x04 9 0x00 0x014b 0x0006 0x0000.00150e54 0x018000b6 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x05 9 0x00 0x014b 0x0004 0x0000.00150e3e 0x018000b4 0x0000.000.00000000 0x00000002 0x00000000 1399886134
0x06 9 0x00 0x014b 0x0007 0x0000.00150e69 0x018000b7 0x0000.000.00000000 0x00000002 0x00000000 1399886134
0x07 9 0x00 0x014b 0x0008 0x0000.00150e81 0x018000b9 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x08 9 0x00 0x014b 0x0009 0x0000.00150e94 0x018000bb 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x09 9 0x00 0x014b 0x000a 0x0000.00150eb8 0x018000bb 0x0000.000.00000000 0x00000001 0x00000000 1399886134
0x0a 9 0x00 0x014b 0x0001 0x0000.00150ec4 0x018000bd 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x0b 9 0x00 0x014b 0x000c 0x0000.00150ee2 0x018000b1 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x0c 9 0x00 0x014b 0x000d 0x0000.00150eea 0x018000b3 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x0d 9 0x00 0x014b 0x000e 0x0000.00150ef1 0x018000b3 0x0000.000.00000000 0x00000001 0x00000000 1399886134
0x0e 9 0x00 0x014b 0x000f 0x0000.00150ef8 0x018000b4 0x0000.000.00000000 0x00000002 0x00000000 1399886134
0x0f 9 0x00 0x014b 0x0010 0x0000.00150f09 0x018000b6 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x10 9 0x00 0x014b 0x0011 0x0000.00150f32 0x018000b7 0x0000.000.00000000 0x00000002 0x00000000 1399886134
0x11 9 0x00 0x014b 0x0012 0x0000.00150f45 0x018000b9 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x12 9 0x00 0x014b 0x0013 0x0000.00150f64 0x018000ba 0x0000.000.00000000 0x00000002 0x00000000 1399886134
0x13 9 0x00 0x014b 0x0014 0x0000.00150f78 0x018000bc 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x14 9 0x00 0x014b 0x0015 0x0000.00150f90 0x018000bd 0x0000.000.00000000 0x00000002 0x00000000 1399886134
0x15 9 0x00 0x014b 0x0016 0x0000.00151002 0x018000bf 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x16 9 0x00 0x014b 0x0017 0x0000.0015108e 0x018000b2 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x17 9 0x00 0x014b 0x0018 0x0000.00151095 0x018000b2 0x0000.000.00000000 0x00000001 0x00000000 1399886134
0x18 9 0x00 0x014b 0x0019 0x0000.001510a1 0x018000b4 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x19 9 0x00 0x014b 0x001a 0x0000.001510b9 0x018000b5 0x0000.000.00000000 0x00000002 0x00000000 1399886134
0x1a 9 0x00 0x014b 0x001b 0x0000.001510e7 0x018000b7 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x1b 9 0x00 0x014b 0x001c 0x0000.00151135 0x018000b9 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x1c 9 0x00 0x014b 0x001d 0x0000.0015113c 0x018000b9 0x0000.000.00000000 0x00000001 0x00000000 1399886134
0x1d 9 0x00 0x014b 0x001e 0x0000.00151146 0x018000bb 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x1e 9 0x00 0x014b 0x001f 0x0000.00151156 0x018000bc 0x0000.000.00000000 0x00000002 0x00000000 1399886134
0x1f 9 0x00 0x014b 0xffff 0x0000.00151165 0x018000be 0x0000.000.00000000 0x00000003 0x00000000 1399886134
0x20 9 0x00 0x014a 0x0021 0x0000.00150d73 0x018000bb 0x0000.000.00000000 0x00000001 0x00000000 1399886134
0x21 9 0x00 0x014a 0x0000 0x0000.00150d8b 0x018000bd 0x0000.000.00000000 0x00000003 0x00000000 1399886134
undo block trace文件:
UNDO BLK:
xid: 0x0016.01f.00000141 seq: 0x76c cnt: 0x2 irb: 0x2 icl: 0x0 flg: 0x0000
Rec Offset Rec Offset Rec Offset Rec Offset Rec Offset
---------------------------------------------------------------------------
0x01 0x1ba0 0x02 0x17bc
*-----------------------------
* Rec #0x1 slt: 0x1f objn: 73429(0x00011ed5) objd: 73429 tblspc: 4(0x00000004)
* Layer: 11 (Row) opc: 1 rci 0x00
Undo type: Regular undo Last buffer split: No
Temp Object: No
Tablespace Undo: No
rdba: 0x018000b3
*-----------------------------
KDO undo record:
KTB Redo
op: 0x02 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: C uba: 0x018000b3.076c.07
Array Update of 20 rows:
tabn: 0 slot: 60(0x3c) flag: 0x2c lock: 0 ckix: 157
ncol: 2 nnew: 1 size: 0
KDO Op code: 21 row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x010002ab hdba: 0x010002aa
itli: 2 ispac: 0 maxfr: 4858
vect = 3
col 1: [12] 44 44 44 44 44 44 44 44 44 44 44 44
tabn: 0 slot: 61(0x3d) flag: 0x2c lock: 0 ckix: 157
ncol: 2 nnew: 1 size: 0
KDO Op code: 21 row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x010002ab hdba: 0x010002aa
itli: 2 ispac: 0 maxfr: 4858
vect = 3
.................省略這一undo record中的一部分
col 1: [12] 44 44 44 44 44 44 44 44 44 44 44 44
tabn: 0 slot: 79(0x4f) flag: 0x2c lock: 0 ckix: 157
ncol: 2 nnew: 1 size: 0
KDO Op code: 21 row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x010002ab hdba: 0x010002aa
itli: 2 ispac: 0 maxfr: 4858
vect = 3
col 1: [12] 44 44 44 44 44 44 44 44 44 44 44 44
*-----------------------------
* Rec #0x2 slt: 0x1f objn: 73429(0x00011ed5) objd: 73429 tblspc: 4(0x00000004)
* Layer: 11 (Row) opc: 1 rci 0x01
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: 0x018000b4.076c.01
Array Update of 18 rows:
tabn: 0 slot: 80(0x50) flag: 0x2c lock: 0 ckix: 157
ncol: 2 nnew: 1 size: 0
KDO Op code: 21 row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x010002ab hdba: 0x010002aa
itli: 2 ispac: 0 maxfr: 4858
vect = 3
.....................省略這一undo record中的一部分
col 1: [12] 44 44 44 44 44 44 44 44 44 44 44 44
tabn: 0 slot: 97(0x61) flag: 0x2c lock: 0 ckix: 157
ncol: 2 nnew: 1 size: 0
KDO Op code: 21 row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x010002ab hdba: 0x010002aa
itli: 2 ispac: 0 maxfr: 4858
vect = 3
col 1: [12] 44 44 44 44 44 44 44 44 44 44 44 44

End dump data blocks tsn: 7 file#: 6 minblk 180 maxblk 180
可以看到,這個undo block中只有兩個undo record。無法再找到延遲事務對應的undo record 即1b。 (10)根據步驟(9)中undo header trace中的uba信息嘗試進行回滾 dump uba :uba: 0x018000bc.07a9.23 alter system dump datafile 6 block 188; UNDO BLK:
xid: 0x0016.01f.0000014b seq: 0x7a9 cnt: 0x2b irb: 0x2b icl: 0x0 flg: 0x0000
Rec Offset Rec Offset Rec Offset Rec Offset Rec Offset
---------------------------------------------------------------------------
0x01 0x1fa4 0x02 0x1f60 0x03 0x1f1c 0x04 0x1ed8 0x05 0x1e94
0x06 0x1e50 0x07 0x1e0c 0x08 0x1dc8 0x09 0x1d84 0x0a 0x1d40
0x0b 0x1cfc 0x0c 0x1cb8 0x0d 0x1c74 0x0e 0x1c30 0x0f 0x1bec
0x10 0x1ba8 0x11 0x1b64 0x12 0x1b20 0x13 0x1adc 0x14 0x1a98
0x15 0x1a54 0x16 0x1a10 0x17 0x19cc 0x18 0x1988 0x19 0x1944
0x1a 0x1900 0x1b 0x18bc 0x1c 0x1878 0x1d 0x1834 0x1e 0x13ec
0x1f 0x0fa4 0x20 0x0b5c 0x21 0x0714 0x22 0x0330 0x23 0x02a8
0x24 0x0264 0x25 0x0220 0x26 0x01dc 0x27 0x0198 0x28 0x0154
0x29 0x0110 0x2a 0x00cc 0x2b 0x0088
*-----------------------------
* Rec #0x1 slt: 0x1e objn: 73429(0x00011ed5) objd: 73429 tblspc: 4(0x00000004)
* Layer: 11 (Row) opc: 1 rci 0x00
Undo type: Regular undo Last buffer split: No
Temp Object: No
Tablespace Undo: No
rdba: 0x018000bb
* Rec #0x23 slt: 0x1f objn: 73429(0x00011ed5) objd: 73429 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: 0x018000bb.07a9.04 ctl max scn: 0x0000.00150d48 prv tx scn: 0x0000.00150d58
txn start scn: scn: 0x0000.00151164 logon user: 85
prev brb: 25166010 prev bcl: 0
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: L itl: xid: 0x0019.01f.0000014b uba: 0x018000eb.07ab.04 ---又可以根據這個uba嘗試回滾,一步一步查看。可以發現無法回滾到我們游標查詢的SCN,因此可以預見游標查詢會由於延遲塊清除而拋出ORA-01555錯誤
flg: C--- lkc: 0 scn: 0x0000.00151159
KDO Op code: LKR row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x010002ab hdba: 0x010002aa
itli: 3 ispac: 0 maxfr: 4858
tabn: 0 slot: 0 to: 0 (11)SESSION B發起游標查詢,與我們預期一致,拋出ORA-01555錯誤! SQL> print :cur1
ERROR:
ORA-01555: snapshot too old: rollback segment number 22 with name "_SYSSMU22$"
too small
備注:此處游標查詢時可以設置邏輯讀跟蹤,或者10046+set db_file_multiblock_read_count=1來跟蹤延遲塊清除時具體訪問的undo塊,但是由於實驗時出現了些許問題,沒有及時跟蹤下來。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved