Installing an HVR upgrade from HVR version 4 to HVR 5

From HVR
Jump to: navigation, search

Upgrading installations can be a large undertaking, especially when it involves downtime or lots of machines. For this reason different HVR versions are typically fully compatible with each other; it is not necessary to upgrade all machines in a channel at once. Also HVR 4 and HVR 5 can connect to each other, for details see Migrating from HVR Version 4 to 5.

In many environments all machines will just be upgraded at the same time.

It is also possible to only upgrade certain machines (e.g. only the hub machine, GUI, remote source or target). If this is done, it should be understood that each HVR release fixes some bugs and or contains new features. Each fix or feature is only effective if the correct machine is upgraded. For example, if a new HVR release fixes an integrate bug, then that release must be installed on the machine(s) which do integrate. If only the GUI and/or hub machine is upgraded, then there will be no benefit. Read the HVR Release Notes (in $HVR_HOME/hvr.rel) for a description of which features and fixes have been added, and which machine must be upgraded for each feature and fix to be effective. New features should not be used until all machines that are specified for that feature are upgraded, otherwise errors can occur.

  1. If a target location is upgraded from HVR version 4 to HVR 5 the replication needs to be flushed. Suspend the capture jobs, wait until the integrate jobs have finished integrating all the changes (so no transaction files are left in the router directory) and then suspend them too.
    $ hvrsuspend hubdb chn–cap
    $ hvrstart –w hubdb chn–integ
    $ hvrsuspend hubdb chn–integ

  2. If this is a hub machine, then stop the HVR Scheduler:
    SC-Hvr-Scheduler sqlserver StopRedCircle.png

  3. If the HVR Remote Listener service is running, it should be stopped.
    SC-Hvr-RemoteListener 4343.png
  4. Stop all HVR GUI processes.

  5. On AIX, uninstall the old HVR runtime executables using command (only for Unix & Linux):
    Unix & Linux
    $ rm $HVR_HOME/lib/*

    Alternatively remove all cached shared libraries from the kernel by performing command slibclean as root. This step is not needed for other flavors of Unix or Linux.

  6. Read and uncompress the distribution file.
    Unix & Linux

    Under Unix and Linux this is done by:

    $ cd $HVR_HOME
    $ umask 0
    $ gzip –dc /tmp/hvr–5.0.3–linux_glibc2.5–x64–64bit.tar.gz | tar xf –

    On Microsoft Windows this is performed using the installation wizard:

    C:\> d:\hvr–5.0.3–windows–x64–64bit–setup.exe

  7. If HVR must perform log–based capture from Ingres, it needs a trusted executable to read from the DBMS logging system. Perform the following steps while logged in as ingres:
    $ cd /usr/hvr/hvr_home
    $ cp bin/hvr sbin/hvr_ingres
    $ chmod 4755 sbin/hvr_ingres

    Additionally, on Linux the trusted executable needs to be patched using

    $ /usr/hvr/hvr_home/lib/patchelf --set-rpath /usr/hvr/hvr_home/lib --force-rpath /usr/hvr/hvr_home/sbin/hvr_ingres

    These steps are not needed if capture will be trigger–based or if capture will be from another machine.

    If HVR and ingres share the same Unix group, then the permissions can be tightened from 4755 to 4750.

  8. If the hub machine is being upgraded, then the HVR version 4 actions need to be upgraded to HVR 5 actions. This can be done automatically by connecting with a new version 5 HVRGUI to this hub installation; A pop-up will appear to change the HVR 4 definitions to HVR 5.

  9. If the hub machine is being upgraded, the datatype information in the HVR catalogs need to be reloaded. For each channel use the HVR GUI's Table Explore to improve this information: Click Replace for all tables that show differences. This step is optional, but if it is omitted and a subsequent HVR Refresh is instructed to recreate mismatched tables it could create target tables with incorrect datatypes.

  10. If the hub machine is being upgraded, it is necessary regenerate the job scripts for all channels. This can be done on the command line as follows:
    $ hvrinit –oj hubdb/password mychn

    SC-Hvr-Initialize demo51 oracle Advanced Scrips and Jobs.png

  11. If a target machine was upgraded from HVR version 4 to HVR 5, the state tables need to be regenerated. If Integrate /Burst is used, the burst tables need to be recreated as well. This can be done on the command line as follows: For each target location:
    $ hvrinit –ocs -l tgt_loc hubdb/password mychn

    SC-Hvr-Initialize demo51 oracle Advanced State and Change Tables.png

  12. If the HVR Remote Listener service was stopped, it must be restarted.
    SC-Hvr-RemoteListener 4343.png

  13. If this is a hub machine, restart the HVR Scheduler.
    SC-Hvr-Scheduler stop sqlserver.png
  14. If the replication jobs were stopped, restart the replication
    $ hvrstart hubdb chn–cap
    $ hvrstart hubdb chn–integ