An algorithm for minimizing roll back cost

0. Introduction Most automatic crash recovery mechanisms for database systems are based on the concept of transaction commitment. Speaking very informally, when the system designamtes a transaction to be committed, it "promises" to install in the database all the updates effected by that transaction. Put another way, should a crash occur after a transaction has become committed, the transaction may not be restarted. If, however, a _ crash occurs before a transaction has become committed, that transaction must be restarted. Several mechanisms that achieve this behavior have been proposed by database system designers (e.g. [R 751, [Lo 771, [G 781, [Li 791). In all these systems, when a transaction is restarted, it is "rolled back" all the way to the beginning. One exception to this rule is System-R which allows to roll an uncommitted transaction back to an earlier "savepoint", which is not necessarily its beginning [A 761. In this paper we investigate the problem of finding the optimal set of savepoints (one per transaction) to which uncommitted transactions executing concurrently must be rolled back after a crash, so that the recovery cost is minimized. This paper is organized as follows. Section 1 informally motivates the problem. In Section 2 we present a more formal model of transaction execution in terms of which our results are stated and proved. In Section 3 we give an algorithm for the problem under consideration and prove its correctness and optimality. In many environments, cascading restarts are considered intolerable, and sufficiently restrictive schedulers are used Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the ,title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. to prevent them. In such environments the problem dealt with in this paper has a trivial solution. This issue is discussed in Section 4. 1. The Problem-We consider a database system in which transactions operate on the database concurrently. The system periodically takes "transaction save-points" for the transactions currently active. A transaction savepoint involves saving the current state of a transaction in non-volatile storage. What exactly constitutes the "current state" of a transaction depends on details that we do not care to …