Available copy techniques

• Whether you make a full image copy or an incremental image copy
• Which technique you use to make incremental copies
• Whether you use the standard Snapshot Copy feature
• Whether you use the Instant Snapshot capability

Full image copy versus incremental image copy

If only a few pages have changed, an incremental image copy runs much faster than a full image copy.

However, the runtime of an incremental copy using random I/O increases as the percentage of changed pages increases. Even when a small number of rows change, this might change a substantial percentage of pages, since there are typically many rows per page. For example, in one case, only 2 percent of the rows changed, but these rows were located across 33 percent of the pages. Under these circumstances, a full image copy runs almost as fast as an incremental image copy, and running a full copy might be the better choice because the BMC AMI Recover (or the IBM Db2 RECOVER) utility might run faster.

Full image copies use sequential I/O and read and write many pages at a time. Incremental image copies that use random I/O can incur significant overhead reading the Db2 table space because of rotational delays and seeks. However, using the BMC AMI Copy READTYPE FULLSCAN option for your incremental copies ensures that those copies will never run longer than a full copy.

The following figure shows a typical comparison of the impact of using various incremental copy and full copy techniques on elapsed time for a range of changed page percentages.

Comparison of performance for different copy types

Incremental copy techniques

When you anticipate a large or variable amount of updates to a table space occurring between full copies, using the FULL AUTO or CHANGELIMIT syntax option allows you to specify that a request for an incremental copy be escalated to a full copy request when the number of changed pages reaches a specified percentage.

For more information, see Escalating-incremental-copies-to-full-copies.

To give you a measure of control over the process when making incremental copies, BMC AMI Copy now provides the READTYPE option which allows you to specify sequential I/O or random I/O or to specify that BMC AMI Copy make the decision. This technique is very useful when you cannot tolerate putting the table space in STOP status when making a full copy. We recommend READTYPE FULLSCAN for making incremental copies where the full copy was made using RESETMOD NO. This ensures that your incremental copies will never run longer than a full copy (which can happen when using random I/O to locate changed pages). For more information, see Optimizing-the-elapsed-time-for-an-incremental-copy.

To reduce media usage when using incremental copies, you can make merged incremental copies using the CUMULATIVE YES option. This technique requires only the most recent full copy and the last incremental copy for recovery.

Snapshot Copies

You can use the Snapshot feature to make image copies of a group of Db2 table spaces to the same point of consistency while updates are in progress.

This provides you with the ability to recover those spaces to the same, consistent point in time should a recovery of that group become necessary.

To make the Snapshot feature available, you must have either XBM version 1.2.01 (or later) or the SNAPSHOT UPGRADE FEATURE (SUF) version 2.2.02 (or later) installed. After installation, you must create the appropriate management set and configuration for the SNAPSHOT UPGRADE FEATURE and have the appropriate authorizations. See the SNAPSHOT UPGRADE FEATURE for DB2 documentation for management set and authorization information.

You must code SHRLEVEL CONCURRENT and RESETMOD NO in your BMC AMI Copy syntax to make Snapshot Copies. You can use the keyword REQUIRED or PREFERRED after SHRLEVEL CONCURRENT to tell BMC AMI Copy what action to take when a consistent point cannot be obtained or maintained. Use REQUIRED to tell BMC AMI Copy to terminate the copy in this situation; use PREFERRED (the default) to tell BMC AMI Copy to continue processing using SHRLEVEL CHANGE.

SHRLEVEL CONCURRENT copies are registered in SYSIBM.SYSCOPY as SHRLEVEL REFERENCE copies if no caching errors are experienced. If caching problems occur but the copy is otherwise successful and PREFERRED was specified, then the copy is registered as a SHRLEVEL CHANGE copy.

You can also use the keyword GROUP in conjunction with SHRLEVEL CONCURRENT to control whether the specified table spaces should share a common consistent point. GROUP YES indicates a common quiesce should take place; GROUP NO indicates that the spaces should be processed individually. For more information, see GROUP.

To prevent the generation of errors due to attempts to update the spaces while the connection to the Snapshot Feature is being established, start your copies before starting an update cycle. To determine when to start the update cycle, you can use the keyword STARTMSG to write a text message of your choice to the JES job log when the connection is complete. See BMC-AMI-Copy-and-Snapshot-initialization-READONLY for more discussion about initialization.

Also, see Making-SHRLEVEL-CONCURRENT-copies-Snapshot-Copies for more information.  

Instant Snapshots

You can use the Instant Snapshot feature to make copies at a data set level using intelligent storage systems.

Instant Snapshots do not require the I/O of standard image copies. Registration of Instant Snapshots is handled in the BMCXCOPY table. Therefore, Instant Snapshots cannot be used for recovery by IBM Db2 RECOVER. However, BMC AMI Recover and BMC AMI Recovery Manager can use them for recovery. Instant Snapshots provide you with the ability to make fast backup copies of your data.

Making and restoring Instant Snapshots uses significantly less CPU time than standard copies. The use of Instant Snapshots reduces the elapsed time for copying and restoring most table spaces and indexes. The time to perform the Instant Snapshot varies according to the hardware implementation but 2 to 10 seconds per data set is typical. Also, depending on the hardware, Instant Snapshots can utilize significantly less DASD than a standard full image copy.

To make the Instant Snapshot feature available, you must have SUF or XBM version 4.4.01 or later installed. After installation, you must create the appropriate management set and configuration for XBM and have the appropriate authorizations. See SNAPSHOT UPGRADE FEATURE for DB2 documentation for more information.

You must code DSSNAP YES or DSSNAP AUTO on the OUTPUT command to make Instant Snapshots. Instant Snapshots require the use of dynamic allocation and output copies to DASD. You can use any valid value of SHRLEVEL on the COPY command. See Command-option-restrictions-for-Instant-Snapshots for more information.

You can also make standard copies from Instant Snapshots using the COPY IMAGECOPY command.

Also, see Making-Instant-Snapshot-copies for detailed information.

Instant Snapshots and standard copies in the same job

By using the DSSNAP AUTO or DSSNAP YES (Instant Snapshots) options with the FULL AUTO or CHANGELIMIT options, you can copy a set of spaces using wild card selection and control when to make standard copies and when to make Instant Snapshot copies.

When you use this copy technique, you realize:

• A speed increase by using Instant Snapshots for the large data sets
• The efficiency of copying the small table spaces and indexes to disk or tape by using standard copy procedures

You can request both types of copies in one job by specifying:

• In the COPY command, the BIGDDN option that references an OUTPUT descriptor that includes DSSNAP YES or DSSNAP AUTO
• In the OPTIONS command, an OUTSIZE threshold to control when BIGDDN should be selected

Doing this allows BMC AMI Copy to automatically select an Instant Snapshot copy for larger spaces that exceed the OUTSIZE threshold, and create standard copies for spaces smaller than OUTSIZE.

Consider this example from the perspective of time required to make the image copies. Assume there are 474 copies made from 3852 partitions. Of those partitions, 13 of them have more than 7200 pages. You can copy the small spaces the conventional way and the large spaces (greater than 7200 pages) with Instant Snapshots. Making the assumption that a typical copy of a small space takes one second and an Instant Snapshot takes three seconds for any size space, the time to make the copies is:

Compare this to the total time needed to make all copies as Instant Snapshots (474 x 3 = 1,422 seconds or 23 minutes 42 seconds) and you see the value of making standard copies and Instant Snapshots as shown in the example SYSIN.