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 where the Target of the captured data will reside.
Example:
Our example starts with the addition of a new Table to an existing Oracle Database that will be a new source for an existing Engine.
Solution:
In order to capture the changes for Oracle tables the table must be altered to allow for change data capture. This action is performed using the ALTER TABLE statement as follows:
$ oracle connect to <database_name>
SQL> ALTERTABLE <schema.tablename> ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
Next, the Capture configuration must be updated to include the new table. The SQDCONF utility will be used to add a table to the capture that will be sent to the existing target Engine.
sqdconf add /<SQDATA_VAR_DIR>/oracdc1/oracdc1.cab --table=<new_table_name> --datastore=cdc:////ORATOORA --active
Finally, determine how the new data will affect the existing Engine and modify the Engine script accordingly. See the Engine Reference for all the options available through Engine Script commands and functions.
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 Support to discuss both the benefits and techniques for implementing and perhaps more importantly maintaining, a load/refresh Engine solution.