数据库的undo和redo日志

本文介绍undo和redo日志的一般概念不涉及具体某个数据库的实现细节参考资料来自《数据库系统实现》的第六章《系统故障对策》。一个假设和四个操作原语一个假设假设数据库由元素组成。为了简化讨论这里假设元素是磁盘块并且元素的大小不超过一个磁盘块。四个操作原语事务进行操作时有三个地址空间1.保持数据库元素的磁盘空间2.缓冲区管理器所管理的主存地址空间也就是缓冲区空间3.事务的局部空间数据库读取元素时该元素首先要被读取到缓冲区空间然后再读取到事务的局部空间写入元素则相反先从局部空间写入到缓冲区空间。缓冲区空间的数据什么时候写入磁盘取决于缓冲区管理器。为了减少磁盘IO缓冲区管理器会尽量让写入操作写入到缓冲区在适当时候再将数据写回磁盘。基于此方便后面讨论定义四个操作原语1.INPUTX将包含数据库元素X的磁盘块拷贝到主存缓冲区2.READXt将数据库元素X拷贝到事务的局部变量t。这里可能包括两个操作如果数据库元素不在主存缓冲区X里面则会先执行INPUTX再将X拷贝到事务的局部变量t。3.WRITEXt将事务局部变量t拷贝到主存缓冲区的数据库元素X4.OUTPUTX将主存缓冲区里面数据库元素X拷贝到磁盘块假如有一个操作读取数据库元素A对元素A的值乘以2读取数据元素B对元素B的值乘以2再将数据库元素A和B写回到磁盘并且数据元素A和B的初始值都是8操作过程如下图1undo日志undo日志的作用是撤回事务把磁盘里面已经执行的数据撤回事务开始前的状态避免出现数据不一致的情况。undo日志规则U1如果事务T改变了数据库元素X那么在数据元素X新值写入到磁盘之前形如TXv的日志记录要先写入到磁盘。T代表事务X代表数据源元素v代表旧值。U2如果事务提交则必须在事务所改变的所有数据库元素写入到磁盘之后COMMIT日志才能写入到磁盘。根据U1和U2和事务相关的数据和日志写入到磁盘的顺序是这样的1.指明所修改的数据库元素的日志记录2.所修改的数据库元素自身3.COMMIT提交日志记录我们在图1事务的基础上根据undo日志规则加入undo日志的记录执行流程就是如下图2图2其中M-A代表数据库元素在内容上的值D-A代表数据元素在磁盘上的值以此类推。观察图2事务开始时写入START T日志记录当在第4和第7步把新值写回缓冲区的时候也记录了相应的日志。在第9步把数据库元素写回之前执行了FLUSH LOG操作先向磁盘刷新修改日志符合U1规则。在第11步写入COMMIT T日志记录之前执行了刷新数据库元素A和B到磁盘符合U2规则。最后第12步再执行一次FLUSH LOG以确保COMMIT T日志及时写到磁盘。使用undo日志的恢复在事务过程的任何阶段都有可能发生奔溃有可能部分数据已经写到了磁盘另一部分数据还没写入磁盘为了保证事务执行的原子性和数据的一致性这时需要利用undo日志对数据进行恢复。以图2为例1.假如奔溃发生在12步之后恢复管理器扫描日志发现COMMIT T日志记录已经到磁盘根据规则U2此时说明事务T所有对数据源元素的修改都已经写到磁盘因此不用对事务T进行处理。2.假如奔溃发生在12步之前这时有两种可能。第一可能是COMMIT T日志记录已经写到了磁盘比如奔溃发生在第11步到第12步之间没有强制刷新日志但日志已经被写回了次盘执行过程回到1。第二种可能是COMMIT T日志记录还没写到磁盘由于不清楚对数据源元素A和B的修改是否已经写到磁盘所以继续向前扫描日志进行撤回。扫描到TB 8将磁盘上的元素B的值改回8扫描到TA 8将磁盘上的元素A的值改回8。最后记录ABORT T日志并刷新到磁盘代表事务T没有执行成功并且已经对他进行了恢复。检查点当日志量很大时恢复管理器不可能无限向前扫描日志那样太慢了。有一种叫检查点的技术可以解决这个问题。当执行检查点时要实现这几个操作1.停止接受新的事务2.等到所有活跃的事务提交或终止并且在日志写入了COMMIT或者ABORT记录3.将日志刷新到磁盘4.写入日志记录CKPT并再次刷新日志5.开始接受新的事务当进行恢复时恢复管理器如果扫描到CKPT说明日志记录CKPT之前的所有日志都已经无须进行恢复所有无须继续向后检查了。因为根据U1和U2规则当所有活跃事务的COMMIT或者ABORT记录出现在磁盘时表明相关的所有数据库元素也已经更新到磁盘。非静止检查点规则静止检查点在执行期间需要停止接受新的事务这会导致数据库的性能低下所以有一种叫非静止检查点的技术在执行检查点期间无须停止接受新的事务。执行步骤如下1.写入日志记录START CKPT(T1, ..., Tk)其中T1, ..., Tk是所有活跃的事务名称或者标识2.等待T1, ..., Tk中的所有事务提交或者终止但允许开始其它新的事务3.当T1, ..., Tk中的所有事务都完成时写入日志记录END CKPT并刷新到磁盘当进行恢复时有两种情况先遇到END CKPT记录。说明完整执行完了一次检查点继续向后扫描扫描到START CKPT(T1, ..., Tk)就无须进行扫描了。因为当在START CKPT(T1, ..., Tk)到END CKPT期间开始检查点时的所有活跃事务的相关日志都已经记录到磁盘所以START CKPT(T1, ..., Tk)后面的日志不再被需要。先遇到START CKPT(T1, ..., Tk)日志记录。说明再执行检查点过程中数据库系统发生了奔溃导致没有记录到END CKPT。这时我们无法知道START CKPT开始时的活跃事务是否已经完成所以只能继续向后扫描直至遇到第二个START CKPT(T1, ..., Tk)日志记录。例子图3假如系统发生了奔溃日志如图3。我们发现T3是一个未完成的事务需要进行撤回而最近检查点开始时的事务T1和T2都已经提交无需撤回。只有T3需要撤回。图4假如系统在检查点执行过程中发生了奔溃如图4。我们先发现了START CKPT并且发现了T1已经提交无须撤回T1。由于先发现START CKPT所以无法知道T2是否完成了提交需要继续向前扫描。同时T3也是一个未完成的日志。所以需要撤回的事务是T2和T3。实际上在检查点执行过程中奔溃不是一定得扫描到第二个START CKPT的出现只需要检查到当时活跃事务里面最早开始的那个事务的START记录即可。redo日志由undo日志规则可知在将事务的所有日志写到磁盘前我们无法提交日志。如果能够将对数据库元素的修改尽量暂时存在于主存缓冲区中这样就能减少磁盘IO只要奔溃时也有办法来恢复。这样的技术就是redo日志。redo日志规则在redo日志中形如TXv的日志记录T代表事务X代表数据源元素v代表新值。redo日志规则只有一条R1在修改磁盘上的任何数据库元素X之前要保证与X修改相关的日志记录比如TXv记录和COMMIT记录要先写到磁盘。根据R1和事务相关的数据和日志写入到磁盘的顺序是这样的1.指明所修改的数据库元素的日志记录2.COMMIT提交日志记录3.所修改的数据库元素自身我们在图1事务的基础上根据redo日志规则加入redo日志的记录执行流程就是如下图5图5观察图5事务开始时写入START T日志记录当在第4和第7步把新值写回缓冲区的时候也记录了相应的日志。在第10步和第11步把数据库元素写到磁盘之前在第8步执行了提交在第9步刷新日志以确保日志记录写入到磁盘。使用redo日志的恢复根据规则R1可以知道如果日志里面有对应事务的COMMIT记录就可以进行恢复如果没有对应事务的COMMIT记录说明没有任何数据库元素写入到磁盘则可以不处理。以图5为例1.假如故障发生在第9步之后日志里面肯定COMMIT记录则可以对数据库元素A和B都进行恢复到16。如果故障发生在第10和11步之间也可以正常对元素A和B进行恢复对元素A的恢复虽然是多余的但也无害。2.假如故障发生再第9步之前如果日志里有COMMIT记录虽然还没有强制刷新日志但可能提交日志已经写到磁盘则处理过程回到1。如果日志里面没有COMMIT记录说明该事务没有任何元素写入到磁盘不做任何处理只需要往磁盘写入对应事务的ABORT T记录即可。非静止检查点规则根据R1规则已提交事务把数据写入到磁盘的时间可能要比提交时间晚得多发现COMMIT日志记录的时候我们也无法判断修改的数据是否已经写入到磁盘。在检查点开始和结束期间我们需要保证在检查点开始时已提交事务修改的所有还没有写入到磁盘的数据库元素进行写入到磁盘。也就是说需要缓冲区管理器知道哪些缓冲区是脏的。同时在检查点期间可以开始新的事务。所以进行redo日志的非静止检查点的步骤如下1.写入日志记录START CKPT(T1, ..., Tk)其中T1, ..., Tk是所有活跃的事务名称或者标识2.把写入日志记录START CKPT时已提交事务的脏缓冲区的数据源元素写入到磁盘。但也允许开始其它新的事务。3.写入日志记录END CKPT并刷新到磁盘当进行恢复时有两种情况先遇到END CKPT记录。这时继续向后扫描日志直至遇到START CKPT(T1, ..., Tk)说明在START CKPT(T1, ..., Tk)前提交的事务所有的脏缓冲区都已经写入到磁盘但Ti的任何一个事务和检查点期间开始的新事务我们无法知道是否所有被修改的数据源元素都已经写入到磁盘。所以还要继续往后扫描日志直至遇到START CKPT(T1, ..., Tk)里面开始时间最早的那个事务的START T日志为止就不必继续往后扫描了。先遇到START CKPT(T1, ..., Tk)记录。由于没有对应END CKPT记录我们无法保证START CKPT(T1, ..., Tk)记录开始时的已提交事务的所有脏缓冲区是否已经写入到磁盘只能继续往后扫描直至遇到第二个START CKPT(T1, ..., Tk)记录。例子图6假如故障在COMMIT T3之后发生扫描日志时先遇到END CKPT记录说明是一个完整的检查点。在扫描到START CKRT(T2)期间可以得知我们需要恢复T2和T3的事务把磁盘里的数据源元素D修改为20元素C修改为15。继续扫描日志直至遇到START T2记录停止可以得知事务T1在开始检查点时已经提交我们可以保证事务T1的在检查点执行完成时所有脏数据都写到了磁盘无须恢复我们需要继续把磁盘里面的元素B恢复为10即可完成恢复。假如故障在END CKPT之前发生扫描日志首先遇到START CKRT(T2)记录说明故障在检查点期间发生没有激记录到END CKPT。我们需要一直扫描到第二个START CKRT记录获取其记录的活跃事务列表直至扫描到其活跃事务列表里面开始时间最早的那个事务Ti的START Ti记录为止。