At times there can be issues that can cause table on primary side to have incorrect data even though the table on secondary side may still have the correct data.
Some of the common situations that can cause this are:
User error.
Some problem on the database on primary caused the content of the table to be removed while the table on secondary survived.
If the table on secondary still contains valid data, it can be used as a reference to sync the table on primary using compare with repair option. The following are the steps involved:
Make sure that there are no messages in the stopped Export queue on secondary, or in the stopped Post queue on primary, or both, as applicable. If there are, then the respective queue(s) need to be reset using qview (see Solution # SOL43362) or the data in such queues need to be drained by starting the respective processes.
Start all Shareplex processes from secondary to primary for the duration of compare.
Stop user access on the primary and secondary for the table in question, or at a minimum, do so on primary.
Disable triggers for the table on the primary.
Run the compare with repair option from the secondary to primary.
Once compare finishes successfully, and “show compare” issued from secondary shows that the table is “repaired” or “in sync”, then stop Export on secondary (and Post on primary, if needed), re-enable triggers on this table on primary and point users and applications accessing this table to the primary.
