数据库系统概论-系统篇-数据库恢复技术|Bobby Blog

事务的基本概念

事务

事务是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。

在关系数据库中，一个事务可以是一条SQL语句，一组SQL语句或整个程序。

事务的开始与结束可以由用户显示控制。如果用户没有显示定义事务，则由数据库管理系统按默认规定自动划分事务。

事务通常是以START TRANSACTION开始，以COMMIT或ROLLBACK结束。COMMIT表示提交，提交事务的所有操作；ROLLBACK表示回滚，系统将事务中对数据库所有已完成的操作全部撤销，回滚到事务开始时的状态。

事务的ACID特性

事务具有4个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持续性（Durability）。

（1）原子性：事务是数据库逻辑工作单位，事务中包括的操作要么都做，要么都不做。

（2）一致性：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。当数据库只包含成功事物提交的结果时，就说数据库处于一个一致性状态。如果数据库运行中发生故障，有些事务尚未完成就被迫中断；这些未完成事务对数据库所做的修改有一部分已经写入物理数据库，这时数据库就处于一种不正确的状态。

（3）隔离性：一个事务的执行不能被其他事务干扰。一个事务的内部操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰。

（4）持续性：持续性也称永久性，指一个事务一旦提交，它对数据库的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。

事务是恢复和并发控制的基本单位。

保证事务ACID特性是事务管理的重要任务。破坏ACID特性的因素有：

多个事务并行运行时，不同事务的操作交叉执行。（数据库管理系统必须保证多个事务的交叉运行不影响这些事务的原子性）
事务在运行过程中被强行停止。（数据库管理系统必须保证被强行终止的事务对数据库和其他事务没有任何影响）

数据库恢复概述

故障是不可避免的

计算机硬件故障
软件的错误
操作员的失误
恶意的破坏

故障的影响

运行事务非正常中断，影响数据库中数据的正确性
破坏数据库，全部或部分丢失数据

数据库的恢复

数据库管理系统必须具有把数据库从错误状态恢复到某一已知的正确状态的功能，这就是数据库的恢复管理系统对故障的对策

恢复子系统是数据库管理系统的一个重要组成部分。

恢复技术是衡量系统优劣的重要指标。

故障的种类

数据库系统中可能发生各种各样的故障，大致可以分为以下几类。

事务内部的故障

有的是可以通过事务程序本身发现的，有的是非预期的，不能由事务程序处理的。

对于事务程序本身发现的，我们可以程序内部通过ROLLBACK进行回滚。

事务内部更多的故障是非预期的，不能由应用程序处理的。如运算溢出、并发事务发生死锁而被选中撤销该事务、违反某些完整性限制而被终止等。后面事务故障仅指这类非预期的故障。

事务故障意味着事务没有达到预期的终点（COMMIT或ROLLBACK），数据库可能处于不正确状态。恢复程序要在不影响其他事务运行的情况下，强行回滚该事务，即撤销改事务已经做出的任何对数据库的修改，使得该事务好像根本没有启动一样。这类恢复操作称为事务撤销（UNDO）。

系统故障

称为软故障，是指造成系统停止运转的任何事件，使得系统要重新启动。例如，特定类型硬件错误（CPU故障）、操作系统故障、系统断电等。这类故障影响正在运行的所有事务，但不破坏数据库。所有正在运行的事务都非正常终止，内存中的数据缓冲区的信息全部丢失。发生系统故障时，一些尚未完成的事务的结果可能已经送入物理数据库，造成数据库可能处于不正确状态。

恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚，强行撤销所有未完成的事务。

发生系统故障时，有些已完成的事务可能有一部分甚至全部留在缓冲区，尚未写回到磁盘上的物理数据库中，系统故障使得这些事务对数据库的修改部分或全部丢失。因此应将这些事务已提交的结果重新写入数据库。所以系统重新启动后，恢复子系统除需要撤销所有未完成的事务，还需要**重做（REDO）**所有已经提交的事务，已将数据库真正恢复到一致状态。

介质故障

称为硬故障，指外存故障；如磁盘损坏、磁头碰撞等。这类故障破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务。这类故障比前两类故障发生的可能性小得多，但破坏性最大。

计算机病毒

一种人为的故障或破坏。

各类故障总结

各类故障对数据库的影响有两种可能性

一是数据库本身被破坏
二是数据库没有被破坏，但数据可能不正确，这是由于事务的运行被非正常终止造成的

恢复的基本原理就是冗余，利用存储在系统别处的冗余数据来重建数据库中已被破坏或不正确的那部分数据。尽管原理简单，但是实现起来相当复杂。

恢复的实现技术

恢复机制涉及两个关键问题是：如何建立冗余数据，以及如何利用这些冗余数据实施数据恢复。

建立冗余数据最常用的技术是数据转储和登记日志文件。

数据转储

转储是指数据库管理员定期地将整个数据库复制到磁盘或其他存储介质上保存起来的过程。这些备用数据称为后备副本（backup）或后援副本。

当数据库遭到破坏后可以将后备副本重新装入，但重装后备副本只能将数据库恢复到转储时的状态，要想恢复到故障发生时的状态，必须重新运行自转储以后的所有更新事务。

转储可以分为静态转储和动态转储。

静态转储是在系统中无运行事务时进行的转储操作。转储开始时数据库处于一致性状态，转储期间不允许对数据库的任何存取、修改活动，得到的一定是一个数据一致性的副本。优点简单，缺点是降低了数据库的可用性。
动态转储是指转储操作与用户事务并发进行，转储期间允许对数据库进行存取或修改。优点是不用等待正在运行的用户事务结束，不会影响新事务的运行。缺点是不能保证副本中的数据正确有效。为此，需要把动态转储期间各事务对数据库的修改活动登记下来，建立日志文件，后备副本加上日志文件就能把数据库恢复到某一时刻的正确状态。

转储还可以分为海量转储和增量转储。海量转储每次转储全部数据库。增量转储只转储上次转储后更新过的数据。从恢复角度看，使用海量转储得到的后备副本进行恢复往往更方便。如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效。

登记日志文件

日志文件的格式和内容

日志文件(log file) 是用来记录事务对数据库的更新操作的文件。不同DBMS采用的日志文件格式并不完全一样。概括起来主要分为两种格式：以记录为单位的日志文件，以数据块为单位的日志文件。

以记录为单位的日志文件需要登记的内容包括：

各个事务的开始标记(START TRANSACTION）
各个事务的结束标记(COMMIT 或ROLLBACK）
各个事务的所有更新操作

以上均作为日志文件中的一个日志记录 (log record)。每个记录的主要内容包括：

事务标识（标明是哪个事务）
操作类型（插入、删除或修改）
操作对象（记录内部标识）
更新前数据的旧值（对插入操作而言，此项为空值）
更新后数据的新值（对删除操作而言, 此项为空值）

以数据块为单位的日志文件包括：

事务标识
被更新的数据块

日志文件的作用

可以用来进行事务故障恢复和系统故障恢复，并协助后备副本进行介质故障恢复。具体作用是：

事务故障恢复和系统故障恢复必须用日志文件
在动态转储方式中必须建立日志文件，后备副本和日志文件结合起来才能有效地恢复数据库
在静态转储方式中，也可以建立日志文件，故障恢复时重新装入后援副本把数据库恢复到转储时刻的正确状态，然后利用日志文件，重做已完成事务，撤销未完成的事务。

登记日志文件

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

登记的次序严格按并发事务执行的时间次序
必须先写日志文件，后写数据库

恢复策略

当系统运行过程中发生故障，利用数据库后备副本和日志文件可以将数据库恢复到故障前的某个一致性状态。不同故障其恢复策略和方法也不一样。

事务故障的恢复

事务在运行至正常终止点前被终止，由恢复子系统利用日志文件撤消（UNDO ）此事务已对数据库进行的修改。事务故障的恢复由系统自动完成，对用户是透明的，不需要用户干预。其步骤是：

反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。
对该事务的更新操作执行逆操作。即将日志记录中“更新前的值” 写入数据库。
继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。

系统故障的恢复

系统故障造成数据库不一致状态的原因有两个，一是未完成事务对数据库的更新可能已写入数据库，二是已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库。恢复操作就是撤销未完成的事务，重做已完成的事务。系统故障恢复是由系统在重启时自动完成的，不需要用户干预，步骤是：

正向扫描日志文件（即从头扫描日志文件），找出在故障发生前已经提交的事务（既有START TRANSACTION 记录，也有COMMIT 记录），将其事务标识记入重做队列（REDO-LIST）。找出故障发生时未完成的事务（只有START TRANSACTION 记录，无相应的COMMIT 记录），将其事务标识记入撤销队列（UNDO-LIST）。
对撤销(UNDO) 队列事务进行撤销(UNDO) 处理。反向扫描日志文件，对每个撤销事务的更新操作执行逆操作，即将日志记录中“更新前的值” 写入数据库。
对重做(REDO) 队列事务进行重做(REDO) 处理。正向扫描日志文件，对每个重做事务重新执行登记的操作，即将日志记录中“更新后的值”写入数据库。

介质故障的恢复

发生介质故障后，磁盘上的物理数据和日志文件被破坏，恢复方法是重装数据库，然后重做已完成的事务。步骤：

装入最新的后备数据库副本( 离故障发生时刻最近的转储副本) ，使数据库恢复到最近一次转储时的一致性状态。对于静态转储的数据库副本，装入后数据库即处于一致性状态。对于动态转储的数据库副本，还须同时装入转储时刻的日志文件副本，利用恢复系统故障的方法（即REDO+UNDO ），才能将数据库恢复到一致性状态。
装入有关的日志文件副本( 转储结束时刻的日志文件副本) ，重做已完成的事务。首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。

介质故障的恢复需要数据库管理员介入，数据库管理员的工作：

重装最近转储的数据库副本和有关的各日志文件副本
执行系统提供的恢复命令

具体的恢复操作仍由数据库管理系统完成

具有检查点的恢复技术

利用日志文件进行数据库恢复时，一般来说，需要检查所有日志记录。这样做有两个问题，一是搜索整个日志将耗费大量的时间，二是很多需要重做处理的事务时间上已经将它们的更新操作结果写到了数据库中，恢复子系统重新执行这些操作，浪费大量时间。解决这些问题，在日志文件中增加一类新的记录——检查点记录，增加重新开始文件，并让恢复子系统在登录日志文件期间动态地维护日志。

检查点记录内容包括：

建立检查点时刻所有正在执行的事务清单
这些事务最近一个日志记录的地址

重新开始文件用来记录各个检查点记录在日志文件中的地址。

动态维护日志文件的方法是，周期性地执行建立检查点、保存数据库状态的操作。具体步骤是：

将当前日志上缓冲区中的所有日志记录写入磁盘的日志文件上
在日志文件中写入一个检查点记录
将当前数据中缓冲区的所有数据记录写入磁盘的数据库中
把检查点记录在日志文件中的地址写入一个重新开始文件

恢复子系统可以定期或不定期地建立检查点, 保存数据库状态。可以按照时间间隔建立，也可以按照日志文件写了多少建立。

使用检查点方法可以改善恢复效率。当事务T在一个检查点之前提交，T对数据库所做的修改已写入数据库，写入时间是在这个检查点建立之前或在这个检查点建立之时。在进行恢复处理时，没有必要对事务T执行重做操作。当事务T在检查点时还没有完成，T对数据库所做的修改已写入数据库，在进行恢复处理时，如果需要重做T ，重做的起始点是检查点。

系统出现故障时，恢复子系统将根据事务的不同状态采取不同的恢复策略。

使用检查点进行恢复的步骤是：

从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录
由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST。这里建立两个事务队列：UNDO-LIST和REDO-LIST。把ACTIVE-LIST暂时放入UNDO-LIST 队列，REDO队列暂为空。
从检查点开始正向扫描日志文件，如有新开始的事务Ti，把Ti暂时放入UNDO-LIST 队列；如有提交的事务Tj ，把Tj从UNDO-LIST队列移到REDO-LIST 队列; 直到日志文件结束。
对UNDO-LIST中的每个事务执行UNDO 操作，对REDO-LIST中的每个事务执行REDO 操作。