How To Use HVR Refresh in Online Mode to Recover

Question

How can I use HVR Refresh in online mode to recover?

Environment

HVR 5

Answer

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

• 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 the columns in the channel from source tables.
  3. Insert these rows using bulk load in the target table

• 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 the command hvrrefresh) or from the GUI as a scheduled job.

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

• Using Online Refresh for Initial Load or Full Re-initialization
• Using Online Refresh to Solve Capture Problem
• Using Online Refresh to correct Data Mismatches

Instructions

1. Suspend the integrate jobs. You can leave the capture jobs running.

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

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

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

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

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

   • Only Resilience: this should be used when not all data is being refreshed. For example, when using the Restrict /RefreshCondition:

     • 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 first integrate cycle, changes before refresh will be skipped (if that option was chosen), and changes from during refresh will be applied with ‘resilience’

The target databases will be consistent after the first integrate cycle has finished.