< Day Day Up > |
The COPYTOCOPY Utility
COPYTOCOPY can be run against any DB2 image copy data set including inline copies made during the execution of REORG or LOAD . Starting with either the local primary or recovery site primary copy, COPYTOCOPY can make up to three copies of one or more of the following types of copies:
Copies created by COPYTOCOPY can be used by the RECOVER utility just like 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 copies 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. To execute COPYTOCOPY , the process or user running the utility must have been granted one of the following privileges:
Processes or users having INSTALL SYSOPR authority can run COPYTOCOPY for table spaces in the DB2 Directory ( DSNDB01 ) and DB2 Catalog ( DSNDB06 ). COPYTOCOPY PhasesCOPYTOCOPY creates a new image copy of a table space or an index from an existing image copy. The COPYTOCOPY utility operates in these distinct phases:
COPYTOCOPY Locking and ConcurrencyWhen COPYTOCOPY is running, the object for which the copy applies is placed in utility restricted read/write state ( UTRW ). Basically, this will prevent anyone from dropping the object while the COPYTOCOPY utility executes. 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 cannot be run concurrently on the same object as the COPYTOCOPY utility:
COPYTOCOPY ExecutionTo 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 is to be copied. There are three options:
Of course, you may choose 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. When COPYTOCOPY is used in conjunction 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 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 JCL used to run the COPYTOCOPY utility is depicted in Listing 32.4. This job is used to make a backup local image copy of table space DSN8S71E in database DSN8D71A . This will be either a full or incremental image copy, whichever was last run for this table space. Listing 32.4. COPYTOCOPY JCL//DB2JOBU JOB (UTILITY),INDEX COPY',CLASS=X,MSGCLASS=X, // NOTIFY=USER //* //**************************************************************** //* //* DB2 COPYTOCOPY UTILITY //* //**************************************************************** //* //COPY EXEC DSNUPROC,SYSTEM=DSN,UID='C2CTS',UTPROC=" //* //DSNUPROC.COPY2 DD DSN=COPY002F.IFDY01,UNIT=SYSDA,VOL=SER=CPY02I, // SPACE=(CYL,(15,1)),DISP=(NEW,CATLG,CATLG) //DSNUPROC.SYSIN DD * COPYTOCOPY TABLESPACE DSN8D71A.DSN8S71E COPYDDN(,COPY2) /* // COPYTOCOPY GuidelinesDeploy the following tips and guidelines as you utilize the COPYTOCOPY utility on your DB2 data. Avoid Terminating COPYTOCOPYIt is not recommended to use the TERM command to terminate a COPYTOCOPY step. A current restart should be done instead. If a job step containing more than one COPYTOCOPY statement abends, do not use TERM UTILITY . Instead, you should restart the job from the last commit point using RESTART . If you terminate COPYTOCOPY in this situation you might cause inconsistencies between the ICF catalog and DB2 catalogs when generation data sets (GDGs) are used. You cannot use RESTART(PHASE) for a COPYTOCOPY job. It is fine to use RESTART(CURRENT) if you do not use the -TERM UTILITY command to terminate a COPYTOCOPY execution. When you use RESTART(CURRENT) , COPYTOCOPY will restart from the last commit point with the same image copy data set, so be sure to specify the data set disposition to DISP=(MOD,CATLG,CATLG) on the JCL DD statements. Inline Copy ExceptionWhen 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. |
< Day Day Up > |