GRAY, J., MCJONES, P., BLASGEN, M., LINDSAY, B., LORIE, R., PRICE, T., PUTZOLU, F., AND TRAIGER, I. The recovery manager of the System R database manager. ACM Computing Surveys 13, 2 (1981), 223--242.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....uncompressed format. Zebra s deltas improved upon this by storing only the changes to the metadata, but were designed exclusively for roll forward (a write ahead log) Database systems also use the roll back and roll forward concepts to ensure consistency during transactions with commit and abort [14]. Several systems have used copy on write and differencing techniques that are common to versioning systems to decrease the bandwidth required during system backup or distributed version updates [4, 6, 26, 31, 32] Some of these data differencing techniques [5, 26, 31] could be applied to CVFS to ....

J. Gray, P. McJones, M. Blasgen, B. Lindsay, R. Lorie, T. Price, F. Potzulo, and I. Traiger. The recovery manager of the System R database manager. ACM Computing the official policies or endorsements, either expressed or implied, of the Air Force Research Laboratory or the U.S. Government. Surveys, 13(2):223--242, June 1981.

....operations in the Vagabond approach. Finally, in Section 5, we conclude the paper. 2 Related work No overwrite strategies have been used previously in several approaches. One example is variants of shadow paging recovery strategies that were used in early database systems, e.g. in System R [3]. However, the performance has not been satisfactory using these strategies. The main reasons for this, were limited buffer size in combination with unclustered data, and relatively large amounts of metadata that had to be written during the commit process. POSTGRES [21, 22] also employed a ....

J. Gray et al. The recovery manager of the System R database manager. ACM Computing Surveys, 13(2), 1981.

....subtle, complex algorithms that would benefit from a more rigorous analysis. For example, it would be interesting to use our framework to model some of the complex trans action processing algorithms that tolerate processor crashes, i.e. failures that obliterate the contents of volatile memory [ 14]. Similarly, algorithms that manage orphans resulting from node crashes in distributed systems [22] are complex, yet no rigorous proof exists. It would also be interesting to integrate our approach more closely with the classical approach, to try to combine the advantages of both. Our framework is ....

J. GRAY, R. LORIE, A. PUTZULO AND J. TRAIGER, The recovery manager of the System R Database Manager, ACM Cornput. Surveys 13, No. 2 (1981), 223-242.

....be released. By waiting until a timeout expired before completing a request with an error return code, the server would reduce the probability that clients observe lock conflicts. 7 Related Work The concept of transactions has been accepted and used in database systems for many years. Both local [7] and distributed [12] database systems have been implemented that provide the failure atomicity, recoverability, and isolation properties of transactions. These concepts have also been extended to specific servers pro vided by operating systems. Locus [18] provides a trans actional file system, ....

Jim Gray, Paul McJones, Mike Blasgen, Bruce Lindsay, Raymond Lorle, Tom Price, Franco Putzolu, and Irving Traiger. The recovery manager of the System R database manager. ACM Computing Surveys, 13(2):223-242, June 1981.

....to CVFS. While journal based metadata is a new concept, journaling has been used in several different file systems to provide metadata consistency guarantees efficiently [8, 9, 11, 39, 42] Database systems also use the roll back and roll forward concepts to ensure consistency during transactions [13]. Several systems have used copy on write and differencing techniques that are common to versioning systems to decrease the bandwidth required during system backup or distributed version updates [4, 6, 25, 30, 31] Specifically, some of these data differencing techniques [5, 25, 30] could be ....

Jim Gray, Paul McJones, Mike Blasgen, Bruce Lindsay, Raymond Lorie, Tom Price, Franco Potzulo, and Irving Traiger. The recovery manager of the System R database manager. ACM Computing Surveys, 13(2):223--242, June 1981.

....Both the system and its users could be bolder in their actions. The system could take more initiative in performing actions on behalf of a user, and a user would be less hesitant to try powerful and perhaps unfamiliar commands. Recovery has long been important in database management systems [6, 7, 11, 17]. Recovery in database systems is motivated by the possibility of system failures. Since failures are infrequent events, the corresponding recovery facilities can be expensive both in time and space and need not be especially easy to use. We are concerned with a user s recovery from his own prior ....

GRAY, J., MCJONES, P., BLASGEN, M., LINDSAY, B., LORIE, R., PRICE, T., PUTZOLU, F., AND TRAIGER, I. The recovery manager of the system R database manager. Cornput. Surv. 13, 2 (June 1981), 223-242.

....effects of the committed transactions and none of the effects of aborted ones [10] Most importantly, this guarantee is valid even in the presence of transaction or system failures. Two well known mechanisms for achieving the recovery objective are shadowpaging [61] and write ahead logging (WAL) [33]. In addition, for distributed databases, a commit protocol has to be implemented to ensure that all sites participating in the distributed execution of the transaction agree on the final decision (commit or abort) A large number of such commit protocols have been designed including the classical ....

J. Gray, P. R. McJones, and M. Blasgen, "The Recovery Manager of the System R Database Manager", ACM Computing Surveys, Vol. 13, No. 2. Transaction Processing: Concepts and Techniques, Morgan-Kaufmann, 1993.

....DAGs may be executed directly without first being translated into an intermediate form. More importantly, modeling with graphs has enabled us to simplify and automate error recovery. To do this, we employ an undo redo error recovery scheme, similar to the one used in the System R recovery manager [Gray81]. In our approach, if a primitive operation fails at any time during the execution of a graph, the execution mechanism will automatically undo the effects of the previously completed primitives. In this section, we describe node states and their transitions, how to execute a graph, and how to ....

Gray, J., McJones, P., Blasgen, M., Lindsay, B., Lorie, R., Price, T., Putzolu, F., and Traiger, I. "The recovery manager of the System R database manager." Computing Surveys, Vol. 13, No. 2. June 1981, pp. 223-242.

....processes. Hence, process locking applies this strategy to enforce the correct completion of partial process schedules. This distinguished completing process then has a special status and will be preferred against all other processes, much like the golden transaction of the System R database [12], the only transaction of the system that is allowed to perform undo operations at a time. 3.2 Process Locking: The Core Protocol In short, the process locking protocol is based on and extends ideas of locks with constrained sharing [1] and timestamp ordering [27, 6] In what follows, we will ....

J. Gray, P. McJones, M. Blasgen, B. Lindsay, R. Lorie, T. Price, F. Putzolu, and I. Traiger. The Recovery Manager of the System R Database Manager. ACM Computing Surveys, 13(2):223--243, June 1981.

..... Is compatible with, and further enhances, existing index management schemes to support high performance operation, and . Does not require a new method to handle recovery, i.e. each Global Index or Local Index can be recovered separately in a conventional way (e.g. as in System R [GrMc81] or ARIES [MoHa92, Moha99] We assume that the readers of this paper are familiar with the System R lock modes, the compatibility relationships amongst them and the durations of locking [GrLo76, MoLe92, Mo90b] We also assume that each Global or Local Index is implemented using a B tree. ....

Gray, J., McJones, P., Blasgen , M., Lindsay, B., Lorie, R., Price, T., Putzolu, F., and Traiger, I., The Recovery Manager of the System R Database Manager, ACM Computing Surveys , Vol. 13, No. 2, June 1981. 16

....log only approach. In Section 4 we describe in detail the algorithms for the most important operations in the Vagabond approach. Finally, in Section 5, we conclude the paper. 2 Related work No overwrite strategies have been used in shadow paging recovery strategies earlier, e.g. in System R [3], but with the limited buffer size at that time, the performance was not satisfactory. POSTGRES [17] also employed a no overwrite strategy, but had also its performance problems, for several reasons, the most important being the buffer force strategy used. Vagabond is based on the same philosophy ....

J. Gray, P. McJones, M. Blasgen, B. Lindsay, R. Lorie, T. Price, F. Putzolu, and I. Traiger. The recovery manager of the System R database manager. ACM Computing Surveys, 13(2), 1981.

....pages it has written have become physically guarded. It will be useful to periodically delay transactions which wish to FREE a hot spot page so that the current writers of the page can finish and the page can be GUARDED. This is similar in concept to action consistent checkpoints discussed in [GRAY81]. There are additional details that concern how to preserve the data structure which holds the mapping of disk pages to buffer pages. However, space precludes an explanation here. Also, assuming that the I O system does not write blocks to the wrong place along with Assumptions 1 and 2 above, our ....

Gray, J. et. al., "The Recovery Manager of the System R Database Manager," Computing Surveys, June 1981.

....and the Charlotte system (cf. section 2.10) Reference: 374] 375] 376] 377] RSS RSS was developed at the IBM San Jose Research Lab. as part of the system R project. RSS is the layer of the system R which is responsible for transaction management and database recovery. Reference: [378] ( 82] RT PC Distributed Services RT PC Distributed Services provides distributed operating system capabilities for the AIX operating system. These include a distributed file system and distributed interprocess communication. Transparency is achieved by remote mounts of files or file systems. ....

J.N. Gray, P. McJones, M.W. Blasgen, R.A. Lorie, T.G. Price, G.F. Putzulu, and I.L. Traiger, "The Recovery Manager of the System R Database Manager", ACM Computing Surveys, 13(2):223--242, June 1981.

....the data from the flow of data records between the executor M311 and the file access routine M101. This flow includes data identification and content. Positioning the logger M621 at this point in the flow means that the logger accesses records, rather than blocks. This follows current conventions [Gray 81] but does not permit file restoration using after images from media crashes. It also does not protect information loss due to failures of the M101 and M102 modules, which could damage other data in the blocks obtained. A restoration in our architecture requires replay of past transactions. ....

....in the schema M201 and obtained from a schema interpreter. c. The logger should not maintain internal state, so that its operation is unaffected by system failures. All its information is within the files that is used to log the information. This assures one aspect of idempotency as defined by [Gray 81] 4.M622. Recovery Manager (L2) a. The recovery manager repairs damaged databases and assists in the recovery from transaction aborts for optimistic transaction protocols. Recovery management is initiated either 1. Automatically by the operating system during its recovery from a detected ....

J. Gray, et al., "The Recovery Manager of the System R database Manager" ACM Computing Surveys, Vol. 13 No. 2, Jun 1981, pp. 223--242.

....ensure that the appropriate action can be taken on a failure, the record must be placed in stable storage before the update takes place. The complexity of transaction mechanisms provided by a system may be extremely varied. For example, consider a traditional database system such as IBM s System R[gra81]. System R supports several complex transactions operating concurrently, implemented by a combination of logging and checkpointing. Logging takes the form of recording all operations on stable storage before the operation is performed. In addition to the normal operations, a record is kept of any ....

Gray J., McJones P., Blasgen M., Lindsay B., Lorie R., Price T., Putzolu F. & Traiger I. The Recovery Manager of the System R Database Manager. ACM Computing Surveys, vol. 13, no. 2, June 1981, pp223-242.

....6 we present analytical models for an IPU TODB and an LO TODB. In Section 7 we compare the performance of IPU and LO TODBs. Finally, in Section 8, we conclude the paper. 2. RELATED WORK No overwrite strategies have been used in shadow paging recovery strategies earlier, e.g. in System R [2], but with the limited bu er size at that time, the performance was not satisfactory. POSTGRES [11] also employed a no overwrite strategy, but had also its performance problems, for several 1 From Webster s Encyclopedic Unabridged Dictionary: Vagabond: a person, usually without a permanent home, ....

J. Gray, P. McJones, M. Blasgen, B. Lindsay, R. Lorie, T. Price, F. Putzolu, and I. Traiger. The recovery manager of the System R database manager. ACM Computing Surveys, 13(2), 1981.

....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 ....

....a fixed amount of disk space to hold log information. The LM manages this disk space as a circular array [3, 10] the log s head and tail pointers rotate through the positions of the array so that records conceptually move from tail to head but physically remain in the same place on disk. System R [24] is a familiar example of this traditional logging technique. The LM maintains a pointer to the oldest record in the log that must still be retained; this constitutes a firewall beyond which the head of the log cannot be advanced. Hence, this logging technique shall be referred to as the ....

Jim Gray, Paul McJones, Mike Blasgen, Bruce Lindsay, Raymond Lorie, Tom Price, Franco Putzolu, and Irving Traiger. The Recovery Manager of the System R Database Manager. ACM Computing Surveys, 13(2):223--242, June 1981. 180

....Our contribution here is new in that it shows how the results of these papers can be used for systematically developing an efficient multi level recovery algorithm. Multi level crash recovery algorithms have been implemented in the commercial database systems SQL DS (this is basically System R [Gr81]) Synapse [Ong84] and Informix Turbo [Cu88] These systems deal with 2 level transactions, where record operations are performed at the higher level and page accesses at the base level. They use a checkpoint oriented base recovery mechanism, thus adversely affecting transaction response time, ....

Gray, J., McJones, P., Blasgen, M., Lindsay, B., Lorie, R., Price, T., Putzolu, F., Traiger, I., The Recovery Manager of the System R Database Manager, ACM Computing Surveys Vol.13 No.2, 1981

....6 we present analytical models for an IPU TODB and an LO TODB. In Section 7 we compare the performance of IPU TODB and LO TODB. Finally, in Section 8, we conclude the paper. 2 Related Work No overwrite strategies have been used in shadow paging recovery strategies earlier, e.g. in System R [1, 3], but with the limited bu er size at that time, the performance was not satisfactory. POSTGRES [13] also employed a no overwrite strategy, but had also its performance problems, for several reasons, the most important being the bu er force strategy used. Vagabond is based on the same philosophy ....

J. Gray, P. McJones, M. Blasgen, B. Lindsay, R. Lorie, T. Price, F. Putzolu, and I. Traiger. The recovery manager of the System R database manager. ACM Computing Surveys, 13(2), 1981.

....to run the server process in the other configurations. The current release of Objectivity DB provides only coarse grain locking, at the level of a container, and the current B tree implementation cannot index objects distributed across multiple containers. Recovery is implemented via shadows [Gra81] During the course of a transaction, updates are written to a shadow database. At commit time, these updates are applied carefully to the actual database with a journal being used to recover in the event that the commit fails. If the transaction aborts, the shadow database is simply deleted. ....

Jim N. Gray et al. The recovery manager of the System R database manager. ACM Computing Surveys, 13(2):223 -- 242, June 1981.

....a crash. There are many methods for recovery that appear in the literature. These methods provide many specific techniques for ensuring transaction atomicity and durability, including write ahead logging, the do undo redo paradigm, forcing log records at commit, forcing pages at commit, and so on [2, 3, 4, 5, 7, 14], and much of this work has found its way into textbooks [1, 6] In addition, general methods exist for undoing nested transactions [16] and multi level transactions [10, 17, 18] We focus on redo recovery. This technique starts at some point in the log and reads to the end of the log. As it ....

J. Gray, P. McJones, M. Blasgen, B. Lindsay, R. Lorie, T. Price, and F. Putzolu. The recovery manager of the System R database manager. ACM Computing Surveys, 13(2):223--242, June 1981.

....Current database systems store data on disk and in memory. Disks are considered stable storage; they are assumed to survive system crashes and power outages. On the other hand, database systems traditionally assume that the contents of main memory (RAM) are lost whenever the system crashes [Gray81, Haerder83], an assumption that appears to have its roots in the switch from core memories to volatile DRAM [Gray78] 100 80 60 40 20 0 1994 1996 1998 Disk I O Other Normalized Execution Time ( Fig. 1. Database Execution time profile on next generation machines. This figure is taken from ....

....values may be restored if the transaction aborts. Persistent database buffer caches require an undo log for the same reason, because all updates to the buffer cache are instantly persistent, just as if they had been stolen immediately. We implement the undo log in Postgres using shadow pages [Gray81]. When the system wants to write to database buffer cache, it first copies the contents to a shadow page and points the database buffer header to the shadow page. When the transaction is ready to commit later, it atomically points the database buffer cache header to the original buffer. Recovering ....

Gray J, McJones P, Blasgen M, Lindsay B, Lorie R, Price T, Putzolu F, Traiger I (1981) The Recovery Manager of the System R Database Manager. ACM Comput Surv 13(2):223--242

....even a small amount of extra work here adds up over time. On the other hand, system crashes do not occur frequently (typically, on the order of twice a week) Usually, new transactions are allowed after the system is brought up after failure, even before the recovery is completed. Methods like [GMLB 81, Crus 84, MHLPS 92] partially recover the state of the database first, and then, while continuing with the recovery, allow normal processing on that part of the database which has been recovered. Some others use a hot standby [Borr 84] or non volatile memory [CKKS 89] for increased data ....

....Thus all transactions that started after the consistent point and aborted need not be undone. The logical log now is used 2 to redo committed transactions and to undo aborted ones (which started before the consistent point ) bringing the database to a logically consistent state. System R [GMLB 81] periodically saves an action consistent state of the data file. An incremental log is used for the undo and redo log records to save changes to shared files. Crash recovery starts with the action consistent copy of the data file and applies the redo log records to restore the lost updates. Here ....

[Article contains additional citation context not shown here]

Gray, J.N., McJones, P., Lindsay, B.G., Blasgen, M.W., Lorie, R.A., Price, T.G., Putzolu, F., Traiger, I.L. The Recovery Manager of System R Database Manager, ACM Computing Surveys, June 1981.

....sets up an intermediate save point , to which one can back up if necessary (a crash) or desired (UNDO command) however, the effects of a nested transaction invocation are not committed until the top level transaction is completed. This model resembles that of the System R recovery manager [12], and it provides, at no extra cost, the concept of save point , which we use both in defining our exception handling mechanism and in providing programmers with an explicit undo statement. For complete uniformity, we view the primitive operators modify, evaluate, create, get, etc. as predefined ....

Gray, J. et al. The recovery manager of the System R Database Manager. ACM Computing Surveys 13(2):223-242, June, 1981.

.... context our design is better than some of the commercial and prototype systems based on wal, e.g. IBM s AS=400 TM [9] CMU s Camelot [42] IBM s DB2 TM [45] Unisys s DMS 1100 [17] and Tandem s Encompass TM [3] and those systems which are based on shadow page technique such as System R [21] and SQL DS [7] Certain errors caused by computer failures and communication delays may lead to repeated executions of operations listed in the intentions list. We claim that their repetition in RHODOS does not produce any uncertain effect. This is because the syntax and semantics of the ....

Gray, J., McJones, P., Blasgen, M., Lindsay, B., Lorie, R., Price, T., Putzolu, F., and Traiger, I.L. "The recovery manager of the system R database manager", ACM Comput. Surv. 13, 2, pp. 223-242, June 1981.

....bear no relation to the errors and may have executed for a long time, to roll back as well. This necessitates a mechanism that cancels parts of the executed operations and reexecutes the undone operations upon the user s requests without a total transaction rollback. The recovery methods[11] 6][5] used in commercial DBMSs provide such partial rollback using savepoints[11] 5] A savepoint can be established at any transaction execution point. After executing for a while, users can request canceling all the updates performed after the savepoint when they meet errors or unexpected results. ....

....back as well. This necessitates a mechanism that cancels parts of the executed operations and reexecutes the undone operations upon the user s requests without a total transaction rollback. The recovery methods[11] 6] 5] used in commercial DBMSs provide such partial rollback using savepoints[11][5]. A savepoint can be established at any transaction execution point. After executing for a while, users can request canceling all the updates performed after the savepoint when they meet errors or unexpected results. After such a partial rollback, the transaction can resume normal execution. ....

[Article contains additional citation context not shown here]

Gray, J. et al., "The Recovery Manager of the System R Database Manager," ACM Computing Surveys, Vol. 13, No. 2, pp. 223--242, June 1981.

....(1SR) Schedule: A schedule S is 1SR if the committed projection of its version function h is equal to the the committed projection of the (standard) version function h in some standard serial schedule S , and both S and S have the same transactions. 2.2. Recoverability Recovery issues [Gray81, Hadz83, Agra85, Bern87] are also vitally important to the correct operation of databases. In particular, recoverability [Hadz83] guarantees that after a failure (either transaction failure or system crash) the database can be recovered to a consistent state, at which point things can carry on as usual. Recoverability is ....

J.N. Gray, et al., "The Recovery Manager of the System R Database Manager," ACM Computing Surveys, vol. 13, no. 2, June 1981, pp. 223-242.

....that the appropriate action can be taken on a failure, the record must be placed in stable storage before the update takes place. 29 The complexity of transaction mechanism provided by a system may be extremely varied. For example, consider a traditional database system such as IBM s System R[gra81]. System R supports several complex transactions operating concurrently, implemented by a combination of logging and checkpointing. Logging takes the form of recording all operations on stable store before the operation is performed. In addition to the normal operations, a record is kept of any ....

....influence on the implementation of the stable storage is the mechanism used to record copied pages. There are two basic techniques, maintain a mapping for every page or record only those pages that have been changed. IBM s system R is an example of a system that maintains a mapping for every page[gra81,lor73]. The mapping is in the form of a page table. The entry for each page contains the address of the original version of the page and the address of the current version of the page. When a page is first modified, a free page is allocated to hold the new version of the page. Thus, the original version ....

Gray J., McJones P., Blasgen M., Lindsay B., Lorie R., Price T., Putzolu F. & Traiger I. The Recovery Manager of the System R Database Manager. ACM Computing Surveys, vol. 13, no. 2, June 1981, pp223-242.

....semantics, and a multi version visibility feature yields checkpoints and atomic snapshots, which can be combined with a concurrency control algorithm [Bernstein87, Barghouti91] to support full transactions. 1. 2 Related work Shadow based recovery schemes have been used in databases for many years [Gray81, Reuter84, Bernstein87], but their use inside the disk subsystem to provide extended recovery semantics is new. Shadowing systems have recently coming into vogue in the file system community in the guise of logstructured file systems that never overwrite active data in place [Rosenblum92] Recovery in Mime 3 3 The ....

Jim Gray, Paul McJones, Mike Blasgen, Bruce Lindsay, Raymond Lorie, Tom Price, Franco Potzulo, and Irving Traiger. The recovery manager of the System R database manager. Computing Surveys 13(2):223--42, June 1981.

....Algorithms are given to solve the associated problems. Modification of snapshots is also discussed; this may turn out to have some interesting applications. 1 Introduction Traditionally, shadow paging has been considered to have poor performance and to be unsuitable for large multi user systems [3, 7, 11, 12]. However, memory sizes have increased due to technological development, and the entire page table of even a large database can now be kept in main memory. This has removed the most important performance problem. Kent [11, 12] has shown how to use shadow paging efficiently in a multi user ....

....paging schemes in the literature. A more detailed description can be found in [24, 25] Snapshots are discussed in section 3 and their applications in section 4. 2 Concurrent Shadow Paging The shadow paging algorithm described here differs from most of the earlier algorithms in the literature [7, 16, 23], but is quite similar to the algorithm given in [12] The ideas about sequential writes and fine granularity locking are from [24, 25] The database consists of a number of disk blocks organized as pages. Each page can hold a fixed number of bytes, and is identified by a number from which its ....

[Article contains additional citation context not shown here]

J. Gray, P. McJones, M. Blasgen, B. Lindsay, R. Lorie, T. Price, F. Putzolu, and I. Traiger. The recovery manager of the System R database manager. ACM Computing Surveys, 13(2):223--242, 1981.

....transactions by allocating new physical pages for any modified pages and then atomically update the mapping to reflect the new database state. Atomic mapping update can be achieved by using two page tables and a current bit in stable storage [7] by using shadow paging together with logging [3], by recording changes in an intentions list (kind of temporary redo log) in stable storage before changing the page table [6] or by constructing a new page table which partially shares the old page table and then atomically updating a page table pointer in stable storage [5] Shadow paging has ....

J. Gray, P. McJones, M. Blasgen, B. Lindsay, R. Lorie, T. Price, F. Putzolu, and I. Traiger. The recovery manager of the System R database manager. Computing Surveys, 13(2):223--243, 1981.

....both GO processing and MV2PL rises as the update transaction size is increased. This rise is caused by a decrease in the system resource demands by update transactions due to increased lock waiting; recall that the probability of lock conflict is proportional to the square of the transaction size [Gray81, Tay85]. So that we may concentrate on the most important results, we do not show the update transaction throughput here. On the other 89 hand, MVQL query throughput drops initially, and then rises. The rise is also caused by reduced resource competition from the update transactions. The initial drop ....

Gray, J., et al., "The Recovery Manager of the System R Database Manager," ACM Computing Surveys, 13(2), June 1981.

....mechanisms and of trusted recovery can be best understood by illustrating the effect of failures and discontinuities of operation on typical systems. Informal and qualitative assumptions of failures derived from operational experience with various systems have been presented in the literature [14,15, 21]. Using these informal assumptions we can define general classes of failures that affect the operation of a TCB. One class of failures is identical to the class of errors caused when users pass wrong parameters to TCB primitives, or invoke the wrong TCB primitives, and when system resources are ....

....failures, the recovery mechanisms are always able to reconstruct either input secure states or output secure states after failures. The literature describes various approaches for providing atomicity at the operating system level [16, 21, 23, 25, 27] and at the data base management system level [14,15]. We summarize these approaches in Chapter 4. 3) Atomicity of all TCB primitives is not always necessary for trusted recovery. In many operating systems or TCB primitives, it may be difficult to ensure that all secure state transitions are atomic. Some operating system primitives consist of ....

[Article contains additional citation context not shown here]

Gray, J. N., Paul McJones, Mike Blasgen, Bruce Lindsay, Raymond Lorie, Tom Price, Franco Putzolu, and Irving Traiger, "The Recovery Manager of the System R Database Manager," Computing Surveys, 13/2, June 1981, pp.223-242.

....is Hints for Computer System Design July 1983 22 fairly easy to ensure that the log is valid no matter when a crash occurs. It is also easy and cheap to duplicate the log, write copies on tape, or whatever. Logs have been used for many years to ensure that information in a data base is not lost [17], but the idea is a very general one and can be used in ordinary file systems [35, 49] and in many other less obvious situations. When a log holds the truth, the current state of the object is very much like a hint (it isn t exactly a hint because there is no cheap way to check its correctness) ....

.... The advantages of atomic actions for fault tolerance are obvious: if a failure occurs during the action it has no effect, so that in recovering from a failure it is not necessary to deal with any of the intermediate states of the action [28] Database systems have provided atomicity for some time [17], using a log to store the information needed to complete or cancel an action. The basic idea is to assign a unique identifier to each atomic action and use it to label all the log entries associated with that action. A commit record for the action [42] tells whether it is in progress, committed ....

Gray, J. et al. The recovery manager of the System R database manager. Computing Surveys 13, 2, June 1981, pp 223-242.

....There is a substantial literature of recovery algorithms, and a short literature on explaining recovery. A recent book [6] captures much of this. Recovery algorithms encompass logging, cache management, and recovery itself. Clever algorithms tailored for particular system have been invented, e.g. [2,3], evolving to physiological techniques [4] such as ARIES [11] Much of this has been an attempt to balance the choice of log operation (and hence the logging cost) against the complexity of the cache management needed to keep the database recoverable. Two papers that described the recovery ....

....If an updated X were flushed first, we could not replay A to regenerate the correct value for Y were the system to crash and require recovery. Flush order dependencies can require the atomic flush of multiple objects. For example, atomic flushing (propagating) was a requirement of IBM s System R [3]. While we might restrict operations to write only one object (but allow reading other objects) this does not avoid the problem. In Figure 1(a) once B is executed, and before its output X is flushed, we must prevent any modification to B s input Y in order for B to be replayable. However, ....

[Article contains additional citation context not shown here]

Gray, J., McJones, P., et al. The Recovery Manager of the System R Database Manager. ACM Computing Surveys, 13,2 (June 1981) 223242.

....to a peroperation rollback (restoring the state changes made by the operation which failed to previous values) by logging the individual state changes of each operation. Logging, also known in the literature as journalling or audit trails, is widely used in database systems [Bjork75, Verhofstad78, Gray81] 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 ....

....participant is asked to roll back by undoing their effects. If, however, all participants vote yes, the transaction commits and each participant rolls forward to completion. Gray et al. describe an instance of the undo redo approach used in the recovery manager of the System R database manager [Gray81] Called the DO UNDO REDO protocol, this approach provides a transactional programming abstraction through the use of four distinct programs: DO, UNDO, REDO, and COMMIT. Illustrated in Figure 2 2, the DO program performs an action which composes a transaction. Executing the DO program results in ....

[Article contains additional citation context not shown here]

Gray, J., McJones, P., Blasgen, M., Lindsay, B., Lorie, R., Price, T., Putzolu, F., and Traiger, I. "The recovery manager of the System R database manager." Computing Surveys 13(2). (June 1981) 223-242.

No context found.

GRAY, J., MCJONES, P., BLASGEN, M., LINDSAY, B., LORIE, R., PRICE, T., PUTZOLU, F., AND TRAIGER, I. The recovery manager of the System R database manager. ACM Computing Surveys 13, 2 (1981), 223--242.

No context found.

J. Gray, P. McJones et al. The Recovery Manager of the System R Database Manager. ACM Computing Surveys, 13(2):223--242, 1981.

No context found.

J. Gray, P. R. McJones, M. W. Blasgen, B. G. Lindsay, R. A. Lorie, T. G. Price, G. R. Putzolu, and I. L. Traiger, "The Recovery Manager of the System R Database Manager," ACM Computing Surveys, vol. 13, no. 2, pp. 223--243, 1981.

No context found.

J. Gray, P. R. McJones, M. W. Blasgen, B. G. Lindsay, R. A. Lorie, T. G. Price, G. R. Putzolu, and I. L. Traiger, "The Recovery Manager of the System R Database Manager," ACM Computing Surveys, vol. 13, no. 2, pp. 223--243, 1981.

No context found.

J. Gray, P. McJones, M. Blasgen, B. Lindsay, R. Lorie, T. a. Price, F. Putzolu, and I. Traiger. The recovery manager of the System R database manager. Computing Surveys, 13(2):223-242, June 1981.

No context found.

Gray, J., McJones, P., Blasgen, M., Lindsay, B., Lorie, R., Price, T., Putzolu, F., and Traiger, I. "The Recovery Manager of the System R Database Manager", Computing Surveys, Vol. 13, No. 2, June 1981.

No context found.

Jim Gray, Paul McJones, Mike Blasgen, Bruce Lindsay, Raymond Lori, Tom Price, Franco Putzolu, and Irving Traiger. The recovery manager of the system r database manager. Computing Surveys, 13(2):223--242, June 1981. 150

No context found.

J. N. Gray, P. McJones, et al. The recovery manager of the system R database manager. ACM Computing Surveys, 13(2):223--242, 1981.

No context found.

Gray, J., McJones, P., et al. The Recovery Manager of the System R Database Manager. ACM Computing Surveys, 13,2 (June 1981) 223-242.

No context found.

J. Gray, P. McJones, et al. The Recovery Manager of the System R Database Manager. ACM Computing Surveys, 13(2):223--242, June 1981.

No context found.

J. Gray, et al., The Recovery Manager of the System R Database Manager, ACM Computing Surveys 13, 2 (June 1981) 223-242.

No context found.

Gray, J., McJones, P., Blasgen, M., Lindsay, B., Lorie, R., Price, T., Putzolu, F. & Traiger, I. "The Recovery Manager of the System R Database Manager". ACM Computing Surveys, vol. 13, no. 2, June 1981 pp 223-242.

No context found.

J.N. Gray, P.R. McJones, B.G. Lindsay, M.W. Blasgen, R.A. Lorie, T.G. Price, F Putzolu, and I.L. Traiger. The recovery manager of the system r database manager. ACM Computing Surveys, 13(2):223--242, June 1981.

No context found.

Gray, J.N., McJones, P., Blasgen, M., Lindsay, B., Lorie, R . , Price, T., Putzolu, F. & Traiger, I.L. "The Recovery Manager of the System R Database Manager". ACM Computing Surveys 13, 2 (June 1982) pp 223-242.

First 50 documents  Next 50

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