Making SHRLEVEL CONCURRENT copies (Snapshot Copies)

Specifying SHRLEVEL CONCURRENT to make image copies of a group of Db2 spaces allows all of the spaces in the group to be copied at the same point of consistency while updates are in progress. Making copies of groups at the same consistent point provides you with the ability to recover those spaces to the same, consistent point in time should a recovery of that group become necessary.

If READONLY=DRAIN, BMC AMI Copy obtains the point of consistency by issuing a DRAIN before the copy starts . Otherwise, BMC AMI Copy obtains this point of consistency by issuing a QUIESCE before the copy starts (see Db2-commands-issued-by-BMC-AMI-Copy-for-read-and-write-databases.)

When making such consistent (Snapshot) copies using SHRLEVEL CONCURRENT, BMC AMI Copy utilizes the page-caching mechanism provided by either of the following installed BMC products:

• For non-data-sharing environments:
  • EXTENDED BUFFER MANAGER version 1.2.01 (or later)
  • SNAPSHOT UPGRADE FEATURE version 2.0.02 (or later)
• For data sharing environments:
  • EXTENDED BUFFER MANAGER version 4 (or later)
  • SNAPSHOT UPGRADE FEATURE version 4 (or later)
• For hardware-assisted Snapshot Copies using the Storage Systems Integration (SSI) component of XBM, XBM version 4.2 or later is required.

You must also create the appropriate management set and configuration for the Snapshot feature and have the appropriate authorizations. For more information, see the  SNAPSHOT UPGRADE FEATURE for DB2 documentation.

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.

If the BMC AMI Copy connection to XBM fails before or during the copy, SHRLEVEL CONCURRENT PREFERRED usage causes BMC AMI Copy to continue processing as if SHRLEVEL CHANGE QUIESCE BEFORE were specified. But if it finds no updates after the quiesce, BMC AMI Copy will register a SHRLEVEL REFERENCE copy.

SHRLEVEL CONCURRENT copies are registered 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 use the XBMRSTRT installation option or the XBMRSTRT keyword on the OPTIONS command in conjunction with SHRLEVEL CONCURRENT to determine how Snapshot Copies are restarted. For restartable Snapshot Copies, you must be using XBM version 3.0 or later. See BMC-AMI-Copy-installation-options-listing for information about XBMRSTRT.

You can use the keyword GROUP in conjunction with SHRLEVEL CONCURRENT to control whether the specified spaces should share a common consistent point. GROUP YES indicates sharing should take place and all spaces will be cached when the job starts. GROUP NO indicates that the spaces should be processed individually and caching for the space will start just ahead of the copy. See GROUP for more information.

When working with a migrated or archived data set, XBM or the SNAPSHOT UPGRADE FEATURE fails with a registration error (RC=12 and reason=1200). However, BMC AMI Copy checks for this failure, recalls the data set, and runs XBM or SUF again.

To prevent the generation of errors due to attempts to update the spaces while the connection to the page caching mechanism 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 BMC AMI Copy/Snapshot initialization is complete.

Alternatively, you can have your update program handle the condition. If neither of these approaches is possible, you can alleviate the situation by using the installation option READONLY that determines how attempts to update the space or partition are treated during this initialization phase.

When READONLY is set to STARTRO, BMC AMI Copy issues the -START RO command while initializing the connection to the page-caching mechanism (provided by the Snapshot feature) to prevent updates while initialization is in progress.

When READONLY is set to LOCKTBL, BMC AMI Copy uses LOCK TABLE to prevent updates. 

When READONLY is set to DRAIN, BMC AMI Copy uses DRAIN to prevent updates .

READONLY=STARTRO

The impact of using each value of READONLY=STARTRO, is as follows:

• STARTRO requires no Db2 catalog lookup and is therefore faster.
• STARTRO allows operation at the partition level.
• Update programs receive SQLCODE -904 if the program attempts an update while the space is in RO status.
• STARTRO on an index space and QUIESCE on its table space is used to establish consistency during initialization. 

READONLY=LOCKTBL

The impact of using each value of READONLY=LOCKTBL, is as follows:

• LOCKTBL requires Db2 catalog lookup.
• LOCKTBL locks the entire space, not just a partition.
• Update attempts might result in an SQLCODE -911.
• You must be authorized to use LOCK TABLE. See DB2 authority for more information.
• LOCKTBL cannot be used if the space or any of its partitions is in UT status or stopped. BMC AMI Copy uses -START RO in this case.
• LOCKTBL cannot be used on DSNDB06 or DSNDB01. BMC AMI Copy uses -START RO in this case.
• LOCKTBL cannot be used if the space is in COPY-pending status. BMC AMI Copy uses -START RO in this case.
• For index copies, the table on which the index is defined is locked using SQL LOCK TABLE.

READONLY=DRAIN

The impact of using each value of READONLY=DRAIN is as follows:

• Application impact is minimized because you can specify DRAINWAIT to be less than the lock timeout.
• Operation is allowed at the partition level.
• Update attempts should not fail if DRAINWAIT is set correctly.

For more information, see DRAINDELAY and DRAINRETRY options for READONLY.