Data base backup and recovery system and method

Description Submit all comments and votes

CROSS REFERENCE TO CO-PENDING APPLICATIONS

The present application is related to co-pending U.S. patent application Ser. No. 07/762,282 entitled "Cooperative Hardware and Microcode Control System for Pipelined Instruction Execution", filed Sep. 19, 1991 and assigned to the assignee of the present invention. The related patent application is herein incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention generally relates to the area of data base management systems and more particularly to the area of data base backup and recovery.

2. Description of the Prior Art

Businesses and society in general are increasingly relying on the availability of data processing systems and the information they process. The cost of a failed data processing system to a business can be enormous, both in terms of idled resources and the opportunity costs associated with unprocessed information. There may be employees whose Jobs are directly tied to the availability of the system, as well business transactions which are tied to system availability. Thus, when a data processing system fails, there may be costs associated with unproductive labor and lost business opportunities such as sales of airline tickets, sales of shares of stock, or transfers of money. In short, data base availability means the difference between success and failure in the marketplace.

One application for which data processing systems are used and for which system availability is of great importance is in the area of transaction processing. Transaction processing generally entails maintaining a data base of information and processing user requests against the data base. The user requests would typically be for reading, adding, deleting, and updating information in the data base. Each such operation is commonly referred to as a transaction.

Systems which provide transaction processing services are susceptible to failures in at least three different areas of processing, as indicated by Haerder and Reuter in "Principles of Transaction-Oriented Data base Recovery", Computing Surveys, Vol 15, No. 4, December, 1983, pp 287, 290. The failures can be at the transaction level, the media level, or at the system level.

Transaction level failures include things such as incorrect input data and deadlock situations, both of which would keep a transaction from being completely processed. In most instances transaction level failures can be remedied by attempting to reprocess the transaction.

Media level failures include secondary storage device failures, and operating system bugs, both of which can result in failed read or write operations on the secondary storage device. Secondary storage devices are used for non-volatile storage of the data base, and are also useful in applications where the amount of data in the data base exceeds the primary storage capacity of the host system. In the event of a media failure, and especially in the case of a failed secondary storage device, all or part of the information in the data base may be inaccessible. The present invention provides a fast and reliable system for data base recovery as will be discussed in detail later.

The third category of failure discussed by Haerder and Reuter is the system failure. System failures include such things as bugs in the data base management system code, operating system faults, general hardware failures, and natural or human disasters. The consequence of such a failure is that the host system for the transaction processing system is generally unavailable and no further transactions can be processed. Until the system can be returned to an operable state, the activities of those relying on the transaction processing system will be sharply curtailed, if not stopped completely. For system failures caused by disasters such as floods, fires, and acts of terrorism, it would be highly unlikely that the system could be returned at all to an operable state. Protection against disasters is quite often provided by a standby system which is available at a site which is far enough removed from the site suffering the disaster to remove the backup system from the threat of being affected by the same disaster.

The period of time for which a transaction processing application user is willing to forego use of the system due to its unavailability largely depends upon the nature of the application. For example, a home user updating a mailing list application on a system that fails may not feel a great sense of urgency to recover the data held in the inaccessible data base; whereas a large bank whose transaction processing application updates hundreds of thousands of accounts on a daily basis would experience an extreme sense of urgency in recovering its data base. The willingness to invest in the extra equipment necessary to ensure a fast recovery time is largely dependent upon the tradeoff between the down-time costs associated with an unavailable system and the hardware costs to provide a standby system.

Two commonly used methods for data base backup and recovery include the audit trail method and the synchronized data base method. Each is discussed briefly below.

The audit trail method involves making a copy of a primary data base at a selected time. The primary data base is the data base against which transactions are processed, and the copy is referred to as the "backup data base". The backup data base may be stored in a non-volatile storage medium, such as one or more magnetic tapes. After making the backup copy, audit information relating to all updates to the primary data base is logged to an audit trail, which may be stored on a magnetic tape or other non-volatile storage medium. The particular audit information saved may vary from system to system and may include one or more of the following: the new updated record, the old record, the difference between the old record and new updated record, and the operation performed on the record. Only transactions which cause updates to the data base need be logged since operations such as a read will have no effect on the state of the data base.

Should the primary data base become inaccessible, the data in the primary data base must be recovered. The state of the primary data base just after the last update operation can be reconstructed using the backup data base and the audit trail. The backup data base is read from the magnetic tapes and written to a direct access storage device. Then, each entry in the audit trail is sequentially read and applied to the data base on the direct access storage device. When the entire audit trail has been processed, the backup data base will be in a state identical to that of the primary data base Just prior to when it became inaccessible. The backup data base can then be made the primary data base against which subsequent transactions can be processed.

It is recognized that with the audit trail method, the length of time required to recover a data base is directly dependent upon the number of data base updates logged to the audit trail. The number of data base updates logged to the audit trail is directly dependent upon the transaction processing application for which the audit trail is kept. For large banks, the application will most likely involve millions of update transactions, and therefore generate a lengthy audit trail. Thus, a lengthy audit trail will increase the time required to recover the data base.

To ameliorate the lengthy recovery time involved with the audit trail method, a second method, referred to as the "synchronized data base method" is also used for data base recovery. The synchronized data base method involves a primary data base on which transactions are first processed, and secondary data base to which update transactions are applied in order to keep the secondary data base synchronized with the primary data base.

The synchronized data base method involves two hosts: the first host having the transaction processing system for the primary data base, and the second host having a transaction processing system for the secondary data base. Before the transaction processing system for the primary data base completes an update transaction, the update is sent to the transaction processing system for the secondary data base. Once the transaction processing system for secondary data base has received the update transaction, two processing possibilities exist. First, the transaction processing system for the secondary data base could send an acknowledgment to the transaction processing system for the primary data base before the transaction has been applied to the secondary data base to signal that the update transaction has been received. The second approach has the transaction processing system of the secondary data base sending an acknowledgement after the update transaction has been applied to the secondary data base and stored in secondary storage.

The first approach has the benefit that the transaction existence time is not unduly prolonged by virtue of sending the update operation to the transaction processing system for the secondary data base. However, this approach has the drawback that the update transaction is still stored in the primary storage of the second host and has not been applied to the secondary data base secondary storage. The risk taken by this approach is that if the host for the transaction processing system of the primary data base fails, and the host for the transaction processing system of the secondary data base fails before the update transaction can be applied to the secondary storage of the secondary data base, the update transaction will be permanently lost, even though the transaction processing system of the primary data base has proceeded under the assumption that the transaction was secured by the secondary transaction processing system.

The advantage to the second approach is that once the host system with the primary data base has received an acknowledgement, the data base update is sure to be secured in the secondary data base. However, the disadvantage with this approach is that the transaction existence time for the update transaction may be lengthened by the time it takes for the transaction processing system of the secondary data base to make the necessary update to secondary storage. This increase in processing time is due to the fact that the access speed to secondary storage is much slower than the access speed to primary storage. The tradeoff for the security of having the data base update committed to secondary storage is an increase in processing time for a transaction. For applications processing large numbers of transactions this delay may be unacceptable.

The current state of data base backup and recovery systems involves the tradeoff between ensuring data security and minimizing the time to recover a data base. Therefore, it would be desirable for a system to provide a secure backup data base and quick recovery of a data base, without adversely impacting the transaction processing rate.

SUMMARY OF THE INVENTION

1. Objects

It is a general object of the present invention to provide a system and method for maintaining a backup copy of a data base with negligible impact on transaction processing performance.

Another object of the present invention is to provide a system and method for protecting a data base against man-made and natural disasters.

A further object of the present invention is to provide a system and method for fast recovery of a primary data base.

It is yet another object of the present invention to provide an automated system for maintaining a backup data base of a primary data base, whereby operator intervention in maintaining the backup data base is minimized.

2. Summary

The present invention provides a new system and method for maintaining a backup data base, and for providing quick recovery of the backup data base in the event that data base processing on the primary data base becomes inoperable. In the preferred embodiment, the present invention can be practiced with only minor modifications to existing software components, in combination with commercially available hardware components.

The invention entails maintaining a primary data base, against which transactions are processed. Information relating to updates to the primary data base is saved to intermediate storage in what is logically referred to as the audit trail.

A backup data base is established at an arbitrary point in time and saved in storage which is separate from that in which the primary data base is stored. Part of transaction processing entails receiving transactions, updating the primary data base for update type transactions, and saving audit information pertaining to the update transaction to intermediate storage. As audit information is being saved as the audit trail in intermediate storage, the audit trail is continuously monitored. When the audit information becomes available, it is read from the intermediate storage. The backup data base is then updated according to the retrieved audit information.

In the event that processing on the primary data base become inoperable, the backup data base will only be a few transactions behind the primary data base. After all the audit information has been read from intermediate storage and the backup data base has been updated accordingly, subsequent data base transactions can be directed to the backup data base. Because the audit information saved to the audit trail is processed as it becomes available, the time required to bring the backup data base up-to-date and switch operations to the backup data base is substantially reduced. Overall, a substantial reduction in data base recovery time, and a minimal impact on the transaction throughput rate is achieved.

In another aspect of the invention, the backup data base is saved at a site which is separated from the site of the primary data base by a distance sufficient to prevent both the primary and backup data bases from being susceptible to a common disaster. The site of the backup data base is referred to as the "remote site". Likewise, the audit information is saved to intermediate storage at the remote site. As audit information is being saved to the audit trail in intermediate storage at the remote site, the audit trail is continuously monitored. When the audit information becomes available, it is read from the remote intermediate storage and the remote backup data base is updated according to the retrieved audit information. If disaster strikes the site of the primary data base, the backup data base is only a few updates away from being current with the primary data base. Transaction processing can resume once processing of the audit information is complete and communication lines have been switched to direct transactions to the remote site.

The foregoing and other advantages will become apparent upon study of the preferred embodiment as set forth in the Detailed Description and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a data processing system in which the present invention could be used;

FIG. 2 shows a second embodiment of the overall data processing environment in which the present invention could be used;

FIG. 3 contains a block diagram of the overall system for recovering audit information from non-volatile storage and applying it to a backup data base;

FIG. 4 is a flow chart of the overall processing steps for maintaining a backup data base;

FIG. 5 shows a flow chart of the main processing performed by a transaction processor which provides access to a data base;

FIG. 6 shows the overall processing for saving audit information pertaining to data base updates to non-volatile storage; and

FIG. 7 contains the flow chart for the overall processing of a recovery processor which processes audit information against a backup data base.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 shows a data processing system in which the present invention could be used. It should be understood that the present invention could be easily adapted to other data processing system architectures and environments. FIG. 1 is merely illustrative of but one embodiment of the present invention. The block diagram of FIG. 1 depicts a 2200/900 Series Data Processing System 10 which is commercially available from the Unisys Corporation. The overall system architecture is described in the co-pending patent application identified above and is briefly described herein for providing context to a preferred embodiment of the present invention. FIG. 1 is a generalized block diagram of the system architecture described in the co-pending application.

The Data Processing System is comprised of four Processing Complexes, respectively numbered 12, 14, 16, and 18. Each Processing Complex may contain two instruction processors for execution the machine specific instructions. In addition, each Processing Complex also contains main storage units which provide the addressable memory for the instruction processors, and a storage controller for providing an interface between the main storage units and the instruction processors. An input/output section within each Processing Complex provides access to various peripheral storage and communication devices. Each Processing Complex is interconnected with each of the other Processing Complexes via Cables 20, 22, 24, 26, 28, and 30. The interconnection between each of the Processing Complexes allows for sharing addressable memory and peripheral device resources between each of the instruction processors of the respective Processing Complexes.

The architecture of the 2200 Series data processing system allows each Processing Complex to be partitioned into a "stand-alone" data processing system. When a partitioned configuration is made, each stand-alone system executes a separate copy of the OS2200 operating system, thereby providing independent operation of the applications on each partition. Each stand-alone system may also be referred to as "host". For the purposes of this exemplary embodiment, Processing Complex 16 and Processing Complex 16 can be thought of as functionally separate data processing systems.

In an alternative configuration, all the Processing Complexes could be configured in single "tightly coupled" system in which applications in each of the Processing Complexes has access to the resources provided by each of the other Processing Complexes. In a tightly coupled configuration one copy of the operating system manages all the system resources.

Within Processing Complex 18 is a Transaction Processor 32. Transaction Processor 32 provides data base access, both for read and update operations, to Primary Data Base 34. Depending upon the storage requirements of the Primary Data Base 34, part or all of the data base may be loaded in the main storage units (not shown) of Processing Complex 18 for quick access. Secondary Storage Device 36 is used for long term storage of Primary Data Base 34. The Transaction Processor 32 could be either a relational data base management system or a transaction processing system using flat files. Neither the type of transaction processing system nor the structure of data within the data base is necessary for understanding or applying the present invention. Any transaction processing system may benefit from application of the present invention.

Also coupled to Processing Complex 18 is a Intermediate Storage 38. Preferably, the Intermediate Storage 38 shown is a Cartridge Tape Library in which sequential access to data on the Magnetic Tapes 40 is provided to applications seeking to store and retrieve data. The Cartridge Tape Library provides automated tape loading and unloading, thereby eliminating operator intervention for loading tapes. Cartridge Tape Library systems are commercially available from the Unisys Corporation. Those skilled in the art will recognize that many other types of non-volatile storage media are available, each having its particular advantages and disadvantages. Suitable alternatives may include magnetic disks, solid-state disks, cache disks, and others known by those skilled in the art. Many such non-volatile storage media have an available battery backup power supply which further decreases their volatility.

Transaction Processor 32 utilizes the Intermediate Storage 38 for saving audit information for transactions which update the Primary Data Base 34. If, for some reason, the Primary Data Base 34 becomes inaccessible, the audit information can be applied against a backup copy of the Primary Data Base 34 to place the backup copy of the data base in the same state as the Primary Data Base 34 just prior to when it became inaccessible. To provide this capability, each time a transaction involving a data base update is performed, audit information is generated which is stored in Intermediate Storage 38. The audit information saved by the Transaction Processor 32 is the updated record.

In the preferred embodiment, Intermediate Storage 38 provides access to the available storage for multiple Processing Complexes. This is illustrated by coupling Lines 42 and 44. Line 42 couples Processing Complex 18 to the Intermediate Storage 38, and Line 44 couples the Intermediate Storage 38 to Processing Complex 16. Each of Lines 42 and 44 represent the assortment of hardware and software necessary to provide applications in each of the Processing Complexes 16 and 18 with access to data stored in the Intermediate Storage 38. As long as applications on Processing Complex 16 and Processing Complex 18 are not competing for the same resources (e.g. tapes and tape drives) concurrent access is allowed to Intermediate Storage 38.

Recovery Processor 46 in Processing Complex 16 reads the audit information stored in the Intermediate Storage 38 and updates the Backup Data Base 48. As with the Primary Data Base 34, the Backup Data Base is stored in a Secondary Storage Device 50. Backup Data Base 48 is a copy of Primary Data Base 34 made at a particular point in time. To bring the Backup Data Base 48 to the same state as Primary Data Base 34, all update transactions processed after the backup copy of the Primary Data Base was made must be applied to the Backup Data Base 48. Recovery Processor 46 waits for Transaction Processor 32 to save audit information to the Intermediate Storage 38, and when the audit information is available reads the audit information from the Intermediate Storage 38 and applies it to Backup Data Base 48. In this manner, the processing rate of Transaction Processor 32 is not adversely impacted by maintaining Backup Data Base 48; the audits are secure in the event that Primary Data Base 34 becomes unavailable; and Backup Data Base 48 is only a few updates away from being in a state which is equal to the Primary Data Base 34, thereby minimizing data base recovery time. A transaction processor available in Processing Complex 16 could be started to take over the processing which is unavailable in Processing Complex 18.

FIG. 2 shows a second embodiment of an overall data processing environment in which the present invention could be used. A first "Host" 102, or data processing system, is available for application program execution, and data storage and retrieval. The term "Host" is flexible, but for the purposes of this discussion a Host can be thought of as tightly coupled data processing system. In reference to FIG. 1, if Processing Complex 16 and Processing Complex 18 are partitioned into distinct operating environments, that is, each has its own copy of the operating system, each would be referred to as a Host. On the other hand, if a single copy of the operating system manages the combined resources of Processing Complexes 12, 14, 16, and 18, all four Processing Complexes are configured as a single Host. Host 104 is a second general purpose data processing system capable of executing application programs and providing data storage and retrieval.

Host 102 has a Transaction Processor 106, and Host 104 has a Transaction Processor 108 and a Recovery Processor 112. Transaction Processor 106 is functionally the same as Transaction Processor 32. Different reference numerals are used because of the different processing environments shown in FIGS. 1 and 2. Transaction Processor 106 provides data base access, both for read and update operations, to Primary Data Base 114. Secondary Storage Device 116 provides for long term storage of Primary Data Base 114. Line 115 represents the hardware and software components providing Transaction Processor 106 access to Secondary Storage Device 116. Transaction Processor 108 does not operate on the Primary Data Base 114, but is available to provide the same functionality as Transaction Processor 106 in event that Transaction Processor 106 becomes inoperable.

Transaction Processor 106 is coupled to Channel Extender 120 via Line 122. Line 122 represents the hardware and software components providing Transaction Processor 106 with access to Channel Extender 120. The Channel Extender 120 is commercially available from the Unisys Corporation. It provides a high speed long distance extension to a conventional input/output channel. An additional five to ten kilometers may be added to an input/output channel with a standard Channel Extender. It is contemplated that a Channel Extender with a wide area network configuration may provide an input/output channel extension of approximately 400 kilometers.

Channel Extender 120 is coupled to Channel Extender 124 via Cable 126. Cable 126 could be either a fiber optic cable or a wide area network. Channel Extender 124 converts the channel extender signals from Cable 126 to signals suitable for transmission over Cable 128 to Intermediate Storage 130. Intermediate Storage 130 provides the same functionality as Intermediate Storage 38. Channel Extenders 120 and 124 thereby provide a direct coupling between Host 102 and Intermediate Storage 130, and the capability to store the audit information at a remote location. In the event that a man-made or natural disaster should interrupt or halt Host 102, operations at the remote location may continue unaffected. That is, Host 104 may provide continued service after communications (not shown) have been switched to Host 104.

Transaction Processor 106 may use the coupling to Intermediate Storage 130 for duplex storage of audits. At the same time that audit information is stored in local Intermediate Storage 131, the audit is also stored in remote Intermediate Storage 130 via the high speed link. Thus, the audits are doubly secure. In the event of a media failure by Secondary Storage Device 116, the aud