(1) 事务要求的回滚段空间不够，表现为表空间用满（ ORA-01560 错误），回滚段扩展到达参数 MAXEXTENTS 的值（ ORA-01628 ）。
解决方法：
A. 扩大回滚段所在表空间
B. 设置较大的MAXEXTENTS参数
C. 为回滚段设置OPTIMAL参数
D. 用较大的EXTENT参数重新创建回滚段
向回滚段表空间添加文件或使已有的文件变大；增加MAXEXTENTS的值。
ORA-01562: failed to extend rollback segment number 12 ORA-01628: max # extentsreached for rollback segment RBS12
扩大表空间
给回滚段表空间增加数据文件，并设置大回滚段 apprbs 的 maxextents 值为无限大：
alter tablespace rbs add datafile ‘/opt/oracle/db02/oradata/ORCL/rbs02.dbf‘ size 8192m autoextend on next 10m maxsize unlimited;
扩大参数
ALTER ROLLBACK SEGMENT rbs01 STORAGE (MAXEXTENTS 1000);
可用如下语句代替 ( 批量提交释放回退段空间 ):
create table tt(id number,sal number,age number); declare begin for i in 1..10000 loop insert into tt values(i,i*10,i*100); end loop; end; select * from tt order by id;
删除表 tt 中 id 不等于 10 的所有数据
begin loop delete from tt where id !=10 and rownum<=10; exit when sql%notfound; commit; end loop; end;
其中 rownum <=10的目的是每 10 条提交一次；
(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. 回滚段太少 / 太小
数据库中有太多的事务修改数据并提交 , 就会发生已提交事务曾使用的空间被重用 , 从而造成一个 延续时间长的查询所请求的数据已经不在回滚段中
( 即：长查询开始之前，事务被修改并且没有提交，长查询进行中，事务提交，并且事务所在回滚段被其他事务覆盖，这时就会出现 ora-01555 错误 )
解决方法 : 创建更多的回滚段 , 为回滚段设置较大的 EXTENT 以及较大的 MINEXTENTS
B. 回滚段被破坏
由于回滚段被破坏 , 造成事务无法将修改前的内容 (read-consistent snapshot) 放入回滚段 , 也会产生 ORA-01555 错误 .
( 即：事务被修改并且没有提交，之后事务所在回滚段损坏，这时在查询这个事务时就会报 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 前对该表做全表扫描 ( 保证所有的修改被确认 ) 会有所帮助 .
E 不适当的 OPTIMAL 参数 :
太小的 OPTIMAL 参数会使回滚段很快被 SHRINK, 造成后续读取操作访问时 , 先前的内容已丢失，仔细设计 OPTIMAL 参数 , 不要让回滚段过于频繁的 EXTEND/SHRINK 有助于问题的解决。
F DB BLOCK BUFFER 太小
如果读一致性所请求的块的先前内容在缓冲区中 , 那么就不用去访问回滚段 ，而如果缓冲区太小 , 使得先前版本的内容在 CACHE 中的可能性变小 , 从而必须频繁的访问回滚段来获取先前的内容 , 这将大大增大 ORA-01555 发生的可能。
oracle 块延迟清除 (delayed block cleanout) 理解
为了保证事务的回退和满足多用户的 CR ， oracle 引入了 undo 机制， 由于 undo 是循环使用的，在一个事务完成过程中，它与 redo 相互配合，其中 undo 在一次事务中需要完成以下工作：
(1) Transaction 开始前回滚段获取一个 ITL( 事务槽 ) ，分配空间， 记录事务信息
(2) Transaction 提交后， redo 完成记录，同时还清除回滚段的事务信息 包括行级锁， ITL 信息 (commit 标志， SCN 等 )
清除这些事务段的信息的过程就叫做块清除， 在完成块清除时 , 我们本事务修改的数据块就会存在两种可能
(1) 所有的数据块还保存在 buffer cache 中
(2) 部分数据块或者是全部数据块由于 LRU 管理已经被刷出了 buffer cache 。
oracle 为了考虑到块清除的成本，以及性能，会作以下两种方式的块清除处理：
(1) 快速块清除 (fast block cleanout), 当事务修改的数据库全部保存在 buffer cache 并且修改数据块的数据量没有超过 cache buffer 的 10% ，快速清除事务信息。
(2) 延迟块清除 (delayed block cleanout) 当修改的数据块的阀值超过 10% 或者本次事务相关的数据块已经被刷出了 buffer cache ， oracle 会下次访问此 block 时再清除事务信息。
原文链接: https://www.yukx.com/oracle/article/details/2060.html 优科学习网Oracle回滚段的常见问题及解决方法
