【发布时间】:2012-05-04 13:46:15
【问题描述】:
如果 Aries 算法在分析阶段之后已经知道要撤消哪些事务,为什么还要在撤消之前应用重做?
我知道(认为)它与 Lsn 编号和保持一致性有关,因为在磁盘上刷新的数据可能与在崩溃时撤消事务不同(由于脏页),但我找不到任何形式的“正式”答案(至少是我能理解的)。
【问题讨论】:
如果 Aries 算法在分析阶段之后已经知道要撤消哪些事务,为什么还要在撤消之前应用重做?
我知道(认为)它与 Lsn 编号和保持一致性有关,因为在磁盘上刷新的数据可能与在崩溃时撤消事务不同(由于脏页),但我找不到任何形式的“正式”答案(至少是我能理解的)。
【问题讨论】:
因为即使提交了事务,缓冲区上也可能存在未刷新的页面。 ARIES 在缓冲区管理器中使用 no-force。重做会将事务表和脏页表带到崩溃时的状态。因此,成功的交易可以反映到稳定的存储中。
【讨论】:
我们需要在redo pass中重复所有的历史崩溃,以确保在执行undo pass之前数据库的一致性。
recovery algorithm ARIES,为了保证DBMS的原子性和持久性,执行3遍:
UNDO 数据日志是逻辑的,而 REDO 数据日志是物理的:
【讨论】:
不知道 aries 是什么,但假设它与其他数据库相同:
从一些基础备份开始应用重做日志,这基本上意味着在备份之后但在崩溃之前发生的所有数据更改语句都被应用。否则,您将丢失自上次备份以来发生的所有内容。
完成后,所有未完成的事务都会回滚,因为没有人可以拿起这些事务来完成它们。
【讨论】:
您希望返回失败时的状态,以便准确了解哪些事务需要撤消。想到的一个例子是连续的失败。从崩溃中恢复时的精确故障。在恢复期间,您将您的操作写入日志。如果您在恢复过程中失败,您将重做日志中的所有操作(甚至是上次尝试期间写入的 UNDO 操作!!)。
它提供了一个简单的算法,因为你不必处理特殊情况和特殊情况的特殊情况。可以保证,在恢复期间发生任何数量的崩溃后,我们将回到与恢复期间没有崩溃相同的状态。
【讨论】:
如果您不支持记录级锁定,那么您可以使用仅重做获胜者事务的选择性重做。否则,最好在撤消之前重复历史记录(全部重做)
【讨论】:
您可以考虑在重做和撤消期间真正做了什么。 根据退出的日志,重做正在重复历史。 相反,撤消是创建新的 CLR 日志记录。当系统崩溃时,日志中有关于未提交的 xact 的记录。如果不撤消,则不会有CLR日志记录,从而造成不一致。
【讨论】:
ARIES 的目标之一是简单。虽然重做之后的撤消可能不是必需的,但它使算法的正确性比在重做之前执行撤消的更复杂的方案更明显。
【讨论】:
除了确保数据库一致并且磁盘与崩溃发生前完全相同(正如 Franck Dernoncourt 回答的那样),在撤消之前执行重做的另一个好处是:
在恢复过程中可能会发生故障。 Redo推进了整个“增量恢复”的进程,即如果redo或undo过程中发生故障,如果redo在undo之前执行,则下一次恢复可以拾取上一次恢复(redo)剩下的部分继续进行。
一个极端的情况是,如果undo在redo之前执行,并且在undo过程中再次失败,那么所有的undo都将变为徒劳。
【讨论】: