分布式数据库管理系统 - 数据库恢复
为了从数据库故障中恢复,数据库管理系统采用了多种恢复管理技术。 在本章中,我们将研究数据库恢复的不同方法。
数据库恢复的典型策略是 −
如果发生软故障导致数据库不一致,恢复策略包括事务撤消或回滚。 但有时也可以采用事务重做的方式来恢复到事务的一致状态。
如果发生硬故障,导致数据库严重损坏,恢复策略包括从存档备份中恢复数据库的过去副本。 通过从事务日志重做已提交事务的操作来获取数据库的最新状态。
从电源故障中恢复
电源故障会导致非持久内存中的信息丢失。 当电源恢复时,操作系统和数据库管理系统将重新启动。 恢复管理器从事务日志启动恢复。
在立即更新模式下,恢复管理器将执行以下操作 −
处于活动列表和失败列表中的事务将被撤消并写入中止列表。
重做提交前列表中的事务。
不会对提交或中止列表中的事务采取任何操作。
在延迟更新模式下,恢复管理器将执行以下操作 −
活动列表和失败列表中的事务将写入中止列表中。 由于更改尚未写入磁盘,因此不需要撤消操作。
重做提交前列表中的事务。
不会对提交或中止列表中的事务采取任何操作。
从磁盘故障中恢复
磁盘故障或硬崩溃会导致数据库完全丢失。 为了从这次硬崩溃中恢复,需要准备一个新磁盘,然后恢复操作系统,最后使用数据库备份和事务日志恢复数据库。 立即更新和延迟更新模式的恢复方法相同。
恢复管理器执行以下操作 −
提交列表和提交前列表中的事务将被重做并写入事务日志中的提交列表。
活动列表和失败列表中的事务将被撤消并写入事务日志中的中止列表。
检查点
检查点是记录从缓冲区写入数据库的时间点。 因此,在系统崩溃的情况下,恢复管理器不必重做检查点之前已提交的事务。 定期检查点可缩短恢复过程。
这两种类型的检查点技术是 −
- 一致的检查点
- 模糊检查点
一致的检查点
一致的检查点在检查点创建一致的数据库映像。 在恢复期间,只有位于最后一个检查点右侧的那些事务才会被撤消或重做。 最后一个一致检查点左侧的事务已经提交,不需要再次处理。 检查点采取的操作是 −
- 活跃事务暂时暂停。
- 主内存缓冲区中的所有更改都会写入磁盘。
- "检查点"记录写入事务日志中。
- 事务日志写入磁盘。
- 暂停的事务已恢复。
如果在步骤 4 中也归档了事务日志,则此检查点有助于从磁盘故障和电源故障中恢复,否则它仅有助于从电源故障中恢复。
模糊检查点
在模糊检查点中,在检查点时,所有活动事务都写入日志中。 如果发生电源故障,恢复管理器仅处理在检查点期间及之后处于活动状态的事务。 在检查点之前已提交的事务将写入磁盘,因此不需要重做。
检查点示例
让我们考虑系统中检查点的时间是tcheck,系统崩溃的时间是tfail。 假设有四个事务 Ta、Tb、Tc 和 Td,这样 −
Ta 在检查点之前提交。
Tb 在检查点之前启动并在系统崩溃之前提交。
Tc 在检查点之后启动,并在系统崩溃之前提交。
Td 在检查点之后启动,并在系统崩溃时处于活动状态。
情况如下图所示 −
恢复管理器采取的操作是 −
- Ta什么也没做。
- 对 Tb 和 Tc 执行事务重做。
- 在 Td 内执行事务撤消。
使用 UNDO / REDO 进行事务恢复
事务恢复是为了消除错误事务的不利影响,而不是从故障中恢复。 错误事务包括所有将数据库更改为不希望的状态的事务以及使用了错误事务写入的值的事务。
这些情况下的事务恢复需要两个步骤 −
撤消所有错误事务以及可能受错误事务影响的事务。
重做所有没有错误但由于错误事务而被撤消的事务。
UNDO操作的步骤是 −
如果错误事务已完成 INSERT,恢复管理器将删除插入的数据项。
如果错误事务已完成 DELETE,恢复管理器将从日志中插入已删除的数据项。
如果错误事务已完成更新,恢复管理器会通过从日志中写入更新前的值来消除该值。
REDO 操作的步骤是 −
如果事务已完成 INSERT,恢复管理器会从日志中生成一条插入。
如果事务已完成 DELETE,恢复管理器会从日志中生成删除。
如果事务已完成更新,恢复管理器会从日志中生成更新。