数据库事务处理技术——故障恢复

1. 数据故障恢复的宏观思路

我们知道DBMS是利用内存（主存）和外存（辅存）这样的存储体系进行数据库的管理，其中内存也就是我们常说的缓存是易失的。而事务时DBMS对数据库进行控制的基本单元，宏观上是由程序设置的一条或者多条SQL语句的一次执行；微观上是对数据元素的一系列基本操作，如读写等，需要提交（commit）和撤销（abort）。事务满足ACID特性，而故障恢复设计的是如何保证原子性和持久性，即故障恢复需要把DB由当前的不正确状态恢复到已知为正确的某一状态，要保证已经commit的事务要保持持久性，确保其保存到我们的外存永久存储介质上；未完成的事务为了保持一致性，恢复其至未事务开始前的状态。

**原子性：**事务的所有操作，要么全都执行，要么全都不执行。

**持久性：**提交的事务对数据库产生的影响是持久的，未提交的事务对数据库不应有影响。

注：DBMS中故障恢复程序约占10%。

实际遇到的故障类型及影响如下表所示。

|------|-----------------------|-----------------------------------------|
| 故障类型 | 故障原因 | 影响范围 |
| 事务故障 | 某一个程序（事务）自身运行错误所引起的故障 | 影响该程序（事务）本身 |
| 系统故障 | 掉电、非正常关机等所引起的故障 | 影响正在运行的事务以及数据库缓冲区，数据库缓冲区将涉及正在运行和已经运行的事务 |
| 介质故障 | 由于介质损害等所引起的故障 | 影响是全面的，既影响内存中的数据，又影响介质中的存储数据 |

1.1 事务故障恢复思路

事务故障可通过重做事务（Redo）和撤销事务（Undo）来恢复。重做事务可保证提交事务的持久性，而撤销事务则消除未提交事务的影响

1.2 系统故障恢复思路

系统故障可通过运行日志（System Log）进行恢复。

运行日志是DBMS维护的一个文件，该文件以流水方式（速度很快） 记录了每一个事务对数据库的每一次操作及顺序。当事务对数据库进行操作时：先写运行日志；写成功后，再将缓冲区信息刷到外存即磁盘上。当发生系统故障时，我们可以根据运行日志记录的事务操作顺序重做事务（当事务在发生故障时已经正确结束）或撤销事务（当事务在发生故障时未结束），但是这样我们遇到了一个问题，运行日志可能保留了很久的记录，我们应道从哪一个点开始恢复呢，为了解决该问题，提出了检查点（checkpoint）机制 ，检查点是这样的时刻：在该时刻，DBMS强制使内存DB Buffer中的内容与介质DB的内容保持一致。

进行系统故障恢复时：

检查点之前结束的事务不需要处理（已经写回DB介质）；

检查点之后结束或发生的事务需要依据运行日志进行恢复（不能确定是否写回DB）：故障点前结束的重做，故障点时刻未结束的撤销。

1.3 介质故障恢复思路

由于介质故障影响是全面的，发生该故障时首先需要用转储点的副本替换破坏的数据库，然后再根据运行日志进行恢复。

1.4 小结

2. 什么是日志

2.1 日志

日志是一个包含日志记录的只能追加的顺序文件夹，不同事务的日志交错存储，按发生时间存储。

发生系统故障时，使用日志进行恢复：

故障时已提交的事务，重做（Redo）

故障时未提交的事务，撤销（Undo）

日志涉及到设计元素和事务。

2.2 缓冲区策略

日志类型和缓冲区的策略相关，为了确定应何时将内存中的更改刷宝到磁盘上，数据库定义了steal/no-steal和force/no-force缓冲区策略。

缓冲区的处理策略主要有如下几种：根据是否允许在commit之前把内存中的数据写入磁盘中，分为 Steal / No steal策略；根据是否要求在commit点及之前将数据写入磁盘中，分为Force / No force 处理策略。

|--------------|-----------------------------------------------------------------------------------------|
| Force | 内存中的数据最晚在commit 的时候写入磁盘 |
| No force | 内存中的数据可以一直保留，在commit之后 过一段时间再写入磁盘。（此时在系统崩溃的时候可能还没写入到磁盘，需要Redo）--灵活 |
| Steal | 允许在事务commit之前 把内存中的数据写入磁盘。（此时若系统在commit之前崩溃时，已经有数据写入到磁盘了，要恢复到崩溃前的状态，需要Undo）--灵活 |
| No steal | 不允许 在事务commit之前把内存中的数据写入磁盘。 |