LOGSORT strategy

BMC AMI Recover examines the pertinent log ranges and extracts the appropriate log records from the Db2 active and archive logs. BMC AMI Recover then passes these log records to BMCSORT, where they are sorted by object, page number, and log point.

Sorting the log allows the objects to be processed sequentially, which is more efficient than accessing them randomly as in a conventional log apply process. Using the LOGSORT/MERGE strategy can reduce the I/O required by performing the following tasks:

• Combining the MERGE and LOG APPLY phases
• Ensuring that each page is accessed only once

Sorting the log enables you to read multiple log files in parallel, which can reduce the elapsed time necessary to read all of the log records for the run.

Why is it faster to sort the log?

Sorting the log records in page number order allows BMC AMI Recover to invoke a merge process that takes a full copy, any number of incremental copies, an input change accumulation file, and the sorted log as input and merges them into a recovered space image.

In data processing terms, this process is analogous to a classic master file update. The full copy is similar to the master file because it was the exact image of the table space at some point in time (this is not strictly true for SHRLEVEL CHANGE copies, which are discussed later). The incremental copies (limited by MAXDRIVES, see MAXDRIVES-integer), change accumulation files, and log records are like update files containing transactions to be applied to the master file.

The merge process simply applies the changes to the full copy to produce an updated image. This strategy is much faster than the conventional strategy, which first writes a space to the merged image of the full copy and incremental copies, and applies the unsorted log record updates to the space (a random read-write operation). Many conventional recoveries have long log apply phases.

Because the inputs are in page order for the LOGSORT/MERGE strategy, BMC AMI Recover can create the final version of the page in memory and write the table space once as a sequential write operation. Sequential write processes, when appropriately blocked, buffered, and scheduled, are much faster than random write processes.

When indexes are recovered by using copies and log records, they are handled in the same way as table spaces and can benefit from the LOGSORT/MERGE strategy.

What are the restrictions when using LOGSORT?

Merges that fail cause LOG INPUT to be repeated on restart for log records of the failed merges.

Failure of an image copy that is detected during merge may cause a merge to require additional log records. When additional log records are required, the job must be restarted to complete failed merges. 

Does LOGSORT have other advantages or disadvantages?

The LOGSORT strategy can provide other advantages, as follows:

• If keys are being extracted in a table space recovery because of either a REBUILD INDEX or RECOVER UNLOADKEYS request for an index on a table in the table space, BMC AMI Recover can extract these keys during the merge process of a LOGSORT strategy. In some cases, the keys are sent directly to a sort at this point by using the NOWORKDDN option (see NOWORKDDN-strategy), or the keys are written to the temporary data set specified by the WORKDDN parameter, usually SYSUT1 for REBUILD INDEX, or the SKEYDDN parameter for RECOVER UNLOADKEYS, depending on how you have set your index sort option. By extracting the keys during the merge process, BMC AMI Recover avoids rereading the table space to rebuild the index, as is the case in the conventional strategy. This strategy can save elapsed time.
• Because BMC AMI Recover sees each page in its final form and writes the object sequentially, very little overhead is incurred by simultaneously making image copies. Therefore, with the LOGSORT strategy, BMC AMI Recover can optionally make and register (in SYSIBM.SYSCOPY) up to four copies of a recovered table space.
• The LOGSORT strategy allows the use of input change accumulation files and the simultaneous processing of a RECOVER command statement and an ACCUM command statement for the same object. (For more information about ACCUM, seeR+/CHANGE ACCUM documentation.)
• The LOGSORT strategy allows the use of BACKOUT for point-in-time recovery. This strategy can be considerably faster than when copies are used. (For more information, see Strategies-for-point-in-time-recovery.)
• The LOGSORT strategy allows BMC AMI Recover to read multiple log files concurrently, which may significantly improve elapsed time. (For more information, see Reading-multiple-log-files-concurrently.)

The LOGSORT strategy can provide disadvantages, as follows:

• The potential disadvantage of using the LOGSORT strategy is that it may require additional resources if there are a significant number of log records to sort. This situation can be alleviated by the periodic running of jobs to build change accumulation files by using R+/CHANGE ACCUM. For more information about change accumulation files, see R+/CHANGE ACCUM documentation.

• BMC AMI Recover invokes BMCSORT. The amount and type of resources required for the sort depend on the number of log records to be sorted.

  If you are reading many log files concurrently, the memory usage of the run will increase. Approximately two megabytes of memory (in the extended, private area above the 16-MB line) will be used for each log file that is read concurrently.

  You can control the number of log files read concurrently with the MAXLOGS option. For more information about the additional resources that may be required for the LOGSORT strategy, see Log sort space requirements, Sort-performance, and SMCORE option.