Reconcile hangs though transactions keep happening on source database (4300217)

Reconcile hung

If the transactions keep occurring on source database and reconcile is still hung, then there could be some problems which is causing the data not to come to target. Before arriving at this conclusion,you may try to do one of the following to force data to be generated so that the reconcile can finish:

1.Issue flush from source sp_ctrl (refer to Solution # 27745):
sp_ctrl> flush o.SID(where SID is the ORACLE_SID of source database)

2.Force log switch on the source database as SYS user:
SQL>alter system switch logfile;

If none of the above yields desired result, then the most likely cause is that something is holding the data from reaching the target. You can check the following:

1.Any queue corruption at upstream, that is Capture or Export can cause interruption in data flow. The easiest way to tell is to issue qstatus command from source sp_ctrl. If the backlog is more than the # of messages in any queue, then that queue is corrupted and the corrupted data needs to be removed from the queue before the replication can resume. This may require assistance from.

3. If any of the Shareplex processes upstream is in a stopped state, the data flow will be hampered. The processes could be Capture, Export or Import. The respective process needs to be restarted for replication to resume and reconcile to finish gracefully.

4.If the Import is in incomplete recovery, then it will discard messages sent to it by Export process. Normally a Shareplex process can go into recovery after certain events like abnormal shutdown, system or OS problems, etc. The recovery normally completes. If it is an incomplete recovery for Import, you will see the following type of message in target event log that indicates that recovery has started:

Notice: Queue write recovery started, qrw_srcseq=181894329432 msg.mpseq=181894178432 [sp_mport(que)/10943]

but no corresponding message like:

Notice: Queue write recovery complete……………….

Support needs to be contacted to resolve this recovery problem and it typically involves resetting the Post queue andtruncating shareplex_trans internal table in database for Shareplex schema.

5.If there is any network issue between source and target, then it needs to be resolved before replication can proceed. In this case you may see the following type of message in event log:

Cannot connect to host <hostname> Connection refused

6. If the wrong log sequence #, which is higher than the current Oracle redolog sequence #, has been supplied in the command, this will cause reconcile to keep waiting for the messages pertaining to that log sequence # before it can finish gracefully. Depending on how far ahead that # is from the current Oracle redolog sequence #, one may have to wait for transactions to occur for that sequence #. This would not only cause undue wait, it will also result in data loss if the log sequence # up to which the target has been recovered is less than this sequence # up to which Post is reconciled.