The previously active config file was deactivated by issuing the command “deactivate config <config name> . The “list config” now shows there is no active config.
However, the “status” shows that there are still residual Shareplex processes running on source and target Shareplex (shown here for source):
sp_ctrl (server_name:2100)> status
Brief Status for server_name
Process State PID Running Since
--------------- ------------------------------ -------- --------------------
Cop Running 26469 13-Oct-10 21:17:50
Read Running 26471 13-Oct-10 21:17:50
Export Running 26478 13-Oct-10 21:18:00
Cmd & Ctrl Running 26481 13-Oct-10 21:18:04
There are no active configuration files
Moreover, the “qstatus” shows that there are residual queues on source and target (again shown here for source):
sp_ctrl (server_name:2100)> qstatus
Queues Statistics for server_name
Name: o.SOURCE_SID (Capture queue)
Number of messages: 0 (Age 0 min; Size 4 mb)
Backlog (messages): 0 (Age 0 min)
Name: server_name (Export queue)
Number of messages: 0 (Age 0 min; Size 1 mb)
Backlog (messages): 0 (Age 0 min)
The command did not execute successfully.
The command “deactivate config” may at times be ineffective in removing the existing replication completely. It tries to terminate existing replication gracefully by removing existing queue structures on both source and target, as well as getting rid of the contents of Shareplex internal tables on source and target database, but some glitches can cause it to fail in doing so. This results in residual entries in internal tables and/or residual queues. Such residual structures can result in the Shareplex internal tables and the queue contents to be in out of synchronicity with each other, and consequently in an inconsistent state. Attempting to activate the previously active config may not be a safe workaround as even if it were successful, it may come with added uncertainty of any impending out of sync, problems with queues, etc. Since the whole purpose of the original command was to get rid of the existing replication, the workaround expressed in the following para offers the only viable solution.
The following is the option available to deal with this situation:
Shutdown Shareplex on both source and target and run ora_cleansp on both to clean up the existing replication environment. Then resync the target and activate the config on source once again.
The “abort config” may be used as an alternative. This will not get rid of the existing replication gracefully but will instead get rid of all Shareplex processes, queues, and contents of Shareplex internal tables on source as well as on target. However, this option will not work once the “deactivate config” failed to clean up the existing replication environment and the only available option will be the one described in Resolution section above.
The “deactivate config” does not require a resync of target so long as the source database is not accessed by users just before the command was successfully executed. However, the option “abort config” may require a resync if there were data in Shareplex queues when the command to abort the config was issued. The same goes with the workaround to run ora_cleansp following the failed “deactivate config”.
