DBMS - 数据恢复
崩溃恢复
DBMS 是一个高度复杂的系统，每秒执行数百个事务。 DBMS 的持久性和健壮性取决于其复杂的架构及其底层硬件和系统软件。 如果它在事务中失败或崩溃，预计系统将遵循某种算法或技术来恢复丢失的数据。
故障分类
为了查看问题发生在哪里，我们将故障概括为各种类别，如下所示 −
交易失败
当事务执行失败或到达无法继续的点时，事务必须中止。 这称为事务失败，只有少数事务或进程受到损害。
交易失败的原因可能是 −
逻辑错误 − 由于某些代码错误或任何内部错误条件，交易无法完成。
系统错误 − 数据库系统本身终止活动事务，因为 DBMS 无法执行它，或者由于某些系统条件而必须停止。 例如，在死锁或资源不可用的情况下，系统会中止一个活动事务。
系统崩溃
有问题 − 系统外部 − 这可能会导致系统突然停止并导致系统崩溃。 例如，供电中断可能会导致底层硬件故障或软件故障。
示例可能包括操作系统错误。
磁盘故障
在技术发展的早期，硬盘驱动器或存储驱动器经常出现故障是一个常见问题。
磁盘故障包括坏扇区的形成、磁盘无法访问、磁头崩溃或任何其他故障，这些故障会破坏全部或部分磁盘存储。
存储结构
我们已经描述了存储系统。 简单来说，存储结构可以分为两类 −
易失性存储 − 顾名思义，易失性存储无法在系统崩溃后幸免于难。 易失性存储设备放置在非常靠近 CPU 的位置； 通常它们被嵌入到芯片组本身。 例如，主存储器和高速缓存存储器是易失性存储的示例。 它们速度很快，但只能存储少量信息。
非易失性存储 − 这些记忆是为了在系统崩溃中幸存下来。 它们的数据存储容量很大，但可访问性较慢。 示例可能包括硬盘、磁带、闪存和非易失性（电池备份）RAM。
恢复和原子性
当系统崩溃时，它可能会执行多个事务并打开各种文件以供它们修改数据项。 事务由各种操作组成，这些操作本质上是原子的。 但根据 DBMS 的 ACID 特性，事务的原子性作为一个整体必须保持，即要么全部执行，要么不执行。
当 DBMS 从崩溃中恢复时，它应该维护以下内容 −
它应该检查所有正在执行的交易的状态。
一个事务可能正在进行一些操作； 在这种情况下，DBMS 必须确保事务的原子性。
它应该检查事务现在是否可以完成或是否需要回滚。
不允许任何事务使 DBMS 处于不一致状态。
有两种技术可以帮助 DBMS 恢复和维护事务的原子性 −
维护每个事务的日志，并在实际修改数据库之前将它们写入一些稳定的存储。
维护影子分页，其中更改在易失性内存上完成，然后更新实际数据库。
基于日志的恢复
日志是一个记录序列，它维护事务执行的操作的记录。 重要的是日志在实际修改之前写入并存储在稳定的存储介质上，这是故障安全的。
基于日志的恢复工作如下 −
日志文件保存在稳定的存储介质上。
当一个事务进入系统并开始执行时，它会写一个关于它的日志。
<Tn, Start>
当事务修改项目 X 时，它写日志如下 −
<Tn, X, V1, V2>
它读取 Tn 已将 X 的值从 V1 更改为 V2。
- 事务完成后，它会记录 −
<Tn, commit>
可以使用两种方法修改数据库 −
延迟数据库修改 − 所有日志都写入稳定存储，并在事务提交时更新数据库。
立即修改数据库 − 每个日志都遵循实际的数据库修改。 即每次操作后立即修改数据库。
通过并发事务恢复
当并行执行多个事务时，日志会交错。 在恢复时，恢复系统很难回溯所有日志，然后开始恢复。 为了缓解这种情况，大多数现代 DBMS 都使用"检查点"的概念。
检查点
在真实环境中实时保存和维护日志可能会填满系统中所有可用的内存空间。 随着时间的推移，日志文件可能变得太大而无法处理。 检查点是一种机制，其中所有以前的日志都从系统中删除并永久存储在存储磁盘中。 检查点声明了一个点，在该点之前 DBMS 处于一致状态，并且所有事务都已提交。
恢复
当具有并发事务的系统崩溃并恢复时，它的行为方式如下 −
恢复系统从最后一个检查点向后读取日志。
它维护两个列表，一个撤销列表和一个重做列表。
如果恢复系统看到包含 <Tn, Start> 和 <Tn, Commit> 或只有 <Tn, Commit> 的日志，它会将事务放入重做列表中。
如果恢复系统看到带有 <Tn, Start> 的日志但没有找到提交或中止日志，它会将事务放入 undo-list。
撤消列表中的所有事务随后都被撤消并删除它们的日志。 重做列表中的所有事务及其以前的日志都将被删除，然后在保存日志之前重做。
