Reduced elapsed time required to recover

BMC AMI Recover offers several features that reduce the elapsed time that is required for recovery. For example, BMC AMI Recover can invoke a MERGE routine that concurrently uses a full image copy, incremental copies, a change accumulation file, and sorted log to efficiently re-create a current table space image. Then, the MERGE routine unloads index keys for a rebuild. The MERGE concept is exclusive to BMC AMI Recover and eliminates the need to read the table space page multiple times.

To further enhance the MERGE concept, BMC AMI Recover can run multiple log sorts and parallel MERGE phases in subtasks. You use the MAXLSORT option in the installation options or on the OPTIONS command to specify the maximum number of log sorts that can run concurrently. MAXLSORT also determines the number of MERGE/RESTORE/SNAP phases that can run in parallel, whether or not log records are processed.

BMC AMI Recover can perform multitasking index rebuilds in which multiple index key sorts and multiple index rebuilds are executed in parallel subtasks. You can define the level of concurrency to improve recovery performance by using the MAXKSORT option in the installation options or on the OPTIONS command. BMC AMI Recover can extract keys from partitions in parallel if the partitions are not being recovered. You can also use the KSORTSHARE option, available as an installation option or on the OPTIONS command, to improve index recovery. KSORTSHARE specifies if key sorts are shared among BMC AMI Recover table space recoveries (MERGE phases) running in parallel.

BMC AMI Recover can use the RECOVER UNLOADKEYS and RECOVER BUILDINDEX commands to rebuild a nonpartitioned index in a two-step process. RECOVER UNLOADKEYS can run in several jobs to extract and sort the keys greatly reducing overall elapsed time, work data set requirements, or both. RECOVER BUILDINDEX uses the keys from RECOVER UNLOADKEYS to build the index.

BMC AMI Recover considers all requests in the SYSIN data set and uses the most efficient technique for recovering all specified objects. This optimization process allows BMC AMI Recover to achieve efficiencies such as extracting keys while a table space is written, detecting stacked tape inputs, and automatically using the inputs in order.

BMC AMI Recover can use copies and log records to recover indexes, avoiding costly key sorts. Indexes can also be recovered with log only after being restored outside of Db2.

By using the BACKOUT option, BMC AMI Recover can recover to a point in time without image copies by using the table spaces, index spaces, and log records to return to a prior state. This process reduces resource consumption in several ways:

  • Only the log between the point in time specified and the current log point is read and processed, which may substantially reduce log processing.

  • In addition, the spaces are read for log backout processing, and image copy processing is completely eliminated.

  • If indexes are not rebuilt and output image copies are not requested, only the pages that are updated by log records are read and written, which can greatly reduce I/Os and speed up the recovery.

BMC AMI Recover can recover by using Instant Snapshot copies, which are data set level copies made by the BMC AMI Copy for Db2  product with the Snapshot Upgrade Facility for Db2 (SUF, also known as XBM) product. Instant Snapshots are non-standard, point-in-time copies that are made on intelligent storage devices.

When you use BMC AMI Recover as part of the Recovery Management for Db2 solution, BMC AMI Recover can recover Db2 table spaces and indexes to any point in time and resolve inflight transactions at that point.

Related topic


Was this page helpful? Yes No Submitting... Thank you

Comments