DB2 Replication Guide and Reference

Data Consistency Requirements

IBM Replication always guarantees table consistency, that is, all data in the target table is actually committed in the base table. IBM Replication also provides consistency across sets of tables with the replication subscription, which can have multiple, related members. These members are the source and target pairs; and the members are usually bound by transaction relationships.

Because the replication members have something in common, the changed data needs to be copied in the same unit of work. Each replication subscription has a name and is identified by a row in the subscription set control table. A replication subscription with replica tables has two rows, one for each direction of copying (from source to replica and replica to source).

Figure 11 shows the relationship of the replication subscription with the Apply program.

Figure 11. Replication Subscriptions and the Apply Program

The Apply program reads changes from the replication source or CD table and creates one spill file created for each table. The Apply program replicates the changes to the target tables.

The replication subscription helps maintain referential constraints that exist among a set of replication source and replica tables. The replication subscription also limits the boundary for cascade rejection due to RI violation or update collision. Finally, replication subscriptions keep the source-to-target definitions for all the components of a view target table together. The replication subscription should contain all target tables that are related, such as with RI constraints.

Replication Subscription Rules

The following section describes the rules and constraints you need to be aware of in planning and defining a replication subscription.

• If any member of the replication subscription requires full-refresh copying for any reason, the entire set is full refreshed. Full-refresh copying occurs only from the replication source to the replica, not the other way around.

• Each replica target table must be of the same generation as all the other replicas in the replication subscription and come from the same replication source table.

• A single synchpoint is maintained for the replication subscription to indicate the copy progress for the entire replication subscription.

• Collision detection levels must be specified while defining a replication source and affects the processing performed on a replica table in the replication subscription.

• Target tables with RI constraints must be full-refreshed by an outside means using the ASNLOAD exit to bypass RI checking.

• RI violations cannot be detected by application logic in an update-anywhere environment. Declarative RI constraints must be used.

• Referential constraints should not be defined for read-only target tables.

• All referential constraints that exist among the source tables should be included in the replication subscription replicas to prevent RI violations.

• The first occurrence of any RI violation terminates the current replication cycle. The subscription cycle will be retried automatically, after the transaction is rejected and compensated.

• All sources referenced by a given subscription set that are external CCDs must come from a single, original source.

• Each SOURCE_TABLE reference, whether a direct table reference or an indirect reference using a view, must be of the same generation as all other SOURCE_TABLE references in the set.

Rules for external programs that maintain CCD tables

If you want to maintain your own CCD table, you must update three columns: CCD_OLD_SYNCHPOINT, SYNCHPOINT, and SYNCHTIME. CCD_OLD_SYNCHPOINT is the SYNCHPOINT associated with the oldest row remaining in the CCD_TABLE, though this sequence number might be older if the CCD table is condensed and the oldest row was overwritten by a more recent update. SYNCHPOINT is a sequence value useful for maintaining the state of CCD copies, subscription states, and for controlling pruning. SYNCHTIME is the timestamp equivalent of SYNCHPOINT.

If the CCDs are maintained by a program external to IBM Replication, there is no source server or target server distinction (because the context is just one database).

• Before a full refresh of the CCD, set CCD_OLD_SYNCHPOINT in the register table to NULL.

• After a full refresh of the CCD, set the CCD_OLD_SYNCHPOINT to a value greater than the previous value of SYNCHPOINT. If SYNCHPOINT has no previous value (because this is the initial load), set the CCD_OLD_SYNCHPOINT to x'00000000000000000000'

• Set the SYNCHPOINT in the register table with MAX(IBMSNAP_COMMITSEQ) in the CCD whenever committing new changes to the CCD. (SYNCHTIME should also be set accordingly, since it is the timestamp equivalent of SYNCHPOINT.)

[ DB2 List of Books | Search the DB2 Books ]