第十章数据库恢复技术-第四、五、六、七节：数据库恢复技术和数

在这里插入图片描述

一：数据库恢复的实现技术

恢复机制涉及的两个关键点就是

如何建立冗余数据
如何利用冗余数据实现数据库恢复

其中建立冗余数据最常用的技术是

数据转储
登记日志文件

（1）数据转储（备份）

数据转储：指DBA定期手动或者DBMS定期自动将整个数据库复制到存储介质上保存起来的过程。这些备用的数据称之为后备副本。当数据库遭到破坏后可以将后备副本重新装入，但是重装后的副本只能将数据库恢复到转储时的状态，要想恢复到故障发生时的状态，必须重新运行自转储以后的所有更新事物。因此，转储常和日志配合使用

在这里插入图片描述

例如，系统在 $T_{a}$ 时刻停止运行事务，进行数据库转储，在 $T_{b}$ 时刻转储完毕，得到 $T_{b}$ 时刻的数据库一致性副本。系统运行到 $T_{f}$ 时刻发生故障。为恢复数据库，首先由数据库管理员重装数据库后备副本，将数据库恢复至 $T_{b}$ 时刻的状态，然后重新运行自 $T_{b}$ ~ $T_{f}$ 时刻的所有更新事务，这样就把数据库恢复到故障发生前的一致状态

A：转储的分类

①：按照系统是否运行事物时分类

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

优点：实现简单
缺点：转储时必须等待正在运行的用户事物结束才能进行。降低了数据库的可用性

动态转储：是指转储期间允许对数据库进行存取或修改，也即转储和用户事物可以并发执行

优点：不用等待正在运行的事物，增强了数据库的可用性
缺点：转储结束时后援副本上的数据库并不能保证正确有效

因此，对于动态转储，还需要建立日志文件（log file）。这样后备副本加上日志文件就能把数据库恢复到某一时刻的正确状态了

②：按转储的范围分类

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

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

依据上述两种分类方式，进行组合，因此共有如下四种转储在这里插入图片描述

（2）登记日志文件

日志文件：是用来记录事物对数据库更新操作的文件。主要有两种格式

以记录为单位的日志文件
以数据块为单位的日志文件

A：日志文件的内容

对于以记录为单位的日志文件

日志文件中需要登记的内容包括：

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

每个事物的开始、结束标记和每个更新操作均为一个日志记录，其内容主要包括

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

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

B：日志文件的作用

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

事务故障恢复和系统故障恢复必须用日志文件
在动态转储方式中必须建立日志文件，后备副本和日志文件结合起来才能有效地恢复数据库
在静态转储方式中也可以建立日志文件，当数据库毁坏后可重新装入后备副本把数据库恢复到转储结束时刻的正确状态，然后利用日志文件把已完成的事务进行重做处理，对故障发生时尚未完成的事务进行撤销处理。这样不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态

在这里插入图片描述针对每一种故障，日志文件的作用如下

事物故障：利用日志撤销（UNDO）未完成事物
系统故障：利用日志撤销（UNDO）未完成事物；重做（REDO）已完成事物
介质故障：利用日志和副本恢复
静态转储副本+日志恢复到故障发生前
动态转储副本+转储期间日志，可以先恢复到备份时的一致性状态，然后再利用备份后的日志还原数据

C：登记日志文件

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

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

二：恢复策略

（1）事物故障的恢复

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

反向扫描日志文件(即从最后向前扫描日志文件)，查找该事务的更新操作
对该事务的更新操作执行逆操作，即将日志记录中“更新前的值"写入数据库。这样，如果记录中是插入操作，则相当于做删除操作(因此时“更新前的值"为空);若记录中是删除操作，则做插入操作;若是修改操作，则相当于用修改前值代替修改后值
继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理
如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了

LOGFILE.seek(0,SEEK_END);
Repeat
 	LOGFILE.ReverseRead(R);
 	if R.ID=T AND R. Type=WRITE then
 	begin
 		if R.BI IS null then 执行 delete语句，删除被插入的对象
 		else if R.AI is null then 执行 insert 语句，插入被删除的对象
 		else 执行 update语句，数据对象的值从AI改回BI
 	end;
 Until R.ID=T AND R.type=STRAT;

（2）系统故障的恢复

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

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

（3）介质故障的恢复

装入最新的数据库后备副本(离故障发生时刻最近的转储副本)，使数据库恢复到最近一次转储时的一致性状态
装入相应的日志文件副本(转储结束时刻的日志文件副本)，重做已完成的事务：即首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列;然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库