一：数据库恢复的实现技术
恢复机制涉及的两个关键点就是
- 如何建立冗余数据
- 如何利用冗余数据实现数据库恢复
其中建立冗余数据最常用的技术是
- 数据转储
- 登记日志文件
（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）介质故障的恢复
- 装入最新的数据库后备副本(离故障发生时刻最近的转储副本)，使数据库恢复 到最近一次转储时的一致性状态
- 装入相应的日志文件副本(转储结束时刻的日志文件副本)，重做已完成的事务：即首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列;然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库
三：具有检查点的恢复技术
（1）一个问题
利用日志技术进行数据库恢复时，恢复子系统必须搜索日志，确定哪些事务需要重做，哪些事务需要撤销。一般来说，需要检查所有日志记录。这样做有两个问题
- 搜索整个日志将耗费大量的时间
- 很多需要重做处理的事务实际上已经将它们的更新操作结果写到了数据库中，然而恢复子系统又重新执行了这些操作，浪费了大量时间
为了解决这些问题，引入具有检查点的恢复技术
（2）概述
具有检查点的恢复技术：这种技术在日志文件中增加了一类新的记录——检查点记录，增加一个重新开始文件，并让恢复子系统在登录日志文件期间动态维护日志。检查点记录内容包括
- 建立检查点时刻所有正在执行的事物清单
- 这些事物最近一个日志记录的地址
其中重新开始文件用来记录各个检查点记录在日志文件中的地址
动态维护日志文件的方法：周期性地执行建立检查点、保存数据库状态的操作。具体步骤为：
- 将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上
- 在日志文件中写入一个检查点记录
- 将当前数据库缓冲区的所有数据记录写入磁盘的数据库中
- 把检查点记录在日志文件中的地址写入一个重新开始文件
使用检查点方法可以改善恢复效率。当事务T在一个检查点之前提交，T对数据库所做的修改一定都已写入数据库，写入时间是在这个检查点建立之前或在这个检查点建立之时。这样，在进行恢复处理时，没有必要对事务T执行重做操作。
（3）利用检查点的恢复技术
系统出现故障时，恢复子系统将根据事务的不同状态采取不同的恢复策略，如下图
- \(T_{1}\)：在检查点之前提交
- \(T_{2}\)：在检查点之前开始执行，在检查点之后故障点之前提交
- \(T_{3}\)：在检查点之前开始执行，在故障点时还未完成
- \(T_{4}\)：在检查点之后开始执行，在故障点之前提交
- \(T_{5}\)：在检查点之后开始执行，在故障点时还未完成
- \(T_{3}\)和\(T_{5}\)在故障发生时还未完成，所以予以撤销;
- \(T_{2}\)和 \(T_{4}\)在检查点之后才提交，它们对数据库所做的修改在故障发生时可能还在缓冲区中，尚未写入数据库，所以要重做;
- \(T_{1}\)在检查点之前已提交，所以不必执行重做操作
系统使用检查点方法进行恢复的步骤是：
①：从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录
②：由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST。建立如下两个事物队列
UNDO-LIST：需要执行UNDO操作的事物集合REDO-LIST：需要执行REDO操作的事物集合
③：从检查点开始正向扫描日志文件
- 如果有新开始的事物\(T_{i}\)，则把\(T_{i}\)暂时放入
UNDO-LIST - 如果有新提交的事物\(T_{j}\)，则把\(T_{j}\)从
UNDO-LIST移到REDO-LIST - 重复，直到扫描日志文件结束
④：对UNDO-LIST中的每个事物执行UNDO操作；对REDO-LIST中每个事物执行REDO操作
用上图所示的例子，恢复步骤如下
①：建立ACTIVE-LIST，很明显ACTIVE-LIST={\(T_{2}\),\(T_{3}\)}。然后初始化UNDO-LIST={\(T_{2}\),\(T_{3}\)}，REDO-LIST={}
②：从检查点开始正向扫描日志文件
- 第一个读到的是事物\(T_{4}\)建立，加入
UNDO-LIST - 第二个读到的是事物\(T_{2}\)提交，那么把\(T_{2}\)从
UNDO-LIST移动到REDO-LIST - 第三个读到的是事物\(T_{5}\)建立，加入
UNDO-LIST - 第四个读到的是事物\(T_{5}\)提交，那么把\(T_{5}\)从
UNDO-LIST移动到REDO-LIST
③：对UNDO-LIST中的每个事物执行UNDO操作；对REDO-LIST中每个事物执行REDO操作
四：数据库镜像
数据库镜像：自动地将整个数据库或其中关键数据复制到另一个磁盘上。需要注意，在实际应用中，只对关键数据和日志文件进行镜像，而不是对整个数据库进行镜像
- 用于数据库恢复：当出现介质故障时，可由镜像磁盘继续提供使用，同时DBMS自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本
- 提高数据库可用性：在没有出现故障时，当一个用户对某个数据加排他锁进行修改时，其他用户可以读镜像数据库的数据，而不必等待该用户释放锁
