关于重做记录的结构 - NinGoo

导读：

　　以前一直对备份恢复理解得不是特别清楚。Oracle文档上一般都是说通过应用重做记录前滚，通过应用undo记录回滚，最终使数据库达到一致。又说，redo记录中包含了更改后的数据和更改前的数据，undo记录包含了更改前的记录，而且undo的更改也会记录redo，这没错，但是究竟redo中记录了哪些东西？对同一个更改，既然redo本身记录了前映象，为什么还要有undo记录前映象？为什么undo的变更也要记录redo？还有哪些东西需要记录redo？

　　这些问题一直没有弄得太明白，前两天翻《Oracle8i备份与恢复手册》的时候，发现了宝贝:)里面讲到的重做记录的结构，对于理解这些问题大有帮助。在恢复的过程中，是以重做记录为单位的，要么应用整条重做记录，要么一条重做记录都不应用。但重做记录本身，也是有一组修改向量组成的。所谓的修改向量，就是对某个单独的块的改动记录。比如下面的SQL：

　　update test set id=2 where department=100;

　　就会产生三个修改向量：

　　1) test表中department=100的记录所在的数据块被修改，需要在redo中记录该数据块的修改向量

　　2)修改该数据块会产生一个回滚块，该回滚块记录了原来id的值，需要在redo中记录该回滚块的修改向量

　　3)如果这是该事务的第一个改动，还会修改回滚段头的事务表，对回滚段头的修改也有一个修改向量记录

　　这样，这个重做记录就包含三个修改向量。当然，有个时候一个重做记录可能包含更多的修改向量，比如产生行链接和行迁移时，改动的数据块就不止一个，对应的回滚块也不止一个，由于每个块都记录一个修改向量，这样一个重做记录中就包含了很多的修改向量。另外，从上面也可以看出，redo是通过记录undo的变更来记录数据块的前映象的，并不是单独在redo中记录数据的前映象和后映象，在undo中记录前映象，再在redo中记录undo的后映象。一个重做记录就包含了一次修改所涉及到的所有块，包括数据块，回滚块和回滚段头块等。所以在应用重做记录的时候，要么这个重做记录中的修改向量都应用成功，要么都应用失败，这和事务的概念是差不多的。

　　那么为什么要记录回滚段头的修改向量呢？因为我们需要回滚段头的事务信息来判断一个事务是已经提交了还是未提交的。虽然在每个块中也有事务记录，但是块中的记录可能是不正确的。这里需要提到一个块清除(block cleanout)的概念。一般情况下，一个事务在commit时，会将该事务所有的重做记录写入到redo文件，会将回滚段头的事务信息清除，也会清除每个块中的事务标志。但是下面两种情况下，此时不会执行块清除

　　1) 该事务commit前，某些已修改但未提交的块已经写入到datafile了

　　2) 该事务修改的块的数量超过了buffer cache中所有块数的10%了

　　这时，事务已经commit，回滚段头中的事务信息也清除了，但这些块中的事务标志还在。这些块会在下一次读取到的时候执行块清除动作。所以，如果只通过块中的事务标志来判断该事务有没有提交，就会出现误判的情况。

　　理解了重做记录的结构后，再来看一下实例恢复的过程。在实例恢复开始时，会从redo日志中找出上一次的checkpoint点，从该点起开始应用redo前滚。在前滚过程中，每条重做记录都记录了数据块和对应回滚块的修改，有时也有回滚段头的修改。那么在应用重做记录后，就会重新构造出数据块，回滚块和回滚段头。就和最初对这些块的改动一样。在前滚完成后，buffer cache中的所有记录就和上次instance崩溃时一样了，除了instance崩溃时redobuffer中一些没有来得及写入redo文件的记录，由于提交成功的事务的redo一定已经写入redo文件了，那么这些没有写入redo的一定都是未提交的事务。由于instance崩溃前存在一些未提交记录，而这些未提交事务在重新启动instance并执行实例恢复后，显然不可能再继续下去了，所以需要回滚这些事务。回滚时从回滚段头读取事务信息，然后通过应用回滚段的记录来回滚事务。由于回滚块也是在buffer cache中修改的，也可能在实例崩溃时没有来得及写入到磁盘中，所以前面前滚时需要应用重做记录中对回滚块的修改向量重新构造出这些没有写入文件中的回滚块，这样后面的回滚阶段才会有所有必须的回滚块记录来进行回滚。



本文转自

http://blog.youkuaiyun.com/NinGoo/archive/2006/04/27/693804.aspx