Reinitializing queue managers in a queue-sharing group

In a queue-sharing group, reinitializing a queue manager is more complex. It might be necessary to reinitialize one or more queue managers because of page set or log problems, but there might also be problems with DB2 or the Coupling Facility to deal with. Because of this, there are a number of alternatives:

Cold start

Reinitializing the entire queue-sharing group involves forcing all the Coupling Facilities structures, clearing all object definitions for the queue-sharing group from DB2, deleting or redefining the logs and BSDS, and formatting page sets for all the queue managers in the queue-sharing group.

Shared definitions retained

Delete or redefine the logs and BSDS, format page sets for all queue managers in the queue-sharing group, and force all the Coupling Facilities structures. On restart, all messages will have been deleted. The queue managers recreate COPY objects that correspond to GROUP objects that still exist in the DB2 database. Any shared queues still exist and can be used.

Single queue manager reinitialized

Delete or redefine the logs and BSDS, and format page sets for the single queue manager (this deletes all its private objects and messages). On restart, the queue manager recreates COPY objects that correspond to GROUP objects that still exist in the DB2 database. Any shared queues still exist, as do the messages on them, and can be used.

Point in time recovery of a queue-sharing group

This is the alternative site disaster recovery scenario.

Shared objects are recovered to the point in time achieved by DB2 recovery (described in A DB2 system fails). Each queue manager can be recovered to a point in time achievable from the backup copies available at the alternative site.

Persistent messages can be used in queue-sharing groups, and can be recovered using the MQSC RECOVER CFSTRUCT command. Note that this command recovers to the time of failure. However, there is no recovery of nonpersistent shared queue messages; they will all be lost unless you have made backup copies independently using the COPY function of the CSQUTIL utility program.

It is not necessary to try to restore each queue manager to the same point in time because there are no interdependencies between the local objects on different queue managers (which are what is actually being recovered), and the queue manager resynchronization with DB2 on restart creates or deletes COPY objects as necessary on a queue manager by queue manager basis.