Making SHRLEVEL CONCURRENT copies (Snapshot Copies)
If READONLY=DRAIN,
obtains the point of consistency by issuing a DRAIN before the copy starts. Otherwise,
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,
utilizes the page-caching mechanism provided by either of the following installed BMC products:
- For non-data-sharing environments:
- EXTENDED BUFFER MANAGER
- SNAPSHOT UPGRADE FEATURE
- For data sharing environments:
- EXTENDED BUFFER MANAGER
- SNAPSHOT UPGRADE FEATURE
- For hardware-assisted Snapshot Copies using the Storage Systems Integration (SSI) component of XBM, XBM 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
what action to take when a consistent point cannot be obtained or maintained. Use REQUIRED to tell
to terminate the copy in this situation; use PREFERRED (the default) to tell
to continue processing using SHRLEVEL CHANGE.
If the
connection to XBM fails before or during the copy, SHRLEVEL CONCURRENT PREFERRED usage causes
to continue processing as if SHRLEVEL CHANGE QUIESCE BEFORE were specified. But if it finds no updates after the quiesce,
will register a SHRLEVEL REFERENCE copy.
SHRLEVEL CONCURRENT copies are registered as SHRLEVEL REFERENCE copies if no caching errors are experienced. If caching issues 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. For information about XBMRSTRT, see BMC-AMI-Copy-installation-options-listing.
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. For more information, see GROUP.
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,
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
/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,
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,
uses LOCK TABLE to prevent updates.
When READONLY is set to DRAIN,
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. For more information, see DB2 authority.
- LOCKTBL cannot be used if the space or any of its partitions is in UT status or stopped.
uses -START RO in this case.
- LOCKTBL cannot be used on DSNDB06 or DSNDB01.
uses -START RO in this case.
- LOCKTBL cannot be used if the space is in COPY-pending status.
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.