Capture Job Seems to Get Suspended by Online Refresh

Question

The Capture job seems to get suspended by the online Refresh job. Will I lose transactions?

Environment

HVR

Answer

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

There are 3 options to choose while performing Refresh:

Option 1: Skip 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.

Option 2: Only Skip 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

Option 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.

In summary,

• The third option 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 action /Restrict on your Refresh to filter the dataset) you can choose the first option Skip Previous Capture and Integration.
• If you have a one-to-many replication (without /Restrict on the Refresh) you can choose the second option Only Skip Previous Integration 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 third option Only Resilience.

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 have created the Capture job you saved the time from when the Capture will start to picking up changes once it is started.

FAQs

If you select the option "Transaction Files and Capture Time" during HVR Initialize, does that change anything?

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

Does that mean HVR 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.