DBMS 中基于日志的恢复

DBMS 的原子性属性规定事务的所有操作必须执行或不执行。中止事务所做的修改对数据库不应该是可见的，而提交事务所做的修改应该是可见的。

为了实现我们的原子性目标，用户必须首先将描述修改的信息输出到稳定的存储中，而不是修改数据库本身。此信息可以帮助我们确保已提交事务执行的所有修改都反映在数据库中。此信息还可以帮助我们确保中止事务所做的修改不会在数据库中持续存在。

日志和日志记录 –
日志是一系列日志记录，记录了数据库中的所有更新活动。在稳定的存储中，维护每个事务的日志。对数据库执行的任何操作都记录在日志中。在对数据库执行任何修改之前，会创建更新日志记录以反映该修改。

表示为： 的更新日志记录具有以下字段：

1. 事务标识符：执行写操作的事务的唯一标识符。
2. 数据项：写入的数据项的唯一标识符。
3. 旧值：写入前数据项的值。
4. 新值：写操作后数据项的值。

其他类型的日志记录是：

1. ：它包含有关事务 Ti 何时开始的信息。
2. ：它包含有关事务 Ti 何时提交的信息。
3. ：它包含有关事务 Ti 何时中止的信息。

撤消和重做操作——
因为所有的数据库修改都必须在创建日志记录之前进行，所以系统既可以使用修改数据项之前的旧值，也可以使用要为数据项写入的新值。这允许系统根据需要执行重做和撤消操作：

1. 撤消：使用日志记录将日志记录中指定的数据项设置为旧值。
2. 重做：使用日志记录将日志记录中指定的数据项设置为新值。

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

1. 延迟修改技术：如果事务在部分提交之前不修改数据库，则称为使用延迟修改技术。
2. 立即修改技术：如果在事务仍处于活动状态时发生数据库修改，则称为使用立即修改技术。

使用日志记录恢复 –
发生系统崩溃后，系统会查阅日志以确定哪些事务需要重做，哪些需要撤消。

1. 如果日志包含记录但不包含记录或记录，则需要撤消事务Ti。
2. 如果日志包含记录 和记录 或记录 ，则需要重做事务 Ti。

检查点的使用——
当系统崩溃时，用户必须查阅日志。原则上，即需要搜索整个日志来确定这些信息。这种方法有两个主要困难：

1. 搜索过程非常耗时。
2. 根据我们的算法，大多数需要重做的事务已经将它们的更新写入数据库。虽然重做它们不会造成伤害，但会导致恢复需要更长的时间。

为了减少这些类型的开销，用户引入了检查点。 形式的日志记录用于表示日志中的检查点，其中 L 是检查点时活动的事务列表。当添加一个检查点日志记录来记录在这个检查点之前已经提交的所有事务时，在检查点记录之前有日志记录。 Ti 所做的任何数据库修改都会在检查点之前或作为检查点本身的一部分写入数据库。因此，在恢复时，无需对 Ti 执行重做操作。

发生系统崩溃后，系统会检查日志以查找最后一个 记录。重做或撤销操作只需要应用于 L 中的事务，以及在记录写入日志后开始执行的所有事务。让我们将这组事务表示为 T。如使用日志记录恢复部分所述，相同的撤消和重做规则适用于 T。

注意，用户只需要检查从最后一个检查点日志记录开始的那部分日志就可以找到事务T的集合，并找出T中每个事务的日志中是否发生了commit或abort记录。例如，考虑交易集 {T0, T1, … . ., T100}。假设最近的检查点发生在事务 T67 和 T69 的执行期间，而 T68 和所有下标低于 67 的事务在检查点之前完成。因此，只有事务 T67、T69、… . ., T100 需要在恢复方案中考虑。如果已经完成(即提交或中止)，则每个都需要重做；否则，它是不完整的，需要撤消。