To achieve high concurrency in a database system has meant building a system that copes well with important special cases. Recent work on multilevel systems suggests a systematic way of providing high concurrency. A multi-level system using locks permits restrictive low level locks of a subtransaction to be replaced with less restrictive high level locks when a subtransaction commits, hence enhancing concurrency. This is possible because sub-transactions can be undone by executing high level compensation actions rather than by restoring a prior lower level state. We describe a recovery scheme, called Multi-Level Recovery (MLR) that logs this high level undo operation with the commit record for the subtransaction that it compensates, posting log records to only a single log. A variant of the method copes with nested transactions, and both nested and multi-level transactions can be treated in a unified fashion. Keywords: multi-level transactions, logging, recovery, hierarchical systems c...

In this paper, we address the correctness and performance issues that arise when implementing logging and crash recovery in a page-server environment. The issues result from two characteristics of page-server systems: 1) the fact that data is modified and cached in client database buffers that are not accessible by the server, and 2) the performance and cost tradeoffs that are inherent in a client-server environment. We describe a recovery system that we have implemented for a particular page-server system: the client-server version of the EXODUS storage manager. The implementation supports efficient buffer management policies, allows flexibility in the interaction between clients and the server, and reduces the load on the server by performing much of the work involved in generating log records at clients. We also present a preliminary performance analysis of the implementation, examining the relative costs of logging and recovery operations and identifying areas for future improvement. 1.

: This paper defines a framework for explaining redo recovery after a system crash. In this framework, an installation graph explains the order in which operations must be installed into the stable database if it is to remain recoverable. This installation graph is a significantly weaker ordering on operations than the conflict graph from concurrency control. We use the installation graph to devise (i) a cache management algorithm for writing data from the volatile cache to the stable database, (ii) the specification of a redo test used to choose the operations on the log to replay during recovery, and (iii) an idempotent recovery algorithm based on this test; and we prove that these cache management and recovery algorithms are correct. Most pragmatic recovery methods depend on constraining the kinds of operations that can appear in the log, but our framework allows arbitrary logged operations. We use our framework to explain pragmatic methods that constrain the logged operations to re...

Providing high concurrency in B + -trees has been studied extensively. But few efforts have been documented for combining concurrency methods with a recovery scheme that preserves well-formed trees across system crashes. We describe an approach for this that works for a class of index trees that is a generalization of the B link -tree. A major feature of our method is that it works with a range of different recovery methods. It achieves this by decomposing structure changes in an index tree into a sequence of atomic actions, each one leaving the tree well-formed and each working on a separate level of the tree. All atomic actions on levels of the tree above the leaf level are independent of database transactions, and so are of short duration. Keywords: concurrency, recovery, indexing, access methods, B-trees c flDigital Equipment Corporation and Betty Salzberg 1991. All rights reserved. 1 College of Computer Science, Northeastern University, Boston, MA. This work was partially s...

Abstract We present a cost-effective method for improving data availability during restart recovery of a data base management system (DBMS) after a failure. The method achieves its objective by enabling the processing of new transactions to be-gin even before restart recovery is completed by exploiting the Comnlt-rs~V concept. It supports fine-granularity (e.g., record) locking with semantically-rich lock modes and operation logging, partial roll-backs, write-ahead logging, and the steal and no-force buffer management policies. The over-head imposed by this method during normal trans-action processing is insignificant. We require very few changes to an existing DBMS in order to sup-port our method. Our method can be implemented with different degrees of sophistication depending on the existing features of a DBMS. 1.

In this paper, we propose logging and recovery algorithms for distributed architectures that use local disk space to provide transactional facilities locally. Each node has its own log file where all log records for updates to locally cached pages are written. Transaction rollback and node crash recovery are handled exclusively by each node and log files are not merged at any time. Our algorithms do not require any form of time synchronization between nodes and nodes can take checkpoints independently of each other. Finally, our algorithms make possible a new paradigm for distributed transaction management that has the potential to exploit all available resources and improve scalability and performance. 1 Introduction The proliferation of inexpensive workstations and networks has created a new era in distributed computing. At the same time, non-traditional applications such as computer aided design (CAD), computer aided software engineering (CASE), geographic information systems (GIS...

Modern database systems provide media recovery by taking periodic backups and applying a transaction log to the backup to bring the data up-to-date. A multi-versioned database is one that retains and provides access to historical versions of data. This paper shows how a history database, supported by the Time-Split B-tree, can be used to also provide the backup function of media recovery. Thus, the same versions used for database history are used for database backup. The cost of taking a backup is comparable to the cost of a good differential backup method, where only changed data is backed up. The media recovery cost, especially when the media failure is only partial, e.g. a single disk page, will usually be lower. Keywords: media recovery, multiversioned data, access methods c flDigital Equipment Corporation and Betty Salzberg 1990. All rights reserved. 1 College of Computer Science, Northeastern University, Boston MA. This work was partially supported by NSF grant IRI-88-15707 an...

In this work, we develop concepts for implementing a logging and recovery component to deal with node crashes in a shared-disk system environment. This is done, using several previously published strategies and adapting those algorithms to fit our special system needs. Our environment is characterized by the following issues: the global lock manager is statically distributed among the system's nodes and employs a hierarchical synchronization protocol for efficient transaction processing. A local lock manager on each node administers local lock requests. Committed modifications to a data page are administrated by the respective page owner, which may - in order to allow maximum adaptability - dynamically migrate across the system. These distribution aspects evoke special problems for the logging component of the system, which are discussed in this paper in detail. We present two logging strategies and discuss their tradeoffs with respect to system performance, recovery costs a...

Abstract. This paper presents an adaptation of the ARIES recovery algorithm that solves the problem of recovery in Shared Disk (SD) database systems, whilst preserving all the desirable properties of the original algorithm. Previous such adaptations of the ARIES algorithm have failed to solve some of the problems associated with SD systems, resulting in a number of undesirable compromises being made. The most significant problem is how to assign log sequence numbers (LSNs) in such a way that the system is recoverable after a crash. Existing adaptations have required, among other things, a perfectly synchronised global clock and a central merge of log data either during normal processing or crash recovery, which clearly imposes a significant overhead on the database system. This adaptation of ARIES removes this requirement entirely, meaning that log merges and synchronised clocks become entirely unnecessary. Further enhancements that allow the Redo and Undo phases of recovery to be performed on a page-by-page basis have significantly reduced the recovery time. Additionally, it is possible for the database to return to normal processing at the end of the Analysis phase, rather than waiting for the recovery process to complete. 1

The shift to multi-core hardware brings new challenges to database systems, as the software parallelism determines performance. Even though database systems traditionally accommodate simultaneous requests, a multitude of synchronization barriers serialize execution. Write-ahead logging is a fundamental, omnipresent component in ARIES-style concurrency and recovery, and one of the most important yet-to-be addressed potential bottlenecks, especially in OLTP workloads making frequent small changes to data. In this paper, we identify four logging-related impediments to database system scalability. Each issue challenges different level in the software architecture: (a) the high volume of small-sized I/O requests may saturate the disk, (b) transactions hold locks while waiting for the log flush, (c) extensive context switching overwhelms the OS scheduler with threads executing log I/Os, and (d) contention appears as transactions serialize accesses to in-memory log data structures. We demonstrate these problems and address them with techniques that, when combined, comprise a holistic, scalable approach to logging. Our solution achieves a 20%-69% speedup over a modern database system when running log-intensive workloads, such as the TPC-B and TATP benchmarks. Moreover, it achieves log insert throughput over 1.8GB/s for small log records on a single socket server, an order of magnitude higher than the traditional way of accessing the log using a single mutex. 1.