Question

The capture job seems to get suspended by online refresh job. Will I lose transactions?

Environment

Local Data Processing

Resolution

No. Running a refresh shouldn't make any data loss if you choose the correct online refresh strategy.

There are 3 options to choose from:

1. Skip the previous capture and integration

This instructs the capture job to skip all the changes from before the refresh and it instructs the integrate job to skip all the changes from before the refresh and to use resilient integration for changes that happened during the refresh. We need to be resilient to these changes because we can not be sure whether these changes are already picked up by the refresh. Resilience means transforming an insert into an update if the row already exists, transforming an update into an insert if the row does not exist and lost-deletes are ignored. This can be used only if there is 1 source and 1 target location in the channel and all data for the selected tables is refreshed.

2. Only skip the previous integration

This means that the changes are only skipped on the integrate side; in this case, also the integrate job is resilient for changes that happened during the refresh. This should be used when refreshing all data for selected tables from 1 source into multiple targets

3. Only resilience

This means that the integrate job will be resilient for the changes during the refresh but no changes will be skipped. This option should be used when only part of the data for selected tables is refreshed; e.g. using a Restrict /RefreshCondition

So in a nuthshell: "only resilience" is the safest choice if you don't know which option you should choose. If you have a one-to-one replication (and you don't use a /Restrict action on your refresh to filter the dataset) you can choose the 1st option and if you have a one-to-many replication (without /Restriction on the refresh) you can go with the 2nd option to save some time by skipping the previous cycle (transactions in the previous cycle will be transferred to the target side anyway with the refresh). If you run your refresh with /Restrict you should always choose the 3rd option.

Note: The Capture job has to be created before a refresh but it's not necessary to start it (but normally you would like to start it as soon as possible to avoid running out of log retention period on your source). Once you created the capture job you saved the time from when the capture will start to picking up changes once it is started.

FAQ

If you check "Transaction Files and Capture Time" does that change anything?

Yes, by choosing this option you can make a capture rewind or you can reset the capture time to "now".

Are you saying Local Data Processing will rewind to a time specific to each table, after the table completes the refresh?

No, if the capture job gets suspended during the refresh is not a problem. The capture job will know where to continue from when you start it again.