The Db2/z (V4.1+ ONLY at this time) Relational Capture provides the ability to refresh the target from a source table during replication. This allows for loading/refreshing from small to medium sized tables within the replication flow vs having to perform an utility unload/load. Larger tables may still require a utility unload/load.
Syntax
//*-------------------------------------------
//* Request a Refresh from a Db2 source table
//*-------------------------------------------
//REFRESH EXEC PGM=SQDCONF
//SYSOUT DD SYSOUT=*
//SQDPARMS DD *
refresh /home/sqdata/db2cdc/db2cdc.cab
--schema=<name> --table=<name> | --key=<name>
--block-size=<number_of_rows>
[--from=<(key_value1, key_valuex)> | --from-included=<(key_value1, key_valuex)>]
[--to=<(key_value1, key_valuex)> | --to-included=<(key_value1, key_valuex)>]
[with-cs]
[--cancel]
/*
Keyword and Parameter Descriptions
| Keyword | Description |
|---|---|
| <cab_file_name> | Must be specified and must match the name specified in the previous create command. |
| --schema=<name> | Schema name, owner, or qualifier of a table. Different databases use different semantics, but a table is usually uniquely identified as S.T where S is referenced here as schema. This parameter cannot be specified with --key. |
| --table=<name> | A qualified table name in the form of schema.name that identifies the source. This may be used in place of two parameters, --schema and --table. Both cannot be specified. |
| --key=<name> | Same as --table. |
| --block-size=<number_of_rows> | The number of rows to extract at a time (refresh slice size). |
| [--from=<(key_value1, key_valuex)> | --from-included=<(key_value1, key_valuex)>] | Optional starting point of refresh; --from starts on row after keys are matched | --from-included starts from row with matching keys. |
| [--to=<(key_value1, key_valuex)> | --to-included=<(key_value1, key_valuex)>] | Optional ending point of refresh; --to ends on row before keys are matched | --to-included ends with row that matches keys. |
| [with-cs | with-ur | with-rr | with-rs] | CS is the default when this optional parm is not specified. There are four Db2/z locking isolation levels that provide control over the number and duration of read (share) locks in a unit-of-work. The objective of the Dynamic Refresh is to eliminate any need to consider locking implication by sizing slices based on the other parameters above. The default, CS minimizes locking while ensuring that uncommitted data is not read. Precisely recommends using caution and consulting with Precisely Support, your DBA's and Source Application SME's before inquiring about other options. UR for example does less locking but allows reading uncommitted data which can clearly cause issues. Advanced users may determine these optional parameter values assist in fine tuning their refresh while maintaining data integrity. |
| [--cancel] | Cancel the refresh before it has completed however one must consider that all published slices will have already been processed downstream. |
Note:
- Before a table can refreshed durring replication, the refresh control table (SQDATA.REFRESH_REQUEST_LOG) must be created on the source system. Job CRDREFR in the Connect CDC SQData CNTL library can be used to create this control table.
- The refresh event is tracked in the refresh control table and you can browse this table to see scheduled table refresh activity.
- The capture must be running in order to perform a refresh.