崩溃恢复

DBMS是一个高度复杂的系统，每秒执行数百个事务。 DBMS的持久性和健壮性取决于其复杂的体系结构以及其基础硬件和系统软件。如果它在事务中失败或崩溃，则可以预期系统将遵循某种算法或技术来恢复丢失的数据。

失败分类

为了查看问题发生的位置，我们将故障归纳为各种类别，如下所示：

交易失败

事务在执行失败或到达无法继续执行的点时必须中止。这称为事务失败，其中只有少数事务或流程受到损害。

交易失败的原因可能是-

• 逻辑错误-事务因代码错误或任何内部错误情况而无法完成的地方。

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

系统崩溃

系统外部存在问题-可能导致系统突然停止并导致系统崩溃。例如，电源中断可能会导致基础硬件或软件故障。

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

磁盘故障

在技术发展的早期，硬盘驱动器或存储驱动器经常出现故障是一个普遍的问题。

磁盘故障包括坏扇区的形成，磁盘无法访问，磁盘磁头崩溃或任何其他故障，这些故障会破坏全部或部分磁盘存储。

储存结构

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

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

• 非易失性存储-这些存储器可以抵抗系统崩溃。它们的数据存储容量巨大，但可访问性却较慢。示例可能包括硬盘，磁带，闪存和非易失性(电池备份)RAM。

恢复与原子性

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

当DBMS从崩溃中恢复时，它应保持以下内容-

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

• 交易可能在某些操作中；在这种情况下，DBMS必须确保事务的原子性。

• 它应该检查事务是否可以立即完成或需要回滚。

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

有两种技术，它们可以帮助DBMS恢复并保持事务的原子性-

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

• 维护影子分页，在易失性存储器上进行更改，然后再更新实际的数据库。

基于日志的恢复

日志是一系列记录，用于维护事务执行的操作的记录。重要的是，日志必须在实际修改之前写入并存储在稳定的存储介质上，这是故障安全的。

基于日志的恢复工作如下-

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

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

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

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

• 当事务完成时，它记录-

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

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

• 立即修改数据库-每个日志都遵循实际的数据库修改。即，在每次操作后立即修改数据库。

并发事务恢复

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

检查站

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

复苏

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

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

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

• 如果恢复系统看到带有n ，Start>和n ，Commit>或只是n ，Commit>的日志，则它将事务放入重做列表中。

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

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