Multiple job optimization

When BMC AMI Recovery Manager creates multiple jobs, it saves them in a single member of a partitioned data set or sequential file by default. You can optionally save them to separate members, which enables you to control job submission although it decreases the performance benefits (see Separating jobs from a multi-job batch job stream).

The number of jobs that are created is controlled by the following factors:

• The value that you provide at the Max concurrent jobs prompt in the subsystem or object set Recovery Options panel sets the maximum number of jobs that can run concurrently during the recovery of a given object set. BMC AMI Recovery Manager might use less than this number depending on other conditions.
• Object sets created using the ARMBGPS program are designed to have one recovery job per object set. ARMBGPS automatically sets the Max concurrent jobs option to 1 when the object sets are created.

• If a noticeable disparity exists among the sizes of objects in an object set, the number of jobs that BMC AMI Recovery Manager creates may be less than the specified maximum. This situation may occur when BMC AMI Recovery Manager finds that the job with the largest estimated execution time can no longer be split into multiple jobs. Estimated recovery time is relative to the objects in the object set and may be influenced by the following factors:
  • Number of pages to be restored from an image copy
  • Number of pages to be copied (after the recovery)
  • Amount of work space required for index unload or build
  • Amount of work space required to check data
  • Utilities used in the recovery

The exact formula is proprietary and was the result of extensive benchmark testing.

• If the object set includes objects that require a resource that cannot be shared, the objects will be recovered in the same job. Examples of such resources include tape volumes that contain stacked image copies, archive logs on tape, or change accumulation files on tape. In this situation, BMC AMI Recovery Manager may limit the number of jobs that it creates to less than the specified maximum. BMC AMI Recovery Manager uses the following configuration options to determine if resources are on tape:
  • Primary Arc on Tape
  • Alternate Arc on Tape
  • Change Accum on Tape

Important recommendations

This section describes the important recommendations regarding BMC AMI Recovery Manager.

Object set size: If possible, limit the size of these object sets to no more than a few hundred objects, both table spaces and indexes. One large object set requires more time for JCL generation than the time required for the same set of objects when divided into smaller object sets. Use ARMBGPS to split all objects in a subsystem into multiple object sets.

SYSCOPY search: If possible, limit the SYSCOPY search in the object set or subsystem options.

Using multiple job optimization with BMC AMI Recover

If you are recovering with the BMC AMI Recover product, the creation of multiple jobs for the recovery of an object set uses the UNLOADKEYS/BUILDINDEX strategy.

To take advantage of this strategy, the following criteria must be met:

• Image copies of the partitions must exist on separate tape volumes.
• You must select the objects by partition when you build the object set.
• You must use BMC AMI Recover as the recovery utility.
• You must select UNLOADKEYS/BUILDINDEX in the subsystem or on the Object Set Recovery Options panel.

Using multiple job optimization in offsite recovery

Using both the ARMBGEN batch JCL generation program and multiple job optimization, BMC AMI Recovery Manager can produce a complete set of JCL for the recovery of your application data at your recovery site.

This JCL can be designed and optimized to meet your specific recovery site needs. To take the fullest advantage of this capability, we recommend that you perform the following steps:

• Specify the RECOVER TORESTARTRBA syntax option when you code the JCL for the ARMBGEN batch program. When you specify this option, the system resource recovery program, ARMBSRR, provides the restart relative byte address (RBA) value to ARMBGEN to ensure that the recovery of your Db2 system objects and application objects at the recovery site are correctly synchronized.
• Create some object sets specifically for use in recovery site JCL generation. Place objects in these object set to reflect the sequence in which you want them to be recovered at the recovery site.

The following steps are an example of a procedure to follow for multiple job optimization:

To optimize multiple jobs

1. Create an object set called OFFSITE_PRIORITY_01 containing all of the objects (both table spaces and related indexes) that you want to have the highest priority for recovery at the recovery site. Then create another object set, OFFSITE_PRIORITY_02 for the next lower priority level, and so on.

   Tip

   If possible, limit the size of these object sets to no more than a few hundred objects. One large object set requires more time for JCL generation than is required for the same set of objects when divided into smaller object sets. Also, performing data set sizing separately and storing it in the repository can speed up JCL generation time. For more information, see Data set sizing. Also, if possible, limit the SYSCOPY search (for more information, see General-recovery-options).

2. Set the value of Max concurrent jobs (on the Recovery Options Specification panel) for these object sets to the number of initiators that will be available for Db2 recoveries at your recovery site.
3. Run the ARMBGEN program to create a fully optimized set of offsite recovery JCL for each of these object sets after you have run the ARMBSRR system resource recovery program.
4. Send the generated recovery JCL offsite along with the JCL that is created by the system resource recovery program, ARMBSRR.For more information about planning for offsite recovery, see Recovering-from-a-Db2-system-disaster.  

Optimized recovery job processing

BMC AMI Recovery Manager has the following paths for optimizing recovery for a set of jobs:

• For jobs generated online and by ARMBGEN for application data, BMC AMI Recovery Manager uses ARMBMJO (BMC-AMI-Recovery-Manager-batch-programs) and the JOB_RESTART table to control and restart failed jobs. For more information, see Restarting-jobs-that-recover-application-data.
• For ARMBSRR jobs for system resource recovery, BMC AMI Recovery Manager uses a synchronization file to restart failed jobs. For more information, see Restarting-system-resource-recovery-ARMBSRR-jobs.

With multiple job optimization, recovery JCL is placed in a single user-specified data set or member, unless you specifically separate the jobs into separate members (see Separating jobs from a multi-job batch job stream). The JCL consists of up to n jobs, where the variable n is the user-specified maximum plus two. In the example shown in the following figure, multiple jobs have been generated and executed as described in the following steps.

The sequence of events is as follows:

1. JOB0 performs the following tasks, and then submits the remainder of the jobs:
   • For jobs generated by ARMBSRR, allocate a job synchronization file.
   • For jobs generated online and by ARMBGEN, initializes the JOB_RESTART table.
2. JOB1 performs the following tasks:
3. For ARMBSRR jobs, the first JOB1 submits another JOB1 (a restart job), which will determine whether the set of jobs completes successfully. The first JOB1 then performs initial recovery steps.
4. For jobs generated online and by ARMBGEN, JOB1 runs concurrently with JOB2.
5. JOB2 through JOBn performs recovery tasks to ensure that these tasks are performed in the correct sequence.
6. For ARMBSRR jobs, the jobs are under the control of the job synchronization file.
7. For ARMBGEN jobs, the jobs are under the control of ARMBMJO and the JOB_RESTART table.
8. When the recovery jobs are completed, the following tasks are next:
9. For ARMBSRR jobs, the restart JOB1 determines whether the jobs have been completed successfully. If so, the synchronization file is deleted. If not, this job is used to restart the set of jobs.
10. For jobs generated online and by ARMBGEN, if any of the jobs failed, ARMBMJO uses the JOB_RESTART table to determine which jobs and steps to execute when you resubmit a set of jobs or a failed job. You can clear the JOB_RESTART table by running CLEAR_TABLE found in the ARMBMJO$ SAMPLIB.

For more information, see Restarting-a-recovery-for-a-set-of-concurrent-jobs.  

Separating jobs from a multi-job batch job stream

You can optionally generate certain types of multi-job batch JCL into separate members of a partitioned data set.

This option enables you to run the generated jobs separately instead of running in a single execution.

This feature is only valid for:

• Batch recovery job streams for which you have specified SYNC=NO and MAX_CONCURRENT_JOB greater than 1
• The ARMBGPS subsystem object set split batch job stream (which does not require synchronization steps)

This feature is incompatible with UNLOADKEYS_BUILDINDEX=YES, which requires synchronization steps. If you have specified UNLOADKEYS_BUILDINDEX=YES or SYNC=YES, BMC AMI Recovery Manager overrides the parameter and generates the jobs into a single member.

To save the jobs into separate members:

• (online) When generating batch jobs, specify Yes at the If output data set partitioned, one job per member (batch) field on the batch JCL generation panel
• (batch) code the MEMBER=YES parameter in the ARMBGNR execution statement. For example: