oracle 删除异常回滚段,回滚段的常见错误及解决方法

(1).回滚段空间不够

ORA-01562 - failed to extend rollback segment number string

回滚段空间不够的原因一般有以下几种情况:

A. 回滚段所在表空间剩余的空闲空间太小, 无法分配下一个EXTENT.

B. 回滚段扩展次数已经达到MAXEXTENTS限制

解决方法:

A. 扩大回滚段所在表空间

B. 设置较大的MAXEXTENTS参数

C. 为回滚段设置OPTIMAL参数

D. 用较大的EXTENT参数重新创建回滚段

C. 将导致ORA-1562错误的DML语句改为分段执行:

例如: 语句为：

DELETE FROM CHENFENG WHERE condition;

可用如下语句代替:

BEGIN

LOOP

DELETE FROM CHENFENG

WHERE condition

AND ROWNUM<10000;

EXIT WHEN SQL%NOTFOUND;

COMMIT;

END LOOP;

END;

(2). ORA-01552 cannot use system rollback segment for non-system tablespace 'string'

原因: 没有可用的非系统回滚段. 分为以下情形:

A. 除了系统回滚段, 未创建其它回滚段

B. 只创建了PRIVATE回滚段, 但INITsid.ORA的ROLLBACK_SEGMENTS中未列出这些回滚段

C. 创建了PUBLIC回滚段, 但这些回滚段都处于OFFLINE状态

解决方法: 根据以上原因相应解决即可

(3).ORA_01555 snapshot too old: rollback segment number string with name "string" too small

原因可分为以下情形：

A. 回滚段太少/太小

数据库中有太多的事务修改数据并提交, 就会发生已提交事务曾使用的空间被重用, 从而造成一个延续时间长的查询所请求的数据已经不在回滚段中.

解决方法: 创建更多的回滚段, 为回滚段设置较大的EXTENT以及较大的MINEXTENTS

B. 回滚段被破坏

由于回滚段被破坏, 造成事务无法将修改前的内容(read-consistent snapshot) 放入回滚段, 也会产生ORA-01555错误.

解决方法: 将被破坏的回滚段OFFLINE, 删除重建.

C. FETCH ACROSS COMMIT

当一个进程打开一个CURSOR, 然后循环执行FETCH, UPDATE, COMMIT, 如果更新的表与FETCH的是同一个表, 就很可能发生ORA-01555错误.

解决方法:

a. 使用大的回滚段

b. 减少提交频率(可参见本论坛"如何避免一个PROCEDURE被重复调用"一贴中, 无名朋友的回帖)

以上两种方法只能减少该错误发生的可能, 不能完全避免. 如果要完全避免, 须从执行方法着手, 可以用以下两种方法:

c. 建立一个临时表, 存放要更新的表的查询列(如主键及相关的条件列), 从临时表FETCH, 更新原来的表.

d. 捕获ORA-01555错误, 关闭并重新打开CURSOR, 继续执行循环.

D. 其它原因:

* Delayed logging block cleanout是ORACLE用来提高写性能的一种机制: 当修改操作(INSERT/UPDATE/DELETE)发生时, ORACLE将原有的内容写入回滚段, 更新每个数据块的头部使其指向相应的回滚段, 当该操作被COMMIT时, ORACLE并不再重新访问一遍所有的数据块来确认所有的修改, 而只是更新位于回滚段头部的事务槽来指明该事务已被COMMIT, 这使得写操作可以很快结束从而提高了性能接下来的任何访问该操作所修改的数据的操作会使先前的写操作真正生效, 从而访问到新的值. Delayed logging block cleanout 虽然提高了性能, 但却可能导致ORA-01555. 这种情况下, 在OPEN/FETCH前对该表做全表扫描(保证所有的修改被确认)会有所帮助.

有两种delayed cleanout的情况：

1.因为相应的回滚段信息还没有被重用，访问这些没有被cleanout的数据块的进程可以确定commit时的SCN.

2.由于时间太久，不能获得精确的SCN，这个数据块会被标记一个‘best guess' SCN或'upper bound commit' number.

如果进行cleanout的这个事务运行时间太久，Oracle无法根据回滚段的信息来获得'upper bound commit' number(在该事务执行期间回滚段被重用的次数太多)，就会发生著名的ORA-1555.

* 不适当的OPTIMAL参数: 太小的OPTIMAL参数会使回滚段很快被SHRINK, 造成后续读取操作访问时, 先前的内容已丢失. 仔细设计OPTIMAL参数, 不要让回滚段过于频繁的EXTEND/SHRINK有助于问题的解决.

* DB BLOCK BUFFER太小: 如果读一致性所请求的块的先前内容在缓冲区中, 那么就不用去访问回滚段. 而如果缓冲区太小, 使得先前版本的内容在CACHE中的可能性变小, 从而必须频繁的访问回滚段来获取先前的内容, 这将大大增大ORA-01555发生的可能.

产生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)。