|
Refresh Execution |
Scroll |
Instruct the Capture to refresh the target with data from the table(s) using the new sqdconf refresh command, specifying the size of the refresh slice with optional key ranges. Using using JCL similar to sample member SQDCONDC included in the distribution, request the Dynamic Refresh (this is not presently a supported function of the ISPF panels):
Syntax
//*-------------------------------------------
//* Request a Refresh from a Db2 source table
//*-------------------------------------------
//REFRESH EXEC PGM=SQDCONF
//SYSOUT DD SYSOUT=*
//SQDPARMS DD *
refresh /home/sqdata/db2cdc1/DB2CDC1.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]
/*
Keyword and Parameter Descriptions
--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 ] - 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.
Example 1
Refresh table SQDATA.EMP using 10,000 row slices to all replication engines defined in the Capture CAB file DB2CDC1.cab, after first preparing the Capture to accommodate Dynamic Refresh requests using a second Transient Storage area, using JCL similar to this:
//*----------------------------------------------
//* Request Refresh of a target Db2 Table
//*----------------------------------------------
//REFRESH EXEC PGM=SQDCONF
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SQDPARMS DD *
refresh --key=SQDATA.EMP --block-size=10000
