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

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

---

我知道（认为）这与Lsn编号和保持一致性有关，因为在磁盘上刷新数据时撤消事务可能与在崩溃时撤消事务不同（由于脏页），但我找不到任何形式的“正式”答案来回答这个问题（至少有一个我能理解）。

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

从应用一些基本备份重做日志开始，这基本上意味着应用备份之后但崩溃之前发生的所有数据更改语句。否则，您将丢失自上次备份以来发生的所有内容

---

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

您希望返回到失败时的状态，以便准确地确定需要撤消哪些事务。脑海中出现的一个示例是连续的失败。当重新记录时，恰恰是失败防止崩溃。在恢复过程中，您将操作写入日志。如果在恢复过程中失败，您将重做日志中的所有操作（甚至是上次尝试时写入的撤消操作！！）

---

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

因为即使事务是并发的，缓冲区上也可能有未刷新的页面MMITED。ARIES在缓冲区管理器中使用无强制。重做会使事务表和脏页表恢复到崩溃时的状态。因此，成功的事务可以反映到稳定的存储中。

如果不支持记录级锁定，则可以使用仅重做成功的选择性重做ner事务。否则，最好在撤消之前重复历史记录（全部重做）

简短回答： 在执行撤消过程之前，我们需要重复重做过程中的所有历史崩溃，以确保数据库的一致性

长答覆： 为了确保DBMS的原子性和耐久性，执行3个过程：

分析过程：查看需要执行的操作（向前播放日志）

重做过程：确保磁盘反映日志中但不在磁盘上的任何更新，包括那些属于最终将回滚的事务的更新。这样可以确保我们处于一致状态，这将允许逻辑撤消

撤消传递：删除任何丢失事务的操作

撤消数据日志是逻辑日志，而重做数据日志是物理日志：

• 我们必须进行物理重做，因为我们不能保证数据库处于一致状态（例如，记录“将值X插入表Y”可能不是一个好主意，因为X可能会反映在索引中，但不会反映在表中，反之亦然，以防插入时发生崩溃）
• 我们可以做逻辑撤销，因为重做后我们知道事情是一致的。事实上，我们必须做逻辑撤销，因为我们只撤销一些操作，以及表单撤销的物理记录，例如，“拆分索引y的x页”就索引管理或不变维护而言，可能不再是正确的做法。在重做过程中，我们不必担心这一点，因为我们会重复历史记录并重放所有内容，这意味着上次对数据库所做的任何物理修改仍然是正确的

---

你可以考虑重做和撤消过程中所做的事情。 根据已退出的日志，重做正在重复历史记录。

---

相反，撤消是创建新的CLR日志记录。当系统崩溃时，日志中有关于未受限制的XACT的记录。如果不撤消它们，将不会有CLR日志记录，从而导致不一致性。

ARIES的目标之一是简单性。虽然重做后撤消可能没有必要，但它使算法的正确性更加令人震惊这比在重做之前执行撤消的更复杂的方案要好。

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

恢复过程中可能会发生故障。重做会推进整个“增量恢复”的进度，即，如果在重做或撤消过程中发生故障，则下一次恢复可以提取上一次恢复（重做）剩下的内容，并继续进行，前提是在撤消之前执行重做

---

一个极端的情况是，如果撤消在重做之前执行，并且在撤消过程中一次又一次失败，那么所有的撤消都将无效。

在这种情况下，“物理”和“逻辑”是什么意思？嗨，Franck，small world。总之，您知道在所有恢复之后事务表是否为空吗？