ORA-01555: snapshot too old错误

注意 ORA-01555 与数据破坏或数据丢失毫无关系。在这方面，这是一个“安全”的错误；惟一的影响是：接收到这个错误的查询无法继续处理。

 

这个错误实际上很直接，其实只有两个原因，但是其中之一有一个特例，而且这种特例情况发生得如此频繁，所以我要说存在3 个原因： 

l         undo段太小，不足以在系统上执行工作。 

l         你的程序跨COMMIT 获取（实际上这是前一点的一个变体）。我们在上一章讨论了这种情况。

l         块清除。

 

在充分说明这三种情况之前，我想先与你分享ORA-01555错误的几种解决方案，一般来说可以采用下面的方法： 

l         适当地设置参数 UNDO_RETENTION（要大于执行运行时间最长的事务所需的时间）。可以用V$UNDOSTAT来确定长时间运行的查询的持续时间。另外，要确保磁盘上已经预留了足够的空间，使undo 段能根据所请求的UNDO_RETENTION增大。 

l         使用手动 undo 管理时加大或增加更多的回滚段。这样在长时间运行的查询执行期间，覆盖undo数据的可能性就能降低。这种方法可以解决上述的所有3个问题。 

l         减少查询的运行时间（调优）。如果可能的话，这绝对是一个好办法，所以应该首先尝试这种方法。这样就能降低对 undo 段的需求，不需求太大的 undo 段。这种方法可以解决上述的所有3个问题。 

l         收集相关对象的统计信息。这有助于避免前面所列的第三点。 由于大批量的UPDATE或INSERT会导致块清除（block cleanout） ，所以需要在大批量UPDATE或大量加载之后以某种方式收集统计信息。

 

对于Oracle9i 和以上版本，管理系统中的undo有两种方法： 

l         自动undo管理 （Automatic undo management）：采用这种方法， 通过UNDO_RETENTION参数告诉 Oracle 要把 undo 保留多长时间。Oracle 会根据并发工作负载来确定要创建多少个undo段，以及每个undo段应该多大。数据库甚至在运行时可以在各个undo段之间重新分配区段，以满足DBA 设置的UNDO_RETENTION目标。这是undo管理的推荐方法。

l         手动undo管理（Manual undo management） ：采用这种方法的话，要由DBA 来完成工作。DBA 要根据估计或观察到的工作负载， 确定要手动地创建多少个undo 段。 DBA 根据事务量 （生成多少undo）和长时间运行查询的长度来确定这些undo段应该多大。

 

在手动 undo 管理的情况下，DBA 要确定有多少个 undo 段，以及各个 undo 段有多大，这就产生了一个容易混淆的问题。有人说： “那好，我们已经配置了 XMB 的 undo，但是它们可以增长。我们把MAXEXTENTS 设置为 500，而且每个区段是 1MB，所以 undo 可以相当大。”问题是，倘若手动地管理undo段，undo段从来不会因为查询而扩大；只有INSERT、UPDATE 和DELETE才会让undo段增长。事实上，如果执行一个长时间运行的查询，Oracle不会因此扩大手动回滚段（即手动管理的回滚段）来保留数据，以备以后可能需要用到这些数据。只有当执行一个长时间运行的UPDATE 事务时才会扩大手动回滚段。在前面的例子中，即使手动回滚段有增长的潜力，但它们并不会真正增长。对于这样一个系统，你需要有更大的手动回滚段（尽管它们已经很大了）。你要永久地为回滚段分配空间，而不是只给它们自行增长的机会。对于这个问题，惟一的解决方案只能是适当地设置手动回滚段的大小。

 

在自动undo 管理的情况下，从ORA-01555角度看，问题则要容易得多。无需自行确定undo空间有多大并完成预分配，DBA 只有告诉数据库运行时间至少在这段时间内保留 undo。如果已经分配了足够的空间可以扩展，Oracle 就会扩展 undo 段，而不是回绕，从而满足 UNDO_RETENTION 保持时间的要求。这与手动管理的 undo 截然相反，手动管理是会回绕，并尽可能块地重用 undo 空间。这是由于这个原因（即自动undo管理支持UNDO_RETENTION参数） ，所以我强烈建议尽可能采用自动undo 管理。

使用手动undo管理时，还要记住重要的一点，遇到ORA-01555错误的可能性是由系统中最小的回滚段指示的（而非最大的回滚段，也并非平均大小的回滚段）。增加一个“大”回滚段不能解决这个问题。处理查询时只会让最小的回滚段回绕，这个查询就有可能遇到 ORA-01555 错误。使用遗留的回滚段时我主张回滚段大小要相等，以上就是原因所在。如果回滚段的大小都相等，那么每个回滚段即是最小的，也是最大的。这也是我为什么避免使用“最优大小”回滚段的原因。如果你收缩一个此前被扩大的回滚段，就要丢掉以后可能还需要的大量 undo。倘若这么做，会丢掉最老的回滚数据，从而力图使风险最小，但是风险还是存在。我喜欢尽可能在非高峰期间手动地收缩回滚段。

    我们已经讨论过块清除机制，不过这里可以做一个总结：在块清除过程中，如果一个块已被修改，下一个会话访问这个块时，可能必须查看最后一个修改这个块的事务是否还是活动的。一旦确定该事务不再活动，就会完成块清除，这样另一个会话访问这个块时就不必再历经同样的过程。要完成块清除， Oracle会从块首部确定前一个事务所用的undo段，然后确定从 undo 首部能不能看出这个块是否已经提交。可以用以下两种方式完成这种确认。一种方式是Oracle可以确定这个事务很久以前就已经提交，它在undo段事务表中的事务槽已经被覆盖。另一种情况是COMMIT SCN还在 undo段的事务表中，这说明事务只是稍早前刚提交，其事务槽尚未被覆盖。

    要从一个延迟的块清除收到ORA-01555错误，以下条件都必须满足： 

l         首先做了一个修改并COMMIT，块没有自动清理（即没有自动完成“提交清除” ，例如修改了太多的块，在SGA块缓冲区缓存的10%中放不下） 。 

l         其他会话没有接触这些块，而且在我们这个“倒霉”的查询（稍后显示）命中这些块之前，任何会话都不会接触它们。 

l         开始一个长时间运行的查询。这个查询最后会读其中的一些块。这个查询从SCN  t1开始，这就是读一致 SCN，必须将数据回滚到这一点来得到读一致性。开始查询时，上述修改事务的事务条目还在undo段的事务表中。 

l         查询期间，系统中执行了多个提交。执行事务没有接触执行已修改的块（如果确实接触到，也就不存在问题了）。 

l         由于出现了大量的COMMIT，undo 段中的事务表要回绕并重用事务槽。最重要的是，将循环地重用原来修改事务的事务条目。另外，系统重用了 undo 段的区段，以避免对 undo 段首部块本身的一致读。 

l         此外，由于提交太多，undo段中记录的最低SCN 现在超过了t1（高于查询的读一致SCN）。  

 

如果查询到达某个块，而这个块在查询开始之前已经修改并提交，就会遇到麻烦。正常情况下，会回到块所指的undo段，找到修改了这个块的事务的状态（换句话说，它会找到事务的COMMIT SCN）。如果这个 COMMIT  SCN 小于 t1，查询就可以使用这个块。如果该事务的 COMMIT  SCN 大于 t1，查询就必须回滚这个块。不过，问题是，在这种特殊的情况下，查询无法确定块的COMMIT SCN是大于还是小于t1。相应地，不清楚查询能否使用这个块映像。这就导致了ORA-01555错误。

 

万一你发现遭遇了这个问题，即选择（SELECT）一个表时（没有应用其他DML操作）出现了ORA-01555错误，能你可以试试以下解决方案：

l         首先，保证使用的事务“大小适当”。确保没有不必要地过于频繁地提交。 

l         使用 DBMS_STATS 扫描相关的对象，加载之后完成这些对象的清理。由于块清除是极大量的UPDATE 或INSERT造成的，所以很有必要这样做。 

l         允许undo表空间扩大，为之留出扩展的空间，并增加undo保持时间。这样在长时间运行查询期间，undo 段事务表中的事务槽被覆盖的可能性就会降低。针对导致ORA-01555错误的另一个原因（undo 段太小） ，也同样可以采用这个解决方案（这两个原因有紧密的关系；块清除问题就是因为处理查询期间遇到了 undo 段重用，而 undo 段大小正是重用 undo 段的一个根本原因） 。实际上，如果把undo表空间设置为一次自动扩展1MB，而且undo保持时间为900秒，再运行前面的例子，对表BIG 的查询就能成功地完成了。 

l         减少查询的运行时间（调优）。如果可能的话，这总是件好事，所以应该首先尝试这样做。