IBM MQ can recover persistent messages on shared queues
if all:
Backups of the CF structures containing the messages have been performed.
All the logs for all queue managers in the queue sharing group are available, to perform
recovery from the point the backups are taken.
Db2 is available and the structure backup table is
more recent that the most recent CF structure backup.
The messages on a shared queue are stored in a coupling facility (CF) structure. Persistent
messages can be put onto shared queues, and like persistent messages on non-shared queues, they are
copied to the queue manager log. The MQSC BACKUP CFSTRUCT and RECOVER CFSTRUCT commands are provided to allow the recovery of a CF structure
in the unlikely event of a coupling facility failure. In such circumstances, any nonpersistent
messages stored in the affected structure are lost, but persistent messages can be recovered. Any
further application activity using the structure is prevented until the structure has been
recovered.
To enable recovery, we must back up your coupling facility list structures frequently using the
MQSC BACKUP CFSTRUCT command. The messages in the CF structure are written onto the active log data
set of the queue manager making the backup. It writes a record of the backup to Db2: the name of the CF structure being backed up, the name
of the queue manager doing the backup, the RBA range for this backup on that queue manager log, and
the backup time. Back up CF list structures even if we are not actively using shared queues, for
example, if you have set up a queue sharing group intending to use it in the future.
We can recover a CF structure by issuing an MQSC RECOVER CFSTRUCT command to the queue manager
that can perform the recovery; we can use any queue manager in the queue sharing group. We can
specify a single CF structure to be recovered, or we can recover several CF structures
simultaneously.
As noted previously, it is important that you back up your CF list structures frequently,
otherwise recovering a CF structure can take a long time. Moreover, the recovery process cannot be
canceled.
The definition of a shared queue is kept in a Db2
database and can therefore be recovered if necessary using standard Db2 database procedures. See Shared queues and queue sharing groups for more information.
Moving shared queues
This section describes how to perform load balancing by moving a shared queue from one coupling
facility structure to another. It also describes how to move a non-shared queue to a shared queue,
and how to move a shared queue to a non-shared queue.
When you move a queue, we need to define a temporary queue as part of the procedure. This is
because every queue must have a unique name, so we cannot have two queues of the same name, even if
the queues have different queue dispositions. IBM MQ
tolerates having two queues with the same name (as in step 2 ), but we cannot use
the queues.
Moving a queue from one coupling facility structure to another
Moving a non-shared queue to a shared queue
Moving a shared queue to a non-shared queue
Moving a queue from one coupling facility structure to another
To move queues and their messages from one CF structure to another, use the MQSC MOVE QLOCAL command. When you
have identified the queue or queues that we want to move to a new CF structure, use the following
procedure to move each queue:
Ensure that the queue we want to move is not in use by any applications, that is, the
queue attributes IPPROCS and OPPROCS are zero on all queue managers in the queue sharing group.
Prevent applications from putting messages on the queue
being moved by altering the queue definition to disable MQPUT s. Change
the queue definition to PUT(DISABLED).
Define a temporary queue with the same attributes as the
queue that is being moved using the following command:
If the queue being moved was defined in the CSQINP2 data sets, change the CFSTRUCT attribute of
the appropriate DEFINE QLOCAL command in the CSQINP2 data sets. Add the REPLACE keyword so that the
existing queue definition is replaced.
Figure 1 shows a
sample job for moving a queue from one CF structure to another.
Figure 1. Sample job for moving a queue from one CF structure to another
The procedure for moving a non-shared queue to a shared queue is like the procedure for moving a
queue from one CF structure to another (see Moving a queue from one coupling facility structure to another ). Figure 2 gives a sample job to
do this. Note: Remember that messages on shared queues are subject to certain restrictions on the
maximum message size, message persistence, and queue index type, so you might not be able to move
some non-shared queues to a shared queue.
Figure 2. Sample job for moving a non-shared queue to a shared queue
Migrating the first (or only) queue manager in the queue sharing group
Figure 2 shows an
example job for moving a non-shared queue to a shared queue. Do this for each queue that needs
migrating.
Note:
Messages on shared queues are subject to certain restrictions on the maximum message size,
message persistence, and queue index type, so you might not be able to move some non-shared queues
to a shared queue.
We must use the correct index type for shared queues. If we migrate a transmission queue to be
a shared queue, the index type must be MSGID.
If the queue is empty, or we do not need to keep the messages that are on it, migrating the
queue is simpler. Figure 4 shows an example job to use in these circumstances.
Figure 4. Sample job for moving a non-shared queue without messages to a shared queue
Migrating any other queue managers in the queue sharing group
For each queue that does not have the same name as an existing shared queue, move the queue as
described in Figure 2 or
Figure 4.
For queues that have the same name as an existing shared
queue, move the messages to the shared queue using the commands shown in Figure 5.Figure 5. Moving messages from a non-shared queue to an existing shared queue
To apply maintenance or service to the Db2 tables or package related to shared queues without
stopping your queue manager, we must temporarily disconnect queue managers in the data sharing
group (DSG) from Db2.
To do this:
Use the MQSC command SUSPEND
QMGR FACILITY( Db2 ).
Do the binds.
Reconnect to Db2 using the MQSC command RESUME QMGR FACILITY( Db2 )
Note that there are restrictions on the use of these commands.
Attention: While the Db2 connection is
suspended, the following operations will not be available. Therefore, we need to do this work
during a time when your enterprise is at its least busy.
Access to Shared queue objects for administration (define, delete,alter)