数据库恢复技术

1.事务的基本概念

1.1概念

是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。

1.2事务和程序

在关系数据库中，一个事务可以是一个SQL语句、一组SQL语句、或整个程序。

一个程序可以包含多个事务。

事务是恢复和并发控制的基本单位。

1.3定义事务

1.3.1显示定义方式

成功执行后，进行commit操作，然后将结果写入数据库。

运行到rollback(回转)，对所有已经完成的操作进行撤销，回转到开始的状态。

2.事务的特征（ACID）

2.1原子性（Atomicity）

此过程不可分割，就像是计算机中的“原语”一样。

2.2一致性

事务执行的结果：使数据库从一致性状态A转化到一致性状态B

一致性状态：

数据库中只包含成功事务提交的结果。

不一致性状态：

数据库系统运行中发生故障，有些事务尚未完成就被迫中断。

未完成事务对数据库所做的修改，有一部分已经写入物理数据库，使数据库处于一种不正确的状态。

2.3隔离性

一个事务的执行不能被其他事务干扰（一个进程进入临界区，其他不能进入）

2.4永久性

一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。

接下来的其他操作和故障不应该对其有任何影响

2.恢复技术

2.1数据转储

2.1.1定义

DBA定期将整个数据库复制到磁带、磁盘或其他存储介质上保存起来的过程。

后备副本/后援副本

数据库遭到破坏后可将整个副本重新装入

重装后备副本只能将数据库恢复到转存时的状态

要想恢复到故障发生时的状态，须要重新运行自转存以后的所有更新事务

2.1.2方法

2.1.2.1静态转存

在系统中无运行事务时进行的转储操作

转储开始时数据库处于一致性状态

转储期间不允许对数据库的任何存取、修改活动

得到的一定是一个数据一致性的副本

优点：实现简单

缺点：降低了数据库的可用性

• 转储必须等待正运行的用户事务结束
• 新的事务必须等转储结束

2.1.2.2动态转储

转储与用户事务并发进行

转储期间允许对数据库进行存取或修改

优点：

• 不用等待正在运行的用户事务结束
• 不会影响新书屋的运行

缺点：

不能保证副本中的数据正确有效（备份的是个中间值，不一致数据）

2.1.2.3海量转储和增量转储

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

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

比较：

海量转储得到的后备副本进行恢复往往更方便

若数据库大，事务处理十分频繁，则增量转储方式更实用有效

2.2登记日志文件

日志文件（log file）是用来记录事务对数据库的更新操作的文件

日志文件的格式有：

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

以记录为单位的日志文件内容：

记录各个事务的开始标记（BEGIN TRANSACTION）

• 事务标记 + BEGIN TRANSACTION

记录各个事务结束标记（COMMIT或ROLLBACK）

• 事务标记 + COMMIT
• 事务标记 + ROLLBACK

记录各个事务的更新操作：insert 、update 、delete

以上均作为日志文件的一个日志记录（log record）

记录事务更新操作的日志记录：

• 事务标识（标明是哪个事务）
• 操作类型（插入I、删除D、或修改U）
• 操作对象（记录ID、Block NO）
• 更新前数据的旧值（对插入操作而言，此项为空值）
• 更新后数据的新值（对删除操作而言，此项为空值）

2.2.1具体作用

事务故障恢复和系统故障恢复必须用日志文件。——undo、redo

在动态转储方式中必须建立日志文件，后备副本和日志文件结合起来才能有效地恢复数据库。

在静态转存方式中，也可以建立日志文件。

• 故障恢复时，可重新装入后援副本把数据库恢复到转储结束时刻的状态
• 利用日志文件，重做已完成事务，撤销未完成的事务。
• 不必重新运行那些以完成的事务程序，就可以把数据库恢复到故障前某一时刻的正确状态。

2.2.2登记日志文件

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

• 登记的次序严格按并发事务执行的时间次序
  • 重做事务：按时间顺序，依次重做
  • 撤销事务：按时间逆序
• 必须先写日志文件，后写数据库
  • 写日志文件操作：把表示这个修改的日志记录写到日志文件中
  • 写数据库操作：把对数据的修改写到数据库中

注意：为什么要先写日志文件？

• 写数据库和写日志文件是两个不同的操作
• 在这两个操作之间可能发生故障
• 如果先写了数据库修改，而在日志文件中没有登记这个修改，则以后若故障恢复时，就无法恢复这个修改
• 如果先写日志，但没有修改数据库，按日志文件恢复时只不过是多执行一次不必要的UNDO操作，并不会影响数据库的正确性

2.3恢复策略

2.3.1事务故障的恢复

事务故障：事务在运行至正常终止点前被终止

恢复方法：由恢复子系统利用日志文件撤销（UNDO）此事务已对数据库进行的修改

事务故障的恢复是由系统自动完成，对用户透明，不需要用户干预

过程：

（1）反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。

（2）对该事务的更新操作执行逆操作。即将日志记录中”更新前的值“写入数据库。

• 插入操作：”更新前的值“为空，则相当于做删除操作
• 删除操作：”更新后的值“为空，则相当于做插入操作
• 若是修改操作，则相当于用修改前值代替修改后的值

（3）继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理

（4）如此处理下去，直至读到事务的开始标记，事务故障恢复就完成了。

2.3.2系统故障的恢复

系统故障造成数据库不一致状态的原因：

• 未完成事务对数据库的更新可能已经写入数据库
• 已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库

恢复方法：

1、Undo 针对故障发生时未完成的事务

2、Redo 针对已完成的事务

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

步骤：

（1）正向扫描日志文件（即从头扫描日志文件），建立2个队列：

• 重做（REDO)队列：在故障发生前已经提交的事务
  • ​​​​​​​这些事务既有BEGIN TRANSACTION记录，也有COMMIT记录
• 撤销（UNDO）队列：故障发生时尚未完成的事务
  • ​​​​​​​这些事务只有BEGIN TRANSACTION记录，没有COMMIT记录
• 一遍扫描建队方法：正向扫描，遇到事务开始记录，就放到UNDO队列，遇到COMMIT记录就将其从UNDO队列移到REDO队列。

（2）对撤销队列（UNDO）进行撤销处理

• 反向扫描日志文件，对每个撤销事务的更新操作执行逆操作
• 即将日志文件中”更新前的值“写入数据库

（3）对重做队列（REDO）事务进行重做处理

• 正向扫描日志文件，对每个重做事务重新执行登记的操作
• 即正向扫描日志记录中”更新后的值“，写入数据库

例题:

2.3.3介质故障恢复

步骤：

（1）装入最新的后备数据库副本（离故障发生时刻最近的转储副本），使数据恢复到最近一次转储的一致性状态

• 对于静态转储的数据库副本，装入后数据库即处于一致性状态
• 对于动态转储的数据库副本，还必须同时装入转储时刻的日志文件副本，利用恢复系统故障的方法（即REDO、UNDO），才可以将数据库恢复到一致性状态。

（2）装入有关的日志文件副本（转储结束时刻的日志文件副本），重做已完成的事务。

• 首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。
• 然后正向扫描日志文件，对重做队列中的所有事务进行重做处理，即将日志记录中”更新后的值“写入数据库。

注意：介质故障恢复需要数据库管理员介入

数据库管理员的工作

• 重装最近转储的数据库副本和有关的各日志文件副本
• 执行系统提供的恢复命令