Change Replication Source -- Fields and controls

Data capture is full-refresh only

Available columns

Define as source

Capture before image

Changed data for partitioned key columns captured as delete and insert

Table will be used for update anywhere

Conflict detection

OK

Cancel

Data capture is full-refresh only

Select this check box to specify that the source table will be used for full-refresh copying to the target table. The Capture program does not log changes for this table and update copying is not available.

Select this check box when you want all rows of the source table replicated to the target table. Use full-refresh copying when:

• You do not want to use the Capture program in your scenario.
• Your table is small and has many, frequent updates.
• You want the data to be completely up-to-date.

Do not use full refresh copying when:

• You have a large table with few or a moderate number of updates.
• You do not want all the rows of the source table copied to the target table, regardless of the number of changes, every time the table is replicated.
• You are using Capture to capture and replicate only changed data to the target table.

Available columns

This field displays column names from the source table.

Define as source

Use this check box to specify columns for replication. This field is selected by default. Ensure all columns are selected if the table might be used for update-anywhere replication.

Capture before image

Use this check box to determine whether the before image of a selected source column will be captured, in addition to the after-image. The before image provides an image of the column prior to being updated, useful for recovery.

When selected, a column is replicated to the target table containing the values of the source table column before the values were updated. By default, the name of the before-image column begins with the prefix character, X. For example:

XNAME

This character must be unique. If any column in the target table already begins with X, a different, unique prefix character is used. If there are no unique characters, before-image columns cannot be selected.

Changed data for partitioned key columns captured as delete and insert

Select this check box to specify that any update to primary key columns is captured as a DELETE and INSERT in the change data table rather than as an UPDATE.

Select this check box under any of the following circumstances:

• If your source applications update one or more columns that are part of a target table primary key
• If your source applications update one or more columns of a target table partitioning key (either the target table is a partitioned database managed by DB2 Enterprise - Extended Edition or DB2 for AS/400, or the target table is a table in a DB2 for OS/390 partitioned table space)
• If your source applications update one or more columns referenced in a subscription predicate of a target table

The Capture program treats updates to primary key columns as INSERT and DELETE statements, rather than UPDATE statements.

Table will be used for update anywhere

Select this check box to specify that this source table can be used in update-anywhere replication. When selected, this table can have changes replicated to an updateable replica target table. The replica table can, in turn, be updated and its changes are replicated to the replication source table.

Conflict detection

Select one of the following radio buttons to determine the conflict detection level for user tables and all associated replicas:

None

If you do not want to monitor conflict detection.

Conflicting updates between the origin table and the replica will not be detected. This option is not recommended for update-anywhere replication.

Standard

If you want moderate conflict detection monitoring in which the Apply program searches rows already captured in the replica's change data tables for conflicts. This is the default.

Enhanced

For conflict detection monitoring that guarantees data integrity among all replicas and the origin table. Apply locks all replicas in the subscription set against further transactions, and begins detection after all changes prior to locking are captured.

Conflict detection does not guarantee data integrity for read dependencies. For example, an application reads the replica's updated row before it is replicated back to the source table. If the transaction for the update is later rejected as a conflict, conflict detection cannot detect this conflict.