The target system is reporting out of sync [OOS]. This article provides a list of causes for out of syncs.
There are many causes for out of syncs. Below are a few items to check on the Target system.
1. Triggers on target system that could affect replicated tables. (Reporting instance)
These triggers have already fired on the source system and SharePlex has replicated their effects so you don't need to fire them on the target instance. If they do fire, it would cause double posting, causing out of sync.
2. Constraints, such as, cascade delete or foreign constraints should be disabled. (Reporting instance)
Disable constraints on the target tables except primary and unique key constraints. Primary and unique keys and indexes substantially improve the performance. Check constraints are redundant.
3. Extra constraints on the target tables
4. Temp tables should not be in replication, because of their volatility. Temporary and worktables should be removed from replication. These tables receive a lot of changes and result in a lot of overhead that adversely impacts performance and could possibly cause out of syncs.
5. Some FND tables should not be in replication, because of their volatility.
6. User access on the target system.
7. dbms_jobs running on source and/or target system
8. Replication of binary data.
9. Resync procedure is incorrect. Having an incorrect resync procedure can also be a cause out of syncs.
10. Virtual private database. Shareplex user can see the table, but it may not be able to retrieve the data from the table.
11. Duplicated entries for object(s) in the configure file. The duplicated entries will cause double posting on the target.
12. RAC target with Max_Commit_Propagation_delay is set to a value that different than 0. Refer to SOL16080 for full explanation on this issue.
13. Some software related issue can also cause OOS.
Not all of out of sync is true out of sync. Sometimes out of sync can be a false out of sync. Do the following steps to determine how an out of sync is a true or a false out of sync:
1. take the rowid from errlog.sql under $SP_SYS_VARDIR/log on TARGET node
2. query the data for this rowid from SOURCE instance. *** rowid in the logs always comes from source instance.
3. build the query with the output from step 2
4. run the query against TARGET instance
5. compare the outputs from step 2 and step 4.
*** If they are different, it is true out of sync; else it is a false out of sync.
© 2025 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center