An Efficient Log.Based Crash Recovery Scheme for Nested Transactions

Transcription

1 Microprocessing and Microprogramming 31 (1991) North-Holland An Efficient Log.Based Crash Recovery Scheme for Nested Transactions Dong C. Shin and Song C. Moon Department of Computer Science and Center for AI Research Korea Advanced Institute of Science and Technology Cheongryang P.O. Box 150, Seoul , Korea In this paper, an efficient recovery scheme for nested transactions using double log sequence numbers(lsns) is proposed, Unlike previous recovery schemes, due to double LSNs, our recovery scheme is able to avoid unnecessary redos and subsequent undos. Furthermore, our scheme can cope with successive crashes which might occur during recovery. In addition, our scheme provides operation logging as well as value logging, which is required in order to allow semantically-rich lock modes. The recovery scheme based on the selective redo/undo consists of three passes: analysis, redo, and undo. 1. Introduction 1.1 Background The concept of nested transactions was introduced to allow failure independence and intra-transaction parallelism [3, 5]. A nested transaction hierarchy consists of not only sequential subtransactions but also concurrent subtransactions. Thus, a nested transaction mechanism must provide a proper synchronization and a recovery. Recovery must ensure atomicity and durability of transactions in case of failures, thereby restoring the databases consistent. In other words, the effects of incomplete transactions must be eliminated whereas the effects of committed transactions must survive the failures. The failures usually include transaction failures, system crashes, and media failures. In the log-based recovery schemes, the log sequence numbers(lsns) [2] are used to keep track of the page state precisely. An LSN is associated with each page so that the LSN can reflect the page state at the time of a system crash. Therefore, by using LSNs, we can avoid attempting to undo an action when its effect has never been present in the page, and can also avoid attempting to redo an action when its effect has been already present in the page. To cope with system crashes during recovery, all updates performed during rollbacks are logged via so called compensation log records(ckrs) [4]. A CLR is always written to the log as an undo action is performed. Therefore, for transactions which are being roiled back at the time of a system crash, only the actions of them which have not been yet undone are rolled back. Consequently, a CLR contains the pointer to the next previous logrecord in the undo chain of log records for the corresponding transaction. 1.2 Motivation It is desirable that a recovery scheme should allow operation logging as well as value logging in order to support semantically.rich lock modes [1, 8], in addition to the read and write lock modes. This is because the recovery action should be taken on basis of operation

2 100 D.C. Shin, S.C. Moon semantics, not before-image, in case semantically-rich lock modes are supported. In case operation logging is supported, the most important issue is how to keep track of the page state precisely with respect to the logged infomaation for the page. In other words, it should be determined exactly whether the modified page is really reflected in the databases or not. Otherwise, the effects of undo or redo actions performed more than once may not be equivalent to those of performing the actions only once, since operation logging performs undo or redo actions by operation semantics. introduce double LSNs. In our scheme, two LSNs are associated with each page: redoable log sequence number(rlsn) and undoable log sequence number(ulsn), The RLSN represents the log record whose redo effects (if any) are already present in the page. The ULSN represents the log record whose undo effects (if any) are not yet present in the page. That is, log records from which redo actions and undo actions necessary for each page start are represented by RLSN and ULSN, respectively. Consequently, RLSN and ULSN are used for redo and undo purposes, respectively. In case operation logging is supported, the use of single LSN cannot cope with system crashes that may occur during recovery. This is because the page states at the time of the first crash will not be preserved, which causes undo actions or redo actions to lose keep tracking of the page states. The solutions for this problem have appeared in [4, 6]. Initially, for each page both its RLSN and its ULSN are identical. During normal processing, both page RLSN and page ULSN are set to the tog record LSN for the action performed. As a result, for each page both its RLSN and its ULSN are always identical during normal processing. However, they become different during recovery. In [4], all the updates including those of aborted transactions as well as those of committed ones are redone before performing undo actions. In [6], on the other hand, all the updates including those of committed transactions as well as those of aborted ones are undone before performing redo actions. It is evident that these schemes sometimes should perform the unnecessary redos(undos) and consequent undos(redos). Therefore, an efficient recovery scheme that is able to avoid such unnecessary undos and redos and supports the operation logging, needs to be developed. The rest of the paper is organized as follows. In Section 2, the concept of double log sequence numbers is introduced. Then, we describe the recovery scheme for nested transactions in Section 3. Finally, conclusions appear in Section Double Log Sequence Numbers 2.1 Selective Redo/Undo with Double LSNs In this section, in order to keep track of the page states precisely while selective redo/undo are allowed, we When redo action needs to be performed during recovery, the log record LSN for the redo action is compared to the page RLSN. If the page RLSN is less than the log record LSN, the redo action is performed, and then only the page RLSN is set to the log record LSN. Otherwise, the redo action is not performed since the update made by the action for the log record has been already present in the page. The page ULSN, however, remains intact during the redo actions. When undo action needs to be performed, the log record LSN for the undo action is compared to the page ULSN. If the log record LSN is less than or equal to the page ULSN, the undo action is performed and the page ULSN is set to the log record LSN. Then, a CLR for the undo action is written to the log. At this time, the log record RLSN is also set to the LSN of CLR. Otherwise, the undo action is not performed, since the update made by the action for the log record has never been present in the page. When the recovery is finished, checkpointing should be taken. Checkpointing ensures that all the effects of recovery should be propagated to the databases. Then,

3 An efficient log-based crash recovery scheme 101 normal processing is resumed. As described earlier, during normal processing, both page RLSN and page ULSN are maintained to be identical. Example 1 shows how our scheme maintains both RLSNs and ULSNs during recovery. normal processing redo pass undo pass (P, LSN, tzsn) (U~--~(2,~)-~ (3,3) ~(5,3)~(~9)--~(2,2) tq~h LSN l L'~3 c 2 g Transaclions ~ 1 T 2 ~ T 3 T 1'4 I'5 1'3 2 t T 1 and T5: committed; T 2, T3, and T4: running tic: CLR for log record i t page state at the crash time: (3,3) Figure 1 Transition of (RLSN,ULSN) during recovery point, the page state becomes (3c,3). Likewise, the undo action for log record 2 is performed. Therefore, the final page state becomes (2c,2). Our scheme is also able to cope with system crashes occurring during recovery. To keep track of the page states precisely, it is required to determine the exact log records from which the redo action and undo action for recovery start. As described, RLSN and ULSN exactly provide the information for this decision. Hence, our scheme is always able to maintain correct page state information even if system crashes occur more thatn once during recovery. Unlike other recovery schemes, by using double LSNs, we can avoid unnecessary redos and subsequent undos. That is, our scheme performs necessary redo actions and undo actions only; our scheme is based on so called selective redo/undo. We are certain that this advantage outweighs the additional space overhead incurred by maintaining two LSNs per page. Example I: Consider Figure 1. For simplicity, suppose that all transactions perform actions on the same page. We can easily realize that T 1 and T 5 need to be redone while T2, T3, and T 4 need to be undone. The fact that at the time of crash the page state (RLSN,ULSN) is (3,3) implies that the updates performed by T 4 and T 5 have not yet propagated to the page. The redo action for T l is not actually performed since its update had already propagated to th6 page. The redo action for log record 5 is, however, performed since its update has not yet propagated to the page. Accordingly, the page state becomes (5,3). Now, the undo actions for T4, T 3, and T 2 need to be performed. Since the undo actions should be performed in the reverse chronological order, the next log record to be processed is record 4. Since the update made by the action for log record 4 has not yet propagated to the page, the undo action for T 4 is not actually performed. Then, the time comes to examine whether undoing T 3 is needed. This undo action is actually performed since the log record LSN (LSN=3) is equal to the the page ULSN (ULSN=3). Subsequently, the page ULSN is set to the log record LSN. Then, the CLR for the undo action is written to the log, and the page RLSN is set to the LSN of CLR. At this 2.2 Correctness The correctness of our scheme can be asserted as follows. To recover from system crashes correctly, it is necessary to determine which actions are to be undone and redone so that unnecessary or erroneous re.dos and undos can be avoided. This decision is made on bais of the page LSN with respect to the log records related to the page. Therefore, it is essential that at the time of crash the page LSN should be remembered for undo purpose, since the page LSN may be changed during recovery. In our scheme, for undo purpose, ULSNs precisely remember the page states at the time of crashes whereas RLSNs behave like conventional LSNs. Due to this fact, our scheme can avoid unnecessary or erroneous undos and redos by using ULSNs and RLSNs, respectively. This ensures that the action whose effects are not present in the page is never undone, and the action whose effects are already present in the page is never redone. Finally, when recovery has finished, taking checkpointing is necessary to reduce the amount of work to be done in case of subsequent crashes. Taking

4 102 D.C. Shin, S.C. Moon checkpointing immediately after recovery is closely related to the correctness of our scheme. Since both RLSN and ULSN of a page are identical during normal processing, which implies that previous page state is no longer remembered for undo purpose, a problem will arise in ease of subsequent system crashes if there is no guarantee that the effects of previous recovery actions are already present in the page. The checkpoindng guarantees this. 3. Recovery for Nested Transactions 3.1 Log Record The log is examined in order to recover from system crashes. The log, in fact, is a sequence of log records, which exactly reflects the states of databases at the time of crash. For each transaction, the log records for the transaction are linked backwards. This is termed baekchalnlng. The log records include the following records: begin, abort, commit, undo, redo, CLR, checkpoint, sub.begin, sub-commit, and sub-abort. The undo or redo record contains the data for undo and/or redo actions. The checkpoint record contains a set of log record pointers for the active transactions at the time of crash. Each pointer points to the most recent log record for the corresponding transaction. Without losing generality, we assume that each log record contains all the necessary information such as transaction identifier, page identifiers, and a pointer to the next previous log record of the transaction. The sub-begin record is the first log record in the backchalning for subtransaction. On the contrary, the sub-abort and sub-commit record are not linked to the backchaining of the subtransaction, but to the backchaining of its parent. In other words, the sub-abort and sub-commit record is added to the backchaining of the parent of the subtransaction when the subtransaction aborts and commits, respectively. Furthermore, the sub-commit and sub-abort records contain the pointer to the most recent log record for the corresponding subtransaction, including other information (e.g., the subtransaction identifier). 3.2 Recovery from Transaction Failures In nested transactions, the inferiors of a transaction to be ~iborted should also be subject to be aborted although they have the sub-commit records. Therefore, the most recent log records for the inferiors are required for recovery. Those inferiors can be easily found from the sub-abort or sub-commit log records, since the sub-abort and sub-commit records are on the backchaining of the transaction to be aborted. Therefore, a set A of log pointers to the most recent log records for the inferiors as well as the transaction to be undone can be established. Initially, the set A contains the log pointers to the most recent log records for the transaction to be aborted and its running inferiors. The pointer set A is updated as the recovery is progressed. The recovery begins by choosing the pointer to the most recent log record from A. If the corresponding log record has a pointer to the previous log record, the chosen pointer is updated with the pointer to the previous log record. Otherwise, the chosen pointer is simply deleted from A. In this way, we can process correctly the log records in reverse chronological order. This process continues until the set A is empty. The log records encountered during this process is handled as follows: t undofredo: Perform the undo action, and then write CLR for the undo action. t sub-commit: Add a new pointer to the most recent log record for the corresponding subtransaction to A. "~ sub-abort and CLR: Do nothing. Each record has a non-null pointer to the next previous log record to be processed. t suwbegln and begin: Do nothing. Each record has a null pointer value, so the pointer is simply removed from A. The recovery is completed by writing abort records for the aborted transactions and its running inferiors. Note that other records such as commit and abort record cannot be encountered during recovery from transaction failures. 3.3 Recovery from System Crashes In our scheme for recovery from system crashes, the log is processed three times: analysis pass, redo pass, and undo pass.

5 An efficient log-based crash recovery scheme Analysis pass Recovery procedure begins from the last checkpoint record just taken before the system crash. The address of this checkpoint record is assumed to be saved in the secure place such as stable storage at the checkpoint time. Then, the log is scanned forwards in order to analyze log records. During the analysis pass, three sets of transactions related to log records are maintained: undo.set(u), redo-set(r), and abort-set(a). U contains the set of pointers to the most recent log records for transactions to be aborted. R contains the set of transactions to be redone. A contains the set of transactions to be aborted whose abort records should be written to the log. Each record encountered during analysis pass is handled as follows: t checkpoint: Add the set of pointers for active transactions to U, and add those transactions to A. t begln and sub-begin: Add a pointer to the record to U, and add the corresponding transaction to A. t undo/redo and CLR: Replace the pointer for the corresponding transaction in U by the pointer to the previous log record. t abort and sub-abort: Replace the pointer for the corresponding transaction in U by the pointer to the record. Then, remove the transaction from A. t sub-commit: Replace the pointer for the corresponding transaction in U by the pointer to the record. 1" commit: Remove the pointers for the transactions is reached. including its inferiors from U and remove the transactions from A. Then, add the transactions to R. The analysis pass is completed when the end of log Redo Pass During the redo pass, the log is scanned forwards from the last checkpoint record. Each record encountered is handled as follows: ~" checkpoint, begin, sub-begin, abort, sub-abort, commit, and sub-commit: Do nothing, "~ undo/reao: If the transaction for the record is in R, attempt to perform redo action. t CLR: Attempt to perform redo action. When the end of log is reached, the redo pass is completed. The attempt to perform redo actions for undo/redo records of the transactions that are only included in R is natural. On the other hand, the attempt to perform redo actions for CLRs is always made, since the effects of undo actions that caused the creation of CLRs may not yet be present in the databases Undo Pass To process the log in reverse chronological order, the log record pointed by the maximum pointer value in the set. U is selected as the next log record to be processed. Each record encountered is handled as follows: t abort, sub-abort, sub-commit, and CLR: Replace the pointer for the corresponding transaction in U by the previous pointer specified in the record. t undo/redo: Attempt to do undo action, and write CLR for the record if undo action is actually performed. Then, replace the pointer for the corresponding transaction in U by the previous pointer specified in the record. t begin and sub.begin: Remove the pointer for the corresponding transaction from U. When the set U is empty, the undo pass is ~ completed. After the undo pass has been completed, the abort records for transactions in A are written to the log. 3.4 Comparison to Related Work As far as we know, the log-based recovery, algorithms for nested transactions are those presented in' [6, 7]. In [6], Moss does not use log sequence number! which is prerequisite for avoiding unnecessary and/or erroneous redo and undo actions. Instead, he performs undo actions before redo actions duzsng recovery, undoing the committed transactions as well as aborted ones. Moreover, he does not introduce the concept of compensation log record(clr) whose use can efficientiy cope with the crash occurred during recovery. In addition, his approach will not work with semantically-rich lock modes and operation logging, since he performs undo actions before redo actions and does not use CLRs.

6 104 D.C. Shin, S.C. Moon Rothermel and Mohan's algorithm [7] is more powerful than Moss' algorithm. They permit semantically-rich lock mode and operation logging. In addition, their algorithm supports partial rollbacks and record-level locking. Their approach uses CLRs as well as LSN. Another property of their algorithm is" so called repeating history, which means that the database state at the time of crash is reestablished before undo pass. That is, they perform redo actions before undo actions, forcing the redo actions of the aborted transactions as well as the committed ones. Our algorithm can avoid such unnecessary redo actions (undo actions) and consequent undo actions (redo actions). This is accomplished by using the double log sequence numbers. Due to the double LSNs, we can perform the redo actions for only the committed transactions, excluding the aborted transactions. That is, we perform selective redo/undo. In addition, our algorithm can also support the semantically-rich lock modes and operation logging, since we perform redo actions before undo actions and use CLRs. Figure 2 summarizes the recovery schemes for nested transactions. crazh checkpoint L Log /v Moss ARIES/bIT Ours analysis / undo all selective redo analvsls redo all.selective undo analysis selective redo seleefivoundo Figure 2 Comparison of different recovery methods 4. Conclusions By using double LSNs, our recovery scheme is able to avoid the unnecessary redos and undos by keeping track of page states precisely. This is accomplished by maintaining log records from which the undo and redo actions should start to perform. Furthermore, the recovery scheme using double LSNs can cope with successive crashes during recovery. References [1] Badrinath, B. R. and Ramaaritham, K., "Synchronizing Transactions on Objects," IEEE Transactions on Computers, Vol. 37, No. 5, May, 1988, pp [2] Gray, J. N., "Notes on Data Base Operating Systems," Lecture Notes in Computer Science, No. 60, Springer-Verlag, 1978, pp [3] Haerder, T. and Rothermel, K., "Concurrency Control Issues in Nested Transactions," Research Report, IBM Research Center, San Jose, California, Feb [4] Mohan, C., Haderle, D., and Lindsay, B., "ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging," IBM Research Report, RJ6649R, Sep [5] Moss, J. E. B., "Nested Transactions: An Approach to Reliable Distributed Computing," Ph.D. Thesis, MIT/LCS/TR-260, MIT Laboratory for Computer Science, Cambridge, Massachusetts, Apr [6] Moss, J. E. B., "Log-Based Recovery for Nested Transactions," Proc. of 13th Int. Conf. on Very Large Data Bases, 1987, pp [7] Rothermel, K. and Mohan, C., "ARIES/NT: A Recovery Method Based on Write-Ahead Logging for Nested Transactions," Proc. of 15th Int. Conf. on Very Large Data Bases, 1989, pp [8] Weihl, E. W., "Commutativity-based Concurrency Control for Abstract Data Types," IEEE Transactions on Computers, Vol. 37, No. 12, Dec. 1988, pp For the efficient recovery, we have proposed the concept of double log sequence numbers. It can support the semantically-rich lock modes and operation logging.