ORA-1555错误综述(转）

ORA-1555错误简单的说就是针对一个数据块产生一致读时发生了错误。一致读就是指 oracle 利用回滚段来临时重构一个和事务或查询开始时的块状态相同的快照块的过程。如果一个块改变了多次，可能就会有多个快照块的。

一个事务或查询开始执行时， oracle 会产生一个SCN来记录这个开始时刻点，这个SCN也就叫做SNAPSHOT SCN。 oracle 仅仅看基于SNAPSHOT SCN的快照记录。如果块中有活动的事务或BLOCK SCN> SNAPSHOT SCN时，就产生了一致读。如果是没有活动的事务但没有产生COMMIT SCN的块，先产生DELAY BLOCK CLEANOUT，再比较COMMIT SCN与SNAPSHOT SCN的大小，如果COMMIT SCN小于SNAPSHOT SCN则直接使用该块，否则要产生一致读。
产生ORA-1555的可能情况：
（1） 一个长时间运行的查询，并同时针对查询需要的块有DML处理
当一个长时间的查询开始执行时，查询所需要的一个数据块被修改并递交了，这个块是需要一致读的，但因为该DML事务已递交了，所以保留前映像的回滚段SLOT可以被另外的事务使用，这个查询事务耗时非常长，在这个时间段中，很可能该SLOT被另外的事务使用而把原值给覆盖了，所以当查询执行到该块时，该块的SNAPSHOT SCN时的值已经找不到了，报ORA-1555错误。
解决方法：
 业务控制，禁止对同一个表的长时间查询和更新处理同时进行，要分开执行
 增加回滚段的个数
 增大回滚段的大小，记住产生ORA-1555的错误可能是最小的回滚段造成的，所以每个回滚段的大小应该一致。
 不使用OPTIMAL选项
 推迟对DML语句的COMMIT
 缩短查询的时间，修改查询语句，比如并行查询
 为要查询的表建立只读SNAPSHOT，这样对表记录的修改就不会影响到查询，但该表不能是太大的表
（2） 交叉递交
通过一个游标建立一个循环来循环读取表的数据，但又在循环中对表的进行修改并递交。如果正好多次修改并递交，将一个数据块在回滚段的前映像给覆盖了，当循环又要取该数据块的值时，报ORA-1555错误。这是个经常出ORA-1555错误的操作。
解决方法：
 修改程序，避免这种情形出现
 尽量在循环读取中，不要做递交处理
 在查询语句中，增加“ order by 1 ”的语句，这样会在临时段中保留ORDER BY的结果，而不在需要一致读了。
（3） 延迟块清除
延迟块清除是指当一个DML事务发生并递交了， oracle 在回滚段做了一个快速COMMIT标记该事务已递交了，但在DATA BUFFER中修改过的数据块并没有标记，（ oracle 一次只清除DATA BUFFER10%的修改的数据块）这些未清除但已递交的数据块要在下一次事务访问才清除掉，这就是延迟块清除。在这个过程中有可能出现ORA-1555的错误，但一般是非常难得的，因为出现这个错误需要满足以下几个条件：
①已做了修改并递交，但又未做清除的数据块
②这些块在被下一个要出错的事务使用前，没有被其他事务使用
③查询期间，系统中又发生了大量的其他DML处理，这些DML处理不涉及到这些块。
④因为这些大量的DML事务，产生了频繁的递交，造成事务表被多次WRAP，最初保留未清除事务的事务条目也被循环的使用，原来的UPDATE COMMIT SCN已经不存在了。
⑤回滚段的最小SCN已经超过查询SCN了
⑥当查询执行到该块的时候，发现该块的UPDATE COMMIT SCN已经不存在了，而且现在回滚段的最小SCN也比查询SCN要大，UPPER BOUND SCN都无法估算了，所以无法确定查询是否能使用这个块，造成ORA-1555错误。
解决方法：
一般这种情况很难出现，可以不考虑，如果确实要解决，可以在DML操作后，做一次FULL TABLE SCAN来清除上次未清除的块。
可以设置DELAYED_LOGGING_BLOCK_CLEANOUTS = true （缺省）
（4） 回滚段有坏块

总结，从上面说明中可以看出，防止ORA-1555问题出现，最根本的一点就是保证回滚段中已COMMIT的事务信息不被覆盖了。9I中， oracle 提供一个更加有效的方法来保证这点，用参数UNDO_RETENTION来保证COMMIT的事务多长时间不被覆盖。具体说明，参见ORACLE9I的自动回滚段管理说明（SMU）