Integration Error After Performing Manual Refresh
Issue
There are integration errors after performing a manual refresh.
Environment
HVR 5
Resolution
The following are some of the reasons that can cause this and different ways to check what is going on:
The replication key does not match the key of the source and target table (i.e., does not pinpoint a unique row). This can be checked using HVR's Table Select feature connect to source and target databases.
The target table is changed outside of HVR (the row is already deleted) This could be checked by reviewing user grants on the target.
Restrictions that are configured incorrectly. For example, Restrict /CaptureCondition can match the delete but not the insert. A Restrict /RefreshCondition that results in an incomplete refresh.
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 (option
-qno
): This should be used when only part of the data for selected tables is refreshed; for example, using a Restrict /RefreshCondition.
- Skip Previous Capture and Integration (option
Online Refresh relies on time stamps to decide which changes to skip or to apply with integrate resilience. When system clocks for source or target and hub machines are not properly synchronized this can result in data inconsistencies and in integration errors during replication.
Not all data is captured. In this case, the insert is not replicated but the delete is. Possible causes can be the following: The inserts are done using an operation that is not supported by HVR (for example, 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 capturing the changes is when the changes are made by HVR integrate (either directly or through a trigger).
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 been 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 or delete.