A DB2 data-sharing group fails
If an entire DB2 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, 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:
- Prevent WebSphere MQ from reconnecting to DB2 by starting DB2 in utility mode, or by altering security profiles.
- If you have any important messages on shared queues, you might be able to off-load them using the COPY function of the CSQUTIL utility program, but this might not work.
- Terminate all queue managers.
- Use the following z/OS command to clear all structures:
SETXCF FORCE,STRUCTURE,STRNAME=- Restore DB2 to a historical point in time.
- Reestablish queue manager access to DB2.
- Restart the queue managers.
- Recover the WebSphere MQ definitions from backup copies.
- Reload any off-loaded messages to the shared queues.
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:
- Create COPY objects for old GROUP objects that existed at the point in time DB2 has recovered to.
- Delete COPY objects for GROUP objects that were created since the point in time DB2 has recovered to and so do not exist in the database.
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.