Enabling multitasking for performance in REORG PLUS

Although REORG PLUS runs very efficiently on single-processor computers, it performs most efficiently on large multiprocessor systems. REORG PLUS considers the following factors when it determines the maximum number of tasks to start:

• Available memory above and below the 16-MB line
• Number of SYSREC and SYSUT1 data sets that you specify
• Governing limitations that you specify through the multitasking options
• Number and size of the preallocated sort work data sets
• Number of Db2 objects on which REORG PLUS must operate for each phase or process 

Multitasking installation options

The following table lists the REORG PLUS installation options that allow you to control the level of multitasking for various phases of the reorganization and for processes within those phases:

The following table lists the valid values for all of the other multitasking options:

For example, assume that you have three CPUs and you specify TASKMAX=5, ANALMAX=*, and RORGMAX=*. REORG PLUS starts up to five tasks for the ANALYZE phase and five for the REORG phase. If you change the TASKMAX value to 500%, REORG PLUS can start as many as 15 tasks for each of those phases. The more tasks that REORG PLUS can start, the better performance it will achieve.

RORGMAX, UNLDMAX, and BILDMAX are enabled only when all of the following conditions exist:

• The value of the SMAX installation option is 0.
• You have not specified the MAXSORTS command option or its value is 0.

The following table provides examples of the option combinations. For more information about specifying the RORGMAX, UNLDMAX, and BILDMAX options, see Multitasking processes that invoke BMCSORT.

REORG PLUS always uses the ANALMAX, COPYMAX, SCPYMAX, and RENMMAX multitasking options. For information about determining the values for ANALMAX, COPYMAX, and SCPYMAX, see Multitasking I/O bound processes. 

Multitasking I/O bound processes

The following multitasked processes are I/O bound:

• ANALYZE phase
• Table space copy process
• Nonpartitioned index copy process for SHRLEVEL REFERENCE and SHRLEVEL CHANGE partial reorganizations that are not using Instant Snapshot technology

You can control the multitasking for these processes with the ANALMAX, COPYMAX, and SCPYMAX installation options, respectively. Because these processes are I/O bound, the number of tasks does not need to be limited to the number of CPUs. In fact, in many cases, the processes are so I/O bound that they require hardly any CPU service at all. Therefore, you can start many more tasks for these operations than the number of CPUs without adversely affecting performance.

By specifying a percentage rather than a fixed maximum number of tasks, you might get similar performance improvements regardless of the number of CPUs on which REORG PLUS is running. REORG PLUS never starts more tasks than it can effectively use. So, for example, you will see a larger number of tasks for a partitioned table space with 254 partitions than for a simple table space with no indexes. 

Multitasking processes that invoke BMCSORT

In addition to the processes mentioned in Multitasking I/O bound processes, the following processes are also typically I/O bound:

• Single-phase REORG phase
• Two-phase UNLOAD phase
• The index build process

You can control the multitasking for these processes with the RORGMAX, UNLDMAX, and BILDMAX installation options, respectively. However, for certain architectural considerations, REORG PLUS starts a maximum of 16 tasks for the REORG phase, UNLOAD phase even if you specify a value greater than 16 on the RORGMAX, UNLDMAX, or BILDMAX option.

To achieve the most flexibility and highest level of multitasking, observe the following guidelines:

• Do not include any SORTWKnn DD statements in your JCL.
• Specify the following:
  • DDTYPE SORTWORK ACTIVE NO on your REORG command, or disable dynamic allocation for the SORTWKnn DDs in your options module
  • The SORTDEVT installation or command option
  • One SYSRECnn DD per partition
  • One SYSUT1nn DD per index
  • SORTNUM 32

For more information about setting the environment for BMCSORT, see Performance-considerations-for-sort-processing-options.

Using multiple SYSREC data sets

When you are reorganizing a partitioned table space, you can improve performance by specifying one SYSRECnn data set for each partition. Using multiple data sets accomplishes the following goals:

• Reduces CPU and elapsed time

  REORG PLUS can concurrently unload the table space information from each partition during unload processing.

• Facilitates faster reloading of the table space that you are reorganizing

For more information about specifying multiple SYSRECnn data sets, see SYSREC data set.

Using multiple SYSUT1 data sets

Using multiple SYSUT1 data sets provides the following performance advantages:

• I/O processing to each SYSUT1 data set is overlapped with other I/O processing and with CPU processing.
• REORG PLUS writes any non-unique index information when the index process receives it and does not pass the information to BMCSORT, thus reducing the amount of data that is sorted. This process also reduces the amount of DASD space that is required for all index information.
• With a single SYSUT1 data set, REORG PLUS pads all keys to the length of the longest key being processed. Padded keys require more DASD space, and more I/O operations are required to process the index information. With multiple SYSUT1 data sets, less padding of keys is needed.
• REORG PLUS attempts to build indexes concurrently. REORG PLUS determines resource utilization in the same way as for the UNLOAD phase with one exception: instead of checking the number of partitions in the table space, REORG PLUS checks the number of data sets that you specified. The index build phase always runs concurrently with reloading the rows into the table space.

If you are using multiple index data sets, specify one SYSUT1 data set for each participating index.

When you specify multiple SYSUT1 data sets, the DD statement specification is SYSUT1nn, where nn is a unique suffix for each DD statement. The suffix is not used to identify which index is assigned to a specific SYSUT1 data set.