数据库恢复技术

故障分类

(1) 系统故障

造成系统停止运行的故障，此时正在执行的所有事务将全部中断，内存中的事务数据丢失，可能会出现不一致的状态

(2) 事务内部的故障

死锁、运算溢出等导致事务处理出现错误、未达到预期终点(Commit或RollBack)的故障，导致事务的非正常结束

(3) 存储设备故障

介质破坏

(4) 其他

数据库恢复策略综述

(1) 事务故障的恢复

利用日志文件撤销事务对数据的更改，系统回滚到事务执行前的状态，好像从来没有发生过事务一样

日志文件：记录数据库所有更新操作，当事务故障发生时系统反向扫描日志文件、并逆向操作。

(2) 系统故障的恢复

系统故障不会破坏磁盘中的数据，但是会丢失内存缓冲区中的数据。

此时有两种可能造成数据库状态不一致：一、未完成事务对数据的更新可能已经写入数据库；二、已完成事务对数据的更新可能还在缓冲区中未写入磁盘。

恢复步骤：

1° 扫描日志文件，找到未完成事务和已完成事务（区别是有无Commit）

2° 正向扫描日志，重新执行Redo已完成事务

3° 反向扫描日志，撤销Undo未完成事务

(3) 存储故障的恢复

依靠镜像磁盘

基于日志的数据库恢复

(1) 日志记录的类型

1° Start Ti：开始事务Ti

2° Ti，Xj，V1，V2：Ti事务对数据项Xj进行写操作，操作前的值为V1，操作后的值为V2

3° Commit Ti：提交事务Ti（表示事务执行成功，事务对数据库所做的任何更新都写入到缓存区中，但是不一定写到磁盘中了）

4° Abort Ti：终止事务Ti

(2) 事务操作写日志的过程

1° 日志中写入 Start Ti

2° Ti的每次write(X)操作前，都要先在日志中写入 Ti，Xj，V1，V2，然后才能更新数据

3° 事务进入部分提交状态时，向日志中写入 Commit Ti

(3) Redo技术

故障发生后，系统扫描日志，对于日志中既包含 Start Ti 又包含 Commit Ti 的事务Ti，要重新执行Redo。

系统按事务的提交顺序重做各个事务。

(4) Undo技术

故障发生后，系统扫描日志，对于日志中包含 Start Ti 但不包含 Commit Ti 的事务Ti，要重新执行Undo。

Undo的过程是：从日志中读取Write记录(Ti，Xj，V1，V2)，按照写入时相反的顺序，将数据从新值恢复成旧值。即V2恢复成V1。

(5) 日志文件可以恢复系统故障和事务故障，不能恢复存储故障

检查点恢复技术

(1) 事务内部的故障仅需要恢复发生故障的个别事务，而系统故障可能会影响多个事务，此时扫描日志文件变成了一个耗时的过程。事实上，系统故障发生时仅影响少量事务，所以使用检查点。

(2) 检查点；记录在日志中，表示数据库是否正常运行的一个标志。

系统需要周期性的向日志中写入一条检查点，记录所有当前活动的事务。

(3) 写检查点时的操作

1° 把日志缓冲区中的内容写入日志

2° 向日志文件写入一个检查点

3° 把数据库缓冲区的内容写入数据库

4° 把检查点在日志中的地址写入重启动文件

写检查点时，不运行事务执行任何更新操作

(4) 具有检查点的恢复时操作

1° 从重启动文件找到最后一个检查点的地址

2° 扫描得到检查点时刻的所有事务

3° Redo已经完成的事务，Undo未完成的事务(判断完成/未完成的标准是是否Commit过)

作者：米都都
链接：https://www.jianshu.com/p/8ff2bbada039
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。