SQLREP Capture and Apply

#1. SQLREP Capture Program problem

There is no way to replay a single registration from DB2 log. Currently it is all or nothing when it comes to starting Capture from a synch point. This is a problem because customers want to have the ability for other registrations not in error to continue processing and the ability to resume the failed registration from a db2 log point to prevent data loss and / or potential full refresh which may not be feasible when the source table has billions of rows. The InfoSphere Data Replication SQLREP is missing this capability that is so needed by customers.

Proposed solution enhancement request for Capture program

a) ability to start, stop, suspend, resume and reinitialize Capture at the source table registration.

b) ability to restart single capture source table registration from DB2 log point. Meaning each source registration should be independent and from a capture perspective have the ability to be restarted froma giving point without affecting others registrations defined in the same Capture starter task.

#2. SQLREP APPLY Program Problem

Currently, when the apply task encounters an error, it stops with the subscription set in error thus preventing other subscriptions which are NOT in error from advancing/moving forward. This causes delay in replication for those subscription sets not in error. Today , this can be bypassed manually by deativating the set in error, then apply picks up and move forward the other subscriptions sets defined in the same apply task. This requires human intervention leading to delay in processing.

Proposed solution enhancement request for APPLY Program

a) ability for the APPLY program to continue processing those subscription sets not in error.

b) abiltiy for the APPLY to continue retrying activate subscription in error and only to stop trying if the set is stopped/deactiviated.