In this paper we present a simple and efficient method, called ARIES ( Algorithm for Recouery and Isolation Exploiting Semantics), which supports partial rollbacks of transactions, finegranularity (e.g., record) locking and recovery using write-ahead logging (WAL). We introduce the paradigm of repeating history to redo all missing updates before performing the rollbacks of the loser transactions during restart after a system failure. ARIES uses a log sequence number in each page to correlate the state of a page with respect to logged updates of that page. All updates of a transaction are logged, including those performed during rollbacks. By appropriate chaining of the log records written during rollbacks to those written during forward progress, a bounded amount of logging is ensured during rollbacks even in the face of repeated failures during restart or of nested rollbacks We deal with a variety of features that are very Important in building and operating an industrial-strength transaction processing system ARIES supports fuzzy checkpoints, selective and deferred restart, fuzzy image copies, media recovery, and high concurrency lock modes (e. g., increment /decrement) which exploit the semantics of the operations and require the ability to perform operation logging. ARIES is flexible with respect to the kinds of buffer management policies that can be implemented. It supports objects of

In this paper, a terminological framework is provided for describing different transaction-oriented recovery schemes for database systems in a conceptual rather than an implementation-dependent way. By introducing the terms materialized database, propagation strategy, and checkpoint, we obtain a means for classifying arbitrary

A number of recent studies have examined the performance of concurrency control algorithms for database management systems. The results reported to date, rather than being definitive, have tended to be contradictory. In this paper, rather than presenting “yet another algorithm performance study,” we critically investigate the assumptions made in the models used in past studies and their implica-tions. We employ a fairly complete model of a database environment for studying the relative performance of three different approaches to the concurrency control problem under a variety of modeling assumptions. The three approaches studied represent different extremes in how transaction conflicts are dealt with, and the assumptions addressed pertain to the nature of the database system’s resources, how transaction restarts are modeled, and the amount of information available to the concurrency control algorithm about transactions ’ reference strings. We show that differences in the underlying assumptions explain the seemingly contradictory performance results. We also address the question of how realistic the various assumptions are for actual database systems.

this paper is organized as follows. We begin with an overview of the kind of recovery properties desirable for a storage system and follow this with a description of related work---one part of which is a key foundation for the Mime architecture. Next, we introduce the functionality and architecture of Mime itself at high level, and follow that with a description of the components of the Mime architecture. We analyze the performance impact of Mime on both existing file systems and new ones that exploit the new functionality, and conclude with a summary of results, and current status.

In spite of the wide variety of concurrency control and recovery mechanisms proposed during the past decade, the behavior and the performance of various concurrency control and recovery mecha-nisms remain largely not well understood. In addition, although concurrency control and recovery mechanisms are intimately related, the interaction between them has not been adequately explored. In this paper, we take a unified view of the problems associated with concurrency control and recovery for transaction-oriented multiuser centralized database management systems, and we present several integrated mechanisms. We then develop analytical models to study the behavior and compare the performance of these integrated mechanisms, and we present the results of our performance evalua-tion.

This report deals with the design and evaluation of a "two-level" failure recovery scheme for distributed systems. In our previous work [30, 32], we motivated a "two-level" recovery approach that tolerates the more probable failures with a low overhead, and less probable failures with possibly higher overhead. The two-level approach can achieve a smaller overhead as compared to traditional recovery schemes. The contributions of this report are summarized below: ffl We present and evaluate a "two-level" recovery scheme that is suitable for a network of workstations, each workstation having a local disk. The recovery scheme presented in the report can tolerate transient processor failures with a low overhead, while other failures require a larger overhead. The report presents analysis of the average (expected) task completion time using the proposed scheme. This scheme has been implemented on a workstation cluster. Our analysis indicates that the proposed two-level recovery scheme can a...

Most of the distributed recovery schemes proposed in the literature are designed to tolerate arbitrary number of failures, with a few notable exceptions of schemes designed to tolerate single failures. In this report, we demonstrate that, it is often advantageous to use "multi-level" recovery schemes. A "multi-level" recovery scheme is one that can tolerate different number of faults at different costs, tolerance of larger number of failures requiring larger costs. The costs are incurred during failure-free operation as well as during recovery. To demonstrate the advantages of multi-level recovery, we analyze a hypothetical 2-level recovery scheme that takes two different types of checkpoints, namely, 1checkpoints and N-checkpoints. A single failure can be tolerated by rolling the system back to a 1-checkpoint, while multiple failure recovery is possible by rolling back to an N-checkpoint. The cost of a 1-checkpoint may be expected to be smaller than that of an N-checkpoint. For such a...

A conventional transaction manager implemented by a database management system (DBMS) was compared against one implemented within an operating system (OS) in a variety of simulated situations. Models of concurrency control and crash recovery were constructed for both environments, and the results of a collection of experiments are presented in this paper. The results indicate that an OS transaction manager incurs a severe performance disadvantage and appears to be feasible only in special circumstances. 1.

INTRODUCTION Current databases need logging and recovery to maintain the correctness properties of transactions and consistency of the database under failures. Also, logging and recovery have tremendous performance implications. While there has been a lot of work that deals with logging and recovery algorithms for traditional disk resident databases ([1, 2, 3, 4, 5]) and Main Memory Databases (MMDB) ([6, 7]), researchers have not systematically explored the issue of logging and recovery in Real-Time Databases (RTDB). In fact, there is a need 109 110 REAL-TIME DATABASE SYSTEMS: ARCHITECTURE AND TECHNIQUES for designing new algorithms for logging and recovery in RTDBs because the sequential nature of logging and the lack of time and priority cognizance during recovery are not in tune with the priority oriented and preemptive nature of activities in RTDBs. This chapter motivates the need to do logging and recovery differently in Real-Time Databas

: Database Recovery is responsible for preserving the database consistency after a failure of any kind (transaction, system or media). Relevant information solely for recovery is saved in a log during normal transaction processing. To recover from a failure, basically two operations: undo and redo are applied with the help of the log on the last consistent state of the database. These two operations can be combined in four different ways to define four different types of recovery algorithms: "undo-redo", "no undo-redo", "undo-no redo" and "no undo-no redo". Each of these algorithms manages log and updates to the database differently, which affect the overall performance and the availability of the database. To our knowledge, not much work has been done on the performance of recovery algorithms. There are only six reports available and these works have concentrated their studies only on a few algorithms. They have mainly used queuing approach, which we believe is not adequate for a det...