这篇文章紧接着上一篇“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块，但是由于实验时出现了些许问题，没有及时跟踪下来。