【故障处理】ORA-01555

一、为什么会出现ORA-01555

    ORA-01555便是著名的snapshot too old（快照太旧）问题。这个错误是由数据库的读一致性(Read consistency）引起的，当查询需要访问被修改的数据时，它会到undo里访问该数据的前镜像，如果该前镜像已被覆盖，查询语句就会返回ORA-01555的错误。

二、引起ORA-01555错误的具体原因

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

    2、SQL语句执行过程中，访问到的块，在进行延迟块清除时，不能确定该块的事务提交时间与SQL执行开始时间的先后次序。（当一个查询触发延迟块清除时，Oracle需要去查询回滚段获得该事务的提交SCN，如果事务的前镜像信息已经被覆盖，并且查询SCN也小于回滚段中记录的最小提交SCN，那么Oracle将无从判断查询SCN和事务提交SCN的大小，此时出现延迟块清除导致的ORA-01555错误）。

三、解决办法

    1、对于第一种原因，解决的办法无非就是增加UNDO表空间大小，优化查询SQL以缩短查询时间，避免频繁地提交，使用undo_rententiion和undo表空间GUARANTEE功能避免。

    2、对于第二种原因，大批量的UPDATE 或INSERT 会导致块清除（block cleanout），所以在大批量UPDATE 或大量加载之后使用DBMS_STATS收集相关对象的统计信息，加载之后完成对这些对象的清理。

四、实例

    1、在1点钟，用户A发出了select * from testdb;此时不管将来testdb怎么变化，正确的结果应该是用户A会看到在1点钟这个时刻的内容。

    2、在1点30分，用户B执行了update命令，更新了testdb表中的第4100万行的这条记录，这时，用户A的全表扫描还没有到达第4100万条。毫无疑问，这个时候，第4100万行的这条记录是被写入了回滚段，假设是回滚段UNDOTS1，如果用户A的全表扫描到达了第4100万行，是应该会正确的从回滚段UNDOTS1中读取出1点钟时刻的内容的。

    3、这时，用户B将他刚才做的操作提交了，但是这时，系统仍然可以给用户A提供正确的数据，因为那第4100万行记录的内容仍然还在回滚段UNDOTS1里，系统可以根据SCN到回滚段里找到正确的数据，但要注意到，这时记录在UNDOTS1里的第4100万行记录已经发生了重大的改变：就是第4100万行在回滚段UNDOTS1里的数据有可能随时被覆盖掉，因为这条记录已经被提交了！

    4、由于用户A的查询时间漫长，而业务在一直不断的进行，UNDOTS1回滚段在被多个不同的transaction使用着，这个回滚段里的extent循环到了第4100万行数据所在的extent，由于这条记录已经被标记提交了，所以这个extent是可以被其他transaction覆盖掉的！

    5、到了1点45分，用户A的查询终于到了第4100万行，而这时已经出现了第4条说的情况，需要到回滚段UNDOTS1去找数据，但是已经被覆盖掉了，这时就出现了ORA-01555错误。

五、参考文章

http://www.laoxiong.net/ora-1555-case.html

http://blog.itpub.net/30776559/viewspace-2138298/

http://f.dataguru.cn/thread-172668-1-1.html

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30776559/viewspace-2138344/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30776559/viewspace-2138344/