Oracle加索引的时候快照过久,Oracle ORA-01555 快照过旧 说明

ORA-01555 快照过旧，是数据库中很常见的一个错误，比如当我们的事务需要使用undo来构建CR块的时候，而此时对应的undo 已经不存在了， 这个时候就会报ORA-01555的错误。 cuug本周五晚8点免费网络公开课《Oracle数据库升级第三季：将升级进行到底--Oracle 10g升级到11g》火热报名ORA-01555错误在Oracle 8i及之前的版本最多。从9i开始的undo自动管理，至现在的10g、11g中的undo auto tuning，使得ORA-01555的错误越来越少。但是这个错误，仍然不可避免。

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)避免频繁的提交 3. 第二种情况描述 在块清除过程中，如果一个块已被修改，下一个会话访问这个块时，可能必须查看最后一个修改这个块的事务是否还是活动的。一旦确定该事务不再活动，就会完成块清除，这样另一个会话访问这个块时就不必再历经同样的过程。要完成块清除，Oracle 会从块首部确定前一个事务所用的undo 段(ITL)，然后确定从undo 首部能不能看出这个块是否已经提交。 可以用以下两种方式完成这种确认：一种方式是Oracle 可以确定这个事务很久以前就已经提交，它在undo 段事务表中的事务槽已经被覆盖。另一种情况是COMMIT SCN 还在undo 段的事务表中，这说明事务只是稍早前刚提交，其事务槽尚未被覆盖。 当满足以下条件时，就会从defered clean 收到ORA-01555的错误：首先做了一个修改并COMMIT，块没有自动清理(即没有自动完成“提交清除”，例如修改了太多的块，在SGA 块缓冲区缓存的10%中放不下)。其他会话没有接触这些块，而且在我们这个“倒霉”的查询(稍后显示)命中这些块之前，任何会话都不会接触它们。开始一个长时间运行的查询。这个查询最后会读其中的一些块。这个查询从SCN t1 开始，这就是读一致SCN，必须将数据回滚到这一点来得到读一致性。 开始查询时，上述修改事务的事务条目还在undo 段的事务表中。查询期间，系统中执行了多个提交。执行事务没有接触执行已修改的块(如果确实接触到，也就不存在问题了)。 由于出现了大量的COMMIT，undo 段中的事务表要回绕并重用事务槽(ITL)。最重要的是，将循环地重用原来修改事务的事务条目。另外，系统重用了undo 段的区段，以避免对undo 段首部块本身的一致读。此外，由于提交太多，undo 段中记录的最低SCN 现在超过了t1(高于查询的读一致SCN)。如果查询到达某个块，而这个块在查询开始之前已经修改并提交，就会遇到麻烦。正常情况下，会回到块所指的undo 段，找到修改了这个块的事务的状态(换句话说，它会找到事务的COMMIT SCN)。如果这个COMMIT SCN 小于t1，查询就可以使用这个块。如果该事务的COMMIT SCN 大于t1，查询就必须回滚这个块。不过，问题是，在这种特殊的情况下，查询无法确定块的COMMIT SCN 是大于还是小于t1。相应地，不清楚查询能否使用这个块映像。这就导致了ORA-01555 错误。 大批量的UPDATE 或INSERT 会导致块清除(block cleanout)，所以在大批量UPDATE 或大量加载之后使用DBMS_STATS收集相关对象的统计信息，加载之后完成这些对象的清理。 关于块清除这块，在 一书中有更详细的说明。