What happens during restart and recovery
WebSphere MQ uses its recovery log and the bootstrap data set (BSDS) to determine
what to recover when it restarts. The BSDS identifies the active and archive
log data sets, and the location of the most recent WebSphere MQ checkpoint in the
log.
After WebSphere MQ has been initialized, the queue manager restart process takes
place as follows:
- Log initialization
- Current status rebuild
- Forward log recovery
- Backward log recovery
- Queue index rebuilding
When recovery has been completed:
- Committed changes are reflected in the data.
- In-doubt activity is reflected in the data. However, the data is locked
and cannot be used until WebSphere MQ recognizes and acts on the in-doubt decision.
- Interrupted in-flight and in-abort changes have been removed from the
queues. The messages are consistent and can be used.
- A new checkpoint has been taken.
- New indexes have been built for indexed queues containing persistent messages
(described in Rebuilding queue indexes).
Batch applications are not notified when restart occurs after the application has requested a connection.
If dual BSDSs are in use, WebSphere MQ checks the consistency of the time stamps
in the BSDS:
- If both copies of the BSDS are current, WebSphere MQ tests whether the two time
stamps are equal. If they are not, WebSphere MQ issues message CSQJ120E and terminates.
This can happen when the two copies of the BSDS are maintained on separate
DASD volumes and one of the volumes was restored while the queue manager was
stopped. WebSphere MQ detects the situation at restart.
- If one copy of the BSDS was de-allocated, and logging continued with a
single BSDS, a problem could arise. If both copies of the BSDS are maintained
on a single volume, and the volume was restored, or if both BSDS copies were
restored separately, WebSphere MQ might not detect the restoration. In that case,
log records not noted in the BSDS would be unknown to the system.