【问题标题】:What is the benefit of repeating history in ARIES recovery method?在 ARIES 恢复方法中重复历史有什么好处?
【发布时间】:2012-11-25 05:23:27
【问题描述】:

ARIES algorithm中,为什么需要在redo pass中重复崩溃前的所有历史? 我可以在分析过程中获取已提交的事务编号,然后重做已提交的事务日志记录吗?这种方法将减少需要重做和撤消的记录数。

【问题讨论】:

    标签: database algorithm rdbms recovery aries


    【解决方案1】:

    简答:

    我们需要在 redo pass 中重复崩溃前的所有历史记录,以确保在执行 undo pass 之前数据库的一致性。

    长答案:

    recovery algorithm ARIES,为了保证DBMS的原子性和持久性,执行3遍:

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

    UNDO 数据日志是逻辑的,而 REDO 数据日志是物理的:

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

    Source

    【讨论】:

      【解决方案2】:

      原因是因为 ARIES 被设计为使用无暴力/偷窃方法。 “窃取”部分意味着来自未提交事务的更改可能会写入磁盘。因此,我们需要重做所有已提交和未提交的事务,以便撤消未提交的事务。

      【讨论】:

      • 谢谢。我找到了一个更合理的答案。为了支持细粒度锁,它必须重做所有更新,即使是在未提交的更新中。这在 ARIES 论文的第 10.1 节中进行了描述,并与选择性重做方法进行了比较。
      猜你喜欢
      • 2013-04-15
      • 2018-01-24
      • 1970-01-01
      • 1970-01-01
      • 2023-03-07
      • 1970-01-01
      • 2016-02-02
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多