Managing log data in a transaction-oriented system.

0001This invention relates to a method for reducing the amount of and managing log data which must be accessed and processed in a transaction-oriented system in which concurrently executing, failure-independent processes share a common log.

0002As pointed out by C. J. Date, "An Introduction to Data Base Systems", Vol. 1, 4th Edition, Addison-Wesley Publishing Co., copyright 1986, Ch. 18, a "transaction" is a logical unit of work referencing a sequence of operations that transforms a consistent state of a recoverable resource into another con­sistent state without necessarily preserving consistency at all intermediate points. For purposes of this discussion, a data base will be referenced as a typical instance of a recoverable resource.

0003A system supporting transaction processing guarantees that if the transaction executes some updates against the data base and a failure occurs before the transaction reaches its normal termination, then those updates will be undone. Consequently, the transaction either executes in its entirety or it is totally cancelled. Since a transaction comprises execution of an application-specified sequence of operations, it is initi­ated with a special BEGIN transaction operation and ends with either a COMMIT operation or an ABORT operation. The COMMIT and ABORT operations are the key to providing atomicity.

0004The COMMIT operation signifies several attributes. First, it indicates that a transaction has successfully terminated. Second, it indicates that the data base is in a consistent state. Lastly, the COMMIT operation indicates that all of the updates made by that unit of work can now be committed or made permanent. In contrast, the ABORT operation signifies an unsuccessful end of transaction. That is, the ABORT means that a fault has occurred, that the data base may be in an incon­ sistent state, and that all of the updates made by the trans­action must be "rolled back" or undone.

0005Transactions are executed on stored program-controlled systems whose logical and physical attributes are generically denomi­nated "resources". Also, such systems may be considered to operate in modes such as a "processing" mode or, in the event of failure, one or more "recovery" modes. Control of both the access to and the operation of the resources is exercised by operating system (OS) software. These are denominated "resource managers". Similarly, the transaction-oriented processing and recovery operations are governed by OS software denominated "transaction processing" and "recovery managers".

0006As pointed out by Deitel, "An Introduction to Operating Systems", Revised 1st Edition, Addison-Wesley Publishing Co., copyright 1984, pp. 103-108, resource managers may be thought of as "monitors". A monitor is a concurrency construct that contains both the data and procedures needed to perform alloca­tion of a particular shared resource or group of shared re­sources. That is, a monitor is a mechanism that allows the safe and effective sharing of abstract data types among several processes.

0007In a transaction-oriented data base system, all changes to the data base are written to a log in support of recovery in the event of interruption. Each transaction utilizes BEGIN, COMMIT, ABORT, or END primitives in order to bound the COMPLETION, UNDO, or REDO of each transaction.

0008It may be observed that a checkpoint record is a list of all transactions alive at the time of the checkpoint, together with the log address of each transaction's most recent log record. A transaction whose records are used in its REDO is a trans­action that has terminated (committed) between the last check­point and the occurrence of failure, whereas a transaction whose records are used in its UNDO is one that has not termi­ nated at the time of the occurrence of failure. Thus, REDOs require transaction return to the most recent COMMIT point and the writing of changes to the log, while UNDOs require return to the transaction BEGIN point.

0009It should be appreciated that transactions define not only the unit of work, but also a unit of recovery. It is necessary for the system to know at restart or recovery time which trans­actions to UNDO and which to REDO. The snapshot or checkpoint taken at predetermined times certainly lists all transactions that were in progress at the time the checkpoint was taken. Thus, depending on the point in time when a failure occurred, the system can construct an UNDO list and a REDO list by working backward through the log, undoing the transactions in the UNDO list, and then working forward again, redoing the transactions in the REDO list. Only when all such recovery activity is completed can the system be in a position to accept new work. Strictly speaking, it is the checkpoint plus succeeding log activity which must be processed to affirm the UNDO and REDO lists.

0010In the prior art, several references describe fault- tolerant, transaction-oriented data base systems. These include: <ul id="ul0001" list-style="none"><li>(1) Gawlick et al, U. S. Patent 4,507,751, "Method and Apparatus for Logging Journal Data Using a Log Write Ahead Data Set", issued March 26, 1985.</li><li>(2) Baker et al, U. S. Patent 4,498,145, "Method and Apparatus for Assuring Atomicity of Multirow Update Operations in a Database System", issued February 5, 1985.</li><li>(3) Paradine et al, U. S. Patent 4,159,517, "Journal Back-up Storage Control for a Data Processing System", issued June 26, 1979.</li><li>(4) Reinsch et al, "Method for Restarting a Long-­running, Fault-tolerant Operation in a Transaction-oriented Data Base System Without Burdening the System Log", copending U. S. S/N 06/835,396, filed March 3, 1986.</li></ul>

0011The current logging technology represented by the references writes all log data produced by a transaction- oriented system into a single stream of data physically resident at a point in time on multiple DASD or tape devices with only one device being written upon at each instant. The Gawlick, Baker, and Paradine patents and the copending Reinsch application re­spectively describe (1) the writing to a log before record updating, (2) buffer dumping to a log, (3) writing to a hard and soft log concurrently to assure multirow atomic updating, and (4) the utilization of a restartable load utility in which all changes to the data base are typically written to a log in support of recovery in the event of interruption.

0012The art also distinguishes the types of information required in the failure recovery of a system from that involved in the failure recovery of a resource. System recovery involves bringing system resources to a prior state of consistency, while resource recovery involves the recreation of a consistent image of a resource after it has been corrupted.

0013The art uses certain terms as synonyms. For instance, the "control" and/or "information state" of a resource or a system may also be termed its "image". In transaction processing, this would most frequently reference the data sets memoriali­zing transactions.

0014The present invention is defined in the attached claims.

0015It is an object of this invention to devise a method for efficiently managing log-based recovery in transaction-­oriented systems. It is a related object to devise a method for reducing the amount of log data which must be accessed and processed to effectuate said recovery.

0016The aforementioned objects are satisfied by a method for writing tagged (partitioned and classified) records from a first log stream to multiple recovery streams and discarding said tagged records from said first stream at the termination of the unit of recovery to permit first log stream reuse. More particularly, the inventive method for reducing the amount of log data accessed and processed in a transaction-oriented system in which concurrently executing, failure-independent processes share a common log comprises the steps of (a) re­cording log data in a partitioned fashion by unit of recovery in a transaction recovery stream (TRS); (b) classifying the log data as a function of its role in recovery (BEGIN, COMMIT, ABORT, END, REDO, UNDO); (c) responsive to unit of recovery state changes (COMMIT/ABORT), performing a one-to-n mapping of a subset of the log data (REDO/UNDO) from a UR partition on the TRS into resource recovery streams (RRSs); and (d) at the termination (END) of the unit of recovery state changes utili­zing the RRSs, discarding all log data associated with the UR from the TRS.

0017The method of this invention generates two data structures to assist in recovery. These include the TRS and the RRS. The TRS, together with checkpoint and status change information, is used to recover the transaction management environment after a failure. The TRS contains the data to determine the unit of recovery (UR) state, the data necessary to ensure an ABORT of a UR, and the data necessary to ensure the COMMIT of a UR. All data logged on behalf of a UR is included as part of the TRS.

0018The RRS is used to forward recover resources. By this is meant the recreation of a valid image of a resource starting from a valid copy of the resource occurring at some predetermined point in time. Based upon UR COMMIT or ABORT, records required for forward resource recovery are copied from the TRS into a predetermined one or more RRSs.

0019The TRS is a highly dynamic log data structure permitting resolution of resource inconsistencies created by those URs which were active at the time of the occurrence of a failure. The TRS is the repository for logged data which was associated with active URs, active URs being those transactions executing between BEGIN and END boundaries.

0020It should be recalled that each transaction utilizes BEGIN, COMMIT, ABORT (REDO, UNDO) or END primitives to bound the transaction. REDOs ensure transaction return to the most recent COMMIT point, while UNDOs ensure return to the trans­action BEGIN point.

0021As previously mentioned, the RRS contains data necessary for forward recovery from an image copy of a resource. The inven­tive method creates any number of RRSs. Thus, each application software using the transaction- oriented data base system can specify the resource name. Thus, each log write request can specify the resource to which a particular record should belong. This includes selecting the record-type semantics specifying the conditions under which a given record can be copied from the TRS to an RRS. Records required to ensure REDO of a transaction may only be copied to the RRS once the associa­ted UR enters the ENSURE-COMMIT state. Records required to ensure the UNDO of a transaction may only be copied to the RRS once the associated UR enters the ENSURE-ABORT state.

0022From the foregoing, it is apparent that by utilizing the method of this invention and maintaining only consistent images of the data in the RRS, a reduction in the storage requirement for RRS information has been attained. This is because UR state records and uncommitted data records need not be included in the saved data. Also, the elimination of uninteresting records reduces I/0 during resource recovery. Lastly, processing during recovery is reduced because the UR state need not be established before applying the data images to the copy.

0023The invention will be described below with reference to the drawings, in which <ul id="ul0002" list-style="none"><li>Figure 1 depicts the occurrence of primitives bounding a transaction with respect to their completion with reference to both checkpointing and system failure according to the prior art.</li><li>Figures 2-3 show a unit of recovery and its bounding primitives where the recovery respectively involves the REDO and UNDO of transactions.</li><li>Figure 4 schematically illustrates the forward resource re­covery process.</li><li>Figure 5 sets out a high-level control flow of the logging method according to the invention.</li><li>Figure 6 illustrates the format of the log records within the transaction recovery stream according to the invention.</li><li>Figure 7 shows a concordance between resource names and re­source recovery streams.</li><li>Figures 8-11 represent pseudo-code delineations of the UR control functions (BEGIN, COMMIT, ABORT, and END).</li><li>Figure 12 shows the high-level pseudo-code delineating the writing of resource recovery records.</li><li>Figures 13-24 illustrate the structuring of the TRS and RRSs according to the invention, including the response to COMMIT/ABORT commands and culminating in the removal of the records of the affected unit of recovery from the TRS.</li></ul>

0024Referring now to Figure 1, there is shown the time of occurr­ence relations among transaction primitives with reference to checkpoints and system failure. At the occurrence of failure and hence restart, the Recovery Manager must obtain the address of the most recent checkpoint record from a restart file or its equivalent, locate the checkpoint record in the system log, and proceed to search forward through the log from that point to the end. As a result of this process, the Recovery Manager is able to determine both the transactions that need to be undone (UNDO) and the transactions that need to be redone (REDO) in order to restore the resource to a consistent state.

0025Each transaction is categorized in one of five classes. Thus, transactions of type T1 were completed before checkpoint time T_c. Transactions of T2 started prior to time T_c and were completed after time T_c but before the system failure time T_f. Transactions of type T3 also started before time T_c but did not complete before time T_f. Transactions of type T4 started after time T_c but were completed before time T_f. Finally, trans­actions of type T5 started after time T_c but did not complete by time T_f. Therefore, transactions T2 and T4 are subject to REDO, while transactions T3 and T5 are subject to UNDO.

0026The Recovery Manager starts two lists. The UNDO list initially contains all transactions listed in the checkpoint record, while the REDO list is initially empty. The Recovery Manager searches forward through the log, starting from the checkpoint record. If the Recovery Manager finds a BEGIN transaction record for a given transaction, it adds that transaction to the UNDO list. Likewise, if the Recovery Manager finds a COMMIT record for a given transaction, it moves that transaction from the UNDO list to the REDO list.

0027The Recovery Manager works backward through the log again, undoing the transactions in the UNDO list. It finally goes forward again, redoing the transactions in the REDO list.

0028The above description provides a source for characterizing selective record types as being REDOs/UNDOs. For purposes of completeness, reference should be made to Figures 2 and 3 which show a unit of recovery and its bounding primitives where the recovery respectively involves the REDO and UNDO of trans­actions.

0029In the subsequent discussion, Figures 5-12 relate to the method concept, while Figures 13-24 concern an illustrative embodi­ment.

0030It should be appreciated that, in the prior art, a log is a single stream upon which is recorded data needed for system restart and data needed for media (resource) recovery. In this invention, instead of using merely a serialized recording of events, there is invoked the data construct of a reusable transaction recovery stream and multiple resource recovery streams.

0031Referring now to Figure 5, there is shown the relationship between the transaction recovery stream (TRS) and the multiple RRSs triggered by the UR primitives (BEGIN, COMMIT/ABORT, END). Once a transaction reaches an atomic point of consistency and its modifications have been externalized to the resource such as, for example, a data base, the space in the TRS occupied by all records relative to the transaction is available for reuse. Data needed for resource (media) recovery is maintained in the RRSs. The associated Log Manager (denominated "logger") is provided with a mapping of RRS/resource names (see Figure 7). The resource name is specified on a log WRITE call. The amount of data required for resource recovery is usually voluminous. This is because such data required for recovery represents a history of all permanent changes made to a modifiable resource.

0032Referring again to Figure 5, it is apparent that the movement of data from the TRS to the appropriate RRS and the reclaiming of space within the TRS is affected by means of UR control triggers specified by the logger. These triggers are: <ul id="ul0003" list-style="none"><li>(1) BEGIN/END UR. This specifies the bounds of a unit of recovery as a set of atomic application program updates to a resource.</li><li>(2) COMMIT UR. This is a decision point indicating that an atomic transition point has been reached. Changes will be made to the resource across failures.</li><li>(3) ABORT UR. This is a decision point indicating that program updates will be undone in the case that partial changes have been made to the modifiable resource.</li></ul>

0033Advantageously, the method of this invention will reuse space on the log and avoid the reading of media recovery records during system restart.

0034Referring now to Figure 6, there is depicted the format of the log records within the TRS. The UR ID field defines the UR partition to which a given log record belongs. The TYPE field identifies the role of the associated data during recovery. The types fall into two categories. These are UR control and resource recovery. The UR control records state changes in the UR. The state changes are communicated to the Log Manager by function calls. These function calls are BEGIN UR, COMMIT UR, ABORT UR, and END UR. Each event creates a UR control log record. The types supportable for UR control records are BEGIN, COMMIT, ABORT, and END. The resource recovery records record the resource changes. The types supported for resource recovery records are UNDO and REDO. The REDO records contain the information necessary to repeat the resource change.

0035It should be noted that the resource name is the field which applies to the resource recovery records only. This field identifies the resource being modified. The resource name also appears in the RRS mapping table of Figure 7. Lastly, the DATA field is the resource specific or control specific information passed by the application. The Log Manager is not sensitive to the format or content of this data.

0036Referring now to Figure 7, there is shown the RRS mapping table. The recovery data for a resource will be copied to the RRS specified by this table. Note that an RRS may contain data for more than one resource, i.e. a one:n mapping. Paren­thetically, nonrecoverable resources are supported by providing a null resource RRS mapping. Thus, resource d is assigned to RRS NULL. Records for nonrecoverable resources are available for transaction recovery, but are not carried forward into an RRS.

0037Referring now to Figures 8-11, there are shown pseudo- code delineations of the UR control functions. Significantly, the pseudo-code expression is of the form typically used in the design of control and data flow. Such use is exemplified by Linger et al, "Structured Programming: Theory and Practice", The System Programming Series, Addison-Wesley Publishing Co., copyright 1979, ISBN 0-201-14461-1, Chapters 4-5.

0038In Figure 8, the pseudo-code assigns an ID for the UR partition and creates a log record on the TRS. At some time in the life of a UR, the decision is made to COMMIT or ABORT. If a COMMIT is made, then the COMMIT UR procedure of the logger shown in Figure 9 is invoked. It should be recalled that prior to the COMMIT point being reached, several participants have donated records into the TRS. The records are denominated REDO/UNDO by the Transaction Manager or Data Base Manager, if applicable, as part of the information being supplied to the logger. The function of the primitives, their control record manifestation and response, may be seen in the following table: <tables id="tabl0001" num="0001"><img file="EP0250847A2_D0001.tif" /></tables>

0039It should be observed that the ABORT procedure is symmetric with the COMMIT procedure. The table treats the procedures set out in Figures 8-11. However, it should be appreciated that the WRITE procedure of Figure 12 may be embedded several times in a transaction stream of the form BEGIN...WRITE,WRITE,...­COMMIT/ABORT END. The WRITE procedure places a record of the UNDO/REDO type on the TRS if the record contains a resource name found in the RRS mapping table.

0040At this point, several observations are in order. First, the term "1:n mapping" references a UR partition defined on each of m resources which are distributed among n RRSs. Where m>n pertains, there is at least one RRS which contains the records­/recovery data from at least two resources (see Figure 4). This is an instance of Dirichelet's "Pigeonhole Principle". Another observation is made with reference to the pseudo-code procedures. A number of pseudo-code procedures includes DO blocks. These are not the same as DO loops. DO blocks are executed only one time through. Thus, in Figure 5, the objective is to establish a unit of recovery. The call to the procedure is driven externally, but is responded to by the Log Manager. This places the record in the TRS.

0041Referring now to Figure 13, there are depicted two URs, namely, UR1 and UR2. The URs are going to alter the resources A, B, C, and D. In this example, UR1 is going to COMMIT its data, while UR2 is going to ABORT its data activity. Significantly, the decision either to COMMIT/ ABORT is made external to the Log Manager. The activities exemplified include (1) movement of data from the TRS to the RRSs and (2) the subsequent deletion of the moved data from the TRS as a function of the END primi­tive.

0042In Figure 13, UR1 and UR2 were created with the counterpart BEGIN commands and installed on the TRS. It is emphasized that the designation of a record as REDO/UNDO is made either by the Transaction or Data Base Manager and not by the Log Manager or logger. The records in Figure 13 are shown in numbered se­quence on the left. For instance, records 1-10 update the TRS for UR1 and UR2. Record 11 depicts an ABORT of UR2 and triggers the copying of UR2's UNDO records 6, 8, and 10 from the TRS to the appropriate RRS. In this regard, record 6 (resource A) is placed on RRS1, while records 8 (resource B) and 10 (resource C) are placed on RRS2. This placement, as set out in Figure 14, is in accord with the RRS mapping table as shown in Figure 7. It is of interest that the UNDO records are placed on RRS2 in reverse sequence. This permits accurate forward processing during resource recovery. It is recalled in this regard that the ABORT (a form of rollback) has the object of backing out. For purposes of completeness, it should be noted that UNDO records need only be on the RRS if the trans­action management supports data base copying in the presence of concurrent transaction activity.

0043Since the RRSs consist only of committed images, then only a portion of the data residing in the TRS record sequence is required for resource recovery. In the case of the ABORT, only three UNDO UR2 records are copied to RRSs 1 and 2 out of seven UR2 records on the TRS.

0044Referring now to Figures 15 and 16, there is shown the response required by the method of the invention to a UR1 COMMIT command recorded on the TRS as record 14. The COMMIT triggers copying of the UR1 REDO records 4, 12, and 13 to RRSs 1 and 2 and null, respectively. It should be observed that only half of the records on the TRS are going to be copied to the RRS, since each transaction at the decision point is driven either by a COMMIT or ABORT. If driven by a COMMIT, only REDO-type records are copied to the RRSs, while if ABORT, only UNDO-type records are copied to the RRSs.

0045When the END UR1 command is received, as shown in Figure 17, this triggers the record deletion process for UR1 from the TRS. The contents of the RRSs remain unaffected, as set out in Figure 18. Execution of the END command removes all trace of UR1 from the TRS, as displayed in Figure 19. The execution of the END command for UR2 likewise effectuates removal of corre­sponding records from the TRS, as shown in Figures 21 and 23. The RRS record sequences remain in tact, as depicted in Figures 20, 22, and 24.