backing up, backing up page sets, point of recovery, creating, creating a point of, recovery, point of, AMS REPRO, backing up and recovering page sets, REPRO command of access method services, REPRO, access method services (AMS), AMS (access method services), copying with AMS REPRO statement, data set, active log, volume dump and restore, dump and restore, data sets, description, backing up definitions, objects" /> Create a point of recovery for non-shared resources

 

Creating a point of recovery for non-shared resources

WebSphere MQ can recover objects and non-shared persistent messages to their current state if both:

  1. Copies of page sets from an earlier point exist.

  2. All the WebSphere MQ logs are available to perform recovery from that point.

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), we 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:

Full backup

Stop the queue manager, thereby forcing all updates on to the page sets.

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.

Fuzzy backup

Take fuzzy backup copies of the page sets without stopping the queue manager.

If you use this method, and your associated logs subsequently become damaged or lost, we 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, we 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.

 

Method 1: Full backup

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.

  1. Stop all the WebSphere MQ applications that are using the queue manager (allowing them to complete first). This can be done by changing the access security or queue settings, for example.

  2. When all activity has completed, display and resolve any in-doubt units of recovery. (Use the commands DISPLAY CONN and RESOLVE INDOUBT, as described in the WebSphere MQ Script (MQSC) Command Reference manual.)

    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.

  3. Issue the ARCHIVE LOG command to ensure that the latest log data is written out to the log data sets.

  4. Issue the STOP QMGR MODE(QUIESCE) command. Record the lowest RBA value in the CSQI024I or CSQI025I messages (see WebSphere MQ for z/OS Messages and Codes for more information). You should keep the log data sets starting from the one indicated by the RBA value up to the current log data set.

  5. Take backup copies of all the queue manager page sets (see Backing up page sets).

 

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

  1. Issue the DISPLAY USAGE TYPE(ALL) command, and record the RBA value in the CSQI024I or CSQI025I messages (see WebSphere MQ for z/OS Messages and Codes for more information).

  2. Take backup copies of the page sets (see Backing up page sets).

  3. Issue the ARCHIVE LOG command, to ensure that the latest log data is written out to the log data sets. To restart from the point of recovery, keep the log data sets starting from the log data set indicated by the RBA value up to the current log data set.

 

Backing up page sets

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

Using Access Method Services

We can use Access Method Services REPRO function (or any equivalent) to make copies of your page sets. We 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 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, we 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 Access Method Services for VSAM or the DFSMS/MVS Access Method Services for the Integrated Catalog Facility manual.

Using volume dump and restore

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.

 

Backing up your object definitions

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.