DBMS - 数据恢复

崩溃恢复

DBMS是一个高度复杂的系统，每秒执行数百个事务。DBMS的持久性和健壮性取决于其复杂的架构及其底层的硬件和系统软件。如果它在事务处理过程中出现故障或崩溃，则预计系统会遵循某种算法或技术来恢复丢失的数据。

故障分类

为了查看问题发生的位置，我们将故障概括为以下几类：

事务失败

当事务无法执行或到达无法继续执行的点时，它必须中止。这称为事务失败，其中只有少数事务或进程受到影响。

事务失败的原因可能包括：

• 逻辑错误 - 事务由于代码错误或任何内部错误条件而无法完成。

• 系统错误 - 数据库系统本身终止活动事务，因为 DBMS 无法执行它，或者由于某些系统条件而必须停止。例如，在死锁或资源不可用情况下，系统会中止活动事务。

系统崩溃

有一些外部问题可能导致系统突然停止并导致系统崩溃。例如，电源中断可能导致底层硬件或软件故障。

示例可能包括操作系统错误。

磁盘故障

在技术发展早期，硬盘驱动器或存储驱动器频繁出现故障是一个常见问题。

磁盘故障包括坏扇区形成、磁盘不可访问、磁盘磁头损坏或任何其他故障，这些故障会破坏所有或部分磁盘存储。

存储结构

我们已经描述了存储系统。简而言之，存储结构可以分为两类：

• 易失性存储 - 顾名思义，易失性存储无法在系统崩溃后幸存。易失性存储设备放置在非常靠近 CPU 的位置；通常它们嵌入到芯片组本身。例如，主内存和缓存内存是易失性存储的示例。它们速度快，但只能存储少量信息。

• 非易失性存储 - 这些内存能够在系统崩溃后幸存。它们的数据存储容量很大，但访问速度较慢。示例可能包括硬盘、磁带、闪存和非易失性（电池备份）RAM。

恢复和原子性

当系统崩溃时，它可能有多个事务正在执行，并且为它们打开了各种文件以修改数据项。事务由各种操作组成，这些操作本质上是原子的。但根据 DBMS 的 ACID 属性，必须维护事务整体的原子性，即要么所有操作都执行，要么都不执行。

当 DBMS 从崩溃中恢复时，它应该维护以下内容：

• 它应该检查所有正在执行的事务的状态。

• 事务可能处于某个操作的中间；在这种情况下，DBMS 必须确保事务的原子性。

• 它应该检查事务现在是否可以完成，或者是否需要回滚。

• 不允许任何事务使 DBMS 处于不一致状态。

有两种技术可以帮助 DBMS 恢复并维护事务的原子性：

• 维护每个事务的日志，并在实际修改数据库之前将它们写入某个稳定存储。

• 维护影子分页，其中更改在易失性内存中完成，稍后更新实际数据库。

基于日志的恢复

日志是记录的序列，它维护事务执行的操作记录。重要的是，日志应在实际修改之前写入并存储在安全可靠的稳定存储介质上。

基于日志的恢复的工作方式如下：

• 日志文件保存在稳定的存储介质上。

• 当事务进入系统并开始执行时，它会写入有关它的日志。

<Tn, Start>

• 当事务修改项 X 时，它会写入如下日志：

<Tn, X, V1, V2>

它读取 T_n 已将 X 的值从 V₁ 更改为 V₂。

• 当事务完成时，它会记录：

<Tn, commit>

可以使用两种方法修改数据库：

• 延迟数据库修改 - 所有日志都写入稳定存储，并在事务提交时更新数据库。

• 立即数据库修改 - 每个日志都跟随实际的数据库修改。也就是说，数据库在每次操作后立即修改。

并发事务恢复

当多个事务并行执行时，日志会交错。在恢复时，恢复系统很难回溯所有日志，然后开始恢复。为了简化这种情况，大多数现代 DBMS 使用“检查点”的概念。

检查点

实时和真实环境中保存和维护日志可能会耗尽系统中所有可用的内存空间。随着时间的推移，日志文件可能会变得太大而无法处理。检查点是一种机制，其中所有以前的日志都从系统中删除并永久存储在存储磁盘中。检查点声明一个 DBMS 处于一致状态之前的点，并且所有事务都已提交。

恢复

当具有并发事务的系统崩溃并恢复时，它的行为如下：

• 恢复系统从末尾反向读取日志到最后一个检查点。

• 它维护两个列表，一个撤销列表和一个重做列表。

• 如果恢复系统看到带有 <T_n, Start> 和 <T_n, Commit> 或仅 <T_n, Commit> 的日志，它会将事务放入重做列表。

• 如果恢复系统看到带有 <T_n, Start> 但未找到提交或中止日志的日志，它会将事务放入撤销列表。

然后撤消撤销列表中的所有事务并删除它们的日志。重做列表中的所有事务及其之前的日志都会被删除，然后在保存其日志之前重做。