简单了解Oracle的回滚段

Posted 张小贱1987

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了简单了解Oracle的回滚段相关的知识,希望对你有一定的参考价值。

因为上一次研究了Oracle的事务一致性,中间查阅资料的时候,看到这个地方与回滚段有关。所以就罗列了以下简单的知识。更为深层次的就不再深挖了,个人感觉对于事务的一致性和隔离级别是开发经理应该了解的,但是回滚段的具体机制应该是DBA的学习范畴了。

 
回滚段(ROLLBACK SEGMENT)的作用:
回滚段是在事务中间过程中,将修改前的状态记录下来,记录的过程中加上类似时间戳的scn。它的主要作用有两个:
  1. 当事务出现错误回滚的时候,原始数据可以从回滚段中找回。
  2. 实现读一致性。当读操作读取到某一行,发现这行数据已经被修改,就会根据读取时刻的scn去回滚段中找之前的数据。
回滚段还有一个重要作用就是误删数据恢复。
 
 
关于回滚段导致的ORA-01555错误。
 
网上的说法:
 
  1. 1、在1点钟,有个用户A发出了select * from table1;此时不管将来table1怎么变化,正确的结果应该是用户A会看到在1点钟这个时刻的内容。这个是没有疑问的。   
  2. 2、在1点30分,有个用户B执行了update命令,更新了table1表中的第4000万行的这条记录,这时,用户A的全表扫描还没有到达第4000万条。毫无疑问,这个时候,第4000万行的这条记录是被写到了回滚段里去了的,我假设是回滚段RBS1,如果用户A的全表扫描到达了第4000万行,是应该会正确的从回滚段RBS1中读取出1点钟时刻的内容的。   
  3. 3、这时,用户B将他刚才做的操作commit了,但是这时,系统仍然可以给用户A提供正确的数据,因为那第4000万行记录的内容仍然还在回滚段RBS1里,系统可以根据SCN来到回滚段里找到正确的数据,但是大家注意到,这时记录在RBS1里的第4000万行记录已经发生了一点重大的改变:就是这个第4000万行的在回滚段RBS1里的数据有可能随时被覆盖掉,因为这条记录已经被提交了!!!   
  4. 4、由于用户A的查询时间漫长,而业务在一直不断的进行,RBS1回滚段在被多个不同的tracnsaction使用着,这个回滚段里的extent循环到了第4000万行数据所在的extent,由于这条记录已经被标记提交了,所以这个extent是可以被其他transaction覆盖掉的!   
  5. 5、到了1点40分,用户A的查询终于到了第4000万行,而这时已经出现了第4条说的情况,需要到回滚段RBS1去找数据,但是已经被覆盖掉了,于是01555就出现了。 
 
 
我的理解:上面的说法大致正确,不过有一个误区,给人造成一种印象:一旦一个事务提交了,它所占据的回滚段里的数据,有可能还是需要的(为了保证读一致性),但是如果此时来了一个新的事务来处理同样的这块数据,这个回滚段就会被重写。其实不是这样的,新的事务会在回滚段里有不同的scn,不会直接重写还有用的回滚段,之所以会出现01555,是因为回滚段的空间是有限制的,一旦时间太长,或者执行了其他复杂事务导致了回滚段不够用,老的回滚段才会被清除。所以要避免01555,主要是扩大回滚段大小,优化耗时的查询,减少占用回滚段太多的不必要事务(如Clob或者Blob字段上的事务)。

以上是关于简单了解Oracle的回滚段的主要内容,如果未能解决你的问题,请参考以下文章

ORA-01555: 快照太旧: 名为 "" 的回滚段号太小

6. Oracle 回滚(ROLLBACK)和撤销(UNDO)

Oracle日常性能查看

oracle -- 数据段(segment)

InnoDB多版本

oracle undo回滚段详解