数据库系统概论--（第七章）数据库恢复技术

事务处理技术。事务是一列的数据库操作，是数据库应用程序的基本逻辑单元。事务处理技术主要包括数据库恢复技术和并发控制技术。数据库恢复机制和并发控制机制是数据库管理系统的重要组成部分。

事务的基本概念

1、事物

所谓事务是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。在关系数据库中，一个事务可以是是一条SQL语句、一组SQL语句或整个程序。

事务和程序是两个概念。一般的讲，一个程序包含多个事务。

事务的开始与结束可以由用户显式控制。如果用户没有显式地定义事务，则由数据库管理系统按默认规定自动划分事务。在SQL中，定义事务的语句一般有三条：

Begin transaction；//开始事务

Commit； //执行成功，提交

Rollback； //执行失败，回滚

事务通常是以 Begin transaction开始，以Commit或Rollback结束。

Commit表示提交，即提交事务的所有操作。具体地说就是将事务中所有对数据库的更新写回到磁盘上的物理数据库中去，事务正常结束。

Rollback表示回滚，即在事务运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库的所有已完成的操作全部撤销，回滚到事务开始时的状态。这里的操作是指对数据库的更新操作。

2、事务的特性

事务具有四个特性：原子性、一致性、隔离性、持续性。

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

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

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

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

数据库的恢复概述

尽管数据库系统中采取了各种措施来防止数据库的安全性和完整性被破坏，保证并发事务的正确执行，但是计算机系统中硬件的故障、软件的错误、操作员的失误以及恶意的破坏仍是不可避免的，这些故障轻则造成运行事务非正常中断，影响数据库中数据的正确性，重则破坏数据库，使数据库中全部或者部分数据丢失。因此数据库管理系统必须具有把数据库从错误状态恢复到某一已知正确状态（亦称为一致状态或完整状态）的功能，这就是数据库的恢复。恢复子系统是数据库管理系统的一个重要组成组分，而且相当庞大，常常占整个系统代码的10%以上。数据库管理系统所采用的恢复技术是否行之有效，不仅对系统的可靠程度起着决定性作用，而且对系统的运行效率也有很大的影响，是衡量系统性能优劣的重要指标。

故障的种类

1、事务内部的故障

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

【例】银行转账事务，这个事务把一笔金额从一个账户甲转给另一个账户乙。

begin transaction
    读账户甲的余额balance;
    balance=balance-amount;  /*amount为转账金额*/
    if(balance<amount)then
    {
        打印‘金额不足，不能转账’
        rollback;
    }
    else
    {
        读账户乙的余额balance1;
        balance1=balance1+amount;
        写回banlance1;
        commit;
    }

这个例子所包含的两个更新操作要么全部完成，要么全部不做，否则就会使数据库处于一个不一致状态，例如可能出现只把账户甲的余额减少而没有把账户乙的余额增加的情况。

在这段程序中若产生账户甲余额不足的情况，应用程序可以发现并让事务回滚，撤销已作的修改，恢复数据库到正确状态。

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

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

2、系统故障

系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。。例如，特定类型的硬件错误（CPU故障）、操作系统故障、DBMS代码错误，系统断电等。这类故障影响正在运行的所有事务，但是不破坏数据库。此时主存的内容，尤其是数据库缓冲区（在内存）中的内容都被丢失，所有运行事务都非正常终止。发生系统故障时，一些尚未完成的事务的结果可能已经送入物理数据库，从而造成数据库可能处于不正确的状态。为保证数据的一致性，需要清除这些事务对数据库所有的修改。

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

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

3、介质故障

系统故障常称为软故障，介质故障称为硬故障。硬故障指外存故障，如磁盘损坏、磁头碰撞、瞬时强磁场干扰等。这类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务。这类故障发生的可能性小得多，但破坏性最大。

4、计算机病毒

计算机病毒是一种人为的故障或破坏，是一些恶作剧者研制的一种计算机程序。这种程序与其他程序不同，它向微生物所称的病毒一样可以繁殖和传播，并造成对计算机系统包括数据库的危害。

总结各类故障对数据库的影响有两种可能性，一是数据库本身被破坏，二是数据库没有被破坏但是数据可能不正确，这是事务的运行被非正常终止造成的。

恢复的基本原理十分简单。可以用一个词概括：冗余。这就是说，数据库中任何一部分被破坏或不正确的数据可以根据存储在系统别处的冗余数据来重建。尽管恢复的原理十分简单，但实现技术的细节却相当复杂。

恢复的实现技术

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

建立冗余数据最常用的技术是数据转储和登记日志文件。通常在一个数据库系统中，这两种方法是一起实现的。

数据转储（备份）

数据转储是数据库恢复中采用的基础技术。所谓转储就是数据库管理员定期的将整个数据库复制到磁带、磁盘或其他存储介质上保存起来的过程。这些备份数据称为后备副本或后援副本。

当数据库遭到破坏后可以将后备版本重新装入，但重装后备版本只能将数据库恢复到转储时的状态。

【例】转储和恢复

 系统在Ta时刻停止运行事务，进行数据转储，在Tb时刻转储完毕，得到Tb时刻的数据库一致性副本。系统运行到Tf时刻发生故障。为恢复数据，首先由数据库管理员重装数据库后背版本，将数据库恢复至Tb时刻的状态，重新运行自Tb~Tf时刻的所有更新事务，这样就把数据库恢复到故障发生前的一致状态。

转储是十分耗费时间和资源的，不能频繁进行。数据库管理员应该根据数据库使用情况确定一个适当的转储周期。

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

静态转储是系统在无运行事务时进行的转储操作，即转储操作开始的时刻数据库处于一致性状态，而转储期间不允许对数据库的任何存取、修改活动。显然，静态转储得到的一定是一个数据一致性副本。

静态转储简单，但转储必须等待正运行的用户事务结束才能进行。同样，新的事物必须等待转储结束才能执行，显然这会降低数据库的可用性。

动态转储是指转储期间允许对数据库进行存取或修改，即转储和用户事务并发执行。动态转储可以克服静态转储的缺点，它不用等待正在运行的用户事物结束，也不会影响新事物的执行。但是转储结束时后援版本上的数据并不能保证正确有效。

为此，必须把转储期间各事物对数据库的修改活动登记下来，建立日志文件。这样，后援版本加上日志文件就能把数据库恢复到某一时刻的正确状态。

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

数据转储分类

转储方式	转储状态
	动态转储	静态转储
海量转储	动态海量转储	静态海量转储
增量转储	动态增量转储	静态增量转储

登记日志文件

1、日志文件的格式和内容

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

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

• 各个事务的开始（begintransaction）标记
• 各个事务的结束（commit或rollback）标记
• 各个事务的所有的更新操作

这里每个事务的开始标记、每个事务的结束标记和每个更新操作均作为日志文件的一个日志记录（log record）

每个日志记录的内容主要包括： 

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

对于以数据块为单位的日志文件，日志记录的内容包括事务标识和被更新的数据块。由于将更新前的整个块和更新后的整个块存放入日志文件中，操作类型和操作对象等信息就不用放入日志记录中了。

2、日志文件的作用

日志文件在数据库恢复中起着非常重要的作用，可以用来进行事务故障的恢复和系统故障的恢复，并协助后备副本进行介质故障恢复，具体作用是：

1. 事务故障恢复和系统故障恢复必须用日志文件。
2. 在动态转储方式中必须建立日志文件，后背副本和日志文件结合起来才能有效的恢复数据库。
3. 在静态转储方式中也可以建立日志文件，当数据库毁坏后可重新装入后援副本把数据库恢复到转储结束时刻的正确状态，然后利用日志文件把已完成的事务进行重做处理，对故障发生时为完成的事务进行撤销处理。

利用日志文件恢复

 3、登记日志文件

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

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

恢复策略

事务故障的恢复

事务故障是指事务在运行至正常终止点前被终止，这时恢复子系统应利用应利用日志文件撤销此事务对数据库进行的修改。事务故障的恢复是由系统自动完成的。，对用户是透明的。系统恢复的步骤是：

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

系统故障的恢复

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

系统故障的恢复是由系统在重新启动时自动完成的，不需要用户的干预。

系统恢复的步骤是：

1. 正向扫描日志文件，找出故障发生时已经提交的事务（这些事务既有begin transaction记录，也有commit 记录），将其事务标识记入重做队列（redo-list）。同时找出故障发生时尚未完成的事务（这些事务只有begin transaction记录，无相应的commit记录），将其事务标识记入撤销队列（undo-list）
2. 对撤销队列中的各个事务进行撤销（undo）处理：进行撤销的方法是反向扫描日志文件，对每个撤销事务的更新操作进行逆操作，即将日志记录中“更新前的值”写入数据库。
3. 对重做队列中的各个事务进行重做处理：进行重做的方法是正向扫描日志文件，对每个事务重新执行日志文件登记的操作，即将日志记录中“更新后的值”写入数据库。

介质故障的恢复

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

装入最新的数据库后备副本（离故障发生时刻最近的转储版本），使数据库恢复到最近一次转储时的一致性状态。

对于动态转储的数据库副本，还需要同时装入转储开始时刻的日志文件副本，利用恢复系统的故障的方法（redo+undo）才能将数据库恢复到一致性状态。

装入相应的日志文件副本（转储结束时刻的日志文件副本），重做已完成的事务。

这样就可以将数据库恢复至故障前某一时刻的一致性状态。

介质故障的恢复需要数据库管理员介入，但数据库管理员只需要重装最近转储的数据库副本和有关的各种日志文件副本，然后执行系统提供的恢复命令即可，具体的恢复操作仍由数据库管理系统完成。

具有检查点的恢复技术

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

检查点记录的内容包括：

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

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

具有检查点的日志文件和重新开始文件

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

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

恢复子系统可以定期或者不定期的建立检查点，保存数据库状态。检查点可以按照预定的时间间隔建立，如每隔一个小时建立一个检查点；也可以按照某种规则建立检查点，如日志文件已写满一半建立一个检查点。

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

恢复子系统采取的不同策略

T1：在检查点之前提交。

T2：在检查点之前开始执行，在检查点之后，故障点之前提交。

T3：在检查点之前开始执行，在故障点时还未完成。

T4：在检查点之后开始执行，在故障点之前提交

T5：在检查点之后开始执行，在故障点时还未完成

T3和T5在故障发生时还未完成，所以予以撤销操作，T2和T4在检查点之后提交，他们对数据库所作的修改在故障发生时可能还在缓冲区中，尚未写入数据库，所以要重做；T1在检查点之前提交所以不必执行重做操作。