International Business Machines Corporation

Austin F M D'Costa

Serge Bourbonnais

Jonathan W Wierenga

Xiao Li

Yat On Lau

Christian Zentgraf

Hong Min

Gong Su

You-Chin Gene Fuh

James Z Teng

Kan Zhang

Tyrone Yu

Xin Wu

Somil Kulkarni

James J Seeger

David Macnaughton Wolfe

Xiang Wei Zhou

David D Zimmerman

Transaction consistency query support is available for replicated data from recovery log to external data stores. An external data store is populated with records using entries of a change data table. The change data table has entries for each transaction that has committed and is to be replicated, and each of the entries stores information for each log entry in a recovery log from a database management system. Each log entry identifies a transactional change of data and a transaction completion indicator of one of commit and abort. In response to receiving a query about a transaction of the transactions, a set of records are retrieved from the external data store for the transaction. From the set of records, records whose sequence identifier values are larger than a maximum transaction commit sequence identifier are removed. From the set of records, remaining records having transaction consistency are returned.

Transaction consistency query support for replicated data from recovery log to external data stores

Several replication subscriptions are defined for a table in a database management system. The table is divided into partitions. Each replication subscription replicates transactions to a range of partitions. Subscriptions are assignable to different consistency groups. Transaction consistency is preserved at the consistency group level. A persistent delay table is created for each of several apply functions. Each apply function processes replication subscriptions for one consistency group, to replicate the table to a target table in parallel. Transactions for a given range of a partition are executed in parallel. When an apply function upon a row of the target table results in an error, the row is stored in the delay table. Application of each row in the delay table is repeatedly retried, and if successful, the row is removed from the delay table.

Parallel replication of data table partition

A data replication method can begin with the detection of an inconsistency between records of a target table and corresponding records of a source table of a relational database management system (RDBMS) performing a parallel apply replication by an improved data replication manager. The target table can be a copy of the source table, both of which include multiple unique constraints and indexes. A timeframe that encompasses the records of the target table having the inconsistency can be determined. The timeframe can utilize a commit timestamp or a log sequence number. Consistency between the target table and the source table can be automatically restored for the determined timeframe through use of a reactive-apply process. Data suppression for updates is automatically restored once the copy is consistent. Transactions performed upon the target table by the reactive-apply process can be performed in parallel. Service at the source table and the target table can be uninterrupted.

Automatically restoring data replication consistency without service interruption during parallel apply

Provided are techniques for replicating relational transactional log data to a big data platform. Change records contained in change data tables are fetched. A relational change history with transaction snapshot consistency is rebuilt to generate consistent change records by joining the change data tables and a unit of work table based on a commit sequence identifier. The consistent change records are stored on the big data platform, and queries are answered on the big data platform using the consistent change records.

Recovery log analytics with a big data management platform

Techniques for restoring point-in-time and transaction consistency across consistency groups between a first and a second independent database management system (DBMS) for a disaster recovery. Several consistency groups (CGs) are defined for replication. For each CG in the first DBMS data changes are transmitted to a second DBMS. A timestamp representing a most recently received commit log record or a heartbeat during periods of inactivity for a CG is stored in a database table at regular intervals. At regular intervals, the timestamp is compared with timestamps for other CGs to identify a common time at which data to be applied to the CGs in the second DBMS have been received into a recoverable data store. The received data is applied to the CGs in the second DBMS up to the common time.

Restoring database consistency integrity

According to one embodiment of the present invention, a system uses parallel transaction messages for database replication. The system receives transaction messages from a source system via a plurality of parallel send queues in a receive queue. Each transaction message includes a message identifier indicating a commit order for that transaction. The system reads transaction messages in the receive queue in order in which they were committed against a source database based on the message identifier, and applies changes described by the transaction messages to a target database. Two or more transaction messages in the receive queue are applied to the target database in parallel. The system deletes transaction messages from the receive queue asynchronously to applying changes described by those transaction messages to the target database. Embodiments of the present invention further include a method and computer program product for parallel transaction messages in substantially the same manners described above.

Parallel transaction messages for database replication

A process for quiescing a master and a plurality of subordinate computer systems in a cluster. An original or a pending state may be entered that is a quiesce or an online state. The master instructs the subordinates the quiesce or online state be made the pending state. The subordinates prepare to change accordingly, determine whether successful, and vote to commit or abort. Based on whether all voted to commit, the master instructs the subordinates to either commit or abort. If to commit and the pending state is the quiesce state, an operation is performed in the subordinates. If to commit and the pending state is the online state, the subordinates prepare to resume the original state. The subordinates change from the original to the pending state. Otherwise, if to abort, the subordinates prepare to remain in the original state and reset the pending to the original state.

Growing community of inventors

Beaverton, OR, United States of America

Austin F M D'Costa