事务处理

1数据库的恢复技术 (2)

1.1 事务的基本概念 (2)

1.2 恢复引论 (3)

1.2.1单纯以后备副本为基础的恢复技术 (4)

1.2.2以后备副本和运行记录为基础的恢复技术 (4)

1.2.3基于多副本的恢复技术 (5)

1.3 运行记录的结构 (6)

1.4 更新事务的处理与恢复 (7)

1.5 易地更新恢复技术 (9)

1.6 消息处理 (9)

1.7 失效的类型及恢复对策 (10)

1.7.1事务失效 (10)

1.7.2系统失效 (10)

1.7.3介质失效 (11)

1数据库的恢复技术

1.1 事务的基本概念

一．事务(Transaction)

事务反映现实世界中需要以完整单位提交的一项工作，也就是一个完整的工作单元，它必须完整地执行，或者全都不执行。数据库中的事务实质上用户定义的一个数据库操作序列，其中的每个操作都要执行，或者都不执行。即事务是DBMS中的执行单位。例如：假设银行中某客户有两个帐户，一个是储蓄帐户，另一个是支票帐户。储蓄帐户的余额是50000元，支票帐户的余额是300元，现在从储蓄帐户中提取一万元，存入支票帐户。设储蓄帐户的余额为D，支票帐户的余额为C。根据银行转账业务规则，必须将D减去10000元，再将C加上10000元。这个事务将使数据库从一个一致性状态（D是50000元，C是300元）达到另一个一致性状态（D是40000元，C是10300元），即该客户的两个帐户的余额和不变。

事务处理的实例图

此例中储蓄账户余额减去10000元和支票帐户余额增加10000元必须全部执行，或者全部不执行。否则，该客户将白白损失10000元，或者银行白白损失10000元。储蓄账户余额减去10000元和支票帐户余额增加10000元是一个完整的逻辑单元即事务。

在关系数据库中，一个事务可以是一条SQL语句，也可以是一组SQL语句。用户可以下面的方式显式定义事务：

BEGIN TRANSACTION

∶

∶

SQL语句

∶

∶

COMMIT/ROLLBACK

其中：BEGIN TRANSACTION为事务的开始，COMMIT或ROLLBACK为事务的结束。COMMIT表示事务正常结束，叫作提交，即提交事务的所有操作。具体说就是把事务中所有对数据库的更新写回到磁盘上的物理数据库中。ROLLBACK表示事务中止，叫作回滚。即在事务执行过程中发生了某种故障，事务不能继续执行，或者人为的中止事务执行。回滚将全部撤销事务对数据库所作操作，将数据库恢复到事务开始时的状态。

二．事务的特性

事务具有以下四个特性：

1．原子性(Atomic)

事务是一个完整的工作单位，事务对数据库的所有操作要么全做，要么全部做(All or Nothing)。

2．一致性(Consistency)

事务将数据库从一个一致性状态转换到另一个一致性状态。所谓数据库的一致性状态是指数据库中的数据满足完整性约束。

3．隔离性(Isolation)

若多个事务顺序执行，即一个事务完全结束后，另一个事务方可开始执行，事务的这种执行方式称为串行访问(Serial Access)或串行执行(Serial Excute)；若多个事务在时间上重叠执行，事务的这种执行方式称为并发访问(Concurrent Access)或并发执行(Concurrent Excute)。在单CPU系统中，同一时间只能有一个事务占有CPU，多个事务交叉(轮流)占有CPU，这种并发访问的方式称为交叉并发(Interleaved Concurrency)；在多CPU系统中，多个事务同时占有CPU，这种并发访问的方式称为同时并发(Simultaneous Concurrency)。

所谓事务的隔离性就是：多个事务并发执行时，彼此独立，互不影响。事务的这种特性是靠后面将要讨论的并发控制来保证的。

4．持久性(Durability)

持久性也称永久性(Permanence)，是指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的，其后的任何操作或故障都不应对此事务的执行结果有任何影响。

事务的以上四个特性也简称为ACID特性。

如前所述，事务是DBMS中的执行单位，事务应满足ACID准则。不但在系统正常时，事务要满足ACID准则，在系统发生故障时也要满足ACID准则；不但在单事务执行时要满足ACID准则，在事务并发执行时也要满足ACID准则。保证事务在故障时满足ACID准则的技术称为恢复；保证事务在并发执行时满足ACID准则的技术称为并发控制。恢复和并发控制是保证事务正确执行的两项基本措施，它们合称为事务管理（transaction management）。

1.2 恢复引论

数据对一个单位是至关重要的。数据库的失效常常导致一个单位的瘫痪。任何系统总不可能不出故障。数据库系统对付故障无非用两手措施：一手是尽可能提高系统的可靠性；另一手是在系统发生故障后，把数据库恢复至一致状态。单靠第一手是不够的，必须要有第二手措施。提高系统可靠性的技术在其他课程中已有论述，本书主要讨论发生故障后恢复数据库为一致状态的技术，即恢复技术。

系统中的硬、软件故障（fault）常常表现为某种差错（error），差错常常导致数据库的失效（failure）。也就是故障是起因，差错是现象，失效是后果。在现代计算机中，差错是可以检测的。一旦检测出差错，数据库系统可以采取相应的恢复措施。系统发生故障时，可能导致数据的丢失（loss）。要恢复丢失的数据，数据必须有后备的副本。对于恢复，数据冗余是必需的。

恢复技术大致分为下列3种。

1.2.1单纯以后备副本为基础的恢复技术

这是从文件系统继承过来的恢复技术，即周期性地把磁盘上的数据库转储（dump）到磁带上。由于磁带脱机存放，可以不受系统故障的影响。转储到磁带上的数据库副本称为后备副本。数据库的数据量一般比较大，取一次后备副本很费时间，且取后备副本时，数据库的状态一般须冻结，这也很影响数据库的正常工作。所以取数据库的后备副本不能太频繁，一般利用周末、夜间等数据库比较空闲的时间进行。从图7－l可见，当数据库失效时，可取最近的后备副本来恢复数据库。很显然，用这种方法，数据库只能恢复到最近后备副本的一致状态，从最近后备副本至发生故障期间所有数据库的更新将会丢失。取后备副本的周期愈长，丢失的数据更新也愈多。

图7-1利用后备副本恢复数据库

数据库中的数据一般只部分更新，很少全部更新。如果只转储其修改过的物理块，则转储的数据量显著减少，转储不必费时过多，转储的频率可以增加，从而可以减少发生故障时的数据更新丢失。这种转储称为增量转储（incremental dumping，简称ID）。例如，一个数据库系统每周取一次后备副本，则在最坏情况下，可能丢失一周的数据更新。如果除了每周取一次后备副本，每天还取一次ID，则至多丢失一天的数据更新。由图7-2可见。当数据失效时，可取出最近的后备副本，并用其后的一系列ID，把数据库恢复至最近ID的数据库状态。很显然，这要比恢复到最近后备副本所丢失的数据更新要少。

图7-2利用增量转储减少数据更新丢失

以后备副本为基础的恢复技术实现起来很简单，不增加数据库正常运行时的开销，其缺点是不能恢复到数据库的最近一致状态。这种恢复技术在文件系统中用得较多，在数据库系统中只用于小型的和不重要的数据库系统。

1.2.2以后备副本和运行记录为基础的恢复技术

运行记录(log 或journal)是供恢复用的数据库运行情况的记录。它一般包括下列3个内容。

前像

当数据库被一个事务更新时，所涉及的物理块更新前的映像（image）称为该事务的前

像（before image，简称BI）。前像以物理块为单位。有了前像，如果需要，可以使数据库恢复到更新前的状态，即撤消更新，这种操作在恢复技术中称为撤消（undo）。

●后像

当数据库被一个事务更新时，所涉及的物理块更新后的映像称为该事务的后像（after image，简称AI）。后像也以物理块为单位。有了后像，即使更新的数据丢失了，仍可以使数据库恢复到更新后的状态，相当于重做一次更新，这种操作在恢复技术中称为重做（redo）。

●事务状态

记录每个事务的状态，以便在恢复时做不同的处理。每个事务从交付DBMS到结束为止，其状态的变迁如图7－3所示。每个事务有两种可能的结局：一是经提交（Commit）而结束，这标志着事务已成功地执行（这相当于all），只有在事务提交后，事务对数据库的更新才能被其它事务访问；另一种结局是由于事务本身或外部的原因，事务失败，要消除事务对数据库的影响（这相当于nothing）。对事务的这种处理称为回滚（rollback）。对恢复来说，当然不必要记下图7－3的每个状态，但是至少要区分出一个事务是提交的，还是未提交的。

基于后备副本与运行记录的恢复如图7－4所示。当数据库失效时，可取出最近后备副本，然后根据运行记录，对未提交的事务用前像回滚，这叫向后恢复（backward recovery）；对已提交的事务，必要时用后像重做、这叫向前恢复（forward recovery）。用这种恢复技术，必须有运行记录，既花费较大的存储空间，又要影响数据库正常工作的性能。尽管如此，由于这种恢复技术可使数据库恢复至最近的一致状态，在数据库系统中用得最多，大部分商品化的DBMS都支持这种恢复技术。

图7-3事务状态迁移图

图7-4基于后备副本和运行记录的恢复

1.2.3基于多副本的恢复技术

如果系统中有多个数据库副本，而且这些副本具有独立的失效模式（independent failure

mode），则可利用这些副本互为备份，从于恢复。所谓独立失效模式是指各个副本不致因同一故障而一起失效。为了获得独立失效模式，各副本的支撑环境要尽可能地独立，例如不共用电源、磁盘、控制器、CPU等。基于多副本的恢复技术在分布式数据库系统中用得比较多。因为在分布式数据库系统中，有时出于性能或其他考虑，在不同的结点上设有数据副本，而且这些数据副本由于处于不同的结点，其失效模式也比较独立。近来由于硬件价格下降，在一些可靠性要求高的系统中，采用镜像磁盘（mirrored disks）技术（见图7－5），即数据库以双副本的形式存于两个独立的磁盘系统中。为使失效模式独立，两个磁盘系统有各自的控制器和CPU，但彼此可以互相切换。在读数时，可以选读其中任一磁盘；在写数时，两个磁盘都写入同样的内容。当一个磁盘中的数据丢失时，可用另一个磁盘的数据来恢复。”

下面主要讨论第二种恢复技术。

1.3 运行记录的结构

运行记录保持恢复所必需的数据。如果运行记录丢失了，则数据库将无法恢复。运行记录一般不能和数据库放在同一磁盘上，以免在磁盘损坏时，两者同归于尽。如果由于条件限制，运行记录和数据库不得不放在同一磁盘上，则应经常把运行记录复制到磁带上，以免在磁盘发生故障时“全军覆没”。有时除了在磁带上保留运行记录副本外，还在不同的磁盘上设置双副本甚至三副本。运行记录的结构因DBMS而异。为了比较具体地介绍恢复技术，下面列出运行记录中的一些基本内容，实际DBMS的运行记录还可能包含若干其它细节，具体结构也不一定相同。

1．活动事务表

活动事务表（active transaction list，简称A TL）记录所有正在执行，尚未提交的事务的标识符（transaction identifier，简称TID）。

2．提交事务表

提交事务表（committed transaction list，简称CTL）记录所有已提交的事务的标识符。

在提交时，应先将要提交的TID列入提交事务表，然后再从活动事务表删除该TID。如果先从活动事务表中删除TID，再将TID加入提交事务表，则可能冒如下的危险：即TID 刚从活动事务表中删除后，系统发生故障，该事务的状态在系统中将无任何记录。

3．前像文件

前像文件可以看成一个堆文件，每个物理块有个块标识符（block identifier，简称BID）。设BID由TID、关系名和逻辑块号所组成，其中TID表示执行更新操作的事务，关系名表示被更新的关系，逻辑块号表示该块是关系中哪块的前像。逻辑块号在关系中是唯一的，即使一个块被删除了，它的逻辑块号也不允许重新使用。如果一个关系需要回滚，可从前像文件中找出该事务的所有前像块，按照逻辑块号写入关系的对应块中，从而消除该事务对数据库所产生的影响。必须注意：undo操作是满足幂等（idempotent）性的，即

undo（undo（undo…（x）））=undo（x）

因此，即使数据库中的某块还没有来得及更新，在恢复时对它做一次undo操作也无妨，无非在这一块上写入同样的内容而已。

4．后像文件

结构与前像文件相仿，不过其中记的是后像。在恢复时，可按提交事务表中的事务次序，按逻辑块号写入其后像。这相当于按提交的次序，重做各个事务。redo操作也满足幂等性，即

redo（redo（redo…（x）））=redo（x）

即使某块的内容没有丢失，对它做一次redo操作也无妨。

运行记录是累积的，很费存储空间。在取后备副本后，以前的运行记录就失去价值。对恢复来说，只要保留最近后备副本以后的运行记录。即使如此，对大数据库，运行记录还是可观的。为此，可以采取下列措施。

不保留已提交事务的前像

对于已提交的事务，只可能做redo操作，不会再去做undo操作，前像可以不再保留。有选择性地保留后像

当更新的内容写人数据库后，只要磁盘不出故障，后像可以不再保留。由于磁盘发生故障的概率比较小，而且不是所有数据在发生故障时都要求恢复到最近的一致状态。在有些DBMS（例如ORACLE）中，允许用户作出是否保留后像的选择。若不保留后像，不但可以节省运行记录的空间，也可以提高事务执行的速度。

合并后像

对于给定逻辑号的物理块，如果多次更新，只要保留最近的后像即可。

1.4 更新事务的处理与恢复

更新事务在执行时应遵守下列2条规则。

一．提交规则（commit rule）

后像必须在事务提交前写入不易失存储器（即数据库或运行记录）中。

根据ACID准则，提交的事务对数据库所产生的影响应是持久的，后像只有写入不易失存储器才能有持久性。但提交规则并不要求后像一定在事务提交前写入数据库。如果后像已经写入运行记录，即使还未写入数据库或未完全写人数据库，事务仍可提交。待事务提交后，再继续写入数据库。在此期间，如果发生故障，可用运行记录的后像重做；若有其它事务访问这些数据，由于更新的内容在未写入数据库前，仍在缓冲块中，其他事务可从缓冲块访问更新后的内容。

二．先记后写规则（log ahead rule）

如果后像在事务提交前写入数据库，则必须把前像首先记入运行记录。

事务在提交前，都有可能失败。事务失败后，须撤消事务对数据库所做的一切更新。为此，必须在改动数据库前，先把前像记入运行记录。也就是先要把老的内容“留底”，才能写入新的内容。

在执行更新事务时，按照后像写入数据库的时间的不同，可有3种可能的方案，兹分别讨论如下。

1．后像在事务提交前完全写入数据库

其步骤如下：

（1）TID→A TL

（2）BI→log ／*先记后写规则*／

（3）AI→DB ／*在提交前，后像完全写入DB，满足提交规则*／

（4）TID→CTL

（5）从ATL删除TID

当事务执行过程中发生故障时，可以根据ATL和CTL中是否有该事务的TID，分别采取不同的恢复措施（见表7－l）。

2．后像在事务提交后才写入数据库

其步骤如下：

（1）TID →A TL

（2）AI →log ／*提交规则*／

（3）TID →CTL

（4）AI →DB

（5）从ATL 删除TID

因为后像在事务提交前未写人数据库，根据先记后写原则，不必记入前像。在不同情况下应采取的恢复措施见表7－2。

3．后像在事务提交后写入数据库

其步骤如下：

（1）TID →A TL

（2）AI ，BI →log ／*提交规则及先记后写规则*／

（3）AI →DB （部分写入）

（4） TID →CTL

（5） AI →DB （继续完成）

（6）从ATL 删除TID

在发生故障时，恢复措施见表7－3。

表7－3

表7－4

是这3种方案的比较。

在表7－4中，方案1似乎不需要AI，这是在数据库本身未遭损坏的前提下所得的结论。如果考虑到存储介质的故障，只有靠AI才能恢复数据库至最近一致状态。因此，一般来说AI对每种方案都是需要的。

在上面3种方案中，总要进行redo或undo，或兼而有之。有无既不要redo，也不要undo 的方案？在数据库的原地更新（update on place）情况下，undo或redo操作是不可避免的。因为恢复不外乎恢复到更新前的状态或是更新后的状态，undo、redo是必需的操作。如果数据库易地更新（update out of place），即在更新时，原来的数据库内容不被重写（overwrite）掉，而另找一个地方写入新的内容，则可免除redo或undo操作，这是下一节将要讨论的内容。

1.5 易地更新恢复技术

1.6 消息处理

一个事务常常要给用户发送消息（message），告知用户事务的执行情况或要求用户做某些动作。如前所举的拨款的例子中，就有“A款不足”和“拨款完成”两个消息，分别用于不能拨款和拨款完成两种情况。发送消息也是事务执行结果的一部分，应该遵守“要么不做，要么全做”的原则。但是消息和数据不同，在很多情况下很难用undo操作来消除其影响。例如，通知出纳员付款或是通知操作员单击按钮等消息，在发出后将产生不能挽回的后果，这些后果显然是不能用undo操作来消除的。因此，在事务结束（包括提交和回滚）前，消息是不能发出的。既然消息要等事务结束后才能发出，事务本身显然不能承担发送消息的任务，必须委托第三者执行。这正像一个人的遗嘱不能由本人执行，而须委托第三者执行一样。发送消息一般委托系统进行，例如委托一个叫做消息管理（message manager，简称MM）的子系统来执行。事务执行时可把消息送给MM，MM为每个事务建立一个消息队列（见图7－9）。图7－9消息队列当事务正常结束时（包括提交和程序中预先设置的回滚），事务通知MM发送消息。当事务因故障或其他不可预知的原因而夭折时，MM在恢复时将把该事务的消息丢弃，以消除该事务的影响。

图7－9 图7－10

MM对事务委托发送的消息，在事务正常结束前，允许事务增加和删除；一旦事务结束，MM就把消息队列存于不易失存储器中，以防止因故障而丢失。为了保证消息可靠地发送给有关用户，MM采用“发送一确认”方式传送（见图7－10）。当消息送出后，超过一定时间仍未收到确认信号，MM便再发送一次，直到收到确认信号为止。有时终端收到了消息，可是因某些故障而发不出确认信号，致使MM重复地发送同一消息。为了防止消息重复，消息可以编号，当终端重复收到同一编号的消息时，可不予理睬。

图7．10消息的传送在本节中、所谓“消息”仅指事务经预先安排拟发给用户的消息，不包括事务执行过程中由系统发给用户的消息，例如语法错、未经授权等。这些消息可以随时发送，不必等到事务结束。

1.7 失效的类型及恢复对策

一个恢复方法的恢复能力总是有限的，一般只对某些类型的失效有用。在任何情况下都适用的恢复方法是没有的。在前述的恢复方法中，都需要后备副本。如果后备副本由于不可抗拒的灾害而损害，则前述的恢复方法将无能为力。通常的恢复方法都是针对概率较高的失效，这些失效可分为下列3类。

1.7.1事务失效

事务失效(Transaction Failure)指事务因不可预知的原因而夭折。

●事务因无法执行而自行夭折

例如，数据库中没有要访问的数据，输入数据类型不对，除数为零等。

●操作员因操作错误或改变主意而要求撤消事务

例如，本来应拨款给张三，在输入时错成李四了，只有撤消事务。

●由于系统调度上的原因而中止某些事务的执行

例如，系统发生死锁，必须中止一些事务才能解除。

事务失效是经常发生的，DBMS应该对事务失效提供有效的恢复措施。事务失效一定发生在事务提交之前。事务一旦提交，即使要撤消也不可能了。对事务失效，一般采取下列恢复措施：

●MM丢弃该事务的消息队列；

●如果需要，进行undo操作；

●从ATL删除该事务的TID，释放该事务所占的资源。

1.7.2系统失效

系统（包括操作系统和DBMS）崩溃，须重新启动（Restart），内存的数据可能丢失，而数据库中的数据未遭破坏。可能的原因有：

●掉电；

●除数据库存储介质故障以外的硬、软件故障。

系统失效（system failure）虽不如事务失效那样经常，但发生的可能性还是很大的。对于系统失效，一般须采取下列恢复措施：

●重新启动操作系统和DBMS；

●恢复数据库至一致状态（对未提交的事务进行undo操作，对已提交的事务进行redo

操作）

只有数据库恢复至一致性状态，才允许用户访问数据库。

未提交的事务在系统中是有限的，所以恢复时，undo的工作量不会太大；但已提交的事务是大量的，由于不能肯定其后像是否完全写入数据库，只得都进行redo，这是很费时的操作。为了减少恢复时redo的工作量，在运行过程中DBMS一般每隔一定的间隔在运行记录中设置一个检查点(Check Point,简称CP)。在检查点，DBMS强制写入所有已提交事务的后像(见图7-11)。很显然，在最近检查点以前提交的事务，恢复时无需redo。检查点的时间间隔可作为参数设置，该参数再DBMS初始化时设置，并可在运行时调整。取CP的一般过程如下：

●暂停事务的执行

●写入上一个CP以后所提交事务留在内存中的后像

●在运行记录的提交事务表中记下检查点

●恢复事务的执行

取CP很影响数据库的正常运行，而它只有在发生系统失效时，才能发挥其减少redo 工作的效益。因此，有些DBMS建议用户在数据库忙碌时少设检查点。

图7-11

1.7.3介质失效

介质失效（media failure）指磁盘发生故障，数据库受损，如划盘，磁头破损等。

在正常情况下，介质失效应该是很少的。在有些简易的DBMS中只提供基于后备副本的恢复手段，而不要求在介质失效时，把数据库恢复到最近的一致性状态。在现代DBMS 中，对介质失效一般都提供恢复数据库至最近一致状态的恢复措施，具体恢复过程如下：

●修复系统，必要时更换磁盘；

●如系统崩溃(OS和DBMS)，重新启动系统；

●加载最近的后备副本；

●用运行记录中的后像，重做取最近后备副本以后提交的事务。

从介质失效中恢复数据库是很费时的，而且要求运行记录提供取最近后备副本后提交的所有事务的后像，数据量也是很大的。简易DBMS很难支持这样的恢复手段，但对于重要的、大型的数据库系统，为了保证数据安全，这些代价是必须付出的。