回顾与超越：ARIES恢复方法的历史演进及互联网时代的影响

88 浏览量更新于2024-07-14 收藏 282KB PDF 举报

本文是C. Mohan在1999年的VLDB会议上发表的论文"Repeating History Beyond ARIES"，作者来自IBM Almaden Research Center，地址位于美国加利福尼亚州圣何塞。论文探讨了原始ARIES（Advanced Recovery for Integrated Environments）恢复方法的背景及其对商业世界和研究领域产生的深远影响。首先，Mohan回顾了ARIES方法的发展历程，强调了它在解决并发控制和数据库恢复问题上的创新性。ARIES家族算法集合了多种并发控制策略，旨在提高系统的性能、可用性和可靠性，这些特性在当时的商业环境中起到了关键作用。重复历史的概念在ARIES中扮演了核心角色，即通过将事务的历史记录保存下来，以便在必要时回滚或重做，从而确保数据一致性。随着互联网时代的到来，论文指出，ARIES中的许多传统理念和技术正逐渐扩展到更广泛的信息化社会。例如，在大型机时代被视为重要指标的性能、可用性和可靠性，现在已成为信息技术社区普遍关注的核心需求。这表明，随着技术的演变，数据库管理系统的演进不仅在于技术创新，还在于满足不断变化的应用场景和用户期望。论文进一步讨论了近年来对事务管理领域的最新进展，以及这些发展对未来的影响。Mohan观察到，随着云计算、分布式系统和移动计算的兴起，对高吞吐量、低延迟和跨平台一致性的需求正在推动交易管理技术向着更加复杂和适应性强的方向发展。在总结部分，作者提出，虽然历史可能会在不同的技术环境中重复，但理解并适应这种重复是关键。对于ARIES而言，这意味着要持续优化其方法以适应新的挑战，同时保持对传统原则的尊重和改进。论文通过深入剖析ARIES的过往成功和未来可能面临的机遇与挑战，为数据库管理系统的设计者和研究人员提供了有价值的洞见。这篇论文深入探讨了ARIES的起源、影响力和未来发展趋势，展示了如何将历史经验应用于不断发展的互联网环境下的事务管理，为业界提供了一种理解技术演进和适应变化的视角。

This is the kind of feature that requires a recovery method

to (1) support operation logging (i.e., logging the quantity

by which a field's value was decremented or incremented,

rather than logging the before and after values of the field

as in IMS), (2) avoid erroneous attempts to undo or redo

some actions unnecessarily by precisely tracking the state

of a page using the LSN concept, and (3) write CLRs.

Unlike in earlier recovery methods, in ARIES, CLRs have

the property that they are redo-only log records. By

appropriate chaining of the CLRs to log records written

during forward processing, a bounded amount of logging

is ensured during rollbacks, even in the face of repeated

failures during restart recovery or of nested rollbacks.

This is to be contrasted with what happens in IMS

[PeSt83], which may undo the same nonCLR multiple

times, and in AS/400 [ClCo89], DB2/MVS V1 and

NonStop SQL, which, in addition to undoing the same

nonCLR multiple times, may also undo CLRs one or more

times (see [MHLPS92] for examples). In the past, these

have caused severe problems in real-life situations.

When the undo of a log record causes a CLR to be written,

the CLR is made to point, via the UndoNxtLSN field of

the CLR, to the predecessor of the log record being

undone. The latter information is readily available since

every log record, including a CLR, contains a pointer

(PrevLSN) to the most recent preceding log record written

by the same transaction. Thus, during rollback, the

UndoNxtLSN field of the most recently written CLR keeps

track of the progress of rollback. It tells the system from

where to continue the rollback of the transaction, if a

system failure were to interrupt the completion of the

rollback or if a nested rollback were to be performed. It lets

the system bypass those log records that had already been

undone.

Since CLRs can describe what actions are actually

performed during the undo of an original action, the undo

action need not be, in terms of which page(s) is affected,

the exact inverse of the action that is being compensated

(i.e., logical undo is made possible). This allows very high

concurrency to be supported. For example, in a B

-tree, a

key inserted on page 10 by one transaction may be moved

to page 20 by another transaction before the key insertion

is committed, as we permit in ARIES/IM [Mohan95b,

MoLe92] (see [Mohan93a] for the description of

ARIES/LHS which also exploits this feature). Now, if the

first transaction were to roll back, then the key will be

located on page 20 by retraversing the tree and deleted

nested rollback

is said to have occurred if a partial rollback

were to be later followed by a total rollback or another partial

rollback whose point of termination is an

earlier

point in the

transaction than the point of termination of the first rollback.

from there. A CLR will be written to describe the key

deletion on page 20. This enables page-oriented redo,

which is very efficient, during restart and media recovery

[MHLPS92].

3.2.2

Restart Recovery

When restarting the transaction system after an abnormal

termination, recovery processing in ARIES involves

making three passes (analysis, redo and undo) over the

log. In order to make this processing efficient, periodically

during normal processing, ARIES takes checkpoints. The

checkpoint log records identify the transactions that are

active, their states, and the addresses of their most recently

written log records, and also the modified data (dirty data)

that is in the buffer pool. During restart recovery, ARIES

first scans the log from the last checkpoint to the end of

the log. During this analysis pass, information about dirty

data and transactions that were in progress at the time of

the checkpoint is brought up to date as of the end of the

log. The analysis pass, using the dirty data information,

determines the starting point (RedoLSN) for the log scan

of the immediately following redo pass. The analysis pass

also determines the list of transactions to be rolled back in

the undo pass. For each in-progress transaction, the LSN

of the most recently written log record will also be

determined.

Next, during the redo pass, ARIES repeats history with

respect to those updates logged on stable storage but whose

effects on the database pages did not get reflected on disk

before the system failure. This is done for the updates of

ALL transactions, including the updates of those

transactions that had neither committed nor reached the

in-doubt state of two-phase commit by the time of the

crash (i.e., even the missing updates of the so-called loser

transactions are redone).

The process of repeating history essentially reestablishes

the state of the database as of the time of the failure. A log

record's update is redone if the affected page's page_LSN

is less than the log record's LSN. The redo pass also

obtains the locks needed to protect the uncommitted

updates of those distributed transactions which will remain

in the in-doubt (prepared) state [MoLO86] at the end of

restart recovery. In contrast, in the recovery methods of

System R [GMBLL81] and DB2 V1 [Crus84], only the

missing updates of terminated and in-doubt transactions

(the nonloser transactions) are redone during the redo

pass. This is called the selective redo paradigm. In

[MHLPS92], we show why this paradigm leads to

problems when fine-granularity (i.e., smaller than page-

granularity) locking is to be supported with WAL.

The next pass is the undo pass during which all loser

transactions' updates are rolled back, in reverse

剩余16页未读，继续阅读

weixin_38624557

粉丝: 8
资源: 912

回顾与超越：ARIES恢复方法的历史演进及互联网时代的影响

js-leetcode题解3-longest-substring-without-repeating-characters.js

rh-nodejs8-nodejs-repeating-2.0.0-9.el7.noarch.rpm

rh-nodejs6-nodejs-repeating-2.0.0-9.el7.noarch.rpm

rh-nodejs6-nodejs-repeating-2.0.0-8.el7.noarch.rpm

21-recovery -ARIES.pdf

Delete-a-single-repeating.zip_Fun_ Fun_ Fun

leetcode2sumc-LeetCode-3.Longest_Substring_Without_Repeating_Characters

js代码-3. Longest Substring Without Repeating Characters

react-native-push-notification.zip

jpgc-prmctl-0.4.zip

最新资源