There are times when reconcile on a particular named Post queue is hung for want of data from source whereas it finishes successfully for the other Post queue. If the other Post queues are heavily backlogged after reconcile finishes, it may not be desirable to issue a simple reconcile (with no options) on the source, for it will force every Post queue to stop once the reconcile marker is encountered by that Post queue, and this may require undue monitoring of other queues that are otherwise doing fine.
Reconcile on one of the several Post queues is hung for want of data.
The easiest way to force a hung reconcile waiting for want of data on a particular named queue is to issue a flush directed at that queue. This is done on the source. This will cause a dummy message to be put in the redo log by Shareplex, and will be gathered by Capture queue and sent to the designated named Post queue forcing the reconcile to finish successfully (barring any other issues that may still cause reconcile to error out). The advantage of this option of reconcile is that it does not impact any other named Post queue. Moreover, it is not required to execute an actual transaction on one of the table belonging to that named queue, in case there are no test tables available to this. The syntax for this option of flush is:
flush o.SID queue <queuename> (where the SID refers to the source's Oracle SID, and <queuename> is the named Post queue in question)
Refer to Reference Guide for Shareplex for more details on flush.