11数据库的恢复技术

一、数据库恢复概述

1.故障类型

• 事务故障：
  是指某个事务在运行过程中由于种种原因未能运行到正常终止而夭折

有两种错误可能导致事务执行失败
①事务程序的逻辑错误
例如，事务内部的非法输入、溢出、超出资源限制等
②系统错误，系统进入一种不良状态（如死锁），使得事务无法继续正常执行。但该事务可以在以后的某个时间重新执行

• 系统故障：
• 是指由于某种原因造成整个系统的正常运行突然停止，致使所有正在运行的事务都以非正常方式终止

造成系统故障的原因：
例如，CPU故障
数据库软件代码错误
操作系统故障
系统断电

• 介质故障：
  是指存储数据库的存储设备故障，数据库数据的传输过程中，由于磁头损坏或故障造成磁盘块上的内容丢失。

介质故障可用其它磁盘上的数据副本，或三级介质（如磁带）上的归档备份进行相应数据的恢复
这类故障比前两类故障发生的可能小，但破坏性更大

2.故障恢复的思想

不同的故障恢复技术不同，但是它们的基本思想是一样的：
在系统正常运行时建立冗余数据，保证有足够的信息可用于故障恢复
故障发生后采取措施，将数据库内容恢复到某个一致性状态，保证事务原子性和持久性

数据库系统主要通过登记日志和数据转储来建立冗余数据 日志记录了数据库的所有更新的详细信息，所有故障的恢复都需要使用它
数据转储制作数据库的后备副本，这些副本与日志配合使用，用来实现介质故障恢复 数据库镜像在不同的存储介质上维护数据库的同步副本，也是建立冗余数据的一种方法 使用数据库镜像可以简化介质故障的恢复，但需要附加的存储设备

二、存储器结构

数据库的存储设备按存取速度、容量和故障可恢复性可分为如下三种： 1．易失性存储器(volatile storage)：内存、高速缓存
2．非易失性存储器（nonvolatile storage）：磁盘、磁带 3．稳定存储器(stable storage)
是一种理想的存储器，其中的信息永不丢失 “永不”是相对的，从理论来说是无法保证的
尽管理论上不能得到稳定存储器，但可以使用技术手段使得非易失性存储器中的信息极不可能丢失，来逼近稳定存储器

三、基于日志的恢复技术

1.日志

日志是日志记录的序列，记录了数据库中所有的更新活动。
日志登记了每个事务的开始标记、结束标记和所有更新操作，事务结束可能是正常提交（commit），也可能是异常中止（abort，事务的更新可能是插入、删除和修改 。

一条更新日志记录记录了一个事务对数据库的一次write操作，它包括如下信息： 事务标识符：执行更新操作的事务的惟一标识符
操作类型：指明更新是插入、删除，还是修改 操作对象：被更新的数据对象的惟一标识，通常是数据对象在磁盘上的位置
旧值：数据对象更新前的值。对插入操作而言，此项为空 新值：数据对象更新后的值。对删除操作而言，此项为空

日志登记必须要遵守以下两条原则：

1. 日志记录必须严格按并发事务执行的时间次序登记
2. 必须先记日志，后写数据库；也就是说，在每次事务执行write操作之前，必须在数据库被更新前建立该write操作的日志记录

redo(Ti)就是根据日志记录，按登记日志的次序，将事务Ti每次更新的数据对象的新值用write操作重新写到数据库中，redo(Ti)执行多次等价于执行一次
undo(Ti)是根据日志记录，按登记日志的相反次序，将事务Ti每次更新的数据对象的旧值用write操作写回数据库
与redo一样，undo(Ti)执行多次等价于执行一次

2.延迟更新技术

延迟更新：指的是将事务对数据库的更新推迟到事务提交之后。
在每个事务执行期间，用日志记录该事务对数据库的所有更新操作，并把所有数据库更新操作推迟到该事务提交后执行 。

延迟更新技术必须遵循如下更新协议：
（1）每个事务在到达提交点之前不能更新数据库
（2）在一个事务的所有更新操作的日志记录写入稳定存储器之前，该事务不能到达提交点

事务故障恢复
对于延迟更新，当事务Ti发生故障时， Ti未到达提交点，因此Ti的更新操作都登记在日志中，而并未输出到数据库
因此，当事务Ti发生故障时，只需要清除日志中事务Ti的日志记录，而无须对数据库本身做进一步处理。如果故障不是Ti自身的逻辑错误，则事务Ti可以在稍后重新启动

系统故障恢复过程如下：
1．正向扫描日志文件，建立两个事务列表。一个是已提交事务列表，包含所有具有日志记录< Ti, commit>的事务Ti ；另一个表是未提交事务列表，包括所有具有日志记录< Tj, start>，但不具有日志记录< Tj, commit>的事务Tj
2．对已提交事务列表中的每个事务Ti执行redo(Ti)：正向扫描日志文件，对于每个形如< Ti, Xj, V1, V2 >的日志记录，如果Ti在已提交事务列表中，则将Xj = V2写到数据库中

3.即使更新技术

即时更新技术允许事务在活跃状态时就将更新输出到数据库中。
处于活动状态的事务直接在数据库上实施的更新称为非提交更新。
即时更新必须遵循如下规则 ：
在日志记录< Ti, Xj, V1, V2 >安全地输出到稳定存储器之前，事务Ti不能用Xj = V2更新数据库
在所有< Ti, Xj, V1, V2 >类型日志记录安全地输出到稳定存储器之前，不允许事务Ti提交

事务故障恢复
不同于延迟更新，事务Ti发生故障时，它可能已经将某些更新输出到数据库。因此，必须执行undo(Ti)。即恢复子系统自动进行如下处理：
反向扫描日志文件直到遇到< Ti, start>，对于每个形如<Ti, Xj, V1, V2 >的日志记录，将Xj = V1写到数据库中

基于即时更新技术的系统故障恢复过程如下：
1．正向扫描日志文件，建立两个事务列表：
一个是已提交事务列表，包含所有具有日志记录< Ti, commit>的事务Ti
另一个是未提交事务列表，包括所有具有日志记录< Tj, start>，但不具有日志记录< Tj, commit>的事务Tj
2．对未提交事务列表中的每个事务Ti执行undo(Ti)
3．对已提交事务列表中的每个事务Ti执行redo(Ti)

四、基于检查点的恢复技术

提高系统故障恢复效率的基本方法是使用检查点技术。
数据库恢复机制定期地建立检测点，执行如下操作：
1．将当前驻留在主存中的所有日志记录强制输出到稳定存储器上
2．将所有修改了的缓冲块强制输出到磁盘上
3．将一个日志记录<checkpoint, L>强制输出到稳定存储器上，其中L是建立检查点时刻所有正在执行的事务清单

系统需要登记检查点记录在日志文件中的位置 在建立检查点时，不允许事务执行任何更新动作，如写缓冲块或写日志记录
建立检查点之后，所有在检查点前发生的更新都已经输出到数据库中，尚未完成的事务都登记在检查点记录中
这样，发生系统故障时，只需要从最近的检查点记录开始扫描日志

对于事务故障，使用检查点技术和不使用检查点技术的恢复过程是相同的 但是对于系统故障，使用检查点技术可以缩小日志的扫描范围，减少不必要的redo，提高故障恢复效率。

当系统故障发生时，首先要重新启动系统。系统重启后，恢复子系统自动按以下步骤进行系统故障恢复：

1. 得到最后一个检查点记录：找到最后一个检查点记录在日志文件中的地址，取出最后一个检查点记录<checkpoint, L>
2. 初始化两个事务列表UNDO-LIST（需要执行undo操作的事务集合）和REDO-LIST（需要执行redo操作的事务集合）：将L中的所有事务都放入UNDO-LIST，而REDO-LIST为空
3. 从最近的检查点开始，正向扫描日志文件，直到日志文件结束，遇到<Ti, start>就把Ti加入UNDO-LIST；遇到< Ti, commit>就把Ti从UNDO-LIST移出，加入到REDO-LIST
4. 对UNDO-LIST中的每个事务Ti执行undo(Ti)操作：反向扫描日志文件，直到遇到UNDO-LIST中每个事务Tk的< Tk, start>，对于每个形如< Ti, Xj, V1, V2 >的日志记录，如果Ti在UNDO-LIST中，则将Xj = V1写到数据库中
5. 对REDO-LIST中的每个事务Ti执行redo(Ti)操作：从最近的检查点开始，正向扫描日志文件，对于每个形如< Ti, Xj, V1, V2 >的日志记录，如果Ti在REDO-LIST中，则将Xj = V2写到数据库中

五、缓冲技术

日志缓冲
一个日志记录通常远小于稳定存储器的块。为了提高I/O效率，日志记录在主存中被缓冲，而不是直接输出到稳定存储器
当缓冲区被日志记录装满，或者执行日志强制输出时，日志记录才被输出到稳定存储器
日志缓冲减少了将日志输出到稳定存储器的开销，但是也带来了风险：一旦系统发生故障，缓冲区中的日志记录将丢失

—————————————————————————
为了保证事务的原子性，必须增加如下规则：
事务Ti在日志记录< Ti, commit>输出到稳定存储器后才进入提交状态
在日志记录< Ti, commit>输出到稳定存储器前，所有与事务Ti有关的日志记录必须已被输出到稳定存储器
在主存中的数据块输出到数据库之前，所有与该数据块中数据有关的日志记录必须已经输出到稳定存储器

数据库缓冲
数据库存储在非易失性存储器中，在需要时再将相应的数据块调入主存
由于主存远小于数据库，有可能在将数据块B2调入内存的时候，需要覆盖原来已经驻留在内存的数据块B1
如果B1已经修改过，则它在被覆盖前必须输出到非易失性存储器
前面所述的日志记录写规则限制了数据库数据的读写自由度，如果B2的输入引起B1的输出，则所有与B1中数据有关的日志记录都要首先输出到稳定存储器
因此，针对这种情况，系统将进行如下处理 ：
输出日志记录至稳定存储器，直至所有与块B1有关的日志记录都已经输出；
将块B1输出到磁盘上；
将块B2由磁盘输入到主存中

六、介质故障恢复技术

1.转储

转储是指将整个或部分数据库复制到磁带或另一个磁盘上，产生数据库后备副本的过程
后备副本可以脱机保存，供介质故障恢复时使用（因此，转储又称归档）
一旦数据库遭到破坏，就可以将后备副本重新装入，将数据库恢复到转储时的状态

按转储时是否允许事务运行分为静态转储和动态转储。

静态转储是在系统中无运行事务时进行的转储
优点： 静态转储容易实现，并且由于转储期间不存在对数据库的任何更新活动，静态转储得到的一定是一个一致的副本。当数据库被破坏时，装入数据库的转储副本就能把数据库恢复到转储时刻的正确状态
缺点： 静态转储必须等待用户事务结束才能进行，并且新的事务必须等待转储结束才能执行，因此降低了数据库的可用性

动态转储允许转储操作与用户事务并发进行，转储期间允许事务对数据库进行存取和更新。动态转储直接制作数据库副本，但是需要同时用日志记录运行事务对数据库的更新
优点:动态转储不必等待正在运行的用户事务结束，也不会影响新事务的运行
缺点：动态转储不能保证副本中数据的一致性，因此，恢复时需要同时使用数据库的后备副本和转储的日志才能把数据库恢复到正确状态

从转储时是转储整个数据库还是转储部分数据库角度考虑，转储分为海量转储和增量转储。

海量转储将制作数据库的完整副本
——————————————————————————
增量转储只复制上次转储后更新过的数据，形成数据库的增量副本。增量副本不能单独使用，恢复时，必须使用最后一个完整副本和之后的所有增量副本才能将数据库恢复到一致状态
——————————————————————————
从恢复角度看，使用海量转储得到的后备副本进行恢复更方便。但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用、更有效

2.介质故障的恢复

当数据库被破坏时，需要用转储的后备副本和日志进行恢复。我们只考虑海量转储。介质故障的恢复方法如下：

装入最新的数据库后备副本，将数据库恢复到最近一次转储时的状态
对于静态转储，装入后备副本后数据库即处于一致状态。对于动态转储，装入数据库副本之后还须装入转储时刻的日志文件副本，使用与系统故障恢复相同的方法，将数据库恢复到一致状态。
装入转储之后的日志，redo已完成的事务。即首先正向扫描日志文件，找出故障发生时已提交的事务，将其加入重做队列。然后，再次正向扫描日志文件，对重做队列中的每个事务Ti执行redo操作

七、其他故障恢复技术

1.影子分页技术

影子页面技术是不同于日志恢复技术，其比日志恢复技术所需要的磁盘操作要少

影子页面技术节省了基本日志记录的读写操作开销，并且不需要UNDO和REDO操作，加快了数据库恢复的速度。
——————————————————————————
但是，影子页面技术有如下不足：
将影子分页技术推广到多个事务并发执行的情况很困难
由于在数据库页面更新时改变了磁盘位置，数据库页面将离散地分布在磁盘上，需要复杂的物理存储管理机制
当页表很大时，建立和存取页表的开销将会很大

2.数据库镜像

数据库镜像是指DBMS自动把整个数据库复制到另一个磁盘上，保持数据库的一个一致副本。当数据库更新时，DBMS自动同时更新镜像，保持镜像与数据库的一致性

在系统正常运行时，镜像可以用于只读事务；发生介质故障时，可以使用镜像恢复数据库