Is it possible to fix queue corruption or delete queues upstream without losing the queues downst (4299839)

At times queues run into corruption issues and the corruption needs to be fixed or the queue in question needs to be deleted before the affected Shareplex process can resume normal processing. The queues may also need to be deleted due to a heavy backlogging that will take just too long to process by Shareplex. Whether it is a fixing of corruption or a deletion of a queue, the data is certainly lost. The question arises as to whether it is possible to continue normal replication once this is done or does it require additional steps for the other queues which are not affected.

General information.

These questions arise as one may want to know whether one is only dealing with the data loss that occurred due to the fixing of queue corruption or removal of a certain queue, or is there more to it. There are two different scenarios which require a different approach when dealing with data loss in a queue:

A. If a queue corruption is fixed without having to delete/reset the queue, for example, data was cleared using commands rrls or discard or fixup all, etc...:

In this case the steps involved are very simple. After the corruption is removed/fixed via rrls or discard, etc...  Shareplex needs to be started (if it was shutdown during the fixing) and the affected process(es) need to be restarted. There is no action required on any other queues, since the process of fixing queue corruption takes care of the fact the remaining data in the queue is compatible with the other queues in terms of the queue sequence numbers and other statistics. These statistics govern whether the data from any queue will move to the next queue. See solution number SOL23995 for additional details on fixing queue corruption.

B. If a queue needed to be deleted or reset to fix corruption or to take care of any other issue:

In this case certain steps need to be performed if the data in the queues downstream needs to be salvaged, and also if the fresh data from queues upstream need to move to the affected queue and beyond to downstream queues. Once a queue is deleted or reset, all queues downstream need to be deleted or reset as well. To salvage the data in these downstream queues, it is essential that the downstream queues be allowed to post to the target database and the downstream queues are reset as well before any fresh data from queues upstream reaches them. For example, if Capture queue needs to be deleted/reset, then the following steps can be undertaken prior to deleting queues downstream to salvage the data in such queues:

1. On source sp_ctrl, stop the Read process prior to deleting Capture queue. This ensures that no data from Capture queue will reach the Export or Post queues without our consent:
sp_ctrl>stop read 

2. Issue qstatus on source and target sp_ctrl to see if the number of messages in Export and Post queues reaches 0. If it does, then all the messages have posted. If not, and if most of the messages have posted, then one may be seeing some residual messages in Post queue due to open transactions, and such messages cannot be posted or salvaged:
sp_ctrl>qstatus

3. Carry out the operations involving deleting/resetting the queue. This will also involve deleting/resetting all the queues downstream (but not upstream) as well as truncation of the internal table owned by Shareplex schema named shareplex_trans table in the target database. See Solution # SOL540 for details.

In nutshell, the situation described in para A and B is handled in a vastly different way. In para A nothing needs to be done to salvage the queues downstream, but in para B certain care is required. If one does not care about salvaging data in queues downstream, then the steps described in sub para 1 and 2 within para B are not required.