1 前言

尽管计算机系统的可靠性在不断提高，数据库系统中也采用了很多措施和方法保证数据库系统的正确运行，但仍不可避免系统出现这样或那样的错误，导致数据库数据丢失或破坏。

所以，数据库系统必须采取相应的恢复措施，把数据库系统从故障状态恢复到一个已知的正确状态，这就是本文要谈的数据库的故障恢复机制。

本文主要从理论的角度介绍数据库系统的故障恢复相关概念，文章将先介绍数据库系统的故障类型，然后介绍对应不同故障类型数据库系统的恢复策略。通过阅读文章，希望大家能够对数据库系统的故障恢复有一定理论层面的了解。另外，本文只介绍集中式数据库的故障恢复相关概念，关于分布式数据库系统的故障恢复涉及到的内容较多，也更复杂，本文暂不涉及。

2 故障类型

数据库系统的恢复机制是针对任何可能出现的故障提供相应的恢复策略，所以再谈具体的恢复策略之前，让我们先来看看数据库系统可能出现的故障类型。

先以一张图来说明数据库系统中的故障类型，如下图所示：

数据库系统故障类型

下面具体说明各类故障类型。

1.事务内部的故障

事务内部的故障可细分为可预期的和不可预期的。可预期的事务故障是指故障的发生可以通过事务程序本身来检测。例如，在业务中，我们可以在转账前先检查转账后账户的余额是否小于零，若发现不足，则由程序主动废弃该事务，撤销已做的修改，恢复数据库到正确状态。相反地，不可预期的事务故障是指故障的发生不能被应用程序所检测并处理。例如，并发事务发生死锁、算术溢出、操作员失误等故障都是不可预期的事务故障，这类故障无法由程序本身所预测。

事务内部的故障大多数都是不可预期的，发生这类故障的事务将不能正常运行到其终点位置（Commit或Abort）。因此，针对这类故障，数据库恢复机制要强行废弃该事务，使数据库回滚到事务执行前的状态。

2.系统故障

系统故障的表现形式是系统停止运转，必须经过重启后系统才能恢复正常。例如，CPU故障、系统死循环、缓冲区溢出、系统断电等故障均为系统故障。这类故障的特点是：仅使正在运行的事务受到影响，但数据库本身没有被破坏。此时，内存中的数据全部丢失。一方面，一些尚未完成的事务的结果可能已写入数据库中；另一方面，一些已提交的事务的结果可能还未来得及更新到磁盘上（读到这里相信大家能够联想到Mysql数据库对应的刷盘机制）。这样，故障发生后数据库可能处于不一致的状态。

对于系统故障，数据库恢复机制要在系统重启后，将所有非正常终止的事务强行废弃，同时将已经提交的事务的结果重新更新到数据库中，以保证数据库的正确性。

3.存储介质故障

存储介质故障是指存储数据的磁盘等硬件设备发生的故障。这类故障的特点是：不仅使正在运行的所有事务受到影响，而且数据库本身也被破坏。因此，此类故障是较为严重的故障。

对于此类故障，我们只能借助定期的备份数据库和日志文件，来进行故障恢复。

综上所述，数据库系统中的故障可归纳为两大类：硬故障和软故障。硬故障通常是永久的，不能自动恢复的，如存储介质故障（不包括使用RAID可以修复的介质故障）。这种故障对于数据库系统来说通常是致命的，应尽力避免。软故障通常是临时性或间歇性的，如事务内部的故障、系统故障等，对于分布式数据库系统来说，还有通信故障，如网络分割故障、报文丢失故障，软故障多是由于系统不稳定造成的，比较容易恢复，如系统可通过恢复机制进行恢复或重新启动事务恢复。系统中大多数的故障都是软故障。

3 故障恢复策略

在介绍了数据库系统中的故障类型后，我们继续讲解数据系统针对不同故障类型的恢复策略。

在故障恢复过程中，数据库恢复管理器依据数据库日志文件对数据库事务进行恢复操作。本节先介绍数据库的日志文件，然后介绍反做（undo）和重做（redo），最后介绍针对不同故障的恢复策略。

3.1 数据库日志文件

事务是数据库系统的基本运行单位。一个事务对数据库的更新操作的执行过程如下图所示：

数据库更新操作的执行过程

一般一个事务的完成，不仅仅是操作序列的执行，还必须将事务执行信息（尤其是更新操作）写入日志文件。这样，在故障发生的时候，系统的恢复机制可以根据日志中的信息对系统进行恢复，保证数据库状态的正确性，维护系统的一致性。因此，数据库日志文件是用来保存恢复信息的数据文件。

那么，日志中一般都记录什么信息呢？日志中一般会记录事务标识符、操作类型（插入、删除或修改）、操作的数据项、数据项的旧值与新值、命令（Begin、Abort、Commit）等信息，有的日志中还会包含检查点信息，检查点是在日志中周期设定的操作标志，用来减少系统故障后的恢复工作量的。

3.2 反做和重做恢复策略

反做（undo）和重做（redo）相信对熟悉数据库的同学来说已经是耳熟能详的概念了。它们俩是数据库恢复过程中采用的两个典型的恢复策略，下面将分别介绍它们。在介绍它们之前，先介绍一个概念：外存数据库。外存数据库是指存在于硬盘上的数据库。修改的数据写到外存数据库是指该数据具有永久性。这个概念会在介绍它们的过程中用到。

1.反做

反做也称撤销，是将一个数据项的值恢复到其修改之前的值，即事务的回滚。当一个事务尚未提交时，如果缓冲区管理器允许该事务修改过的数据写到外存数据库（这里涉及到数据库的刷盘策略），一旦此事务出现故障需要废弃时，就需对这个事务修改过的数据项进行反做，即根据日志文件将其恢复到修改之前的值。反做的目的是保持数据库的原子性。

2.重做

重做是将一个数据项的值恢复到其修改后的值，即恢复一个事务的操作结果。当一个事务提交时，如果缓冲区管理器允许该事务修改过的数据不立刻写到外存数据库（也就是当前的修改结果还在内存中，这时发生故障内存中的数据便会丢失，实际结果还没有持久化到数据库，也涉及到数据库的刷盘策略），一旦此事务出现故障，需对被这个事务修改过的数据项进行重做，即根据日志文件将其恢复到修改后的值。重做的目的是保持数据库的耐久性。

如果在进行反做/重做的过程中又发生了故障，则要重新进行反做处理，所以反做/重做需要有幂等性。

系统的故障恢复是以日志文件为基础完成的，因此，要求事务在执行过程中满足先写日志协议（WAL）：

• 在外存数据库更新之前，应将日志文件中有关数据项的反做信息写入外存文件。
• 事务提交之前，日志文件中的有关数据项的重做信息应在外存数据库更新之前写入外存文件。

3.3 故障恢复策略

在介绍了数据库系统恢复涉及到的数据库日志、反做和重做策略概念后，我们最后看看针对软故障和硬故障，数据库系统相应的故障恢复模策略。

1.软故障的恢复策略

当软故障发生时，造成数据库不一致状态的原因包括：

（1）一些未完成事务对数据库的更新已写入外存数据库；

（2）一些已提交事务对数据库的更新还没来得及写入外存数据库。

因此，针对这两类原因，我们数据库系统对应的故障恢复操作为反做和重做。

2.硬故障的恢复策略

硬故障的主要恢复措施是进行数据转储和建立日志文件。

首先，我们要定期将数据库转储到其他磁盘，形成一系列备份数据库，当数据库被破坏，则可以将这些副本重新导入到数据库中，使数据库恢复到数据转储时的状态，接下来，利用日志文件重新运行转储以后的所有更新事务，将数据库进一步恢复到故障发生时的状态。这也就是我们常说的全量与增量备份。

4 总结

本文主要讲解了数据库系统的关于事务恢复的相关概念，先是介绍了相应的故障类型，包括软故障与硬故障，然后介绍了数据库系统的恢复策略，主要是通过数据库日志文件、反做与重做来进行故障恢复。关于数据库系统的恢复相关概念就介绍到这里，希望能够对大家有所帮助。

5 参考文献

[1] 萨师煊，王珊编. 数据库系统概述[M]. 4版. 北京：高教出版社，2006.5.

[2] 郑振楣，于戈，郭敏. 分布式数据库[M]. 北京：科学出版社，1998.