The COPYTOCOPY utility was introduced some time ago now, way back in DB2 for z/OS Version 7. The
purpose of the COPYTOCOPY utility is to make additional image copies of currently
existing image copy data sets. But many DBAs "out there" keep pluggiong away, almost unaware that COPYTOCOPY even exists. So let's spend a little time talking about it today.
The primary benefit of COPYTOCOPY is to reduce the
amount of time required to run the COPY utility. Remember that the COPY utility
can be used to take up to four image copies with a single execution of the
utility. But with COPYTOCOPY available, instead of using COPY to make four
image copy backups, the DBA can use COPY to make a single image copy, and then
run COPYTOCOPY to make additional image copies. The COPY utility will take less
time to create a single image copy backup than it will to take multiple image
copy backups. And the combination of COPY plus COPYTOCOPY can, at times perhaps, be used to
increase availability.
Individual data and index partitions are treated as
distinct target objects by the COPYTOCOPY utility. Any other utilities
operating on different partitions of the same table space or index space can be
run concurrently with COPYTOCOPY.
The following utilities can not be run concurrently on the
same database object as the COPYTOCOPY utility:
- COPY
- LOAD
- MERGECOPY
- MODIFY
- RECOVER
- REORG INDEX
- REORG TABLESPACE
Furthermore, COPYTOCOPY is flexible enough to run
against any DB2 image copy data set. This includes inline copies made during
the execution of the REORG and LOAD utilities. COPYTOCOPY must start with a
primary image copy backup – either the local primary or recovery site primary
copy. From that image copy, the COPYTOCOPY utility can make up to three copies
of one or more of the following types:
- local primary
- local backup
- recovery site primary
- recovery site backup
Copies created by COPYTOCOPY can be used by the RECOVER
utility just like regular image copies created using the COPY utility. Both
table space and index space copies can be made using the COPYTOCOPY utility.
Any DB2 utility process that uses image copy data sets can use the image copy
data sets created by COPYTOCOPY. This includes MERGECOPY, UNLOAD, and
subsequent runs of COPYTOCOPY. However, keep in mind that image copies created
with the CONCURRENT option of the COPY utility are not supported by the
COPYTOCOPY utility.
Just like the COPY utility, the COPYTOCOPY utility
records information about the image copies that it creates in the
SYSIBM.SYSCOPY system catalog table. The COPYTOCOPY utility will insert the
values in the DSNAME, GROUP_MEMBER, JOBNAME, AUTHID, DSVOLSER and DEVTYPE
columns as appropriate depending on the copies that are being created.
You cannot run COPYTOCOPY to create additional image
copies for certain DB2 Catalog (SYSCOPY in DSNDB06) and DB2 Directory (DSNDB01
and SYSUTILX both in DSNDB01) objects.
The COPYTOCOPY utility operates in these distinct
phases:
- UTILINIT
– Initialization and setup
- CPY2CPY
– Copying the image copy
- UTILTERM
– Cleanup
TERM and Restart Issues
The use of the TERM command to terminate a COPYTOCOPY step
that has abended is not recommended. A current restart should be done instead
to allow COPYTOCOPY to pickup where it left off. Terminating COPYTOCOPY in such
a situation might cause inconsistencies between the ICF catalog and DB2 catalog
when GDGs are used.
You cannot use RESTART(PHASE) for a COPYTOCOPY job. It
is fine to use RESTART(CURRENT) as long as you avoid using the -TERM UTILITY
command to terminate a COPYTOCOPY step. When you use RESTART(CURRENT),
COPYTOCOPY will restart from the last commit point with the same image copy
data set, so be sure to code a data set disposition of DISP=(MOD,CATLG,CATLG)
on your JCL DD statements.
Inline Copy Exception
When using COPYTOCOPY to copy an inline image copy that
was made by the REORG utility with the part range option you will need to
specify individual DSNUM for the partitions to be copied. The COPYTOCOPY
utility does not support part range. COPYTOCOPY will copy only the specified
partition data from the input inline image copy data set into the output image
copy data set.
COPYTOCOPY Execution
To run the COPYTOCOPY utility it is not necessary to
provide the explicit data set name of the image copy being copied. Instead, the
input to the COPYTOCOPY utility is the name of the table space, index space, or
index for which the original copy was made, and an indication of which image
copy in the catalog should be copied. To specify this information COPYTOCOPY
provides three options:
- FROMLASTCOPY – indicates that the most recent
image copy taken for the table space or index space is to be used as input to
the COPYTOCOPY utility. The input could be either a full image copy or
incremental copy. The utility will retrieve the information from the
SYSIBM.SYSCOPY system catalog table.
- FROMLASTFULLCOPY – indicates that the most recent full image copy taken for the
object is to be used as the input to COPYTOCOPY job. Once again, this
information is obtained by querying the DB2 Catalog.
- FROMLASTINCRCOPY – indicates that the most recent incremental image copy taken for
the object is to be used as the input to COPYTOCOPY job. FROMLASTINCRCOPY is
not valid for index spaces or indexes. If FROMLASTINCRCOPY is specified for an
index space or index, COPYTOCOPY will use the last full image copy that was
taken for the index, if one is available. And once again, this information is
obtained by querying the DB2 Catalog.
Of course, you may choose instead to specify the data set
name for the image copy that is to be copied by the COPYTOCOPY utility. This
can be accomplished by using the FROMCOPY clause. But keep in mind that when you
are using COPYTOCOPY with a list of objects defined using the LISTDEF statement,
the FROMCOPY clause is not valid.
If the FROMCOPY keyword is not used the COPYTOCOPY
utility must determine which specific image copy is to be copied. Before
COPYTOCOPY can execute it may have to choose between the local site primary
copy, local site backup copy, recovery site primary copy, and recovery site
backup copy data sets. COPYTOCOPY will search image copies in the following
order to determine the input data set to be used:
- If you are running COPYTOCOPY at your local site,
the search order will be (1) local site primary copy, (2) local site backup
copy, (3) recovery site primary copy, (4) recovery site backup copy.
- If you are running the utility at your recovery
site, the search order will be (1) recovery site primary copy, (2) recovery
site backup copy, (3) local site primary copy, then finally (4) local site
backup copy.
If the input data set cannot be allocated or opened, the
COPYTOCOPY utility will try to use the next image copy data with the same
START_RBA value in SYSIBM.SYSCOPY column, in the search order as indicated
previously. When the FROMCOPY keyword is used though, only the explicitly
specified data set can be used as the input to COPYTOCOPY.
An Example of the COPYTOCOPY Utility
Let’s take a quick look at a sample JCL
job step to run the COPYTOCOPY utility. The following code can be run to make a
backup local image copy of the table space DSN8S71E in the sample DB2 database
DSN8D71A. This will be either a full or incremental image copy, whichever was
last run for this object:
//STEP1 EXEC DSNUPROC,UID='DBAPCSM.CPY2CPYT',
// UTPROC='',
// SYSTEM='DB2T',DB2LEV=DB2A
//SYSIN DD *
//COPY2 DD
DSN=COPY002F.IFDY01,UNIT=SYSDA,VOL=SER=CPY02I,
//
SPACE=(CYL,(15,1)),DISP=(NEW,CATLG,CATLG)
//SYSIN DD *
COPYTOCOPY TABLESPACE DSN8D71A.DSN8S71E COPYDDN(,COPY2)
/*
Bottom Line
The COPYTOCOPY utility
provides a useful new feature to the toolkit of DB2 DBAs. Using COPYTOCOPY to
create additional image copies from existing image copies can enhance
availability and assist DBAs in creating an optimal backup and recovery plan
for their DB2 applications and databases.
