To define a replication source using the DB2 Control Center, click the Tables folder for the source database to show all tables. Right-click on a table object to show the pop-up menu and select Define as replication source.
You can define replication sources using the Quick or Custom choices. Quick allows you to define a replication source using default values. Custom allows you to customize the defaults, such as specifying that certain columns should not be captured.
After you define the replication source, an object is created in the Replication Sources folder. The source table can now be defined in a subscription set.
To define a replication source using DJRA, click Define One Table as a Replication Source or Define Multiple Tables as Replication Sources, then fill in the required information, such as source server, source table names, and source columns.
For data restrictions when defining replication sources and subscriptions, see Data restrictions.
The Capture program does not recognize new DB2 replication sources until you issue either the reinit command or stop and restart the Capture program. The Capture program does not begin capturing changes for a replication source until a subscription is created for that replication source and the subscription set members have been fully refreshed.
To define a replication source for update-anywhere replication using the DB2 Control Center, define a custom replication source and use the following selections:
When you select this check box, the DB2 Control Center also selects the Define as Source and Capture before image check boxes for every column.
Attention: Conflicting updates between the source table and the replica will not be detected. This option is not recommended for update-anywhere replication.
Even if you specify enhanced conflict detection, when the Apply program runs in a mobile environment (started with the asncopy or asnsat command, or with the COPYONCE keyword), the Apply program uses standard conflict detection.
To define a replication source for update-anywhere replication using DJRA, select the conflict detection level (described above) when you define a table as a replication source, and select the replica target structure when you add the member to the subscription set.
To reduce the risks of conflicts and costs of rejected conflicting transactions, use update-anywhere replication under the following conditions:
For update-anywhere replication, update conflicts can occur when:
The Apply program detects update conflicts, after they occur, during the subscription cycle. The source table is considered the primary table. That is, it can receive updates from replica tables, but if there is a conflict, the source table wins and the replica tables' conflicting transactions are rejected. The Apply program detects direct row conflicts by comparing the key values in the CD tables with the source and target tables. If it finds any that match, it marks the replica transaction as rejected in the UOW table and rolls back the replica transaction.
The Apply program cannot detect read dependencies. If, for example, an application reads information that is subsequently removed (by a DELETE statement or by a rolled back transaction), the Apply program cannot detect the dependency.
DB2 DataPropagator provides three levels of conflict detection: no detection, standard detection, and enhanced detection. Each level has a numerical value which is stored in the CONFLICT_LEVEL column of the register control table. You must decide, based on your tolerance for lost or rejected transactions and performance requirements, which type of detection to use. See Defining replication sources for update-anywhere replication for more information about the levels of conflict detection and how to specify them.
Use the rejection codes provided in the UOW table to identify the before and after row values in the CD table for each rejected transaction. Because the ASNDONE exit routine runs at the end of each subscription cycle, you can add code to the routine to handle any rejected transactions. See Using the ASNDONE exit routine for more information on the ASNDONE exit routine. Alternatively, because the change data rows and UOW control table rows for rejected transactions are exempt from normal pruning (they are, however, subject to RETENTION_LIMIT pruning), you could handle the rejected transactions as a batch by using a program that scans the UOW table.
You can define replication sources that are views of other tables. After defining each replication source table included in the view, you can create a view replication source. The view replication source is then available for replication to a target table.
You cannot use the DB2 Control Center to define an existing view as a replication source; use DJRA instead.
To define a join using the DB2 Control Center:
USERID.VIEW_NAME AS SELECT A.COL1, A.COL2, B.COL6, B.COL5
Do not type the words CREATE VIEW. This part of the statement is automatically supplied during processing.
TABLEA A, TABLEB B
Do not type the word FROM. This part of the statement is automatically supplied during processing.
A.COL1=B.COL1
Do not type word WHERE. This part of the statement is automatically supplied during processing.
To define a view as a replication source using DJRA, click Define DB2 Views as Replication Sources and fill in the required information, such as source server, source view qualifier, and source view name.
By default, the Capture program captures an update to the source table as an UPDATE statement. However, for the following conditions, you must instruct the Capture program to capture updates as DELETE and INSERT statements (that is, you must enable logical-partitioning-key support):
Because the values for the target-table primary key come from the changes captured on the source server, which reflect the new key values, these values cannot be used to find the existing target table row (it doesn't exist yet). Converting the UPDATE to a DELETE and INSERT pair ensures that the target table reflects the changes made at the source server.
In this case, the column included in the predicate need not be a primary-key column. If a subscription is defined with a predicate based on a specific column value (for example, WHERE DEPT = 'J35'), and you change that column (for example, to DEPT='FFK'), the captured change will not be selected for replication because it does not meet the predicate criteria. That is, your new FFK department will not be replicated because your subscription is based on department J35. Converting the UPDATE to a DELETE and INSERT pair ensures that the target-table row is deleted.
Enabling logical-partitioning-key support ensures that target rows are moved from one node to another when the source column for the logical-partitioning key is changed and replicated. The move is accomplished by a DELETE at the old node and an INSERT at the new node.
By default, when you update the primary keys of either the source or target tables, the Capture program captures the changed row for the update. The Apply program then attempts to update the row in the target table with the new key value. This new key value is not found in the target table, so the Apply program converts this update to an insert. In this case, the old row with the old key value remains in the table (and is unnecessary). When you enable replication logical-partitioning-key support, the Capture program captures the change as separate DELETE and INSERT statements: delete the old row and insert the new row.
Each captured UPDATE is converted to two rows in the CD table for all columns, non-key columns as well as key columns. You might need to adjust the space allocation for the CD table to accommodate this increase in captured data.
When you use the DB2 Control Center to define the source table, select the Changed data for partitioned key columns captured as delete and insert check box on the Define as Replication Source window to specify that the Capture program should capture updates as DELETE and INSERT statements.
When you use DJRA to define the source table, select the Updates as delete/insert pairs radio button from either the Define One Table as a Replication Source window or the Define Multiple Tables as Replication Sources window.