Online Refresh

Viewing 1 post (of 1 total)
  • Author
    Posts
  • #10985
    ggoodrich
    Keymaster

    An online refresh is a refresh procedure that can be performed while users are making changes on the source database. The procedure consists of the following steps:

    1. Stop integration jobs.
    2. Capture jobs may be left running.
    3. Choose HVR Refresh in GUI and select “Online” option (we also set parallelism & bulk).
    4. After completion, restart integration
    5. We check that capture is still running. If it’s stopped, restart it

    Whether or not to stop the capture job is optional. It can be a performance improvement, but on the other hand, if the refresh takes a long time and the capture job is stopped then it may take a long time to catch up. Please note that the Online Refresh comes with two skipping options (option ‘-qrw’ Read/Write and option ‘-qwo’ Write only) and a no-skipping option (-qno). Using skipping on the read (capture) side of the refresh only make sense if the capture job is stopped. No skipping should be used when not all of the data for a particular table will be refreshed (e.g. due to a Restrict /RefreshCondition)

    Some background

    The online refresh uses control-files to signal the replication jobs that a refresh for a certain table has taken place. When Read/Write skipping is enabled it 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.

    Write only skipping 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.

    No-skipping means that the integrate job will be resilient for the changes during the refresh but no changes will be skipped. The reason that the integrate job needs to be suspended is that the refresh writes these control files at the very end of the refresh. If the integrate job was left running all the changes would already have been integrate and the skipping/resilience has no effect.

    Before the refresh starts “hvrload” can be used to define start-capture moment (which is not the same as running the capture job):
    hvrload defines the start moment of the capture, when the capture job is triggered at a later moment it will go back to the moment of the hvrload) or to a specific time stamp in the past if capture rewind has been used (hvrload -i.

    Anyway, this step is only really needed if you would like to forcefully skip all changes before this hvrload moment (e.g. because the capture job has been in a failed state for a week and you don’t want to process these changes anymore) or if the capture job has never run before.

    It is not needed to have /OnErrorSavedFailedRow or /Resilience defined (this used to be in older versions of HVR).

Viewing 1 post (of 1 total)
  • The forum ‘Expert Notes’ is closed to new topics and replies.

© 2020 HVR

Test drive Contact us