WebSphere MQ can recover objects and non-shared persistent messages to their current state if both:
These represent a point of recovery for non-shared resources.
Both objects and messages are held on page sets. Multiple objects and messages from different queues can exist on the same page set. For recovery purposes, objects and messages cannot be backed up in isolation, so a page set must be backed up as a whole to ensure the proper recovery of the data.
The WebSphere MQ recovery log contains a record of all persistent messages and changes made to objects. If WebSphere MQ fails (for example, due to an I/O error on a page set), you can recover the page set by restoring the backup copy and restarting the queue manager. WebSphere MQ applies the log changes to the page set from the point of the backup copy.
There are two ways of creating a point of recovery:
This allows you to restart from the point of recovery, using only the backed up page set data sets and the logs from that point on.
If you use this method, and your associated logs subsequently become damaged or lost, you cannot to use the fuzzy page set backup copies to recover. This is because the fuzzy page set backup copies contain an inconsistent view of the state of the queue manager and are dependent on the logs being available. If the logs are not available, you need to return to the last set of backup page set copies taken while the subsystem was inactive (Method 1 below) and accept the loss of data from that time.
This method involves shutting the queue manager down. This forces all updates on to the page sets so that the page sets are in a consistent state.
This brings the page sets to a consistent state; if you do not do this, your page sets might not be consistent, and you are effectively doing a fuzzy backup.
This method does not involve shutting the queue manager down. Therefore, updates might be in virtual storage buffers during the backup process. This means that the page sets are not in a consistent state, and can only be used for recovery in conjunction with the logs.
You can take a backup of your page sets in two ways:
To recover a page set, WebSphere MQ needs to know how far back in the log to go. WebSphere MQ maintains a log RBA number in page zero of each page set, called the recovery log sequence number (LSN). This number is the starting RBA in the log from which WebSphere MQ can recover the page set. When you back up a page set, this number is also copied.
If the copy is later used to recover the page set, WebSphere MQ must have access to all the log records from this RBA value to the current RBA. That means you must keep enough of the log records to enable WebSphere MQ to recover from the oldest backup copy of a page set you intend to keep.
You can use Access Method Services REPRO function (or any equivalent) to make copies of your page sets. You can do this whether or not the queue manager is running. If you want to do it while the queue manager is running, you must DEFINE the page sets with SHAREOPTIONS(2,3).
If you copy the page set while the queue manager is running you must use a copy utility that copies page zero of the page set first - if you do not do this you could corrupt the data in your page set. Access Method Services REPRO meets this requirement.
If the process of dynamically expanding a page set is interrupted, for example by power to the system being lost, you can still use Access Method Services REPRO to take a backup of a page set.
If you perform an Access Method Services IDCAMS LISTCAT ENT('page set data set name') ALLOC, you will see that the HI-ALLOC-RBA is higher than the HI-USED-RBA. Access Method Services REPRO just copies the page set up to the high used RBA, and does not give an error.
The next time this page set fills up it is extended again, if possible, and the pages between the high used RBA and the highest allocated RBA are used, along with another new extent.
For more information on the REPRO statement, see the DFSMS/MVS(R) Access Method Services for VSAM or the DFSMS/MVS Access Method Services for the Integrated Catalog Facility manual.
Volume dump services dumps all the data sets on the volume. Likewise, restore volume services can (depending on the type of service) restore all the data sets.
You should also back up copies of your object definitions. To do this, use the MAKEDEF feature of the CSQUTIL COMMAND function (described in Issuing commands to WebSphere MQ (COMMAND)).
Back up your object definitions whenever you take a backup copy of your queue manager, and keep the most current version.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csq849n |