3-4. 基于redo日志的恢复机制在线视频

下面我们来看基于redo日志的恢复机制

那么我们前面讲的undo日志呢，它有一个特点

就是说，每次去写这个commit的时候呢，首先必须要更新数据

但是呢，如果频繁的更新数据，而缓冲区又没有满的话

这个时候它的IO操作就会增加，IO操作次数太多

那数据库它的这个效率就比较低了，就会降低它的效率

redo日志就是基于这样的一个想法

就说我完全可以让数据先不更新到磁盘上去

直到缓冲区达到一个比如说百分之七十或者百分之八十

它的一个限度，这个时候我再强制缓冲区里的数据写到磁盘里面去

这样的话，我会减少IO操作，因为IO它的这个代价是比较高的

所以这样的话，就说它提出来我们用重做已经提交的事务这样的一种方式

说它的日志文件里面它的对数据库这个修改这个格式就变成是这样的一个

也就说记录事务t它的操作以及操作的数据项和数据项更新后的它的这个新值

也就是更新后的值叫新值

那么redo日志它的创建规则是什么呢，它是这样的

它说那么我如果有数据更新的时候

我先把所有记载数据更新的日志记录和commit先写磁盘

也就说它和commit也先写磁盘了，然后再把更新的数据写入磁盘

也就是如果用一个简单的这个话来说呢

也就是先写日志，后写数据这样

那么它恢复的规则就是重做已经提交的事务

也就是它扫描日志的时候发现有commit的事务

它重新的再做一遍，那为什么呢

就是因为它虽然在这个日志里面有commit

但是实际上因为我们是先写commit，后写数据

那commit之后有可能是发生故障，数据有可能没有更新到磁盘上去

所以它要做这件事情，就说发现有commit这样的一些事务

我重新再做一遍，确保它真正的更新到磁盘上去

那么这张表呢，就是我们举的用redo日志的一个例子

和这个前面这个例子是一样的，前面的我们的日志记录是先写start 〈T〉

以及对数据的一些操作，然后接下来是output〈A〉和〈B〉

然后接下来才是commit，是吧，而现在redo日志就是先写对数据的操作

然后直接写commit，然后把所有的日志刷新到磁盘上去

接下来再去更新数据，这样的话呢，大家就可以自己去分析

你比如说在commit前后，是吧，发生故障的时候

应该怎么去扫描，那么我们就不做过多的解释

下面我们来看一下它的检查点的使用

就说因为我们所有的日志可能都要加检查点

redo日志也是一样的，那redo日志的检查点和undo日志有点类似

也就说它实际上也是在一个合适的地方

它先插入一个START CKPT，然后这个地方括起来目前所有活动的事务

然后呢，把这个START CKPT然后刷新到日志里面去

那么，把它刷新到日志之后呢，那么我们再做什么事情呢

它就要把目前活动事务，它所提交的，就说缓冲区里面

目前已经提交了，这样的一些事务，它的数据要更新到磁盘上去

也就说START CKPT它之前已经提交的这样的一些数据

一定要目前就开始写了，只要插入到START CKPT

然后它就开始向数据库更新，那么更新到什么为止呢

就说它所有的都已经更新完之后，才加入一个END CKPT

它是这样来加入它的这个检查点规则

这个和undo日志显然就是不一样的

因为undo日志是等待着这个所有的这个START CKPT里面所有的事务提交

它再插入，而这个redo日志一定要记住

就说它START CKPT插入之后

它要把START CKPT之前全部提交事务的数据更新

更新完了之后再写END CKPT，这是它的这个规则

那么从这个角度上来看，我们这张图就表示出来了

我们就发现，就说redo日志里面有可能有一些事务要跨越多个检查点

那么因为有些事务它可能就是没有执行完

下面这两个例子就是redo日志的一个比较正确的实例

比如第一个是，有一个事务的START CKPT，T1

比如目前是活动事务T1，那么我加入START CKPT

如果在它之前有其他的事务提交

那么目前就开始把其他事务的更新

数据更新要放到网上磁盘上去写

写完之后呢，直接插入END CKPT

那么当然在这期间呢，也可以有新的事务去启动

这是没问题的，那么右边的这个例子，也是一样的

也就说我们之前有个START CKPT T1

然后呢，启动它之后呢

我们就开始在它之前的一些已经提交的事务，要向数据库进行更新

更新完了，我们插入一个END CKPT

然后接下来我们再在一个合适的地方插入START CKPT

目前活动事务是T1，T2，是吧，然后插入完之后

在这个START CKPT之前，提交事务

它的数据库更新，我们要向磁盘上去写

写完之后，写END CKPT T1，T2

它是这样的一个规则，那么按照这样一个规则

我们在进行数据恢复的时候，日志应该扫描多远呢，我们用这个图来看

那么我们在扫描日志的时候，和undo日志是一样的

也就说首先可能我们也是第一个遇到的是一个END CKPT这样的一个点

那么我们说，如果我们要遇到了END CKPT的话

那么我们应该扫描到什么地方呢

那实际上我们根据redo日志它的那个规则，就说

我们如果遇到了END CKPT，那就说明什么呢

就说END CKPT目前它括弧里的所包含的这些事务呢

都是目前一些活动的事务，是吧，一些活动的

也有可能是提交的这样的一些事务

但是呢，在END CKPT之前，它已经向数据库更新了什么呢

更新了它所对应的START CKPT之前提交的事务的更新

这就意味着它所对应的START CKPT之前所有提交的事务我们不用去扫描了

只有START CKPT本身包含的事务和它后面启动的事务

再有commit的话，我们采取重做，是吧

所以这样的话呢，我们呢向前扫描

直接扫描到END CKPT对应的一个START CKPT就可以了

那这就是我们首先碰见到END CKPT，这一点的时候，扫描多远

第二个就是如果我首先碰到的是START CKPT的时候

我应该向前扫描多远呢，这个也一样

显然就是如果我先碰见了START CKPT的话

那就说明什么呢，就说它所包含的这些事务，目前呢

是应该活动的事务或者是目前提交的事务，是吧

就在这个START CKPT写之前的这些提交的事务

有可能已经更新到数据库上了，也有可能没有更新到数据库上

而这些事务实际上包含在什么地方呢

是不是应该包含在前一个START CKPT里面

因为它的前一个START CKPT，它在之前的那样一些成功提交的事务

显然是已经不需要我们去关心的

只有它目前活动的事务后面才有可能提交

才有可能在下一个START CKPT那个地方提交并且可以开始更新

所以这样的话呢，我们只要再向前去搜索

搜索到前一个START CKPT，这个时候我们就结束了

然后从前一个START CKPT，向后去扫描

这些事务如果有这个commit的话，我们就重新去做就可以了

那这就是redo日志，它的检查点的这样一种使用

当然在这个过程当中，那么有一些事务，比如说某一些事务T

它有可能跨越，就是说虽然我们只扫描到这个START CKPT

比如说如果第一个我们碰见的是START CKPT的话

那么这个时候呢，我们知道，START CKPT之前已经提交的事务

那么它的对数据库的更新有可能写到磁盘里面去，也有可能没有写

所以这个时候我们需要对这些数据要进行重做

那么它重做呢，这些事务有可能比如说START CKPT之后已经启动事务

也有可能是它之前启动的事务，而它扫描，向前扫描呢

如果扫描的前一个START CKPT的话，那么我们知道前一个START CKPT

因为它对应的有一个END CKPT

这说明它之前的已经提交的事务，已经成功写到磁盘上去

这是没问题的，所以这样的话

我们只要扫描到前一个START CKPT就可以结束

也就说前一个START CKPT，它所包含的所有的事务有可能在后面进行提交

那么这样的话呢，我们在日志里如果碰见这样的一些事务

那么它就可以直接去进行重做就行了

那么当然呢，这些事务，比如说这个我们碰见的START CKPT这些事务

它有可能会跨越，也就说我找到这个事务

我们知道能确定这些事务在前一个START CKPT

但是呢，这个事务有可能还跨越了前面更多的一些检查点

所以这个时候有可能我们追踪的时候还要对日志扫描的更远

那么这就是redo日志

实际上呢，redo日志因为会有事务跨越多个检查点

所以有的人也提出来我可不可以把这个事务

比如说它的恢复机制呢，把undo和redo日志给它们进行一个结合

这样就是产生了一个叫做undo/redo日志的这样一种恢复

关于这个恢复呢，我就不做更多的讲解

大家可以回去结合undo日志的特点和redo日志的特点

那么来自己来自学这方面的内容

那么这个内容呢，就是一个关键的点在于什么呢

就是要提醒一下同学，就说它在因为是undo日志把它俩结合起来

实际上正好利用它俩恢复的特点，undo是对commit进行一个恢复

而redo呢，对commit进行一个重组

那么既然是这样它们如何进行结合的呢

它们基本上就是我们创建日志规则的时候

就是我这个commit可以在数据更新之前也可以在数据更新之后

然后这样的话呢，就说我如果将来以后在扫描的时候

那么我就可以充分利用undo和redo的这个特点去使用

这个呢，大家呢自己回去看我的PPT来进行

和这个我的这本高级数据库系统技术这本书大家可以来自学一下

后面我们可以来讨论

在PPT上有关于undo/redo日志的一些日志记录的一些规则

大家可以去看，好了，那么这样的话呢

关于这个基于日志的恢复这一部分呢，我们就讲这么多

那么这章呢，大家呢，主要要掌握这样几个内容

第一个就是数据库的故障以及它的一些基本恢复手段

另外一个呢，就是关于事务和日志的基本概念

主要是事务的概念，大家要理解

接下来就是重点掌握undo日志和redo日志它的恢复策略

和它的恢复机制，以及检查点使用的规则