Issue

There are integration errors after performing a manual refresh.

Environment

Local Data Processing

Resolution

Here are some reasons that can cause this and various ways to check what is going on:

1. Replication key does not match the key of source and target table (i.e., does not pin-point a unique row). This can be checked using HVR's Table Select feature connect to source and target databases
2. Target table is changed outside of HVR (the row is already deleted) This could be checked by reviewing user grants on the target
3. Restrictions that are configured incorrectly. E.g. Restrict /CaptureCondition that can match the delete but not the insert. A Restrict /RefreshCondition that results in an incomplete refresh
4. Wrong Online Refresh options. Online refresh needs to be enabled when the source database is being changed (DML) during the refresh. There are several settings:
   • "Skip Previous Capture and Integration" (option -qrw). This can be used if there is 1 source and 1 target in the channel and all data for the selected tables is refreshed.
   • "Skip Previous Integration" (option -qwo). This should be used when refreshing all data for selected tables from 1 source into multiple targets
   • "Do not skip changes" (-qno). This option should be used when only part of the data for selected tables is refreshed; e.g. using a Restrict /RefreshCondition
5. Online Refresh relies on time stamps to decide which changes to skip or to apply with integrate resilience. When system clocks for source / target and hub machines are not properly synchronized this can result in data inconsistencies and in integration errors during replication
6. Not all data is captured. In this case the insert is not replicated but the delete is. Possible causes. The inserts are done using an operation that is not supported by HVR (e.g. partition exchange load) or an operation that is not logged (some direct path operation if the table or partition does not have force logging). This can be investigated by turning on DbIntegrate /Journal in the channel. This will change integrate to not delete all tx-files after processing them, but move them to a separate directory. This gives an audit trail of all rows that are replicated with HVR. Another reason for HVR not to capture the changes is when the changes are made by HVR integrate (either directly or via a trigger).
7. A transaction had started before the initial capture time but its results were not picked up by the Refresh because the transaction had not yet committed when the affected table(s) was (were) refreshed. If such a transaction for example inserts a row into a table that is subsequently updated or deleted in a new transaction then HVR would report the row as non-existent for the update/delete.