Slow Post due to out of Sync and Consequent Increase in Logging Activity (4330687)

Slow Post due to out of Sync and Consequent Increase in Logging Activity

Post writes out of sync entries to event_log as well as to SID_errlog.sql files located in $SP_SYS_VARDIR/log subdirectory. SID denotes the Oracle SID of target database. Normally this writing activity should not slow down Post; however, if there are massive out of sync errors, this can slow down Post.

Massive out of sync errors causing slow posting.

Resolution 1:

The solution suggested is for a Unix environment only. 

If you want to continue posting but not having Shareplex writing to event_log and SID_errlog.sql, link the event_log and SID_errlog.sql to /dev/null as follows:

1. Shutdown Shareplex on target.

2. Create soft link for the files as below:

$ ln -s /dev/null event_log
$ ln -s /dev/null SID_errlog.sql (substitute appropriate value for SID)

3. Start Shareplex on target

This will cause entries not to be written to event log nor SID_errlog.sql, but will help speed up Post.
You should remove the soft links after you resync the tables.

Resolution 2:

Starting with SharePlex 8.6.x, number of out of sync messages logged per table,  into the event_log and *errlog.sql can be controlled by the parameter SP_OPO_SYNC_LOG_FREQUENCY.  

sp_ctrl>set param SP_OPO_SYNC_LOG_FREQUENCY <integer>   (where integer is any positive integer)

For example, to log first out of sync message in event log and *errlog.sql and skip the next 9 out of sync messages, set the parameter as below:

sp_ctrl>set param SP_OPO_SYNC_LOG_FREQUENCY 10

Reset the parameter as below.

sp_ctrl>reset param SP_OPO_SYNC_LOG_FREQUENCY

This method differs from the redirecting the logging to /dev/null in 3 respect: The logging is not disabled totally as the parameter can be set to do minimal logging. For example, you can set it to 100 so that the first out of sync entry will be logged but the next 99 entries will be discarded. This allows users a fine control over logging. It is done on per table basis. So if you set it to 100, for every table the first out of sync will be logged but the next 99 will be skipped. To undo the change is extremely easy as opposed to the redirecting the logging to /dev/null.