The Capture appears to be normal and is current with Oracle though it is not processing any recently executed transactions done on replicating tables on source. Nor is it processing the flush message generated by "flush o.SID" issued from source sp_ctrl (where SID is the source Oracle SID). The following message in event log indicate that Capture is in recovery that never completes, despite bouncing Capture or Shareplex:
11/21/06 23:42 SharePlex was shutdown
11/21/06 23:43 SharePlex was started on cpu 839b4bd9 using port 14024
11/21/06 23:43 Process launched: sp_ocap (for o.idweb) [pid = 21765]
11/21/06 23:43 Notice: Oracle version 92 [sp_ocap(osp)/21765]
The message "Queue write recovery completed" never shows up indicating that the recovery didn't complete. The reason a process goes into recovery can range from abnormal shutdown of Shareplex, killing of that process, network or OS problems, software bug, etc.
Certain abnormal events can render a Shareplex process in a state of recovery.
You can try bouncing Capture and Shareplex to see if this resolves the problem. If it does not, then the only solution is to shutdown Shareplex on source and target, delete the queues and truncate shareplex_trans table on target before restarting Shareplex on source and target.
Please be aware doing this means you will lose all messages in the queues that you delete and you will need to resync.
1) ON SOURCE Shareplex must be shutdown ./qview qview> qsetup <port#> qview> list --this will show all queues on the source box
qview> deleteq C qview> deleteq X -delete all queues one by one if you have multiple export queues
2) ON TARGET
Shareplex must be shutdown ./qview qview> qsetup <port#> qview> list qview> deleteq P (delete all post queues by repeating the command) qview> exit
3) ON TARGET ./sqlplus splex_user/splex_pwd truncate table shareplex_trans
After Shareplex is restarted, the queues will spawn and replication would resume normally.