Capture new Db2/z data - connect_cdc_sqdata - Latest

Whether initiating Change Data Capture for the first time, expanding the original selection of data or including a new source of data from the implementation of a new application, the steps are very similar. The impact on new or existing Capture and Apply processes can be determined once the source of the data is known, precisely what data is required from the Source, whether business rules require filters or data transformations and finally where the Target of the captured data will reside.

While this example assumes that an existing Capture and Apply configuration is being modified it also applies to an entirely new implementation.

Example

SQDATA.dept table has been added to an existing Db2 Database that will be a new Source for an existing Engine that will apply the captured changed data to a new Target table.

ALTER TABLE SQDATA.dept DATA CAPTURE CHANGES;

//*----------------------------------------
//*- ADD TABLES TO CONFIG FILE
//*----------------------------------------
//ADDTBL EXEC PGM=SQDCONF
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SQDPARMS DD *
 add /home/sqdata/db2cdc/db2cdc.cab 
--key=dept --datastore=cdc:////DB2TODB2
--active 
//*

Finally, determine how the new data will affect the the existing Engine and modify the Engine script accordingly. See the Engine Reference for all the options available through Engine Script commands and functions.

Note:

Whenever a new source is to be captured for the first time, consideration must be given to the existing state of the source datastore when capture is first initiated. The most common situation is that the source already contains data that would have qualified to be captured and applied to the target, if the CDC and Apply process had already been in place.

Depending on the type of source and target datastore the following solutions that can insure source and target are in sync when Change Data Capture is implemented:

• While utilities may be available to unload the source datastore and load the target datastore, they will generally be restricted to both the same type (RDBMS, IMS, etc) of source and target datastore.
• Those utilities generally also require the source and target datastores to have identical structure (columns, fields, etc). Precisely recommends the use of utility programs if those two constraints are acceptable.
• If however, the source and target are not identical, Precisely recommends that a special version of the already tested Engine script be used for the initial load of the target datastore. This approach has the additional benefit of providing a mechanism for "refreshing" target datastores if for some reason an "out of synchronization" situation occurs because of an operational problem or a business rule change affecting filters or transformations. Contact Precisely support to discuss both the benefits and techniques for implementing and perhaps more importantly maintaining, a load/refresh Engine solution.