为什么Aries在撤消数据库管理恢复之前执行重做？

Question

为什么Aries算法在撤消之前应用重做，如果它已经知道在分析阶段后要撤消哪些事务？

我知道（认为）它与Lsn数字有关并且在某种意义上保持一致性，因为在磁盘上刷新的数据可能与在崩溃时撤消事务不同，从而撤消事务（由于脏页），但我找不到任何形式的“正式”答案（至少有一个我能理解的）。

Answer 1

因为即使提交了事务，缓冲区上也可能存在未刷新的页面。 ARIES在缓冲区管理器中使用 no-force 。重做将事务表和脏页表带到崩溃时的状态。因此，成功的交易可以反映到稳定的存储中。

Answer 2

简答：

我们需要在重做传递中重复所有历史记录崩溃，以确保在执行撤消传递之前数据库的一致性。

答案很长：

recovery algorithm ARIES，为了确保DBMS的原子性和持久性属性，执行3次传递：

1. 分析通行证：看看需要做什么（播放日志）
2. 重做传递：确保磁盘反映日志中但不在磁盘上的所有更新，包括属于最终将回滚的事务的更新。这样，它可以确保我们处于 一致状态 ，这将允许逻辑撤消。
3. 撤消传递：删除任何丢失交易的操作

UNDO数据日志是合乎逻辑的，而REDO数据日志是物理的：

• 我们必须进行物理REDO，因为我们无法保证数据库处于一致状态（因此，例如，记录“INSERT VALUE X INTO TABLE Y”可能不是一个好主意，因为X可能会反映在如果在插入时发生崩溃，则索引但不是表，反之亦然，
• 我们可以做逻辑UNDO，因为在REDO之后我们知道事情是一致的。实际上，我们必须进行逻辑UNDO，因为我们只对UNDO进行了一些操作，并且形式的UNDO的物理日志记录，例如“索引y的拆分页面x”在索引管理或不变量方面可能不再是正确的做法保养。我们在重做期间不必担心这一点，因为我们重复历史并重放所有内容，这意味着上次对数据库进行的任何物理修改仍然是正确的。

Source

Answer 3

不知道白羊座是什么，但假设它与其他数据库相同：

从一些基本备份重做日志开始应用，这基本上意味着在备份之后但在应用崩溃之前发生的所有数据更改语句。没有它，你将失去自上次备份以来发生的一切。

完成后，所有未完成的交易都会被回滚，因为没有人可以拿起这些交易来完成它们。

Answer 4

您希望在失败时回到状态，以准确了解哪些交易需要撤消。想到的一个例子是连续失败。从崩溃中恢复时的精确失败。在恢复期间，您可以在日志上编写操作。如果在恢复过程中失败，您将重做日志中的所有操作（甚至是在上次尝试期间写入的UNDO操作!!）。

它提供了一个简单的算法，因为您不必处理特殊情况和特殊情况的特殊情况。可以保证在恢复期间发生任何数量的崩溃后，我们将恢复到恢复期间没有崩溃的状态。

Answer 5

如果你不支持记录级别的锁定，那么你可以使用只有重做赢家交易的selective-redo。否则，最好在撤消之前重复历史记录（重做全部）

Answer 6

您可以考虑在重做和撤消期间真正完成的操作。 根据退出的日志，重做正在重复历史。 相反，撤消是创建新的CLR日志记录。系统崩溃时，日志中包含有关未提交的xact的记录。如果你不撤消它们，就不会有CLR日志记录，从而导致不一致。

Answer 7

ARIES的目标之一是简洁。虽然重做之后的撤消可能不是必需的，但它使得算法的正确性比在重做之前执行撤消的更复杂的方案更明显。

Answer 8

除了确保数据库一致并且磁盘与崩溃发生之前完全相同（正如Franck Dernoncourt所回答的），在撤消之前执行重做的另一个好处是：

恢复过程中可能会发生故障。重做推进整个“增量恢复”的进度，即，如果在重做或撤消期间发生故障，则下一次恢复可以获取先前恢复（重做）已经离开并继续，如果在撤消之前执行重做。

极端情况是，如果撤消在重做之前执行，并且在撤消期间再次发生故障，则所有撤消都将徒劳无功。