FlashCopy image copies

Operational restrictions for FlashCopy

A data-set-level FlashCopy has certain operational restrictions that can cause a utility to resort to traditional I/O methods to complete a copy operation. This behavior can occur even when you explicitly request FlashCopy support in either the subsystem parameter or the utility control statement. In some cases, the utility aborts the copy operation.

The circumstances in which the utilities might not be able to complete a copy operation by using FlashCopy include the following situations. In these situations, the term data set refers to a DB2® table space or index space or a FlashCopy image copy:

• FlashCopy Version 2 disk volumes are not available.
• The source data set is already the target of a FlashCopy relationship.
• The target data set is already the source of a FlashCopy relationship.
• The source data set is already participating in the maximum number of FlashCopy relationships.
• The CISIZE, CASIZE, physical record size, or physical block size of the target data set is different from that of the source data set. The CASIZE of the target data set can be different from the source data set if the source data set is less than one cylinder.
• The source data set and the target data set are not both fully contained on the same physical control unit (controller).
  Recommendation: Use the storage class attribute ACCESSIBILITY=REQUIRED or ACCESSIBILITY=PREFERRED for the source data set and for the target data set. If the storage class that is associated with a data set has this attribute, DFSMS attempts to select volumes such that the data set is contained on volumes within a single physical control unit.
• Either the source data set or the target data set is not SMS-managed.

For more information about FlashCopy restrictions, see Moving Data Sets with FlashCopy.

If FlashCopy cannot be used, the utility completes the copy operation by using traditional I/O methods to copy the object, which can result in longer than expected execution time.

Only one utility can create a FlashCopy image copy of an object at one time. For example, suppose that the COPY utility with the SHRLEVEL CHANGE and FLASHCOPY options is running on an object. Then, the LOAD utility with the SHRLEVEL CHANGE and FLASHCOPY options starts running on the same object. The LOAD utility receives message DSNU180I with a return code of 8 to indicate that the LOAD utility is not compatible with the COPY utility.

Specification of the FlashCopy option

For utilities that support the creation of FlashCopy image copies, you can specify the FlashCopy option by using DB2 subsystem parameters, utility control statement parameters, or both.

You can use the FlashCopy subsystem parameters to define the FlashCopy option as the default behavior for each of the utilities that support the FlashCopy option. When the FlashCopy subsystem parameters are enabled as the default behavior, you do not need to specify the FlashCopy options in the utility control statement.

If you specify the FlashCopy options in both the subsystem parameters and the utility control statement parameters, the specifications in the utility control statement override the specifications of the subsystem parameters.

Image copy consistency with FlashCopy

The support for FlashCopy provided by the COPY and LOAD utilities includes an option that can make an image copy consistent for recovery purposes.

When you specify the SHRLEVEL CHANGE and FLASHCOPY CONSISTENT options, the utility does some extra checking after the FlashCopy image copy is created. The utility checks the logs for changes to the copied data that were uncommitted at the time that the image copy was created. Any uncommitted data that is identified in the logs is backed out of the image copy before the utility terminates.

DB2 shadow processing is used to make the FlashCopy image copy consistent. The FlashCopy image copy data set is used as the shadow. Other utilities that use DB2 shadow processing use a different naming convention.

The process of creating an image copy by specifying FLASHCOPY CONSISTENT uses more system resources and takes longer than creating an image copy by specifying FLASHCOPY YES. The reason is that backing out uncommitted work requires reading the logs and updating the image copy.

SYSCOPY records for FlashCopy image copies

For each FlashCopy image copy, DB2 creates one or more records in the SYSIBM.SYSCOPY table. SYSCOPY records for FlashCopy image copies can differ slightly from the SYSCOPY records for sequential format image copies depending on the following factors:

• Whether the object that is being copied is partitioned
• The number of partitions or object pieces that are being copied

For a FlashCopy image copy of a single partition or piece of an object, one SYSCOPY record is created for the partition or piece.

For a FlashCopy image copy of a table space or index space:

• If a table space contains more than one partition or piece, DB2 creates a separate SYSCOPY record for each of the following items:
  • The table space or index space
  • Each partition or piece in the table space or index space
  In the DSNUM column of the SYSCOPY record, DB2 assigns a data set number to the table space or index space and to each partition or piece. The data set numbers start at 0 for the table space or index space and are incremented by 1 for each partition or piece.

  For example, if a table space has two partitions, a FlashCopy image copy of the table space creates three SYSCOPY records:

  1. A SYSCOPY record for the tables space with DSNUM=0
  2. A SYSCOPY record for the first partition with DSNUM=1
  3. A SYSCOPY record for the second partition with DSNUM=2
• If there is only one partition or piece in the table space, only one SYSCOPY record is created with DSNUM=0.

For FlashCopy image copies that were created with the FLASHCOPY YES option, the START_RBA value corresponds to the RBA or LRSN when the object's pages were last externalized to disk.

For FlashCopy image copies that were created with the FLASHCOPY CONSISTENT option and have undergone consistency processing, the START_RBA value corresponds to one of the following values, depending on whether active units of work existed:

• If active units of work existed, the START_RBA value corresponds to the beginning RBA or LRSN of the oldest uncommitted unit of work that was backed out.
• If no active units of work existed, the START_RBA value corresponds to the RBA or LRSN when the object's pages were last externalized to disk.

In the SYSCOPY section of the output from REPORT RECOVERY, the SYSCOPY records are presented in ascending START_RBA order and not in timestamp order. Thus, the SYSCOPY records for FlashCopy image copies might be shown in the REPORT RECOVERY out of chronological order as compared to other SYSCOPY records.

The implication of the START_RBA value for FlashCopy image copies is that a recovery from a FlashCopy image copy likely requires more log processing.

Recovery and FlashCopy image copies

Using FlashCopy to create image copies has the several implications for recovery. Those implications are described in Recovering with FlashCopy image copies

Utility support for FlashCopy

The following DB2 for z/OS utilities can use FlashCopy to create image copies:

• COPY
• LOAD
• REBUILD INDEX
• REORG INDEX
• REORG TABLESPACE

When creating a FlashCopy image copy, the COPY and LOAD utilities with SHRLEVEL CHANGE can include additional phases of execution, depending on the options that are specified in the utility control statement. The additional execution phases include:

LOGAPPLY

If CONSISTENT was specified for either the COPY utility or the LOAD utility, the utility identifies the most recent checkpoint for each member. All objects that are being copied are updated to the same log point to prepare for backout processing.

LOGCSR

If CONSISTENT was specified for either the COPY utility or the LOAD utility, the utility reads the logs during this phase. The utility uses the logs to identify the uncommitted work that needs to be backed out of the image copy.

LOGUNDO

If CONSISTENT was specified for either the COPY utility or the LOAD utility, the utility backs out uncommitted work to make the image copy consistent.

SEQCOPY

If additional sequential format image copies are requested, the COPY utility creates them from the FlashCopy image copy during this phase.

The following utilities accept the VSAM data sets that are produced by FlashCopy as input:

• COPYTOCOPY
• DSN1COMP
• DSN1COPY
• DSN1PRNT
• RECOVER

The UNLOAD utility does not accept FlashCopy image copies as input. To use a FlashCopy image copy as the source for the UNLOAD utility, use the COPYTOCOPY utility to create sequential format image copies from the FlashCopy image copy.

A return code of 8 or greater from DFSMSdss results in termination of the utility FlashCopy process, even if OPTIONS EVENT(ITEMERROR,SKIP) was specified.

Tips for using FlashCopy image copies

In some cases, a REORG of your data is required before you create a FlashCopy image copy. In these cases, if you do not run REORG first, the versioned data will not be in the proper format for the corresponding utility, and the utility will be unable to process the data correctly. The following tips can help you avoid problems.

• Using FlashCopy image copies with the UNLOAD utility: The UNLOAD utility cannot operate directly on a FlashCopy image copy. Therefore, when you unload data, use the COPYTOCOPY utility first to create a sequential image copy from the FlashCopy image copy. Then, run the UNLOAD job on the sequential copy. In certain cases, some individual rows might not be properly unloaded, in which case a warning message is issued. This situation might occur in two circumstances, mentioned below, but you can take actions to avoid the problem.
  • If your data is versioned (with an immediate ALTER statement), run REORG on your data before creating the FlashCopy image copy.
  • If your data has been compressed (by a compression during an insert operation), run the REORG on your data before creating the FlashCopy image copy. REORG is required only once after the compression during the insert operation occurred.
• Using a FlashCopy image copy for porting data: Use the FlashCopy image copy as input to the DSN1COPY utility. If your data is versioned (with an immediate ALTER statement), run the REORG utility before creating the FlashCopy image copy.