How To Use Local Data Processing Refresh in Online Mode to Recover

The Online Refresh procedure enables re-synchronization without requiring end-user down-time on the source database. Like HVR Compare, the Refresh has two modes of operation:

1. Bulk: Refresh will truncate the target table and use a bulk load method to load the data. This is very efficient, but cannot be used when end-users are accessing the data in the target tables as target tables will be truncated in this process causing temporary loss of data. When no Restrict /RefreshCondition applies, it will:

   1. Truncate the target table

   2. Select <all cols in channel> from <source tables>

   3. Insert these rows using bulk load in the target table

2. Row-by-row: This will do a row-by-row compare first and then after identifying the differences it will apply them using insert/update/delete statements. This is less intrusive on the target tables, however it consumes more resources and takes longer. Because singleton insert/update/delete statements impact performance negatively, it is recommended to use bulk-refresh whenever possible.

The refresh can be run interactively from the command line (using command hvrrefresh) or from the HVRGUI or it can be run as a scheduled job.

The online refresh can be helpful in these and other scenarios:

1. Using Online Refresh for Initial Load or Full Re-initialization

2. Using Online Refresh to step over a Capture Problem

3. Using Online Refresh to correct Data Mismatches

Instructions

1. Suspend the integrate jobs. The capture jobs can be left running.

2. Run HVR Refresh and check the box for Online Refresh mode. There are three different options:

   1. Skip Previous Capture and Integration: skip changes from before the refresh on read and write side. This can be used when all data is refreshed (no refresh condition) and there is only 1 integrate location

      1. Changes before the online refresh should be skipped both on the read side (by the capture job) and on the write side (by the integrate job). There are two advantages to skipping changes on the capture side; performance (those changes will not be send over the network) and avoiding some replication errors (i.e. those caused by an alter table statement). The disadvantage of skipping changes on the capture side is that these changes may be needed by other replication targets. If they are needed, then the other integration locations will need a new 'online' refresh, but without –qrw (capture and integrate), and using only the integrate (-qwo) otherwise the original targets will need yet another refresh.

   2. Only Skip Previous Integration: skip changes from before the refresh on write side only. This can be used when all data is refreshed (no refresh condition) when there are multiple integrate locations

      1. Write only. Changes before the online refresh should only be skipped on the write side (by the integrate job), not on the read side (by the capture job). If changes are being replicated from the read location to multiple targets, then this value will avoid skipping changes that are still needed by the other targets.

   3. Only Resilience. This should be used when not all data is being refreshed. For example when using a Restrict /RefreshCondition:

      1. No skipping. Changes that occurred before the refresh are not skipped, only special handling is activated for changes that occurred during the refresh. This is useful for online refresh of a context–sensitive restriction of data (–Cctx and Restrict /RefreshCondition /Context).

3. After the refresh the integrate jobs can be restarted. During the 1^st integrate cycle, changes before refresh will be skipped (if that option was chosen) and changes from during refresh will be applied with ‘resilience’ 

Related articles