If an entire DB2(R) data-sharing group fails, recovery might be to the time of failure, or to a previous point in time.
In the case of recovery to the point of failure, WebSphere MQ reconnects when DB2 has been recovered, the resynchronization process takes places and normal queue manager function is resumed.
However, if DB2 is recovered to a previous point in time, there might be inconsistencies between the actual queues in the Coupling Facility structures and the DB2 view of those queues. For example, at the point in time DB2 is recovered to, a queue existed that has since been deleted and its location in the Coupling Facility structure reused by the definition of a new queue that now contains messages.
If you find yourself in this sort of situation, you must stop all the queue managers in the queue-sharing group, clear out the Coupling Facility structures, and restart the queue managers. You must then use WebSphere MQ commands to define any missing objects. To do this, use the following procedure:
SETXCF FORCE,STRUCTURE,STRNAME=
When the queue managers restart, they attempt to resynchronize local COPY objects with the DB2 GROUP objects. This might cause WebSphere MQ to attempt to do the following:
The DELETE of COPY objects is attempted with the NOPURGE option, so it fails for queue managers that still have messages on these COPY queues.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csq84j3 |