Defining Incremental Replication Subscriptions

A subscription defines the data that is to be replicated from a particular source object to a particular destination. A snapshot subscription provides full refresh replication, which copies all the source data that you specify for replication, regardless of when that data was last replicated. This provides a "snapshot" of the specified source data at the time of replication.

For sources that are enabled with SQDR Plus you can create subscriptions that perform incremental updates to the destination data. Incremental subscriptions perform a baseline replication against which changes are tracked, and update the destination data as required to keep it synchronized with the source data. Incremental subscriptions have the following requirements and limitations relative to snapshot subscriptions:

• Each incremental subscription must be a member of a group, and all members of the group must use the same source and destination.

• No two incremental subscriptions can replicate to the same target table.

• Foreign constraints are not replicated for incremental operations; however, unique constraints and indexes can be optionally replicated. You also can use a Relative Record Number (RRN) or ROWID column to help ensure there is a unique field to identify change data.

• You can incrementally replicate a subset of the source columns to a destination, but the subset must include at least one of the fields associated with a unique index to identify the change data. The unique index can be the Relative Record Number (RRN) or ROWID column.

• If you are replicating from a Db2 for Linux, Windows, and UNIX (Db2 for LUW) source and the source does not have unique indexes defined, only change data from insert operations can be applied to the destination. A new baseline replication must be performed if delete or update operations are committed to the source table.

• If you are replicating from SQL Server, the source table must have a primary key defined.

• The maximum row length of tables that can be replicated incrementally is slightly less than the maximum allowed by Db2 for LUW to accommodate the mechanisms that track the change data. SQDR Plus needs a minimum of five columns (more if there are unique indexes) for managing the incremental change data in the staging table, therefore the database table cannot contain the maximum number of columns or the maximum bytes per row that are allowed by Db2 for LUW. LOB data is replicated directly from the source instead of being stored in the change data (staging) tables.