在不自动提交的情况下，回滚段有啥用。

Posted 2023-04-26

我执行execute（update....）时，没有提交，也就是说底层的数据库没有变化，那如果我现在执行回滚的话，底层数据库数据没有变，也就是说不需要回滚，那这个回滚到底回滚的什么？

回滚段用于容纳update, insert, delete语句时产生的中间数据，这些中间数据就是用于“回滚”（rollback)的。
如果回滚段设置过小，你在对大表执行update, insert, delete语句时可能会一直卡死在一个地方，你这时通过DBA工具查看回滚段表空间，使用率会达到99%，这时只能通过扩大回滚段表空间来解决。
没有回滚段是不可想像的。 参考技术A 回滚的作用，可用于修改重要数据,如果出现一点错误可以有补救的机会 参考技术B 参考答案 有勇气并不表现害怕不存在，而是敢面对恐怖战胜胆怯。本回答被提问者采纳

简单了解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字段上的事务）。