数据库中日志问题详解

核心提示： 简单概括，undo日志系统顺序如下：1) 指明所改变数据库元素的日志记录2) 改变的数据库元素自身3) COMMIT日志记录，数据库中日志问题详解(2)，3.应用对于前面所举的例子(A转帐50元给B帐号)，如果使用了undo日志系统，数据库状态就可能不一致，这时候，则相关的工作流程如表2如

简单概括，undo日志系统顺序如下：

1) 指明所改变数据库元素的日志记录

2) 改变的数据库元素自身

3) COMMIT日志记录。

3.应用

对于前面所举的例子(A转帐50元给B帐号)，如果使用了undo日志系统，则相关的工作流程如表2如下。

我们可以看到FLUSH LOG这个命令。该命令的用于强制将还没有刷盘日志记录写到磁盘上。对于步骤8执行之前，三个undo记录(,,)是存储在缓冲区中的(这样描述是为将问题简单化)，执行步骤8之后，三条undo记录便写入了磁盘日志文件。在步骤12再次执行FLUSH LOG命令时，只将未刷盘的日志记录写入磁盘。

步骤9、10，在前面已经描述过，是将数据库元素的修改从缓冲区写入到磁盘文件，因为WRITE操作仅仅是将修改反应到缓冲区中(这样描述也是为了将问题简单化)。

关注步骤8，执行完步骤8之后，将满足undo的规则1(如果事务T改变了数据库元素X，那么形如的日志记录必须在X的新值写到磁盘前写到磁盘)。在我们真正将数据库元素A与B的修改反应到磁盘前，我们已经将它们对应的与写入到磁盘日志文件。

关注步骤11与步骤12，执行它们将满足undo的规则2(如果事务提交，则其COMMIT日志记录必须在事务改变的所有数据库元素已写到磁盘后再写到磁盘，但应尽快)。我们已经将数据库元素A与B的修改反应到磁盘上，接着可以写入来表示事务T的成功执行，但是该日志记录还在缓冲区中，所以我们在步骤12执行FLUSH LOG进行日志刷盘。

4.使用undo日志进行数据库的恢复

现在假设系统故障发生了。有可能给定事务的某些数据库更新已经写到磁盘上，而同一事务的另外一些更新尚未到达磁盘。如果这样，事务的执行就不是原子的，数据库状态就可能不一致。这时候，我们就有必要使用日志将数据库恢复到一致的状态。