WebSphere MQ 学习笔记(4) Recovery&Problem Determine

　　1. Recovery and restart

　　use logs for three types of recovery:

　　restart recovery

　　crash recovery

　　media recovery

　　1) A WebSphere MQ log consists of two components:

　　a. One or more files of log data(a log extent). For UNIX systems, each of the three files defaults to 4 MB.

　　/var/mqm/log/

　　WebSphere MQ starts with these primary log files, but if the primary log space is not sufficient, it allocates secondary log files. It does this dynamically and removes them when the demand for log space reduces. By default, up to two secondary log files can be allocated.

　　b. A log control file

　　The log control file contains the information needed to control the use of log files, such as their size and location, the name of the next available file, and so on.

　　2) Types of logging

　　a. Circular logging

　　Use circular logging if all you want is restart recovery, using the log to roll back transactions that were in progress when the system stopped.

　　b. Use linear logging if you want both restart recovery and media recovery (recreating lost or damaged data by replaying the contents of the log).

　　3) Using checkpointing to ensure complete recovery

　　A checkpoint is a point in time when the record described in the log is the same as the record in the queue.

　　WebSphere MQ generates checkpoints automatically. They are taken when the queue manager starts, at shutdown, when logging space is running low, and after every 10 000 operations logged.

　　4) Calculating the size of the log

　　The size of the log is determined by the following log configuration parameters:

　　LogFilePages The size of each primary and secondary log file in units of 4K pages

　　LogPrimaryFiles The number of preallocated primary log files

　　LogSecondaryFiles The number of secondary log files that can be created for use when the primary log files are full

　　when a persistent message is put to a queue, all the message data must be written to the log to make it possible to recover the message. The size of the log depends, typically, on the number and size of the persistent messages the queue manager needs to handle.

　　5) Managing logs

　　Of the log records, only those written since the start of the last complete checkpoint, and those written by any active transactions, are needed to restart the queue manager.

　　The following are methods for determining which log files are still required: Logger event messages, Queue manager status, Queue manager messages.

　　6) Using the log for recovery

　　WebSphere MQ helps you to recover from:

　　A damaged data object

　　A power loss in the system

　　A communications failure

　　i. Recovering damaged objects

　　a) Media recovery

　　Media images can be recorded manually, using the RCDMQIMG command, or automatically in some circumstances.

　　7) Backing up and restoring WebSphere MQ

　　There are two ways of protecting a queue manager:

　　Backup the queue manager data

　　Using a backup queue manager

　　i) Backing up queue manager data

　　1. Ensure that the queue manager is not running.

　　2. Find the directories under which the queue manager places its data and its log files, using the information in the configuration files.

　　3. Take copies of all the queue manager’s data and log file directories, including all subdirectories.

　　4. Preserve the ownerships of the files.

　　ii) Restoring queue manager data

　　To restore a backup of a queue manager’s data:

　　1. Ensure that the queue manager is not running.

　　2. Find the directories under which the queue manager places its data and its log files, using the information in the configuration files

　　3. Clear out the directories into which you are going to place the backed-up data.

　　4. Copy the backed-up queue manager data and log files into the correct places.

　　5. Update the configuration information files (or equivalent Registry entries on Windows).

　　iii) Using a backup queue manager

　　An existing queue manager can have a dedicated backup queue manager. A backup queue manager is an inactive copy of the existing queue manager.

　　a. Creating a backup queue manager

　　1. Create a backup queue manager for the existing queue manager using the control command crtmqm.

　　2. Take copies of all the existing queue manager’s data and log file directories, including all subdirectories

　　4. Execute the following control command on the backup queue manager: strmqm -r BackupQMName

　　b. Updating a backup queue manager

　　1. Copy all the log extents that have been completed since the last update from the existing queue manager log directory to the backup queue manager log directory.

　　2. Execute the following control command on the backup queue manager: strmqm -r BackupQMName

　　c. Starting a backup queue manager To substitute an unrecoverable queue manager with it’s backup queue manager, do the following:

　　1. Execute the following control command to activate the backup queue manager: strmqm -a BackupQMName

　　2. Execute the following control command to start the backup queue manager: strmqm BackupQMName

　　3. Restart all channels.

　　8) Dumping the contents of the log using the dmpmqlog command

　　Use the DMPMQLOG command to dump the contents of the queue manager log.

　　2. Problem determination

　　Tracing:

　　strmqtrc -x all -t comms

　　For example, to format all trace files in the current directory use the following command:

　　dspmqtrc *.TRC