ORA-01555 快照过旧，是数据库中很常见的一个错误，比如当我们的事务需要使用undo来构建CR块的时候，

而此时对应的undo 已经不存在了， 这个时候就会报ORA-01555的错误。

环境是Oracle 11g RAC 由于客户执行一个比较复杂的sql，使用PLsql运行了88分钟后出现报错,这是一个要查看报表的sql。

临时的处理方法如下:

以下为虚拟机模拟操作，建议数据库安装的时候这个参数一定要提前调整优化一下，不要使用默认值。

[root@ysdb1~]#su-oracle
[oracle@ysdb1~]$sqlplus/assysdba
sql*Plus:Release11.2.0.4.0ProductiononFriDec2310:39:442016
Copyright(c)1982,2013,Oracle.Allrightsreserved.
Connectedto:
OracleDatabase11gEnterpriseEditionRelease11.2.0.4.0-64bitProduction
WiththePartitioning,RealApplicationClusters,AutomaticStorageManagement,OLAP,DataMiningandRealApplicationTestingoptions
SYS@ysdb1>showparameterundo;
NAMETYPEVALUE
-----------------------------------------------------------------------------
undo_managementstringAUTO
undo_retentioninteger900--默认15分钟
undo_tablespacestringUNDOTBS1
SYS@ysdb1>
SYS@ysdb1>altersystemsetundo_retention=10800scope=both;
Systemaltered.

--查看表空间容量

SYS@ysdb1>coltablespace_namefora15
SYS@ysdb1>colfree_ratefora15
SYS@ysdb1>SELECTa.tablespace_name,ROUND(a.total_size)"total_size(MB)",ROUND(a.total_size)-ROUND(b.free_size,3)"used_size(MB)",ROUND(b.free_size,3)"free_size(MB)",ROUND(b.free_size/total_size*100,2)||'%'free_rate
FROM(SELECTtablespace_name,SUM(bytes)/1024/1024total_size
FROMdba_data_files
GROUPBYtablespace_name)a,(SELECTtablespace_name,SUM(bytes)/1024/1024free_size
FROMdba_free_space
GROUPBYtablespace_name)b
WHEREa.tablespace_name=b.tablespace_name(+);
TABLESPACE_NAMEtotal_size(MB)used_size(MB)free_size(MB)FREE_RATE
----------------------------------------------------------------------
SYSAUX600178.625421.37570.23%
UNDOTBS120056.062143.93871.97%
USERS51480%
SYSTEM700287.5412.558.93%
UNDOTBS22006.687193.31396.66%

SYS@ysdb1>SELECTtablespace_name,status,SUM(bytes)/1024/1024"Bytes(M)"
FROMdba_undo_extents
GROUPBYtablespace_name,status;
TABLESPACE_NAMESTATUSBytes(M)
TABLESPACE_NAMESTATUSBytes(M)
----------------------------------
UNDOTBS1UNEXPIRED11
UNDOTBS2UNEXPIRED2.125
UNDOTBS1EXPIRED44.0625
UNDOTBS2EXPIRED3.5625

1.出现ORA-01555错误，通常有2种情况：

1)sql语句执行时间太长，或者UNDO表空间过小，或者事务量过大，或者过于频繁的提交，导致执行sql过程中进行一致性读时，sql执行后修改的前镜像（即UNDO数据）在UNDO表空间中已经被覆盖，不能构造一致性读块（CR blocks）。 这种情况最多。

2)sql语句执行过程中，访问到的块，在进行延迟块清除时，不能确定该块的事务提交时间与sql执行开始时间的先后次序。 这种情况很少。

2.第1种情况解决的办法：

1)增加UNDO表空间大小

2)增加undo_retention 时间，默认只有15分钟

3)优化出错的sql，减少查询的时间，首选方法

4)避免频繁的提交