Coordinating remote copy status changes across multiple...

Details Coordinating remote copy status changes across multiple... Coordinating remote copy status changes across multiple...

2000-04-28

2002-11-19

Corrielus, Jean M. (Department: 2172)

Data processing: database and file management or data structures

Database design

Data structure types

C707S793000, C707S793000, C707S793000

Reexamination Certificate

active

06484187

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a system, method, and program for ensuring data consistency across different storage areas and, in particular, coordinating similar status changes across multiple logical sessions at the appropriate consistency time.
2. Description of the Related Art
Disaster recovery systems typically address two types of failures, a sudden catastrophic failure at a single point in time or data loss over a period of time. With the gradual type of disaster, updates to volumes may be lost. To assist in recovery of data updates, a copy of data may be provided at a remote location. Such “dual” or “shadow” copies are typically made as the application system is writing new data to a primary storage device. International Business Machines Corporation (IBM), the assignee of the subject patent application, provides two systems for maintaining remote copies of data at a secondary site, extended remote copy (XRC) and peer-to-peer remote copy (PPRC).
These system recover data updates between a last, safe backup and a system failure. Such data shadowing systems can also provide an additional remote copy for non-recovery purposes, such as local access at a remote site. The XRC and PPRC systems are described in IBM publication “Remote Copy: Administrator's Guide and Reference,” IBM document SC35-0 169-02 (IBM Copyright 1994, 1996), which publication is incorporated herein by reference in its entirety. In such backup systems, data is maintained in “volume pairs”. A volume pair is comprised of a volume in a primary storage device and a corresponding volume in a secondary storage device that includes an identical copy of the data maintained in the primary volume. Typically, the primary volume will be maintained in a primary direct access storage device (DASD) and the secondary volume of the pair is maintained in a secondary DASD shadowing the data on the primary DASD. A primary storage controller may be provided to control access to the primary DASD and a secondary storage controller may be provided to control access to the secondary DASD.
In the IBM XRC environment, the application system writing data to the primary volumes includes a sysplex timer which provides a time-of-day (TOD) value to time stamp data writes. The application system time stamps data sets when writing such data sets to volumes in the primary DASD. The integrity of data updates depends upon performing updates at the secondary volumes in the same order as they were done at the corresponding primary volume. In systems such as XRC, the time stamp provided by the application program determines the logical sequence of data updates. In many application programs, such as database systems, certain write operations cannot occur unless a previous write operation has already occurred; otherwise the data integrity is jeopardized. A data write whose integrity depends on the occurrence of previous data writes is a “dependent write”. For instance, if a customer opens an account, deposits $400, and then withdraws $300, the withdrawal update to the system is dependent on the occurrence of the other writes, including the opening of the account and the $400 deposit. When such dependent transactions are copied from the primary volumes to secondary volumes, the transaction order must be maintained to preserve the integrity of dependent write operations.
Volumes in the primary and secondary DASDs are “consistent” when all writes have been transferred in their logical order, i.e., all earlier writes transferred first before their corresponding dependent writes. In the banking example, this means that the $400 deposit is written to the secondary volume before the $300 withdrawal. A “consistency group” is a collection of updates to the primary volumes such that dependent writes are secured in a consistent manner. In the banking example, this means that the withdrawal transaction is in the same consistency group as the deposit or in a later group; the withdrawal cannot be in an earlier consistency group. Consistency groups maintain data consistency across volumes and storage devices. If a failure occurs, consistency groups ensure that data is recovered from the secondary volumes will be consistent.
Each consistency group has a “consistency time” which is derived from the application system's time stamps. More particularly, the consistency time is a time that is always equal to or after every time stamp from a data write of that consistency group. In the XRC environment, the consistency time is the latest time to which the system guarantees that updates to the secondary volumes are consistent. As long as the application program is writing data to the primary volume, the data writes' time stamps increase, and so does the consistency time. However, if update activity ceases, then the consistency time does not change as there are no data sets with time stamps to provide a time reference for further consistency groups. If all the records in the consistency group are written to secondary volumes, then the reported consistency time reflects the latest time stamp of all records in the consistency group. Methods for maintaining the sequential consistency of data writes and forming consistency groups to maintain sequential consistency in the transfer of data between a primary DASD and secondary DASD are described in U.S. Pat. Nos. 5,615,329 and 5,504,861, which are assigned to IBM and incorporated herein by reference in their entirety.
Consistency groups are formed within a “session.” All volume pairs assigned to a session will have their updates maintained in the same consistency group. Thus, the sessions determine the volumes whose updates will form a consistency group. Consistency groups are formed within a journal. From the journal, updates from a consistency group are applied to the secondary volume. If the system fails while updates from the journal are being applied to a secondary volume, during recovery operations, the updates that did not complete writing to the secondary volume can be recovered from the journal and applied to the secondary volume.
In some data storage systems, consistency problems are possible if a database or data set spans multiple sessions. In these systems, consistency groups are not able to maintain consistency across sessions; in such systems, consistency groups are only formed within one session. This concern, namely allowing consistency across sessions or other groupings of storage areas, was addressed by U.S. patent application Ser. No. 09/422,595, entitled “Method, System, and Program For Maintaining Data Consistency Across Groups of Storage Areas,” filed on Oct. 21, 1999 in the names of R. M. Kern et al., and assigned to IBM. The foregoing application is hereby incorporated herein by reference.
Although the approach of the foregoing application might be satisfactory for many applications, the present inventors are actively involved in researching possible improvements for products such as these. In this respect, one area of focus involves preserving consistency during backup operations. In this endeavor, the present inventors have recognized that status changes in one of the sessions can impede the ability of the other sessions to maintain mutual consistency. In particular, if one of the sessions is suspended (for example, with the XSUSPEND command), then this session is not processing any updates and also not incrementing its time of the last consistency group in the journal. Another situation arises when a complete set of consistent secondary devices is desired, for example, to capture a point in time backup of all of the volumes. In this case, the normal means of obtaining this condition in a single session is insufficient in the multiple session environment. Consequently, known multi-session data storage facilities may not be completely adequate for some applications due to certain unsolved consistency issues.
SUMMARY OF THE INVENTION
Broadly, the present invention concerns a multi-session data storage facility that coordinates simi

Affiliated with

Also associated with

Rating

Coordinating remote copy status changes across multiple... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Coordinating remote copy status changes across multiple..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Coordinating remote copy status changes across multiple... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2916692