|Publication number||US6065018 A|
|Application number||US 09/034,867|
|Publication date||May 16, 2000|
|Filing date||Mar 4, 1998|
|Priority date||Mar 4, 1998|
|Publication number||034867, 09034867, US 6065018 A, US 6065018A, US-A-6065018, US6065018 A, US6065018A|
|Inventors||Harley Al Beier, Robert Frederic Kern, David Wayne Moore, Karen Alicia Ranson, Vern Lee Watts|
|Original Assignee||International Business Machines Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (16), Referenced by (226), Classifications (19), Legal Events (6)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
The present invention relates generally to disaster recovery in data processing systems using both hierarchial and relational databases. More particularly, the present invention relates to a method and apparatus to synchronize hierarchial and relational database recovery logs transmitted to a remote site for disaster recovery.
2. Description of the Related Art
Data processing systems typically require a large amount of data storage. Customer data, or data generated by users within the data processing system, usually occupy a great portion of this data storage. Effective data processing systems also provide back-up copies of this user data to insure against a loss of such data. For most businesses, any loss of data in their data processing systems is catastrophic, severely impacting the success of the business. To further protect customer data, some data processing systems extend the practice of making back-up recovery copies to provide disaster recovery. In disaster recovery systems, a recovery copy of the customer data is kept at a site remote from the primary storage location. If a disaster strikes the primary storage location, the customer data can be retrieved or "recovered" from the recovery copies located at the remote site.
A known method of providing disaster protection is to mirror, or shadow, the primary storage data at a remote storage site. Remote dual copy, or remote data duplexing, is one form of this data mirroring solution. In remote dual copy, additional storage devices are provided in the data processing system such that an additional copy of the primary data is written to a recovery storage device. Storage devices are coupled together to form duplex pairs, each duplex pair consisting of a primary and recovery storage device. The primary storage device is located at the primary storage location, while the recovery storage device is located at the remote site. When data is written to the primary storage device, the data processing system automatically copies the data to the recovery site.
Full volume copying is an alternate method for providing disaster recovery of a database. Full volume copying may use a storage management server to generate recovery storage volumes from the primary storage volumes. Commonly, a client-server configuration includes several clients connected to a single server. The clients create client files and transfer these files to the server. The server receives the client files and stores them on several attached storage devices. When used as a storage management system, the server manages the back-up, archival, and migration of these client files. By storing the client file on an attached storage device, the server creates a first back-up, or primary, copy of the client file. The server may, in turn, create additional back-up copies of the client file to improve the data availability and data recovery functions of the storage management system. Clients may vary from small personal computer systems to large data processing systems having a host processor connected to several data storage devices. The server can also range from a small personal computer to a large host processor.
To provide disaster recovery, the storage management server must generate a recovery copy of the client file and oversee the transmission of this recovery copy to a remote site. As a disaster recovery system, the server partitions the storage subsystem into a set of primary storage volumes and a set of remote, or off-site, recovery storage volumes. The off-site recovery volumes may contain removable media, so that they can be transported to the remote site. These volumes may be formatted using the same format or a different format from that used by the primary storage volumes for storing data and commands.
The server determines which client files need to be backed-up within the storage subsystem, how frequently these back-up copies should be made, or which set of the volumes should be transported to the remote site. The server or a separate controller may manage the off-site recovery storage volumes and determine which volumes are needed for disaster recovery. Off-site storage volumes no longer needed for disaster recovery may be reclaimed and reused. The server typically coordinates the reclamation and reuse of the recovery storage volumes. Successful reclamation and reuse of recovery volumes no longer needed for disaster recovery substantially improves the efficiency and performance of a disaster recovery system.
Incremental back-up techniques have evolved to improve the efficiency of disaster recovery systems. Using these techniques, only the user files new to the primary storage volume are copied to the recovery volumes since the last periodic back-up operation was completed. Thus, incremental back-up eliminates the unnecessary copying of files that remain unchanged since the previous back-up operation. As compared to full volume copying, incremental back-up reduces the number of partially filled storage volumes at the remote site. It also reduces the amount of duplicate files and duplicate volumes stored at the remote site, thereby simplifying the management of off-site recovery storage volumes.
Regardless of the recovery system used, these prior art recovery systems do not synchronize the remote recovery logs of the hierarchial and relational databases if independent transmission protocols are used. The update logs of the two database management systems--the hierarchial database and the relational database--are independently transmitted to the remote site. In essence, the logs for the hierarchial and relational database management systems operate as though each were a separate process even if the databases are related. If disaster strikes the primary site, the respective logs may not terminate at a consistent point.
For example, if a user has a system using an IMS and a DB2 system, current recovery systems do not synchronize the recovery logs. Although recovery logs may be kept, they are not synchronized with respect to time. As explained below, this may result in database inconsistencies if disaster strikes and the recovery logs at the remote site are used to recover the databases.
What is needed is a way to coordinate the disaster recovery techniques used by disparate database management systems. Remote log processing by the database management systems must be synchronized so that updates to related databases are consistent when a primary site disaster occurs. In addition, at least one of the database management systems needs to be able to update in real time the set of database copies it maintains at the remote site to keep them current with the primary set of databases to reduce the take-over time in the event of a disaster.
Broadly, the present invention concerns a method and apparatus to coordinate disaster recovery of related hierarchial and relational databases. Remote site recovery logs transmitted to a remote site are synchronized to expedite and insure consistent recovery in the event of a disaster at the primary site.
In one embodiment, the invention may be implemented to provide a method to synchronize logs at a remote site to recover logically different but related databases in the event a disaster occurs. The related databases in one embodiment are a hierarchial structured database and a relational structured database. A recovery log is used for recovery of database records, and a time stamp derived from a common time source may be assigned to each log record.
The update log records are transmitted to a recovery database management system where the log records are maintained in creation time sequence. If a disaster strikes the primary site, and recovery of data contained within the database is needed, the remote site recovery logs and databases may be used to recover some or all of the lost data. Based upon a comparison of the time stamp for the last received update record for the hierarchial database and the time stamp for the last received update record for the relational database, the logs are truncated to a common point in time. This truncation synchronizes the recovery logs and is used to generally ensure that the databases once recovered are consistent to a point as close as possible to the point at which the disaster occurred. For example, if an IMS and a DB2 database are being used, the IMS and DB2 recovery logs would be substantially synchronized by the truncation and, after recovery, their respective databases will be substantially consistent.
In another embodiment, the invention may be implemented to provide an apparatus for synchronizing the recovery logs. The apparatus comprises a storage management server coupled to a plurality of client systems. The server includes a storage manager, databases that may be shared, and a plurality of storage pools. The storage manager is coupled to the databases and the storage pools. A first storage pool, also referred to as a primary storage pool, contains a set of primary storage volumes for storing a primary copy of client files. The primary storage volumes may be located at a primary site. A secondary storage pool, also known as a recovery storage pool, contains a set of recovery storage volumes for storing a back-up copy of client files. The recovery volumes may comprise resident volumes located at the primary storage site and off-site volumes transported to a remote storage site.
In one embodiment, the storage manager receives client files from the client system and stores a primary copy of the client files in the primary storage pool. The storage manager also performs an incremental back-up operation by copying the newly created, or newly updated, client files in the primary storage pool to the recovery storage pool. The storage manager determines which recovery volumes are marked as off-site volumes and transported to the remote storage site. The storage manager also maintains a reference list, or index, within the database linking the primary copy of a client file to the recovery copy of the file within the copy storage pool. The storage manager automatically reclaims off-site recovery volumes no longer needed for disaster recovery before transporting the recovery volumes to the primary storage site.
In still another embodiment, the invention may be implemented to provide an article of manufacture comprising a data storage device tangibly embodying a program of machine-readable instructions executable by a digital data processing apparatus to perform method steps for synchronizing hierarchial and relational recovery logs transmitted to a remote site.
The invention affords its users with a number of distinct advantages. One advantage the invention provides is a way to synchronize the recovery logs of related databases where the databases use different database structures. Another advantage of the invention is that it ensures that the data on the related databases once recovered is consistent to the point at which a disaster occurs. The invention allows the complex problem of maintaining consistent databases to be accomplished in a manner which overcomes the time-consuming and error-prone methods currently practiced and putting data integrity at risk. For example, users of current methods generally write code to help in determining a consistent point to end the logs but the code depends on non-programming interfaces and thus can deteriorate with maintenance. In other words, as system software is replaced the code has to be updated or it may become dysfunctional.
This invention also provides a number of other advantages and benefits, which should be apparent from the following description of the invention.
The nature, objects, and advantages of the invention will become more apparent to those skilled in the art after considering the following detailed description in connection with the accompanying drawings, in which like reference numerals designate like parts throughout, wherein:
FIG. 1 is a block diagram of a data processing system showing a plurality of client systems coupled to a storage management server;
FIG. 2 is a block diagram of the storage management server in FIG. 1 providing off-site storage volumes for disaster recovery;
FIG. 3 is a block diagram illustrating a procedure commonly followed in committing updated data to a database;
FIG. 4 is a block diagram illustrating details of the database management system of FIG. 2;
FIG. 5 is a perspective view of an exemplary signal-bearing medium in accordance with the invention;
FIGS. 6A and 6B are a flowchart of an operational sequence for synchronizing the hierarchial and relational logs transmitted to a remote site for recovering related databases; and
FIGS. 7A through 7D illustrate the truncation of respective log records as discussed with respect to task 628 shown in FIG. 6B.
One aspect of the invention concerns an apparatus 100 for synchronizing recovery logs transmitted to a remote site for disaster recovery of related databases which may be embodied by various hardware components and interconnections as described in FIG. 1. Throughout this discussion, "recovery" refers to disaster recovery of a primary site with a remote site.
The apparatus 100 employs multiple client systems 102 coupled to a server system (primary site) 103. The primary site 103 includes a storage manager 104 coupled to a server database 106. The database may comprise multiple databases using similar or dissimilar formatting. The storage manager 104 is further coupled to a plurality of primary storage pools 110 and a cache 130. A storage pool 110 consists of a plurality of storage devices, either DASD, optical disk, or magnetic tape devices. All storage devices within the primary storage pool 110 may be, but are not necessarily, identical in type and format. The server database is further coupled to a set of recovery volumes 220 shown in FIG. 2 and providing a back-up for the server database 106. In one embodiment, the recovery volumes 220 are located at a site remote from the primary storage site.
Each client system 102 creates original user data files, or client files, which are stored within the corresponding client system if the client system is provided with a storage system. Regardless, the client systems 102 transfer client files to the server system 103. Transferring client files to the primary site 103 inherently provides a back-up mechanism within the server for original client files stored within the client system. The storage manager 104 directs the client file to a storage device, or storage volume, within a primary storage pool 110. The primary storage pool stores a primary copy of the client files. The storage manager 104 maintains a log 105 within the server database 106 listing the files stored within the primary storage pool 110 and the cache 130 of the primary site 103. Once the client file is stored within a primary storage pool 110, the storage manager 104 updates the server database 106 and logs the updates in log 105 at the primary site 103.
In one embodiment, the server system 103 might also include the cache 130. This cache is used by the storage manager 104 to coordinate temporary storage of data copied from nonvolatile storage during a restart recovery process. In one embodiment, the cache 130 is volatile storage. In another embodiment, the cache is nonvolatile but erasable. Regardless, if the cache 130 becomes full during a restart recovery process, over-flow data may be written to another cache, for example, cache (not shown) located in the storage manager 104.
In one embodiment, the server system might also generate an additional back-up recovery copy of the client file and store this recovery copy on a storage device, or storage volume, within a remote site 200 shown in FIG. 2. The storage manager 104 coordinates this operation. Once the additional recovery copy is created, the storage manager 104 updates the log 105 of server database 106 to catalog the recovery copy of the client file. In addition, the log entry within the server database corresponding to the recovery copy includes cross-reference to the primary copy of the client file. Thus, the primary copy in the primary storage pool 110 is linked to the recovery copy.
FIG. 2 shows a server (referred to as remote or off-site) 200 of FIG. 1 configured as a remote disaster recovery system. The disaster recovery system includes a remote storage pool 220 within the remote site 200. The remote site server 200 also includes the controller 202 and a recovery log 204. In addition, the remote storage pool 220 may contain copies of the data volumes contained in the primary storage volumes located within the primary storage pools 110 and any other resident copy storage volumes within the primary storage site 103. The remote site 200 contains remote storage pool 220 which are copy storage volumes that have been transferred from the primary storage site 103 at the direction of the storage manager 104.
The storage manager 104 determines which primary storage pool volumes 111-120 should be used for back-up storage and recovery, and then copies and marks the designated volume in the server database 103 as an off-site storage volume. The copies are then delivered to the remote site 200. The storage manager 104 uses the server database 106 to monitor the recovery copies of the client files stored on the off-site storage volumes 221-229. The storage manager 104 can then determine when an off-site volume is no longer needed for disaster recovery, and marks this volume for deletion or transfer back to the primary storage site 103. Further, as each database transaction is executed and each database recovery copy is made, an entry is made by the storage manager 104 in the log 105 to keep track of each transaction and data update. In another embodiment, back-up volumes to the primary storage pool 110 may be kept at the primary site 103 in addition to the remote storage pool 220 back-up copies housed at the remote site 200.
Regardless of whether primary storage pool volume 111 through 120 is marked and copied as an off-site volume and then physically transported to the remote site, or whether the contents of the copy of the primary storage pool volumes is transmitted to the remote site via a data link, the remote site 200 shown in FIG. 2 processes the data in a similar manner. When updated data is received by the controller 202 of the remote system 200, the controller decides which of the off-site storage volumes 220 and respective recovery logs will receive the updated data. If an existing file on a remote site volume 221 through 229 is to be updated, the controller 202 routes the updated data to the respective volume and log. If no current file exists that needs to be updated, the controller 202 may allocate the file to any of the storage volumes 220. As the updated data is received, the controller 202 also updates a recovery log 204.
The log 204 acts as index for the data records being maintained on the remote storage pool 220 volumes. The recovery log 204 may also perform other functions as discussed below. The transfer of data from the primary storage site 103 to the remote site 200 is coordinated by the storage manager 104 and the controller 202.
Despite the specific foregoing description, ordinarily skilled artisans (having the benefit of this disclosure) will recognize that the apparatus discussed above may be implemented in a machine of different construction, without departing from the scope of the invention.
In addition to the various hardware embodiments described above, a different aspect of the invention concerns a method for recovering related databases using the present invention.
The apparatus shown in FIGS. 1 and 2 are used in one embodiment to maintain related databases. For example, the server database 106 may contain multiple databases where the databases do not share a similar logical structure or format. Regardless, each of the databases is intended to contain data which reflects a real state of the information that database is supposed to capture. When the databases reflect what is the current state of the data, the databases are deemed consistent.
To better understand the recovery system of the present invention, the following terminology should be helpful. A database transaction is a program unit whose execution preserves the consistency of the database. For example, if before a transaction executes the database is in a consistent state then, when the next transaction completes its execution, the database remains in a consistent state. The transaction assesses and possibly updates various data items contained in the database. Each of the data items may be read by the transaction and is written by the transaction if it updates that data item. A transaction is the work that occurs between the beginning of a unit of work and a commit or abort as defined below.
As reflected in FIG. 3, a transaction block diagram is shown. The transaction is shown in its initial state in task 302. When it reaches its last statement, it enters a partially committed state in task 304. At this point, the transaction has completed its execution, but it is still possible that it may have to be aborted, which includes rolling back the non-committed data, since the actual updates may not have been output to storage yet, and thus a hardware failure may preclude its successful completion. In one embodiment of the present invention, writing to storage takes place only after a transaction has entered the commit stage as shown in task 308. As discussed below, one way to implement such a scheme is to store any value associated with such writing to storage temporarily in a nonvolatile storage, and to perform the actual writes only at commit time 308. A committed transaction will then be able to complete its write except in the case of hardware storage failures.
The transaction enters the failed state in task 306 if it is determined that the transaction cannot proceed with normal execution, that is, for example, due to hardware or logical errors. If failure occurs, the transaction must be rolled-back. Once a rollback has occurred, the transaction enters the aborted state in task 310.
As applied to this invention and as illustrated in FIG. 4, "forward" database updating is performed by using REDO records of a transaction log 408. As an example, assume that records, identified by record numbers RA-RF are included in the defined data block j (DDBj) which is included in a data set stored in a database 406. Assume next a transaction against records RB-RD of DDBj, and that the records are to be updated as a result of the transaction. For updating, storage manager 404 transfers the page DDBj to a buffer 402 where the records RB-RD are updated, in each case by changing record data CB to CX. During the processing of these records, log entries are made in the sequence in which the records were updated. Each record update results in the writing of an UNDO and REDO record to the transaction log 408. For example, the transaction log entry for updating record RB includes an UNDO record with a field containing the record data before updating (CB), a field identifying the record (RB), and a field containing a relative block number (RBN) which identifies the location of the primary storage page containing the record. The REDO component of the log record includes a field containing the update of the record data (CX) and the RBN and RB fields identifying, respectively, the page and the record. Assuming completion of the transaction or set of transactions which update records RB-RD, the storage manager 404 will write the buffer page to the primary storage location for DDBj. Later, if recovery is required, the recovery process will use the transaction log REDO records to update records RB-RD.
Forward and "backward" updating recovery functions are available in database products manufactured by the IBM Corporation. Forward and backward updating are supported in the database manager of the IBM DB2 and IMS/ESA program products. In these products, UNDO records are logged in addition to REDO records. If a transaction associated with a REDO record ABORTs, the record data from the UNDO record is logged as a REDO record and is applied to the database, thus "backing-out" the original update to the record. In the FAST PATH database manager of the IBM IMS/ESA program product used in one embodiment, UNDO records are not logged. Rather, changes are withheld from the database until REDO records have been logged and the updating transactions have completed. Successful completion of the transaction is indicated by a COMMIT operation which is recorded by a COMMIT record in the transaction log. If the transaction is abnormally terminated, an ABORT record is entered in the log.
After the server database 106 and the storage pools of server 103 have been updated by a transaction, the off-site recovery storage volumes of remote site 200 may be updated, as described below with respect to the method of the invention. However, because of the related databases in one embodiment of the present invention where each database may not employ a common logical structure or format, the present invention provides a method to coordinate recovery of the related databases and the logs used for recovery. The method of the present invention is described in detail as to its overall sequence of operation below.
Overall Sequence of Operation
FIGS. 6A and 6B show a sequence of method steps 600 to illustrate one example of the method aspect of the present invention. For ease of explanation, but without any limitation intended thereby, the example of FIGS. 6A and 6B are described in the context of the apparatus 100 described above. The steps are initiated in task 602, when a primary database system linked to a remote recovery facility processes transactions. The primary database comprises a hierarchial database and a relational database. In the one embodiment, the hierarchial database is a IMS database and the relational database is a DB2 database.
The related hierarchial and relational databases are maintained in task 604. Maintaining the primary database comprises updating the database with changes to the data stored therein and continually updating that data. Several techniques are known in the art for maintaining the primary database in a consistent state. The primary database may incorporate separate logs for the hierarchial database and the relational database, and may implement a plurality of logs for each. The update log information may be transmitted to a remote site to insure recovery if disaster recovery is required by the primary database.
In maintaining a database, an entry is made to each update log and a time stamp is assigned to each entry. Commonly, the time stamp is assigned by the storage manager 104 shown in FIG. 1 or the controller 202 shown in FIG. 2, however, those skilled in the art will realize that any processor used in conjunction with the primary database may assign the time stamp. The time stamp represents the creation time sequence for a given entry, that is, the time at which the entry was created in a respective log.
When entries to the update log are complete in task 606, the update log records are transmitted to the remote site for backup protection. If no records need to be updated as the result of a transaction, the method returns to task 604 and continues maintaining the database.
If hierarchial log records from task 608 are transmitted from the primary database to the recovery database, they are processed only up to the point that data has been captured on the relational database log volumes at the remote site. The point is established by comparing entry time stamps. This assures that in the event of a primary site disaster the truncation point for the hierarchial tracking logs will be earlier in time than the end point of the relational tracking logs. Using the time stamp of task 604, the updates to the records are transmitted in task 608 to the remote site. In one embodiment, the record updates may be transmitted to the recovery database's management system including controller 202 in parallel in task 610.
As part of maintaining the recovery resources, the storage manager 104 or the controller 202 keeps track of the time stamp of the last hierarchical and relational log entries. The hierarchical time stamp is compared to the last relational log in task 612, then the updates are applied to the hierarchical databases. If the hierarchical time stamp is not less than or equal to the relational log time stamp, then the method 600 requests a new time stamp for the last entry to the relational log in task 614. The request seeks to determine the time stamp of the last entry to the relational database logs.
If a new time stamp for the last entry to the relational database (relational time stamp) is received within a designated period of time in task 616, then the method 600 again compares the hierarchial database time stamp in task 617 (hierarchial time stamp) with the relational time stamp in task 612, and if the hierarchial time stamp is less than or equal to the relational time stamp, the updated log records are applied to the remote site 200 hierarchial database. By assuring that the hierarchial time stamp is less than or equal to the relational time stamp, the update logs for the hierarchial database and the relational database are able to be synchronized for later processing (truncation).
Returning to task 616, if a new hierarchial time stamp has not been received within a predetermined time period, then the method 600 uses the last relational database time stamp in task 618 as the point in time to stop applying updates to the remote site hierarchial databases. Transaction updates to the databases which occurred after this time stamp are not applied unless a new relational time stamp is received in task 618. This routine maintenance of the databases and related logs ends in task 620. If disaster recovery is required, this time stamp represents the end time stamp of the hierarchial relational logs. The hierarchial logs are truncated at the point represented by this time stamp in task 623 shown in FIG. 6B.
If disaster strikes and a takeover of the primary site functions by the remote site is required, the remote recovery method of the invention is implemented as shown in FIG. 6B beginning at task 622. For example, the primary site may be rendered unusable due to fire, flood or earthquake.
If disaster recovery is required, the last hierarchial time stamp recorded on the recovery log is reported in task 624. This time stamp is used to coordinate the remote site 200 recovery. After the time stamp is reported, the remote site's controller 202 may automatically initiate recovery. In another embodiment, the time stamp is reported to a user, such as a database administrator, and the user initiates the recovery. For example, the last hierarchial time stamp may be displayed on a device such as a monitor, printed-out on a printer, audibly output, or otherwise communicated to the user. The communication device used may be interfaced with the client 102 shown in FIG. 1 and/or the remote site 200 shown in FIG. 2. In either case, the hierarchial time stamp is reported as the "recovery timestamp" in task 624 and used to synchronize the recovery logs to that point in time for recovery and restart purposes in task 626.
In one embodiment, the end user may only use the last hierarchial time stamp as the recovery time stamp. The time stamp selected is used as a truncation point to synchronize the recovery log records at the selected point in time in task 628. These recovery log records, comprising the hierarchial and relational database recovery logs, are used to restart and recover the primary database at the remote site in task 630.
Truncation of the recovery log records at the remote site is best understood referring to FIGS. 7A through 7D. FIGS. 7A and 7B show a time line for record entries for the preferred embodiment DB2 logs and IMS logs received at the remote site, respectively, used in conjunction with the DB2 and IMS databases. At time 0, no record entries have been made. As time increases, indicated by the line increasing to the right, an increasing number of record entries have been made to each log. FIG. 7A shows the DB2 logs having an end time marked at the point-in-time 702. FIG. 7B shows the IMS LOG #1 having an end time marked at a point-in-time 704 and IMS LOG #2 continuing past time 702.
The recovery logs are constructed such that the hierarchial database recovery time lags the relational database recovery time, that is, that processing of entries in the IMS logs shown in FIG. 7B always lag the recovery time of the DB2 logs shown in FIG. 7A. Comparison of FIGS. 7A and 7B indicate that the hierarchial database recovery time 704 for the IMS logs does lag the relational database recovery time 702. As shown in FIGS. 7C and 7D, respectively, the DB2 logs are truncated in the present invention to the hierarchial database recovery time represented by time stamp 704, and the hierarchial logs are also truncated to that point in time. The DB2 log data contained on the DB2 logs at a time after recovery time stamp 704 is not used in the data recovery method 600. This "truncation" results in the DB2 log recovery time equaling the IMS log recovery time which synchronizes the logs used to recover the hierarchial and relational databases.
After truncation of the logs, recovery continues in task 632. During recovery, the primary site is not available and recovery is coordinated from the remote site 200. Recovery continues when the hierarchial and relational databases are restarted at the remote site 200. The method ends in task 634.
During remote site recovery, update log records are written to the logs at the remote site. The relational databases are not maintained in real time as update log records are received. They are recovered after a disaster has occurred using normal recovery such as generally discussed in U.S. Pat. No. 5,615,329, issued Mar. 25, 1997, entitled "REMOTE DATA DUPLEXING," incorporated herein by reference and assigned to the assignee of the present invention, or using other commonly practiced recovery utilities. Once the remote site 200 databases have been recovered, the recovered databases become the "primary" database because the original primary database is no longer useable. These remote logs are used to restore the primary database to its prior state as of the time reported in task 624 used for recovery purposes.
In one embodiment, shadowing of the relational remote site databases may occur by running the recovery utility periodically at the remote site 200. The hierarchial remote site databases are shadowed in real time but the relational remote site databases are not because the remote relational logs are subject to truncation--allowing the hierarchial recovery log to always lag the relational recovery log--as discussed above. This periodical "shadowing" of the relational remote site 200 databases reduces the time required to recover the relational databases if a primary site disaster strikes.
Such a method may be implemented, for example, by operating the apparatus 100 to execute a sequence of machine-readable instructions. These instructions may reside in various types of signal-bearing media. In this respect, one aspect of the present invention concerns a programmed product, comprising signal-bearing media tangibly embodying a program of machine-readable instructions executable by a digital data processor to perform a method to synchronize recovery logs transmitted to a remote site to recover related databases having dissimilar logical structures or formats.
This signal-bearing media may comprise, for example, RAM (not shown) contained within the apparatus 100. Alternatively, the instructions may be contained in another signal-bearing media, such as a magnetic data storage diskette 500 as shown in FIG. 5, directly or indirectly accessible by the apparatus 100. Whether contained in the apparatus 100 or elsewhere, the instructions may be stored on a variety of machine-readable data storage media, such as DASD storage (e.g., a conventional "hard drive" or a RAID array), magnetic tape, electronic read-only memory (e.g., ROM, CD-ROM, EPROM, or EEPROM), an optical storage device (e.g., CD-ROM, WORM, DVD, digital optical tape), paper "punch" cards, or other suitable signal-bearing media including transmission media such as digital and analog and communication links and wireless. In an illustrative embodiment of the invention, the machine-readable instructions may comprise lines of compiled C, C++, or similar language code commonly used by those skilled in the programming for this type of application arts.
While there have been shown what are presently considered to be preferred embodiments of the invention, it will be apparent to those skilled in the art that various changes and modifications can be made herein without departing from the scope of the invention as defined by the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5170480 *||Sep 25, 1989||Dec 8, 1992||International Business Machines Corporation||Concurrently applying redo records to backup database in a log sequence using single queue server per queue at a time|
|US5278982 *||Dec 23, 1991||Jan 11, 1994||International Business Machines Corporation||Log archive filtering method for transaction-consistent forward recovery from catastrophic media failures|
|US5446871 *||Mar 23, 1993||Aug 29, 1995||International Business Machines Corporation||Method and arrangement for multi-system remote data duplexing and recovery|
|US5561795 *||May 13, 1994||Oct 1, 1996||Unisys Corporation||Method and apparatus for audit trail logging and data base recovery|
|US5566297 *||Jun 16, 1994||Oct 15, 1996||International Business Machines Corporation||Non-disruptive recovery from file server failure in a highly available file system for clustered computing environments|
|US5594863 *||Jun 26, 1995||Jan 14, 1997||Novell, Inc.||Method and apparatus for network file recovery|
|US5594900 *||Mar 22, 1995||Jan 14, 1997||International Business Machines Corporation||System and method for providing a backup copy of a database|
|US5615329 *||Feb 22, 1994||Mar 25, 1997||International Business Machines Corporation||Remote data duplexing|
|US5619644 *||Sep 18, 1995||Apr 8, 1997||International Business Machines Corporation||Software directed microcode state save for distributed storage controller|
|US5640561 *||Jun 6, 1995||Jun 17, 1997||International Business Machines Corporation||Computerized method and system for replicating a database using log records|
|US5673382 *||May 30, 1996||Sep 30, 1997||International Business Machines Corporation||Automated management of off-site storage volumes for disaster recovery|
|US5682513 *||Mar 31, 1995||Oct 28, 1997||International Business Machines Corporation||Cache queue entry linking for DASD record updates|
|US5852715 *||Mar 19, 1996||Dec 22, 1998||Emc Corporation||System for currently updating database by one host and reading the database by different host for the purpose of implementing decision support functions|
|US5913219 *||Feb 4, 1997||Jun 15, 1999||Electronics And Telecommunications Research Institute||Database recovery apparatus and method of using dual plane nonvolatile memory|
|US5924096 *||Oct 15, 1997||Jul 13, 1999||Novell, Inc.||Distributed database using indexed into tags to tracks events according to type, update cache, create virtual update log on demand|
|US5949970 *||Jan 7, 1997||Sep 7, 1999||Unisys Corporation||Dual XPCS for disaster recovery|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US6237008 *||Jul 20, 1998||May 22, 2001||International Business Machines Corporation||System and method for enabling pair-pair remote copy storage volumes to mirror data in another storage volume|
|US6249849 *||Jun 16, 1999||Jun 19, 2001||International Business Machines Corporation||“Fail-Safe” updating of redundant data in multiple data storage libraries|
|US6266784 *||Sep 15, 1998||Jul 24, 2001||International Business Machines Corporation||Direct storage of recovery plan file on remote server for disaster recovery and storage management thereof|
|US6336172 *||Apr 1, 1999||Jan 1, 2002||International Business Machines Corporation||Storing and tracking multiple copies of data in a data storage library system|
|US6336173 *||Apr 1, 1999||Jan 1, 2002||International Business Machines Corporation||Storing and tracking multiple copies of data in data storage libraries|
|US6411991 *||Sep 25, 1998||Jun 25, 2002||Sprint Communications Company L.P.||Geographic data replication system and method for a network|
|US6466951 *||Feb 8, 2000||Oct 15, 2002||Telefonaktiebolaget Lm Ericsson (Publ)||Data base synchronizing system with at least two host databases and a remote database|
|US6473829 *||May 28, 1999||Oct 29, 2002||International Business Machines Corporation||Data storage device providing communication between processing units|
|US6542904 *||Jul 30, 1999||Apr 1, 2003||International Business Machines Corporation||Method and system for efficiently providing maintenance activity on a relational database that is utilized within a processing system|
|US6658590 *||Mar 30, 2000||Dec 2, 2003||Hewlett-Packard Development Company, L.P.||Controller-based transaction logging system for data recovery in a storage area network|
|US6671705 *||Aug 17, 1999||Dec 30, 2003||Emc Corporation||Remote mirroring system, device, and method|
|US6701455 *||Aug 29, 2000||Mar 2, 2004||Hitachi, Ltd.||Remote copy system with data integrity|
|US6799258 *||Jan 10, 2002||Sep 28, 2004||Datacore Software Corporation||Methods and apparatus for point-in-time volumes|
|US6847983||Feb 28, 2001||Jan 25, 2005||Kiran Somalwar||Application independent write monitoring method for fast backup and synchronization of open files|
|US6850958 *||Nov 16, 2001||Feb 1, 2005||Fujitsu Limited||Backup system, backup method, database apparatus, and backup apparatus|
|US6925476 *||Aug 17, 2000||Aug 2, 2005||Fusionone, Inc.||Updating application data including adding first change log to aggreagate change log comprising summary of changes|
|US6938045||Jan 18, 2002||Aug 30, 2005||Seiko Epson Corporation||Image server synchronization|
|US6973533||Aug 20, 2002||Dec 6, 2005||International Business Machines Corporation||Data storage device providing communication between processing units|
|US6978280 *||Oct 12, 2000||Dec 20, 2005||Hewlett-Packard Development Company, L.P.||Method and system for improving LUN-based backup reliability|
|US6978396 *||May 30, 2002||Dec 20, 2005||Solid Information Technology Oy||Method and system for processing replicated transactions parallel in secondary server|
|US6983295 *||Oct 24, 2002||Jan 3, 2006||Unisys Corporation||System and method for database recovery using a mirrored snapshot of an online database|
|US6985915||Feb 28, 2001||Jan 10, 2006||Kiran Somalwar||Application independent write monitoring method for fast backup and synchronization of files|
|US7003694 *||May 22, 2002||Feb 21, 2006||Oracle International Corporation||Reliable standby database failover|
|US7035878||Aug 17, 2000||Apr 25, 2006||Fusionone, Inc.||Base rolling engine for data transfer and synchronization system|
|US7039660||Jul 29, 2003||May 2, 2006||Hitachi, Ltd.||Disaster recovery processing method and apparatus and storage unit for the same|
|US7051173 *||Jan 3, 2001||May 23, 2006||Fujitsu Limited||Backup system and method thereof in disk shared file system|
|US7069295||Feb 14, 2002||Jun 27, 2006||The Escher Group, Ltd.||Peer-to-peer enterprise storage|
|US7085782||May 14, 2003||Aug 1, 2006||International Business Machines Corporation||Log grooming in a multi-log environment|
|US7096382 *||Mar 4, 2002||Aug 22, 2006||Topio, Inc.||System and a method for asynchronous replication for storage area networks|
|US7130971 *||Mar 30, 2004||Oct 31, 2006||Hitachi, Ltd.||Assuring genuineness of data stored on a storage device|
|US7162593||Jan 5, 2006||Jan 9, 2007||Hitachi, Ltd.||Assuring genuineness of data stored on a storage device|
|US7185227 *||Apr 30, 2003||Feb 27, 2007||Hitachi, Ltd.||Data restoring method and an apparatus using journal data and an identification information|
|US7203732||Jun 2, 2001||Apr 10, 2007||Miralink Corporation||Flexible remote data mirroring|
|US7206796 *||Aug 12, 2005||Apr 17, 2007||Microsoft Corporation||System and method for synchronizing multiple database files|
|US7210058||Sep 29, 2003||Apr 24, 2007||International Business Machines Corporation||Method for peer-to-peer system recovery|
|US7222136 *||May 23, 2002||May 22, 2007||Oracle International Corporation||Communicating data dictionary information of database objects through a redo stream|
|US7243103 *||Aug 12, 2002||Jul 10, 2007||The Escher Group, Ltd.||Peer to peer enterprise storage system with lexical recovery sub-system|
|US7243256||Jun 8, 2006||Jul 10, 2007||Hitachi, Ltd.||External storage and data recovery method for external storage as well as program|
|US7260590 *||Dec 27, 2000||Aug 21, 2007||Cisco Technology, Inc.||Streamed database archival process with background synchronization|
|US7278049||Sep 29, 2003||Oct 2, 2007||International Business Machines Corporation||Method, system, and program for recovery from a failure in an asynchronous data copying system|
|US7281023||Dec 15, 2003||Oct 9, 2007||At&T Knowledge Ventures, L.P.||Architecture of database application with robust online recoverability|
|US7305584||Feb 24, 2006||Dec 4, 2007||Hitachi, Ltd.||Data restoring method and an apparatus using journal data and an identification information|
|US7330859 *||Sep 10, 2003||Feb 12, 2008||International Business Machines Corporation||Database backup system using data and user-defined routines replicators for maintaining a copy of database on a secondary server|
|US7353223||Aug 28, 2003||Apr 1, 2008||Sap Aktiengesellschaft||Directed graph for distribution of time-constrained data|
|US7370222||Mar 9, 2007||May 6, 2008||Hitachi, Ltd.||External storage and data recovery method for external storage as well as program|
|US7376866 *||Oct 22, 2004||May 20, 2008||Network Appliance, Inc.||Method and an apparatus to perform fast log replay|
|US7383293 *||Oct 31, 2007||Jun 3, 2008||International Business Machines Corporation||Database backup system using data and user-defined routines replicators for maintaining a copy of database on a secondary server|
|US7386463||Aug 9, 2001||Jun 10, 2008||Miralink Corporation||Data/presence insurance tools and techniques|
|US7421549 *||Mar 2, 2004||Sep 2, 2008||Hitachi, Ltd.||Method and apparatus of remote copy for multiple storage subsystems|
|US7428657 *||Nov 14, 2005||Sep 23, 2008||Hitachi, Ltd.||Method for rolling back from snapshot with log|
|US7437609 *||Jan 3, 2006||Oct 14, 2008||Oracle International Corporation||Reliable standby database failover|
|US7447710||Aug 9, 2004||Nov 4, 2008||Sybase, Inc.||Database system providing self-tuned parallel database recovery|
|US7464288||Feb 6, 2008||Dec 9, 2008||Hitachi, Ltd.||External storage and data recovery method for external storage as well as program|
|US7469358||Mar 9, 2007||Dec 23, 2008||Hitachi, Ltd.||External storage and data recovery method for external storage as well as program|
|US7539703 *||Jun 20, 2006||May 26, 2009||Hitachi, Ltd.||Setup method for disaster recovery system|
|US7546488||Jul 2, 2004||Jun 9, 2009||Seagate Technology Llc||Event logging and analysis in a software system|
|US7546489||Jan 25, 2005||Jun 9, 2009||Seagate Technology Llc||Real time event logging and analysis in a software system|
|US7549083||Dec 12, 2006||Jun 16, 2009||Hitachi, Ltd.||Data restoring method and an apparatus using journal data and an identification information|
|US7555618||Dec 5, 2006||Jun 30, 2009||Hitachi, Ltd.||Assuring genuineness of data stored on a storage device|
|US7562103||Sep 16, 2005||Jul 14, 2009||Hitachi, Ltd.||Disaster recovery processing method and apparatus and storage unit for the same|
|US7565572 *||Aug 15, 2008||Jul 21, 2009||Hitachi, Ltd.||Method for rolling back from snapshot with log|
|US7620668 *||Nov 17, 2009||Microsoft Corporation||Authoritative and non-authoritative restore|
|US7627612 *||Sep 28, 2006||Dec 1, 2009||Emc Israel Development Center, Ltd.||Methods and apparatus for optimal journaling for continuous data replication|
|US7640276 *||May 19, 2005||Dec 29, 2009||Hitachi, Ltd.||Backup system, program and backup method|
|US7643824||Jan 5, 2010||Cooligy Inc||Wireless telephone data backup system|
|US7644308 *||Mar 6, 2006||Jan 5, 2010||Hewlett-Packard Development Company, L.P.||Hierarchical timestamps|
|US7668874||Aug 29, 2003||Feb 23, 2010||Hitachi, Ltd.||Disaster recovery processing method and apparatus and storage unit for the same|
|US7680795 *||Mar 16, 2007||Mar 16, 2010||International Business Machines Corporation||Shared disk clones|
|US7681076||Apr 30, 2008||Mar 16, 2010||Network Appliance, Inc.||Method and an apparatus to perform fast log replay|
|US7711712 *||Mar 12, 2007||May 4, 2010||Hitachi, Ltd.||System and method for managing consistency among volumes based on application information|
|US7725667||Mar 12, 2004||May 25, 2010||Symantec Operating Corporation||Method for identifying the time at which data was written to a data store|
|US7725760||Aug 24, 2004||May 25, 2010||Symantec Operating Corporation||Data storage system|
|US7730222||Aug 24, 2004||Jun 1, 2010||Symantec Operating System||Processing storage-related I/O requests using binary tree data structures|
|US7774565||Dec 12, 2006||Aug 10, 2010||Emc Israel Development Center, Ltd.||Methods and apparatus for point in time data access and recovery|
|US7788462||Oct 31, 2007||Aug 31, 2010||International Business Machines Corporation||Resource management for data storage services|
|US7809685 *||Feb 9, 2007||Oct 5, 2010||Ricoh Co., Ltd.||Secure and efficient methods for logging and synchronizing data exchanges|
|US7818435||Dec 14, 2000||Oct 19, 2010||Fusionone, Inc.||Reverse proxy mechanism for retrieving electronic content associated with a local network|
|US7827362||Aug 24, 2004||Nov 2, 2010||Symantec Corporation||Systems, apparatus, and methods for processing I/O requests|
|US7840536||Dec 26, 2007||Nov 23, 2010||Emc (Benelux) B.V., S.A.R.L.||Methods and apparatus for dynamic journal expansion|
|US7849361||Dec 12, 2006||Dec 7, 2010||Emc Corporation||Methods and apparatus for multiple point in time data access|
|US7860836||Dec 26, 2007||Dec 28, 2010||Emc (Benelux) B.V., S.A.R.L.||Method and apparatus to recover data in a continuous data protection environment using a journal|
|US7870169 *||Jun 29, 2007||Jan 11, 2011||International Business Machines Corporation||Method for enabling traceability and recovery from errors during migration of software applications|
|US7873860||Jan 18, 2011||Hitachi, Ltd.||External storage and data recovery method for external storage as well as program|
|US7885938 *||Feb 27, 2008||Feb 8, 2011||Symantec Corporation||Techniques for granular recovery of data from local and remote storage|
|US7890461||Feb 15, 2011||Hitachi, Ltd.||System executing log data transfer synchronously and database data transfer asynchronously|
|US7895334||Jul 19, 2000||Feb 22, 2011||Fusionone, Inc.||Remote access communication architecture apparatus and method|
|US7904428||Mar 8, 2011||Symantec Corporation||Methods and apparatus for recording write requests directed to a data store|
|US7904913||Nov 1, 2005||Mar 8, 2011||Bakbone Software, Inc.||Management interface for a system that provides automated, real-time, continuous data protection|
|US7917708||May 22, 2009||Mar 29, 2011||Hitachi, Ltd.||Assuring genuineness of data stored on a storage device|
|US7941501||Mar 19, 2007||May 10, 2011||Miralink Corporation||Flexible remote data mirroring|
|US7949666||Jul 9, 2004||May 24, 2011||Ricoh, Ltd.||Synchronizing distributed work through document logs|
|US7953749 *||Jun 18, 2004||May 31, 2011||Oracel International Corporation||Providing the timing of the last committed change to a row in a database table|
|US7971097||Oct 27, 2008||Jun 28, 2011||Hitachi, Ltd.||Data restoring method and an apparatus using journal data and an identification information|
|US7979404||Sep 17, 2004||Jul 12, 2011||Quest Software, Inc.||Extracting data changes and storing data history to allow for instantaneous access to and reconstruction of any point-in-time data|
|US7979441||Jan 21, 2010||Jul 12, 2011||Quest Software, Inc.||Method of creating hierarchical indices for a distributed object system|
|US7986616 *||Aug 5, 2009||Jul 26, 2011||Broadcom Corporation||System and method for maintaining a layer 2 modification buffer|
|US7991748||Feb 17, 2004||Aug 2, 2011||Symantec Corporation||Virtual data store creation and use|
|US8001076||Jul 12, 2005||Aug 16, 2011||International Business Machines Corporation||Ranging scalable time stamp data synchronization|
|US8005799 *||Jun 23, 2009||Aug 23, 2011||Fujitsu Limited||Information management system|
|US8006094||Feb 21, 2007||Aug 23, 2011||Ricoh Co., Ltd.||Trustworthy timestamps and certifiable clocks using logs linked by cryptographic hashes|
|US8010627||Sep 25, 1998||Aug 30, 2011||Sprint Communications Company L.P.||Virtual content publishing system|
|US8015194||Dec 29, 2005||Sep 6, 2011||Ricoh Co., Ltd.||Refining based on log content|
|US8041940||Dec 26, 2007||Oct 18, 2011||Emc Corporation||Offloading encryption processing in a storage area network|
|US8060713||Mar 28, 2008||Nov 15, 2011||Emc (Benelux) B.V., S.A.R.L.||Consolidating snapshots in a continuous data protection system using journaling|
|US8060889||Nov 15, 2011||Quest Software, Inc.||Method and system for real-time event journaling to provide enterprise data services|
|US8073954||Jul 19, 2000||Dec 6, 2011||Synchronoss Technologies, Inc.||Method and apparatus for a secure remote access system|
|US8074222 *||Feb 7, 2008||Dec 6, 2011||Fujitsu Limited||Job management device, cluster system, and computer-readable medium storing job management program|
|US8095511||Apr 28, 2004||Jan 10, 2012||Microsoft Corporation||Database data recovery system and method|
|US8095537||Dec 29, 2005||Jan 10, 2012||Ricoh Co., Ltd.||Log integrity verification|
|US8108429||May 6, 2005||Jan 31, 2012||Quest Software, Inc.||System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services|
|US8131723||Mar 31, 2008||Mar 6, 2012||Quest Software, Inc.||Recovering a file system to any point-in-time in the past with guaranteed structure, content consistency and integrity|
|US8151140||Jul 28, 2010||Apr 3, 2012||Quest Software, Inc.||Method and system for virtual on-demand recovery for real-time, continuous data protection|
|US8156074||Jan 26, 2000||Apr 10, 2012||Synchronoss Technologies, Inc.||Data transfer and synchronization system|
|US8170996||Dec 9, 2010||May 1, 2012||Hitachi, Ltd.||Storage subsystem|
|US8181111||Dec 31, 2008||May 15, 2012||Synchronoss Technologies, Inc.||System and method for providing social context to digital activity|
|US8185733||Oct 2, 2008||May 22, 2012||Ricoh Co., Ltd.||Method and apparatus for automatically publishing content based identifiers|
|US8190576 *||Oct 26, 2006||May 29, 2012||Panasonic Corporation||File recording device and imaging device|
|US8195628||Oct 11, 2010||Jun 5, 2012||Quest Software, Inc.||Method and system for data reduction|
|US8200706||Jul 11, 2011||Jun 12, 2012||Quest Software, Inc.||Method of creating hierarchical indices for a distributed object system|
|US8205009||Apr 1, 2003||Jun 19, 2012||Emc Israel Development Center, Ltd.||Apparatus for continuous compression of large volumes of data|
|US8205058 *||Dec 10, 2004||Jun 19, 2012||International Business Machines Corporation||Resource management for data storage services|
|US8255006||Nov 10, 2009||Aug 28, 2012||Fusionone, Inc.||Event dependent notification system and method|
|US8315976||Feb 26, 2008||Nov 20, 2012||Synchronoss Technologies, Inc.||Data transfer and synchronization system|
|US8332687||Jun 23, 2010||Dec 11, 2012||Emc Corporation||Splitter used in a continuous data protection environment|
|US8335761||Dec 2, 2010||Dec 18, 2012||Emc International Company||Replicating in a multi-copy environment|
|US8335771||Sep 29, 2010||Dec 18, 2012||Emc Corporation||Storage array snapshots for logged access replication in a continuous data protection system|
|US8352523||Sep 23, 2011||Jan 8, 2013||Quest Software, Inc.||Recovering a file system to any point-in-time in the past with guaranteed structure, content consistency and integrity|
|US8364648 *||Apr 9, 2008||Jan 29, 2013||Quest Software, Inc.||Recovering a database to any point-in-time in the past with guaranteed data consistency|
|US8365017||Jan 29, 2013||Quest Software, Inc.||Method and system for virtual on-demand recovery|
|US8375248||Feb 12, 2013||Quest Software, Inc.||Method and system for virtual on-demand recovery|
|US8392680||Mar 30, 2010||Mar 5, 2013||Emc International Company||Accessing a volume in a distributed environment|
|US8412946||Jul 29, 2011||Apr 2, 2013||Ricoh Co., Ltd.||Trustworthy timestamps and certifiable clocks using logs linked by cryptographic hashes|
|US8417905||Aug 25, 2011||Apr 9, 2013||Datacore Software Corporation||Methods and apparatus for point-in-time volumes|
|US8423825||May 25, 2011||Apr 16, 2013||Hitachi, Ltd.||Data restoring method and an apparatus using journal data and an identification information|
|US8429198||Jun 6, 2012||Apr 23, 2013||Quest Software, Inc.||Method of creating hierarchical indices for a distributed object system|
|US8433869||Sep 27, 2010||Apr 30, 2013||Emc International Company||Virtualized consistency group using an enhanced splitter|
|US8442943||Aug 18, 2008||May 14, 2013||Synchronoss Technologies, Inc.||Data transfer and synchronization between mobile systems using change log|
|US8464018||Apr 23, 2012||Jun 11, 2013||International Business Machines Corporation||Resource management for data storage services|
|US8478955||Sep 27, 2010||Jul 2, 2013||Emc International Company||Virtualized consistency group using more than one data protection appliance|
|US8479004||Aug 31, 2006||Jul 2, 2013||Ricoh Co., Ltd||Paper-based document logging|
|US8521695||Dec 28, 2011||Aug 27, 2013||Microsoft Corporation||Database data recovery system and method|
|US8521973||Sep 28, 2007||Aug 27, 2013||Symantec Operating Corporation||Systems and methods for providing a modification history for a location within a data store|
|US8544023||Oct 11, 2010||Sep 24, 2013||Dell Software Inc.||Management interface for a system that provides automated, real-time, continuous data protection|
|US8554733 *||Jun 15, 2005||Oct 8, 2013||Hitachi Ltd.||Disaster recovery method, disaster recovery system, remote copy method and storage system|
|US8611873||May 12, 2005||Dec 17, 2013||Synchronoss Technologies, Inc.||Advanced contact identification system|
|US8615566||Mar 23, 2001||Dec 24, 2013||Synchronoss Technologies, Inc.||Apparatus and method for operational support of remote network systems|
|US8620286||Sep 26, 2008||Dec 31, 2013||Synchronoss Technologies, Inc.||Method and system for promoting and transferring licensed content and applications|
|US8621025||Jan 14, 2011||Dec 31, 2013||Synchronoss Technologis, Inc.||Mobile data transfer and synchronization system|
|US8639974||Dec 20, 2012||Jan 28, 2014||Dell Software Inc.||Method and system for virtual on-demand recovery|
|US8645471||Jul 21, 2004||Feb 4, 2014||Synchronoss Technologies, Inc.||Device message management system|
|US8650167||Jun 1, 2012||Feb 11, 2014||Dell Software Inc.||Method and system for data reduction|
|US8671076 *||May 8, 2007||Mar 11, 2014||Bmc Software, Inc.||Database recovery using logs applied to consistent copies|
|US8694700||Sep 29, 2010||Apr 8, 2014||Emc Corporation||Using I/O track information for continuous push with splitter for storage device|
|US8712970 *||Jan 28, 2013||Apr 29, 2014||Dell Software Inc.||Recovering a database to any point-in-time in the past with guaranteed data consistency|
|US8732479 *||Mar 11, 2011||May 20, 2014||Carbonite, Inc.||Methods, apparatus and systems for remote file storage using local client status files|
|US8738575 *||Sep 17, 2007||May 27, 2014||International Business Machines Corporation||Data recovery in a hierarchical data storage system|
|US8762328||Nov 4, 2009||Jun 24, 2014||Intellectual Ventures Ii Llc||Flexible remote data mirroring|
|US8775386||Aug 18, 2010||Jul 8, 2014||International Business Machines Corporation||Device and method for generating copy of database|
|US8799232 *||Sep 12, 2012||Aug 5, 2014||International Business Machines Corporation||Method for generating copy of database|
|US8832399||Apr 1, 2013||Sep 9, 2014||Emc International Company||Virtualized consistency group using an enhanced splitter|
|US8839031||Apr 24, 2012||Sep 16, 2014||Microsoft Corporation||Data consistency between virtual machines|
|US8856083 *||Jun 9, 2006||Oct 7, 2014||Oracle International Corporation||Framework to optimize delete all row operations on database objects to improve throughput, query ability and flashback|
|US8856202||Aug 20, 2009||Oct 7, 2014||Intellectual Ventures Ii Llc||Flexible remote data mirroring|
|US8898112||Sep 7, 2011||Nov 25, 2014||Emc Corporation||Write signature command|
|US8903788||May 18, 2007||Dec 2, 2014||Ricoh Co., Ltd.||Synchronizing distributed work through document logs|
|US8930751||Apr 24, 2012||Jan 6, 2015||Microsoft Corporation||Initializing replication in a virtual machine|
|US8943428||Nov 1, 2010||Jan 27, 2015||Synchronoss Technologies, Inc.||System for and method of field mapping|
|US8972347||Dec 14, 2012||Mar 3, 2015||Dell Software Inc.||Recovering a file system to any point-in-time in the past with guaranteed structure, content consistency and integrity|
|US8996460||Mar 14, 2013||Mar 31, 2015||Emc Corporation||Accessing an image in a continuous data protection using deduplication-based storage|
|US8996483||Mar 28, 2007||Mar 31, 2015||Ricoh Co., Ltd.||Method and apparatus for recording associations with logs|
|US9026696||Jan 10, 2014||May 5, 2015||Emc Corporation||Using I/O track information for continuous push with splitter for storage device|
|US9069709||Jun 24, 2013||Jun 30, 2015||Emc International Company||Dynamic granularity in data replication|
|US9081842||Mar 15, 2013||Jul 14, 2015||Emc Corporation||Synchronous and asymmetric asynchronous active-active-active data access|
|US9087013||Mar 14, 2013||Jul 21, 2015||Datacore Software Corporation||Methods and apparatus for point-in-time volumes|
|US9087112||Jun 24, 2013||Jul 21, 2015||Emc International Company||Consistency across snapshot shipping and continuous replication|
|US9110914||Mar 14, 2013||Aug 18, 2015||Emc Corporation||Continuous data protection using deduplication-based storage|
|US9146878||Jun 25, 2013||Sep 29, 2015||Emc Corporation||Storage recovery from total cache loss using journal-based replication|
|US20010013102 *||Jan 3, 2001||Aug 9, 2001||Yoshihiro Tsuchiya||Backup system and method thereof in disk shared file system|
|US20020016827 *||Jun 2, 2001||Feb 7, 2002||Mccabe Ron||Flexible remote data mirroring|
|US20020133737 *||Mar 4, 2002||Sep 19, 2002||Sanpro Systems Inc.||System and a method for asynchronous replication for storage area networks|
|US20040193658 *||Aug 29, 2003||Sep 30, 2004||Nobuo Kawamura||Disaster recovery processing method and apparatus and storage unit for the same|
|US20040193945 *||Apr 30, 2003||Sep 30, 2004||Hitachi, Ltd.||Data restoring method and an apparatus using journal data and an identification information|
|US20040230623 *||May 14, 2003||Nov 18, 2004||International Business Machines Corporation||Log grooming in a multi-log environment|
|US20040267835 *||Apr 28, 2004||Dec 30, 2004||Microsoft Corporation||Database data recovery system and method|
|US20050027892 *||Aug 25, 2004||Feb 3, 2005||Miralink Corporation||Flexible remote data mirroring|
|US20050050012 *||Aug 28, 2003||Mar 3, 2005||Udo Klein||Directed graph for distribution of time-constrained data|
|US20050050064 *||Aug 28, 2003||Mar 3, 2005||Udo Klein||Synchronizing time-constrained data|
|US20050055445 *||Sep 10, 2003||Mar 10, 2005||International Business Machines Corporation||High availability data replication of an R-tree index|
|US20050071708 *||Sep 29, 2003||Mar 31, 2005||International Business Machines (Ibm) Corporation||Method, system, and program for recovery from a failure in an asynchronous data copying system|
|US20050076261 *||Feb 13, 2004||Apr 7, 2005||Revivio, Inc.||Method and system for obtaining data stored in a data store|
|US20050076262 *||Feb 13, 2004||Apr 7, 2005||Revivio, Inc.||Storage management device|
|US20050081077 *||Sep 29, 2003||Apr 14, 2005||International Business Machines Corporation||Method for peer-to-peer system recovery|
|US20050131853 *||Aug 9, 2004||Jun 16, 2005||Sybase, Inc.||Database System Providing Self-Tuned Parallel Database Recovery|
|US20050131966 *||Dec 15, 2003||Jun 16, 2005||Sbc Knowledge Ventures, L.P.||Architecture of database application with robust online recoverability|
|US20050131969 *||Jan 31, 2005||Jun 16, 2005||Fujitsu Limited||Database duplicating method, database duplicating apparatus, database creating method, and database creating apparatus|
|US20050198452 *||Mar 2, 2004||Sep 8, 2005||Naoki Watanabe||Method and apparatus of remote copy for multiple storage subsystems|
|US20050223164 *||Mar 30, 2004||Oct 6, 2005||Hitachi, Ltd.||Assuring genuineness of data stored on a storage device|
|US20050256897 *||Jun 18, 2004||Nov 17, 2005||Oracle International Corporation||Providing the timing of the last committed change to a row in a database table|
|US20050262097 *||May 6, 2005||Nov 24, 2005||Sim-Tang Siew Y||System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services|
|US20050278392 *||Aug 12, 2005||Dec 15, 2005||Microsoft Corporatioan||System and method for synchronizing multiple database files|
|US20060005080 *||Jul 2, 2004||Jan 5, 2006||Seagate Technology Llc||Event logging and analysis in a software system|
|US20060010095 *||Jul 9, 2004||Jan 12, 2006||Wolff Gregory J||Synchronizing distributed work through document logs|
|US20060010180 *||Sep 16, 2005||Jan 12, 2006||Nobuo Kawamura||Disaster recovery processing method and apparatus and storage unit for the same|
|US20060064416 *||Sep 17, 2004||Mar 23, 2006||Sim-Tang Siew Y||Method and system for data reduction|
|US20060101384 *||Nov 1, 2005||May 11, 2006||Sim-Tang Siew Y||Management interface for a system that provides automated, real-time, continuous data protection|
|US20060117157 *||Jan 5, 2006||Jun 1, 2006||Hitachi, Ltd.||Assuring genuineness of data stored on a storage device|
|US20060129770 *||Dec 10, 2004||Jun 15, 2006||Martin Howard N||Resource management for data storage services|
|US20060168479 *||Jan 25, 2005||Jul 27, 2006||Seagate Technology Llc||Real time event logging and analysis in a software system|
|US20060179347 *||Jan 3, 2006||Aug 10, 2006||Anderson Richard J Jr||Reliable standby database failover|
|US20060218204 *||Mar 25, 2005||Sep 28, 2006||International Business Machines Corporation||Log stream validation in log shipping data replication systems|
|US20060224639 *||May 19, 2005||Oct 5, 2006||Satoru Watanabe||Backup system, program and backup method|
|US20060242370 *||Jun 15, 2005||Oct 26, 2006||Yoshio Suzuki||Disaster recovery method, disaster recovery system, remote copy method and storage system|
|US20060242452 *||Jun 8, 2006||Oct 26, 2006||Keiichi Kaiya||External storage and data recovery method for external storage as well as program|
|US20060259811 *||Jul 17, 2006||Nov 16, 2006||Topio, Inc.||System and a method for asynchronous replication for storage area networks|
|US20060265434 *||May 6, 2005||Nov 23, 2006||Microsoft Corporation||Authoritative and non-authoritative restore|
|US20070016626 *||Jul 12, 2005||Jan 18, 2007||International Business Machines Corporation||Ranging scalable time stamp data synchronization|
|US20070083724 *||Dec 5, 2006||Apr 12, 2007||Hitachi, Ltd.||Assuring genuineness of data stored on a storage device|
|US20070288529 *||Jun 9, 2006||Dec 13, 2007||Oracle International Corporation||Framework to optimize delete all rows operations on database objects|
|US20110161289 *||Jun 30, 2011||Verisign, Inc.||Data Replication Across Enterprise Boundaries|
|US20130006941 *||Sep 12, 2012||Jan 3, 2013||International Business Machines Corporation||Device and method for generating copy of database|
|CN1784676B||Jul 27, 2004||May 30, 2012||微软公司||Database data recovery system and method|
|CN101034339B||Mar 6, 2007||Nov 3, 2010||惠普开发有限公司||Hierarchical timestamps|
|EP1562117A2||Feb 12, 2004||Aug 10, 2005||Hitachi, Ltd.||Data restoration method using a log and corresponding storage subsystem|
|EP1562117A3 *||Feb 12, 2004||Aug 3, 2011||Hitachi, Ltd.||Data restoration method using a log and corresponding storage subsystem|
|WO2001097030A1 *||Jun 2, 2001||Dec 20, 2001||Miralink Corp||Flexible remote data mirroring|
|WO2005086032A1 *||Jul 27, 2004||Sep 15, 2005||Peter Byrne||Database data recovery system and method|
|U.S. Classification||707/610, 714/20, 714/12, 709/201, 714/E11.13, 718/101, 707/999.202, 707/954, 707/758, 707/956, 707/682, 707/999.201|
|Cooperative Classification||G06F11/1402, Y10S707/99952, Y10S707/956, Y10S707/99953, Y10S707/954|
|Aug 12, 1998||AS||Assignment|
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BEIER, HARLEY AL;KERN, ROBERT FREDERIC;MOORE, DAVID WAYNE;AND OTHERS;REEL/FRAME:009379/0772;SIGNING DATES FROM 19980313 TO 19980317
|Sep 25, 2003||FPAY||Fee payment|
Year of fee payment: 4
|Dec 3, 2003||REMI||Maintenance fee reminder mailed|
|Sep 19, 2007||FPAY||Fee payment|
Year of fee payment: 8
|Oct 26, 2011||FPAY||Fee payment|
Year of fee payment: 12
|Sep 3, 2015||AS||Assignment|
Owner name: GLOBALFOUNDRIES U.S. 2 LLC, NEW YORK
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:036550/0001
Effective date: 20150629