Theo Haerder and Andreas Reuter. Principles of transaction-oriented database recovery. COMPSUR, 15(4):287--317, 1983.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....We also argue against the use of any type of global checkpointing for a federated or multidatabase system. Keywords: checkpointing, distributed, databases 1. Introduction Database recovery has long been recognized as an important research topic with respect to database transaction processing [18, 20, 21, 62]. The checkpointing issues are well understood and many proposed techniques exist for both centralized and distributed databases. While there have been many surveys for recovery in distributed databases [25, 3, 48] and surveys for centralized checkpointing and recovery [2, 21] there has been ....

....processing [18, 20, 21, 62] The checkpointing issues are well understood and many proposed techniques exist for both centralized and distributed databases. While there have been many surveys for recovery in distributed databases [25, 3, 48] and surveys for centralized checkpointing and recovery [2, 21], there has been little work comparing all proposed checkpointing schemes for distributed databases. This is the objective of this paper. While there is much published work on checkpointing of distributed systems [7, 26, 35, 64] we concentrate only on checkpointing of distributed database ....

[Article contains additional citation context not shown here]

Theo Haerder and Andreas Reuter. Principles of transaction-oriented database recovery. ACM Computing Surveys, 15(4):287--317, December 1983.

....be used when a site recovers from a failure enforces certain constraints on buffer management, directing buffer manager to force certain pages to the disk at particular times, and not allowing it to write certain pages to the disk at some other times. This issue is discussed in elaborate detail in [42, 43]. A page modified by a transaction that has not yet committed is a dirty page until either the commit or the abort of the transaction is completed. Based on how the buffer manager handles the dirty and clean pages the buffer management policies can be classified as follows: Steal No Steal Policy ....

Theo Haerder and Andreas Reuter, "Principles of Transaction-Oriented Database Recovery", ACM Computing Surveys.

....2.3.4 Transactions A special class of operations, transactions, are executed in a manner which guarantees the semantic properties of: atomicity, consistency, isolation, and durability. Collectively referred to as ACID by Harder and Reuter, these are the defining properties of transactions [Harder83, Gray93] Atomicity requires that each transaction either completes successfully or leaves the system unchanged. Atomic transactions eliminate the need for programmers to interpret and correct incomplete state changes and therefore greatly simplify the process of coping with errors [Lomet77, ....

Harder, T. and Reuter, A. "Principles of transaction-oriented database recovery." Computing Surveys 15(4). (December 1983) 287-317.

....and automated business processes. The transactions in such environments require to access data held in multiple autonomous database systems for a long duration. To support the long lived transactions in these environments, it is impossible or unrealistic to go on keeping all the ACID properties [7] supported by traditional transactions. To overcome the limitations of the traditional transaction model, many advanced transaction models have been proposed [1] Most of them have taken the application semantics into account and provided some semantic mechanisms for programmers. For examples, the ....

T. Harder and A. Reuter. Principles of transactionoriented database recovery. ACM Computing Surveys, 15(4):287--317, 1983.

....the collection as a whole should appear as an atomic action. The notion of atomic actions is much like the transaction concept in database theory and so it is useful to examine for a moment the traditional transaction. Typically, a transaction is characterized by the following set of properties [HR83,GMB 81] Consistency. A transaction preserves the set of invariant properties which the system must satisfy. Although in the course of execution, a transaction may momentarily cause some property to be violated, all such properties are again satisfied by the time the transaction is ....

Theo Haerder and Andreas Reuter. Principles of transaction-oriented database recovery. Computing Surveys, 15(4):287--317, December 1983.

....when it joins the transaction. Eventually, the client ends the transaction by issuing another request to the OTS which coordinates the commit procedure with all objects involved in this transaction on behalf of the client. Thus, the OTS manager is responsible of maintaining the ACID properties [11] of the registered resource objects with respect to a transaction in the presence of 3 failures. Application Objects Client Object Implementation Common Object Services (COSS) Common Facilities (CFA) Object Request Broker (ORB) Figure 1. The OMA Framework. There are many CORBA compliant ....

T. Harder and A. Reuters, "Principles of Transaction-Oriented Database Recovery", Computing Surveys, vol. 15, no. 4, 1983.

....is used. The definition for these terms are ( 22] 27] backward error recovery: Find an earlier (previously passed) error free state of the system and return there, by undoing what has been done since. Examples of general techniques using this approach are recovery blocks [20] and transactions [15]. forward error recovery: Find an error free state that the system is supposed to eventually reach, and perform actions to reach that state. This is often done using predefined alternative actions or replanning of what actions to use to achieve the goal [7] 27] Other criteria which have ....

....actions 3 [8] 9] 24] Attempts have been made to introduce a notion of recovery points (or blocks) in a program, specifying a legal and consistent state to return to in case of errors. This may be viewed as a weaker version of the concept of transactions as used in the data base community [15], and there is ongoing work studying the usability of these concepts in the automation area [32] 3. Examples are longjump in C and structured use of methods in C 4 of 9 Error Recovery in Automation An Overview 4.3.2 Knowledge based systems The term knowledge based systems is commonly used to ....

T. Harder and A. Reuter. Principles of Transaction Oriented Database Recovery. ACM Computing serveys 15(4):287-317, 1983

....and recoverable, it can be shown that PRED ae SR RC. Similarly, if by SR ST we denote the class of histories that are both serializable and strict, SR ST ae PRED [SWY93] 3 Serializa ilit ith rdered er ination We start this section by describing in more detail the standard recovery mechanism [HR83, BHG87, GR93] which is also assumed in the model proposed in [SWY93] In this model, a log is maintained on stable storage for recovery purposes. Note that virtually all commercial systems employ a log based recovery method [GR93] whereas deferred update methods have not been adopted in ....

T. Harder and A. Reuter. Principles of Transaction-Oriented Database Recovery. ACM Computing Surveys, 15(4):287--317, December 1983.

....operations, referred to as a transaction. Concurrency control and recovery are two of the main components for transaction management. Concurrency control enforces serializability [4, 2] which requires the effects of a history to be equivalent to a serial history. Recovery mandates recoverability [8, 2] which ensures the correctness of a history even when failures of transactions may occur. Intuitively, a history is recoverable if whenever an uncommitted transaction aborts, its effects can be wiped out without subsequently aborting any committed 1 transaction. Traditionally, a history is ....

....read write model, the operation type of an operation in an object based database depends on both the invocation and the response. Operations with the same invocation but different responses may have different conflict relations with other operations. In our model, update in place recovery strategy [8, 14] is used for the execution of operations; i.e. the effects of an operation is incorporated to an object immediately after its execution. An operation sequence is a series of operations. An operation sequence on an object is valid, if it satisfies the specification of the object. We assume that ....

[Article contains additional citation context not shown here]

T. Harder and A. Reuter. Principles of transaction oriented database recovery. ACM Computing Surveys, 15(4), December 1983. 23

....optimistic concurrency control for disconnected operation, two separate techniques for handling cache hits or and cache misses are required. When there s a cache hit, the mobile transaction model, which relaxes the traditional ACID (Atomicity, Consistency, Isolation, Durability) properties [26] and provides optimistic tentative commits may be applied to replicated objects in the cache. When there s a cache miss, individual read and write operations may be recorded in an operation log which is then replayed upon reconnection (similar to the queued RPC model described in Section 4.1. ....

T. Harder and A. Reuter. "Principles of Transaction-Oriented Database Recovery." Computing Surveys, Vol. 15, No. 4, 1983.

....a read operation. If a transaction contains one or more write operations it is called an update transaction, otherwise a read only transaction. 2.2. 1 The ACID Concept The ACID properties atomicity, consistency, isolation, and durability express requirements in the execution of a transaction [HR83] A transaction is considered a single logical entity; thus, atomicity requires that a transaction s changes to the database are atomic. Either all of them happen or none happen. If at the end of the transaction (EOT) all operations have been processed 1 see Section 2.1 2 see Section 3.2 ....

T. Harder and A. Reuter. Principles of transaction-oriented database recovery. ACM Computing Surveys, 15(4):287--317, December 1983.

....log record, what does the RM do with it 1.4 Review of Previous Research Several good textbooks and articles have been published on the subject of fault tolerance in database systems. A reader who would like to become familiar with the basic techniques and terminology of the field is referred to [20, 24, 30, 5, 26]. The remaining subsections of this section review prior research that is specifically relevant to the material in this thesis. 15 1.4.1 Disk Storage Management The Firewall Method of Disk Management Traditionally, logging has been the method of choice for fault tolerance in most database ....

....resources consumed by the transaction have essentially been wasted, and the transaction s effort will be repeated 2 Logging is not the only possible solution to the fault tolerance problem. However, it has tended to be the most popular solution for reasons of performance and efficiency. Refer to [37, 30, 2, 5, 39] for explanations of alternative methods of achieving fault tolerance (such as shadowing) and comparisons of the strengths and weaknesses of the different approaches. 3 Sophisticated fuzzy checkpoint methods allow the database to continue servicing requests from client transactions while the CM ....

[Article contains additional citation context not shown here]

Theo Haerder and Andreas Reuter. Principles of Transaction-Oriented Database Recovery. ACM Computing Surveys, 15(4):287--317, December 1983.

....requiring transactions to read only committed values. Executions that satisfy this requirement are said to avoid cascading aborts (ACA) Had88] Finally, if the database uses in place updating, it is convenient to implement the abort mechanism by restoring the before images of all aborted writes [Ver78, HR83, BHG87]. In order to use before images to eliminate the effects of aborted transactions, read and write operations on a data object x must be executed only on committed values. Executions with this property are called strict (ST) Had88] Figure 1 illustrates the relationship among the various ....

....we point out that PRED allows cascading aborts, which are undesirable from a performance point of view, and describe a modified protocol that avoids cascading aborts. 3. 1 Serializability ith Ordered Ter ination We start this section by describing in more detail the standard recovery mechanism [Ver78, HR83], which is also assumed in the model proposed by Schek, Weikum and Ye [SWY93] In this model, a log is maintained on stable storage for recovery purposes. The log is composed of a sequential set of records, each corresponding to a write operation. The log has the following properties: 1. Each log ....

T. Harder and A. Reuter. Principles of Transaction-Oriented Database Recovery. ACM Computing Surveys, 15(4):287--317, December 1983.

....this paper to avoid awkwardness. Echo was in active use from November 1990 to November 1992, when the evolution of our laboratory s hardware and software base led us to retire the system. At its peak, Echo had about 50 users. 2 For a survey of logging techniques, see Bernstein [2] and Haerder [11]. 2 that important file system operations, such as renaming a file, can be performed atomically. In none of these cases do the logging restrictions have a significant impact on file system performance, but they do make the task of implementation more difficult. Section 5 gives some detailed ....

Theo Haerder and Andreas Reuther. Principles of transaction-oriented database recovery. ACM Computing Surveys, 15(4):287--317,December 1983.

....the actual checkpointing is triggered by a programmer controlled language level interface. 5 Typically, VFT pointers reference virtual function tables corresponding to a specific executable. 62 Texas is most conducive to both no undo redo and undo no redo logging strategies as described in [HR83] Our current implementation uses a two phase, write ahead logging mechanism to provide atomic checkpoints. We implement the no undo redo strategy as shown in Figure 4.2. Persistent Store Log Virtual Memory A B H C G E F D Phase 1 Phase 2 Recovery Phase A B H C G E F D A B H ....

Theo Haerder and Andreas Reuter. Principles of Transaction-Oriented Database Recovery. ACM Computing Surveys, 15(4):287--317, December 1983.

....before the failure and includes none of the transactions that aborted before the failure or were active at the time of failure. In general, the Recovery Manager of a database system has to satisfy the A and the D in the so called ACID principle (Atomicity, Consistency, Isolation, Durability) HR83] Since there is no suitable transaction concept we are not able to use the recovery techniques of the underlying file system for recovering a database. The primary purpose of this paper is to deal with database recovery after a media failure. A media failure occurs when any part of the database ....

....5 presents our conclusions and some future work. 2 Logging and Recovery in Database Systems The log contains a sequence of entries describing updates (insert, delete, modify) that were applied to the database. There are many ways of writing log records and corresponding recovery algorithms ( HR83] Reu84] BHG87] MHL 92] and others) In the following we discuss some of the most common (and widely implemented) logging and recovery techniques. If a transaction aborts, the Recovery Manager has to reset (undo) all updates that the transaction performed. To ensure this it is necessary ....

T. Harder and A. Reuter. Principles of Transaction-Oriented Database Recovery. ACM Computing Surveys, 15(4):287--317, December 1983.

....(C) is defined differently from validity of integrity constraints. Atomicity (A) of SDAI transac tions is not guaranteed, either [16] neither is isolation (I) because concurrent access of multiple applications is outside the scope of [14] In short, durability (D) is the only ACID property [11] of an SDAI transaction conceptually supported so far. 3.3 Metadata management Unlike the common understanding of metadata in the SSDB community [8] SDAI metadata have nothing to do with application domain specifics. They are also data about data but from the database management point of ....

T. Harder and A. Reuter. Principles of transactionoriented database recovery. ACM Computing Surveys, 15(4):287--317, 1983.

....used when a site recovers from a failure enforces certain constraints on buffer management, directing buffer manager to force certain pages to the disk at particular times, and not allowing it to write certain pages to the disk at some other times. This issue is discussed in elaborate detail in [HR83, GR93] A page modified by a transaction that has not yet committed is a dirty page until either the commit or the abort of the transaction is completed. Based on how the buffer manager handles the dirty and clean pages the buffer management policies can be classified as follows: Steal No Steal ....

Theo Haerder and Andreas Reuter. Principles of Transaction-Oriented Database Recovery. ACM Computing Surveys, 15(4), 1983.

....to it: updates are externalized and the right to revoke them is waived. 7. 3 Compensation 25 This creates two kinds of consistency problems, which have to be dealt with correctly: a) In case a ConTract has to be cancelled, its global effects cannot be undone by simply restoring before images [HaRe83] rather they have to be compensated for by semantical undo, i.e. compensating actions [Gray81, GaSa87, KoLS90] Under certain circumstances other ConTract steps may be affected by this compensation. This situation must be handled adequately. b) Releasing locks early without any further ....

Harder, T., and Reuter, A. Principles of Transaction-Oriented Database Recovery. ACM Computing Surveys, 15(4), 1983.

....of transactions, it is correct, because serial executions are also correct. With ACID transactions we mean that the transactions running in our system have the properties of conventional ones, the ACID (atomicity, consistency, isolation, and durability) properties pointed out by Harder and Reuter [HR83]. In other words, our protocol neither treats the semantic knowledge of transactions in order to allow non serializable executions to be produced, nor copes it with long duration transactions (in fact, the transactions may span minutes and even hours, but are not in terms of days or months) This ....

....the execution of operations on isolated objects, and as a complement for the typed locks. 4. 3 Accessing Implicitly Locked Objects As a matter of fact, multiple abstraction relations to an object in a KB may lead to problems with the implicit locks, so that the isolation property of transactions [HR83] may be seriously corrupted. Actually, an interference arises whenever an object with two or more parents is implicitly locked by one of them. The implicit lock on a child object is only visible if it is accessed through a specific path of the graph. To illustrate this problem, let us refer to ....

Harder, T., Reuter, A.: Principles of Transaction-Oriented Database Recovery. ACM Computing Surveys, 15(4), Dec. 1983.

No context found.

Theo Haerder and Andreas Reuter. Principles of transaction-oriented database recovery. COMPSUR, 15(4):287--317, 1983.

No context found.

Theo Haerder and Andreas Reuter. Principles of transaction-oriented database recovery. COMPSUR, 15(4):287--317, 1983.

No context found.

Theo Haerder and Andreas Reuter. Principles of transaction-oriented database recovery. COMPSUR, 15(4):287--317, 1983.

No context found.

Theo Haerder and Andreas Reuter. Principles of transaction-oriented database recovery. COMPSUR, 15(4):287-317, 1983.

No context found.

Harder, T. and A. Reuter. "Principles of Transaction-Oriented Database Recovery.". Computing Surveys, Vol. 15, No. 4. 1983.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC