MQ Recovery scenarios

Disk drive failures

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 queue_manager 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 queue_manager -t all * 

where queue_manager 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: 

1.      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. 

2.      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. 

Damaged queue manager object

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.

Damaged single object

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.

Automatic media recovery failure

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.