在一个OLTP系统中，可能从来不会看到这种情况发生，因为OLTP系统的特点是事务都很短小，只会影响为数不多的一些块。
如果你有如下的处理，就会受到块清除的影响：
· 将大量新数据批量加载到数据仓库中；
· 在刚刚加载的所有数据上运行UPDATE（产生需要清理的块）；
· 让别人查询这些数据
比较好的做法是：在批量加载了数据后，通过运行DBMS_STATS实用程序来收集统计信息，就能自然的完成块清除工作。
下面我们来说一下“延时块清除”以及Oracle-01555错误
首先要说明一点，oracle-01555错误是一个安全的错误，它不会造成数据丢失或者损坏，只是会让收到该错误的查询无法继续。
oracle-01555错误的原因：
1）undo太小
如果在一个查询（时间较长的查询）开始后，对表进行了dml操作，因为oracle的一致性读，那么查询就需要用到相应的回滚数据。但是因为查询的时间较长，在我们需要用那些回滚段来构造cr块时发现回滚段已经被其他数据覆盖了。这样就会报oracle-01555错误！
比较直观的解决方法是DBA告诉数据库应用最长的查询需要多长时间，并把UNDO_RETENTION设为这个值，同时相应增大undo表空间大小。
在此我给大家稍微介绍一下orale中UNDO_RETENTION这个参数。oracle回滚段中区有四种状态 active；inactive；expired；free
active表示事物还在活动；inactive表示事物已提交（区可用但是尽量避免使用）；expired表示undo区可以被覆盖；free表示空闲的区
这里我们主要关注一下inactive和expired两个状态的区别，inactive表示事物已经提交，理论上此时区已经可以被重新使用，但是因为oracle的一致性读，所以我们可能还需要把inactive区中的数据再保留一段时间，保留多长时间由UNDO_RETENTION参数决定。在保留了UNDO_RETENTION时间后，区的状态就改成expired。 （--注意如果一个事物需要用回滚段，而回滚表空间中此时已经没有free，和expired状态的区，那么就算inactive区没有被保留够UNDO_RETENTION时间，也是可以被使用的）
2）延时块清除
这种情况比较少见，特别是在OLTP系统里，在OLAP系统里可能会碰到，解决方法是在每次大量的insert或update之后，记得用DBMS_STATS包扫描相关对象。
前面我已经说了为什么会有延时块清除，主要是为了提高事物的效率！
延迟清除的块的下一个读者,首先根据块中的记录的回滚信息去查找回滚段中记录的commit时的SCN，
但回滚段可能已回绕,找不到提交时的scn了，
但是，从回滚段中可以得到一个最小的提交scn并且该事务已经提交肯定小于这个从回滚段中还存在的最小scn。
那么oracle给这个块清除的事务分配一个从回滚段中找到的最小事务scn。
这虽然不准确，但是是安全的，对于数据访问也不构成影响。所以叫 upper bound ,猜测的一个scn的上限。
延迟清除的块在被select 时,如果读的select 的scn 比这个回滚段里面最小的scn 还要小的话(回滚段已回绕),那么在回滚段里面找不到数
据了,oracle 就没有办法判断select 的SCN 与被要清除的数据块的大小关系,于是ora-01555就出现了,这个时候oracle 就不知道数据块里面
的数据是不是是查询时刻需要的数据.
如果select scn 大于回滚段里面最小的scn 的话,那么oracle 就使用这个最小的scn 来做为这个事务的 scn 来更新块的itl ,从而完成块的清除.
更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
