数据库恢复技术

1、事务

1.1概念

事务指的是满足 ACID 特性的一组操作，可以通过 Commit 提交一个事务，也可以使用 Rollback 进行回滚。

SQL中，定义事务的语句一般有三条：

BEGIN TRANSACTION; # 表示事务开始
COMMIT;            # 表示提交，即提交事务的所有操作
ROLLBACK;          # 表示回滚，若事务运行过程中发生了某种故障，事务不能继续执行，系统将对事务中已完成的操作进行撤销，这里的操作指的是对数据库的跟新操作。

 

1、ACID特性

1. 原子性（Atomicity）

事务被视为不可分割的最小单元，事务的所有操作要么全部提交成功，要么全部失败回滚。

2、一致性（Consistency）

数据库在事务执行前后都保持一致性状态。在一致性状态下，所有事务对一个数据的读取结果都是相同的。因此，当数据库只包含成功事务提交的结果时，数据库就处于一致性状态。而当未完成事务对数据库所做修改有一部分已写入物理数据库，则数据库就处于不一致的状态，即中间态。例如：账户A向账户B转1万元，某个时刻，事务执行到数据库中A账户减少1万元，B账户还未增加1万元， 则数据库就处于不一致状态。

3、隔离性（Isolation）

一个事务所做的修改在最终提交以前，对其它事务是不可见的。即一个事务的内部操作及使用的数据对其它并发事务是隔离的。

4、持久性（Durability)

一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢失,使用重做日志来保证持久性。

2、故障

2.1 事务内部故障

先看一个银行转账的事务：

BEGIN TRANSACTION
    读账户A的余额BALANCE    
    BALANCE = BALANCE - AMOUNT;    /*AMOUNT 为转账金额*/
    IF(BALANCE < 0)THEN
    {
        打印'金额不足，不能转账';    /*事务内部可能造成事务被回滚的情况*/
        ROLLBACK;                  /*撤销刚才的修改，恢复事务*/
    }
    ELSE
    {
        读账户B的余额BALANCE1；
        BALANCE1 = BALANCE1 + AMOUNT;
        写回BALANCE1;
        COMMIT;                    /*提交事务*/
    }
    
            

事务内部的故障有的可以通过事务程序本身发现并处理的，如例子中的余额不足的故障。但大多事务内部故障是不可预期的，如上面例子余额的运算发生溢出等。

2.2 非事务故障

1）系统故障（软故障）

系统故障是指造成系统停止运转的任何时间，使得系统需要重新启动。例如：CPU故障、操作系统故障、DBMS故障、系统断电等；系统故障造成数据库不一致状态的原因有两个：一是未完成事务对数据的更新操作可能已写入数据库；二是已提交事务对数据库的更新操作可能还留在缓冲区没来得及写入数据库。

（注意：事务完成是指事务提交成功，并不是数据已成功写入物理数据库，数据可能还在数据缓冲区）

2）介质故障（硬故障）

硬故障指外存故障。例如磁盘损坏、强磁场干扰等；

3）计算机病毒（人为）

发生故障需要进行恢复，原理一个词：冗余

3、恢复的实现技术

3.1 数据转储

所谓转储就是定期地对数据库进行备份。转储技术只能将数据库恢复到转储时的状态，且转储是十分耗费时间和资源的。

静态转储：转储期间不允许对数据库进行任何存取修改活动。

动态转储：转储期间允许数据库进行存取和修改。但不能保证转储结束时后援副本的数据正确有效。因此，可借助日志文件对转储期间的事务活动进行记录。恢复时利用后援副本与日志文件就能把数据库恢复到某一时刻的正确状态。

海量转储：每次转储全部数据库。

增量转储：每次转储只转储上一次转储后更新过的数据。

3.2日志文件

1、日志文件时用来记录事务对数据路的更新操作的文件。

格式有两种：以记录为单位的日志文件和以数据块为单位的日志文件。

以记录格式的日志文件为例，日志文件中的记录类型包括：

• 各个事务的开始标记
• 各个事务的结束标记
• 各个事务的所有更新操作标记

上述三种内容每个为一种日志记录，每个日志记录的内容包括 ：

• 事务标识（类似于学号之于学生）
• 操作类型（insert、update、delete等）
• 操作对象
• 更新前的数据旧值（对insert操作而言为NULL）
• 更新后的数据新值（对delete操作而言为NULL）

2、 未保证数据库是可恢复的，登记日志文件时必须遵守两条原则：

• 登记次序严格按照并发事务执行的时间次序
• 必须先写日志文件厚些数据库（重点理解）

4、恢复策略

4.1事务故障恢复策略

事务故障的恢复时有系统自动完成的，对用户是透明。恢复步骤为：

1）反向扫描日志文件，查找该事务的更新操作（通过事务标识查找）

2）对事物的更新操作执行逆操作。例如：若操作类型为insert,则恢复就进行delete操作，反之则进行insert操作；若操作类型为update，则使用更新前的旧值替代更新后的新值。

3) 从当前日志记录开始，重复1）与2），当读该事务的开始标记时，该事务故障的恢复就完成了。

4.2系统故障的恢复

系统故障造成数据库不一致状态的原因有两个：一是未完成事务对数据的更新操作可能已写入数据库；二是已提交事务对数据库的更新操作可能还留在缓冲区没来得及写入数据库。因此恢复操作有两步：撤销系统故障发生时未完成的事务，重做已完成事务。

系统故障的恢复是由系统自动完成的，对用户是透明。恢复步骤为：

1)正向扫描日志文件，找出既有 BEGIN TRANSACTION记录，也有COMMIT记录的事务，将其事务标识放入重做队列（REDO_LIST）；同时找出只有BEGIN TRANSACTION 记录的事务，将其事务标识放入撤销队列（UNDO_LIST）。

2）对撤销队列中的各个事务进行撤销处理。单个事务撤销步骤同4.1

3）对重做队列中的各个事务进行重做。即正向扫描日志文件，对每个重做事务重新执行日志文件登记的操作，即将日志文件记录中“更新后的值”写入数据库。

4.3 介质故障的恢复

介质故障是最严重的的一种故障。需要数据管理员介入，借助后援副本和响应日志文件恢复整个数据库。方法是重装数据库，然后重做已完成的事务。

1）装入离故障发生时刻最近的静态转储副本，若为动态转储，还需装入对应转储期间的日志文件，运用系统故障恢复方法（REDO_LIST && UNDO_LIST）将数据库恢复到一致性状态。

2）装入转储结束时刻至故障发生时刻的日志文件副本，对该日志文件同样运用系统故障恢复方法。

5、具有检查点的恢复技术

日志恢复技术一般需要检查所有日志文件。这样做有两个问题：一是搜索日志文件耗时较大；二是（针对系统故障）存在很多不必要的重做操作。例如：系统故障并不会影响物理数据库数据，只需重做提交成功但数据滞留在缓冲区的事务，而对于提交且写入数据库成功的事务，日志恢复技术也会进行重做。

1、检查点记录包含的内容有：

建立检查点时刻所有正在执行的事务清单；

2、通过检查点技术动态维护日志文件，维护步骤为：（周期性建立检查点，周期根据实际应用而定即可）

1）将当前缓冲区中的所有记录写入日志文件中

2）写检查点周期到来，在日志文件写入该检查点记录；

3）将当前数据缓冲区的所有数据记录写入物理磁盘；

4）将该检查点记录写入重新开始文件。

（重点：检查点记录写入重新开始文件前当前数据缓冲区的所有数据写入物理磁盘，这是保证该检查点之前不会出现已提交事务的数据还未写入物理数据库的情况，因此检查点恢复时对检查点之前的已提交事务不必进行重写，这也是检查点技术快与日志文件技术的原因）

3、系统使用检查点技术进行恢复的步骤：

1)从重新开始文件找到最后一个检查点记录在日志文件中的地址，由该地址找到日志文件中的最后一个检查点记录；

2）通过该检查点找到检查点建立时刻所有事务清单：以该检查点为起点，对日志文件进行正向扫描，进行重做操作和撤销操作即可。（具体方法同前UNDO_LIST和REDO_LIST)

（检查点恢复技术的意义在于找到一个在保证数据库一致性和正确性的前提下最适宜的扫描起点（最后一个检查点），从而省略了该起点前面的已提交事务无谓的重做操作）