Database object replication details

Behavior of Database I/O with Db2 Mirror

When the content of a replicated database file changes, regardless of the interface used, the data changes are synchronously replicated to the target node. When the replication state is ACTIVE, data changes can be initiated from either the primary or secondary node. On the secondary node when the replication state is BLOCKED, any attempt to change replicated objects will fail.

When journaling is being used, the data journal entries may not be identical across the two nodes. When replicated data changes are managed by Db2® Mirror, the implementation of replicating the data may use different operations on each node to reach the same conclusion. Regardless of the operations used, the active rows are identical and reside at identical relative record numbers (RRNs).

When replication is suspended for any reason, data changes can continue to be made on the primary node, and those changes are tracked within the file object at the row level. When replication is resumed, Db2 Mirror resynchronization processing locks tracked objects and rows, and proceeds to synchronize the data changes to the secondary node. When resynchronization completes, the files are once again in sync.

When replication is suspended, the behavior of interrupted transactions is well defined when commitment control is being used. Under commitment control, the transaction on the primary node will continue without any noticeable change to the application or user. However, on the secondary node, a transaction interrupted by suspending replication results in the transaction being rolled back. If the user or application is not using commitment control (COMMIT *NONE), changes to the database are made without the possibility of rollback. This means that when commitment control is not being used, data changes are not guaranteed to reach some predictable point when replication is suspended. All the changes made up to the time when the suspend happened will exist on both nodes.

The database management of replication includes efficiencies for data movement. This optimization of replication could result in a difference in how many deleted records reside at the end of the file. A difference in the number of deleted records at the end of the file is normal and not indicative of being out of sync.

Using sequence objects

Sequences include an optional CACHE value, which improves the performance of the NEXT VALUE sequence expression by pre-allocating values in memory. With Db2 Mirror, the synchronous replication of a sequence occurs when the cached values are exhausted and the corresponding *DTAARA object is updated to reflect the allocation of a new set of cached values.

Commitment control consideration

When the RENAME SQL statement, Rename Object (RNMOBJ) CL command, or ALTER TABLE SQL statement are used so that the target object's replication state changes from exclude to include, the entire operation must use COMMIT(*NONE).

Any DDL replication operation that uses COMMIT(*NONE) is required to be initiated on a commit boundary. If not on a commit boundary, the operation will fail with SQL7061.