ARIES:一种利用日志技术支持细粒度锁定与部分回滚的事务恢复方法

16 浏览量更新于2024-07-14 收藏 4.88MB PDF 举报

ARIES（Algorithm for Recovery and Isolation Exploiting Semantics）是一项在1992年发表的创新性计算机科学研究成果，由C. Mohan、Don Haderle、Bruce Lindsay、Hamid PIRAHESH和Peter SCHWARZ等人在IBM Almaden Research Center和Santa Teresa Laboratory合作提出。该论文主要探讨了一种名为ARIES的事务恢复方法，它支持细粒度（如记录级别）的锁定以及利用写前日志（Write-Ahead Logging, WAL）实现的部分回滚。 ARIES的核心理念在于，它采用重复历史（redoing all missing updates）的方法，在系统故障后重启时，能够确保所有缺失的更新在进行交易回滚之前都已完成。这种方法通过在每个页面上使用日志序列号（log sequence number），来关联页面的状态与其已记录的更新，确保事务的完整性和一致性。 ARIES方法的关键特性包括： 1. **细粒度锁定**：ARIES支持对数据库操作进行精确到记录级别的锁定，提高了并发处理能力，减少了锁冲突，从而提升了系统的并发性能和吞吐量。 2. **部分回滚**：在发生事务失败时，ARIES允许回滚事务的一部分，而不是整个事务，这提高了恢复效率，并降低了数据丢失的风险。这种灵活性在处理大规模事务时尤为重要。 3. **写前日志（WAL）**：所有事务更新，包括回滚期间的操作，都被记录在日志中。通过巧妙地链接回滚期间的记录与正常事务进程中的记录，ARIES能够跟踪事务状态并有效地进行恢复。 4. **恢复过程**：当系统出现故障时，ARIES能够利用日志信息进行顺序的恢复操作，确保在回滚失败交易的同时，能够将所有必要的更新应用到数据库中，恢复到一个一致的状态。 5. **高效性**：ARIES的设计旨在提供简单且高效的事务管理，避免了复杂的回滚算法，从而减少了恢复时间和内存开销。 ARIES作为一种先进的数据库事务恢复技术，其设计理念和实现方式对于理解现代分布式数据库系统中的事务管理有着重要的参考价值。通过利用细粒度锁定和写前日志，ARIES不仅提高了并发性和可用性，还优化了系统恢复过程，为数据库系统的可靠性提供了强有力的支持。

ARIES: A Transaction Recovery Method .

105

Section 12 outlines the many different properties of ARIES. We conclude by

summarizing, in Section 13, the features of ARIES which provide flexibility

and efficiency, and by describing the extensions and the current status of the

implementations of ARIES.

Besides presenting a new recovery method, by way of motivation for our

work, we also describe some previously unpublished aspects of recovery in

System R. For comparison purposes, we also do a survey of the recovery

methods used by other WAL-based systems and collect information appearing

in several publications, many of which are not widely available. One of our

aims in this paper is to show the intricate and unobvious interactions

resulting from the different choices made for the recovery technique, the

granularity of locking and the storage management scheme. One cannot

make arbitrarily independent choices for these and still expect the combina-

tion to function together correctly and efficiently. This point needs to be

emphasized as it is not always dealt with adequately in most papers and

books on concurrency control and recovery. In this paper, we have tried to

cover, as much as possible, all the interesting recovery-related problems that

one encounters in building and operating an industrial-strength transaction

processing system.

2. GOALS

This section lists the goals of our work and outlines the difficulties involved

in designing a recovery method that supports the features that we aimed for.

The goals relate to the metrics for comparison of recovery methods that we

discussed earlier, in Section 1.1.

Simplicity. Concurrency and recovery are complex subjects to think about

and program for, compared with other aspects of data management. The

algorithms are bound to be error-prone, if they are complex. Hence, we

strived for a simple, yet powerful and flexible, algorithm. Although this

paper is long because of its comprehensive discussion of numerous problems

that are mostly ignored in the literature, the main algorithm itself is quite

simple. Hopefully, the overview presented in Section 3 gives the reader that

feeling.

Operation logging. The recovery method had to permit operation logging

(and value logging) so that semantically rich lock modes could be supported.

This would let one transaction modify the same data that was modified

earlier by another transaction which has not yet committed, when the two

transaction:’ actions are semantically compatible (e.g., increment/decrement

operations; see [2, 26, 45, 881). As should be clear, recovery methods which

always perform value or state logging (i. e.,

logging before-images and after-

images of modified data), cannot support operation logging. This includes

systems that do very physical —byte-oriented— logging of all changes to a

page [6, 76, 811. The difficulty in supporting operation logging is that we need

to track precisely, using a concept like the LSN, the exact state of a page

with respect to logged actions relating to that page. An undo or a redo of an

update should not be performed without being sure that the original update

ACM Transactions on Database Systems, Vol. 17, No. 1, March 1992

106 .

C. Mohan et al

is present or is not present, respectively. This also means that, if one or more

transactions that had previously modified a page start rolling back, then we

need to know precisely how the page has been affected during the rollbacks

and how much of each of the rollbacks had been accomplished so far. This

requires that updates performed during rollbacks also be logged via the

so-called compensation log records (CLRS). The LSN concept lets us avoid

attempting to redo an operation when the operation’s effect is already

present in the page. It also lets us avoid attempting to undo an operation

when the operation’s effect is not present in the page. Operation logging lets

us perform, if found desirable, logical logging, which means that not every-

thing that was changed on a page needs to be logged explicitly, thereby

saving log space. For example, changes of control information, like the

amount of free space on the page, need not be logged. The redo and the undo

operations can be performed logically. For a good discussion of operation and

value logging, see [881.

Flexible storage management.

Efficient support for the storage and manip-

ulation of varying length data is important. In contrast to systems like

IMS, the intent here is to be able to avoid the need for off-line reorganization

of the data to garbage collect any space that might have been freed up

because of deletions and updates that caused data shrinkage. It is desir-

able that the recovery method and the concurrency control method be such

that the logging and locking is logical in nature so that movements of

the data within a page for garbage collection reasons do not cause the

moved data to be locked or the movements to be logged. For an index,

this also means that one transaction must be able to split a leaf page even if

that page currently has some uncommitted data inserted by another transac-

tion. This may lead to problems in performing page-oriented undos using the

log; logical undos may be necessary. Further, we would like to be able to let

a transaction that has freed up some space be able to use, if necessary, that

space during its later insert activity [50]. System R, for example, does not

permit this in data pages.

Partial rollbacks. It was essential that the new recovery method sup-

port the concept of savepoints and rollbacks to savepoints (i.e., partial

rollbacks). This is crucial for handling, in a user-friendly fashion (i. e.,

without requiring a total rollback of the transaction), integrity constraint

violations (see [1, 311), and problems arising from using obsolete cached

information (see [49]).

Flexible buffer management. The recovery method should make the least

number of restrictive assumptions about the buffer management policies

(steal, force, etc.) in effect. At the same time, the method must be able to

take advantage of the characteristics of any specific policy that is in effect

(e.g., with a force policy there is no need to perform any redos for committed

transactions.) This flexibility could result in increased concurrency, decreased

1/0s and efficient usage of buffer storage. Depending on the policies, the

work that needs to be performed during restart recovery after a system

ACM Transactions on Database Systems, Vol. 17, No. 1, March 1992

ARIES: A Transaction Recovery Method . 107

failure or during media recovery maybe more or less complex. Even with

large main memories, it must be noted that a steal policy is still very

desirable. This is because, with a no-steal policy, a page may never get

written to nonvolatile storage if the page always contains uncommitted

updates due to fine-~anularity locking and overlapping transactions’ updates

to that page. The situation would be further aggravated if there are long-

running transactions. Under those conditions, either the system would have

to frequently reduce concurrency by quiescing all activities on the page (i.e.,

by locking all the objects on the page) and then writing the page to non-

volatile storage, or by doing nothing special and then paying a huge restart

redo recovery cost if the system were to fail. Also, a no-steal policy incurs

additional bookkeeping overhead to track whether a page contains any

uncommitted updates. We believe that, given our goal of supporting semanti-

cally rich lock modes, partial rollbacks and varying length objects efficiently,

in the general case, we need to perform undo logging and in-place updating.

Hence, methods like the transaction workspace model of AIM [46] are not

general enough for our purposes. Other problems relating to no-steal are

discussed in Section 11 with reference to IMS Fast Path.

Recovery independence.

It should be possible to image copy (archive dump),

and perform media recovery or restart recovery at different granularities,

rather than only at the entire database level. The recovery of one object

should not force the concurrent or lock-step recovery of another object.

Contrast this with what happens in the shadow page technique as imple-

mented in System R, where index and space management information are

recovered lock-step with user and catalog table (relation) data by starting

from an internally consistent state of the whole database and redoing changes

to all the related objects of the database simultaneously, as in normal

processing. Recovery independence means that, during the restart recovery of

some object, catalog information in the database cannot be accessed for

descriptors of that object and its related objects, since that information itself

may be undergoing recovery in parallel with the object being recovered and

the two may be out of synchronization [141. During restart recovery, it should

be possible to do selective recovery and defer recovery of some objects to a

later point in time to speed up restart and also to accommodate some offline

devices. Page-oriented recovery means that even if one page in the database

is corrupted because of a process failure or a media problem, it should be

possible to recover that page alone. To be able to do this efficiently, we need

to log every page’s change individually, even if the object being updated

spans multiple pages and the update affects more than one page. This, in

conjunction with the writing of CLRS for updates performed during rollbacks,

will make media recovery very simple (see Section 8). This will also permit

image copying of different objects to be performed independently and at

different frequencies.

Logical undo. This relates to the ability, during undo, to affect a page

that is different from the one modified during forward processing, as is

ACM Transactions on Database Systems, Vol. 17, No. 1, March 1992.

剩余68页未读，继续阅读

weixin_38710578

粉丝: 4
资源: 932

ARIES:一种利用日志技术支持细粒度锁定与部分回滚的事务恢复方法

ARIES论文英文版

Write-ahead Logging

ARIES机制介绍

ARIES - A Transaction Recovery Method Supporting xxxx

Repeating History Beyond ARIES - C. Mohan (VLDB Conf, 1999)-计算机科学

SegmentBased Recovery: Writeahead logging revisited

aries-sdk-javascript

aries-cloudagent-webhook-relay:Hyperledger Aries Cloud Agent-Webhook中继

aries-acapy-fullstack-starter

aries-deployer-3.0-M1-sources.jar

最新资源