Home HVR Real-time Replicator Knowledge Base HVR Initialize (formerly HVR Load) – what options to use and when Reply To: HVR Initialize (formerly HVR Load) – what options to use and when
Reply To: HVR Initialize (formerly HVR Load) – what options to use and when
Thanks for submitting your questions on the forum.
Emit time refers to when changes will be sent from capture to integrate. Emit time could be different than capture start time for a system with long-running transactions. HVR will only start capturing changes against tables in the channel from the capture time forward, but of course in order to capture long-running transactions in the system in their entirety you may want to start capture earlier, and emit only from some point forward. ERP systems on the Oracle Database often have long-running transactions in the database, but long-running transactions are not common on many other databases.
There are some scenarios when a capture rewind is checked as part of initialize, but a “reset” (i.e. refresh) is not required. For example if the source system database is upgraded from one version to another whilst the application is down. A database upgrade often results in a lot of transaction log changes and irrespective of whether HVR could read through these changes without any issues it may just be cleaner to suspend the capture during the upgrade. Also, it is not unlikely that the database will be restarted as part of the upgrade, possibly more than once. Then post upgrade you would perform a capture rewind to current (or to the point in time post upgrade but before the application starts) to skip over the transaction log changes during the upgrade. In such scenario you would know that you didn’t miss any application changes. Another example would be an application upgrade with downtime during which, depending on the upgrade, there would also be no changes getting applied to the tables you want to replicate. Of course in some cases during an application upgrade table changes are performed (DML and/or DDL) that may or may not need to be reflected as part of the replication.
If old transaction logs are still accessible on the server post a restart then I would expect HVR to be able to continue to run through the old sequence of transaction logs until it needs to resume back at the reset point. I suspect that as it stands we require a re-initialize when getting to the point when the reset happens to be able to continue. If transaction logs from before the server restart are no longer available then you will likely require a refresh to get the data back in sync. You could always use compare to identify the damage which, depending on the change rate on the application, may be more or less difficult to achieve.
Hope this helps.