#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.
|Who would benefit from this IDEA?||All customers using SQLREP will benefit|
How should it work?
For Capture, it should work as follow:
1) if Capture program encounters a -551 error and let say it happened at 5pm for source table TASNIVP registration, Capture will stop only capturing for that one source table and once the grant is issued, Capture will replay back for that source table to reprocess all rows from the 5pm time forward. This prevents data loss from a replication perspective. The source table had the data originally processed and rejected by the capture because of the -551 error.
For APPLY, it should work as follow:
When the apply encounters an error, the apply should continue processing for those subscription sets not in error which are defined/shared the same apply task. The apply program continues trying to reprocess failed subscriptions until the set is deactivated.
|Priority Justification||Production outages|
|Customer Name||Morgan Stanley|
NOTICE TO EU RESIDENTS: per EU Data Protection Policy, if you wish to remove your personal information from the IBM ideas portal, please login to the ideas portal using your previously registered information then change your email to "email@example.com" and first name to "anonymous" and last name to "anonymous". This will ensure that IBM will not send any emails to you about all idea submissions