This section looks at a number of possible problems and indicates how to
recover from them.
You might have problems with a disk drive containing either the queue
manager data, the log, or both. Problems can include data loss or
corruption. The three cases differ only in the part of the data that
survives, if any.
In all cases first check the directory structure for any damage
and, if necessary, repair such damage. If you lose queue manager data,
the queue manager directory structure might have been damaged. If so,
re-create the directory tree manually before you restart the queue
manager.
Having checked for structural damage, there are a number of things you can
do, depending on the type of logging that you use.
- Where there is major damage to the directory structure or any damage
to the log, remove all the old files back to the QMgrName
level, including the configuration files, the log, and the queue manager
directory, restore the last backup, and restart the queue manager.
- For linear logging with media recovery, ensure that the
directory structure is intact and restart the queue manager. If the
queue manager does not restart, restore a backup. If the queue manager
restarts, check, using MQSC commands such as DISPLAY QUEUE, whether any other
objects have been damaged. Recover those you find, using the
rcrmqobj command. For example:
rcrmqobj -m QMgrName -t all *
where QMgrName is the queue manager being recovered.
-t all * indicates that all objects of any type (except
channels) are to be recovered. If only one or two objects have been
reported as damaged, you can specify those objects by name and type
here.
- For linear logging with media recovery and with an undamaged
log, you might be able to restore a backup of the queue manager data
leaving the existing log files and log control file unchanged. Starting
the queue manager applies the changes from the log to bring the queue manager
back to its state when the failure occurred.
This method relies on two things:
- You must restore the checkpoint file as part of the queue manager
data. This file contains the information determining how much of the
data in the log must be applied to give a consistent queue manager.
- You must have the oldest log file required to start the queue manager at
the time of the backup, and all subsequent log files, available in the log
file directory.
If this is not possible, restore a backup of both the queue manager data
and the log, both of which were taken at the same time.
- For circular logging, restore the queue manager from the latest
backup that you have. Once you have restored the backup, restart the
queue manager and check as above for damaged objects. However, because
you do not have media recovery, you must find other ways of re-creating the
damaged objects.
If the queue manager object has been reported as damaged during normal
operation, the queue manager performs a preemptive shutdown. There are
two ways of recovering in these circumstances, depending on the type of
logging you use:
- For linear logging only, manually delete the file containing
the damaged object and restart the queue manager. (You can use the
dspmqfls command to determine the real, file-system name of the
damaged object.) Media recovery of the damaged object is
automatic.
- For circular or linear logging, restore the last backup of the
queue manager data and log and restart the queue manager.
If a single object is reported as damaged during normal operation:
- For linear logging, re-create the object from its media
image.
- For circular logging, we do not support re-creating a
single object.
If a local queue required for queue manager startup with a linear log is
damaged, and the automatic media recovery fails, restore the last backup of
the queue manager data and log and restart the queue manager.
© IBM Corporation 1994, 2002. All Rights Reserved