How SharePlex reports out-of-sync conditions
For all objects except those involved in transformation, SharePlex verifies that the source and target data in a given operation are synchronized before posting the replicated data to the target. SharePlex does not verify synchronization if transformation is being used because:

Transformation changes the target data, so before and after images cannot be compared.
The transformation routine posts the data, not SharePlex.
When SharePlex determines that source and target data are different, it generates error conditions but continues to post other data from the post queue. To direct Post to stop processing altogether when it detects an out-of-sync condition, change the SP_OPO_OUT_OF_SYNC_SUSPEND (Oracle) or SP_OPX_OUT_OF_SYNC_SUSPEND (Open Target) parameter. See the Post parameter documentation in the SharePlex Reference Guide.

When an out-of-sync condition occurs, the Post process logs a message in the Status Database and also to the Event Log. To view these files in sp_ctrl:

Status Database: Use the show statusdb or show sync command.
Event Log: Use the show log command.
Use these commands frequently to monitor for out-of-sync errors.

The following is an example of how SharePlex reports an out-of-sync condition.

sp_ctrl ( doyen21:321)> show sync

Out Of Sync Status Database doyen21

Count Details

—– ——————–

3 Table “SCOTT”.”DATA_Test1″ out of sync for queue doyen21 since 16-Oct-

04 01:23:11

3 Table “SCOTT”.”DATA_Test2″ out of sync for queue doyen21 since 17-Oct-

04 01:11:05

1 Table “SCOTT”.”DATA_Test3″ out of sync for queue doyen21 since 17-Oct-

04 01:09:23

When data goes out of synchronization, SharePlex logs the failed SQL statements to the database_ID_errlog.sql file in the data sub-directory of the SharePlex variable-data directory.

Important: If you see an out-of-sync message in the Status Database and in the Event Log, but there is no record in the database_ID_errlog.sql file for the transaction, do not ignore those messages. They could be associated with a ROLLBACK. Regardless of whether or not a transaction is rolled back, SharePlex still compares the pre-images of the source and target rows. If they are different, that indicates that the data is out of synchronization. Only when a transaction is committed on the source but fails on the target does SharePlex log it to the database_ID_errlog.sql file, to give you a record of the statement that should have been applied as a tool for problem solving and for manually applying the statement if appropriate. Rolled back statements are canceled operations, and therefore not logged on the target.

Recent Posts

Start typing and press Enter to search