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(R) or the Coupling Facility to deal with. Because of this, there are a number of alternatives:
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.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csq84j7 |