Compare fails with ORA-02292 (4299798)

The compare fails with ORA-02292 as the target compare log (the *declt* log) shows:

 000: Oracle Error 2292: ORA-02292: integrity constraint (OWNER.TABLENAME) violated - child record found

000: Error ORA-2292 calling OCIStmtExecute in de_repair_delete_core (2717) for rowid AAAOj5AAIAAAAeXAAA

000: No further repairs will be applied

000: Error 1 calling de_repair_delete in de_compare_delete_extra_client_rows (217)

000: Continuing to process so all the out-of-sync rows are reported

000: Status : Error

The ORA-02292 referential Integrity error is encountered on target when repairing the target table.

The following workaround should resolve the issue:

 Disable referential integrity constraints on the problem table and the corresponding child table on target.

 Separately run compare with repair option on both parent and child tables after the referential integrity constraints on the problem target tables are disabled.

 Re-enable the referential integrity constraint on the target

Here are some more points worth noting:

Make sure no queues are stopped and that they are not backlogged when re-enabling constraints

If re-enabling fails, one can attempt to re-enable them multiple times as needed (for a table that fails to enable it after a successful repair of both parent and child table). If the source is quiet and the queues are fully drained, the constraints should re-enable fine, unless there are data integrity issues on source, a condition rarely observed.

If there are hierarchies of RI constraints, say grandfather, father and child, then the enabling of constraints may fail with ORA-02291 or ORA-02292 even though one of the parent/child pair has been successfully repaired. One may then need to disable all the constraints in the chain, repair the tables and then re-enable the constraints.

It is assumed that this is a one way replication or if not, then the applications are pointed to the trusted source (or primary) for the duration of compare.