Image Copies

In order to be able to recover data when a problem occurs, you must have a solid recovery plan and a strategy for each of the many situations. This plan will include performing image copies on a regular basis. You create image copies of your table spaces and selected index spaces.

Frequency of Image Copies

The frequency with which image copies should be taken depends on the allowable down time for the primary user of the application. You should determine the clock time needed if you have to recover your data. If an application cannot be unavailable for more than 2 hours, you will need to take image copies more frequently than if your application can be unavailable for a complete day. Depending on the currency of data required in the recovery, you will have to determine when image copies can be taken and what types of image copies need to be taken. You may need to have incremental image copies taken throughout the day, or you may have to do only one full copy at the end of the day's processing. In some situations, an image copy is taken at the beginning of a batch window, especially if there are long-running batch processes. This allows for a restore in case something goes wrong during the batch cycle.

A number of technical considerations are involved in image copy frequency. The bare minimum you should allow is half the retention period of the archive log, less 1 day ([retention period / 2] 1 day). This will guarantee that, at any moment, there are two valid image copies of the table spaces. You always want two valid copies because of possible media failure or to reduce the risk of inconsistent data on the image copy. After a drop and recreate of an object, all system-retained recovery information is gone. After you run utilities that will recreate the data (REORG, LOAD REPLACE without the LOG YES option), you have to run an image copy to establish a new base for recovery.

Dual Image Copies

DB2 provides for the ability to create dual image copies. If the primary image copy has an error and no secondary copy of your data exists, a recovery will fail. Even when it is possible to fall back to a previous image copy, substantial time is needed to perform the log apply from the previous image to where the failed image copy was taken. A previous image copy should be regarded as a safety net, in case the pages have errors. By uncataloging the most current image copy, it is possible to force a fallback. This works only if the image copies are cataloged.

In addition to using dual copies, you can make two sets of copies so that two copies are on site (local) and two copies are off site (remote). Using just the second copy of a dual-copy image for off-site backup is not the best choice, because if an on-site copy is bad, obtaining the off-site copy after a failure may be inconvenient, depending on where the off-site disaster recovery is located. Keeping two copies on the primary site will ensure that an immediate backup is available to use if a copy is bad; the same concept applies when recovering from image copies at the disaster-recovery site, where two copies should be maintained also. In order to do this, you could do the following in the COPY utility:


This would ensure that you took two copies for the primary site and two for the recovery site.


The COPYTOCOPY utility permits additional image copies to be made from the primary image copy. The copies are registered in the DB2 catalog with the following information:

  • Original values from source copy: ICDATE, ICTIME, and START_RBA


The target object is left in read/write access mode (UTRW), which will allow SQL statements and some utilities to run concurrently with the same target objects. A maximum of three copies can be taken at once. This is a total of four: local primary, local backup, remote-site primary, and recovery-site backup.

COPYTOCOPY has about a 5 percent performance benefit over the COPY utility and helps minimize the time needed for copying critical options in order to create additional remote-site copies.

The following is an example of the syntax:


Tape versus Disk Image Copies

The fastest recoveries occur when the input data sets reside on disk. This applies to both image copy recoveries and archive logs. However, because disk space is more expensive than cartridges, there is a tradeoff between the cost of an unavailable application and the cost of disk space. Mounting, remounting, and winding cartridges can take a very long time. If you use the cartridge method and stack the files, you should use the proper JCL options during image copy and recovery so that the cartridge stays mounted and positioned. The handling of stacked files on cartridge can be automated by using TEMPLATE statements in the utility parameters.

Full and Incremental Image Copies

Two types of backups are available: full copies or incremental copies. A full image copy copies all the pages in the table space, whether or not it has changed (FULL YES is the utility default). Incremental image copies copy only the pages that have changed since the last image copy.

You can view the type of copy in the ICTYPE column in the SYSCOPY catalog table, along with the database name, the table space name, time of the copy, the start RBA/LRSN, data set name, and volume serial number, if the image copy is not cataloged. A full image copy will have an ICTYPE of F, and an incremental will have an ICTYPE of I.

Incremental copies of data can be useful. But because the procedures involved in taking incremental copies are more complex than those for full image copiesfor example, how often to take incremental copies, and when to run the MERGE COPY utilitymany database administrators choose to take only full image copies.

Data may be lost or the recovery time may be extended when using incremental image copies. Incremental copies are a substitute for the log. DB2 will try to mount the incremental-image copies to skip large parts of the log during the log-apply phase. But if this fails, DB2 notes the RBA, or LOGPOINT, of the last successful incremental and uses the archive log from that point on. If the archive log does not exist anymore from this point on, the recovery will fail.

Some administrators use the incremental copy utility for its speed and then run the MERGECOPY utility to merge the last full copy and latest incremental into a new full copy. This procedure combines the best of both worlds: ease of recovery and the speed of incremental image copies.


You might want to reconsider the use of incremental copies if the data is very volatile and has more than 5 percent of the pages updated between copies, because the runtime of the incremental image copy will be longer than that of a full copy. If runtime is not an issue and the size of the image copy data set is, an incremental copy might be the best solution.


If the feature for tracking space map changes is turned off (TRACKMOD NO) in the table space definition, incremental copies are required to perform a table space scan in order to find the individual pages that have changed and need to be copied. Only full image copies can be used in this case; therefore, if incremental copies are needed, avoid using TRACKMOD NO.

The image-copy utility has parameters to determine whether an incremental or a full image copy should be made. You can use user-defined thresholds in the image copy utility to control subsequent steps, depending on whether an incremental copy or a full copy was done.

Both full and incremental copies are important for creating backups in a 24/7 environment that must always be operational and that must be able to meet an acceptable recovery window. Full copies should be taken when

  • A table is newly loaded using LOAD LOG NO **

  • A table is loaded with LOAD RESUME LOG NO **

  • A table is reorganized with REORG LOG NO **

  • Table data has been modified extensively


In many cases, marked by **, DB2 will enforce an image copy by setting the image copy pending (ICP) condition for the object. It is unwise to ignore this statusby, for example, using the REPAIR utilityunless you never intend to update the data again and keep the original input of the utility, such as a load in a data warehouse environment.

Incremental copies should be taken when changes have been made to the table since the last full image copy and processing the log would take too much time during the recovery. During the recovery, DB2 requires access to all incremental copies at the same time. If they reside on cartridge, this could be a problem because of the number of available units. If DB2 cannot mount all incremental image copies, it will ignore them and start processing the log again. You can prevent this situation by running the MERGECOPY utility to merge incremental image copies into a single set.

Copying Partitions and Data Sets

For both table spaces and index spaces, individual partitions can be backed up by the image-copy utility by specifying the partition number in the DSNUM keyword on the control statement of the COPY utility. Logical partitions of nonpartitioning indexes cannot be image copied; if PIECESIZE has been used, the pieces of an index cannot be individually image copied. This DSNUM will be recorded in the SYSCOPY table for each partition or data set that was copied.

If you image copy by partition, you also have to recover by partition. If you image copy the entire partitioned table spaceno use of the DSNUMyou can recover the entire table space or one or more partitions.

Copy Data Sets

It is advisable to have multiple copies for an image copy in the event that one image copy becomes damaged. This can be easily accomplished via the COPYDDN parameter on the COPY utility control card. Here, you can specify a primary copy and a secondary, or backup, copy by specifying the DD names for the two copy data sets. This backup copy is intended to be a local backup copy so that during a recovery, it can be used if the primary copy is not usable. In many installations, this local backup copy is in addition to having a copy for remote-site recovery.

Follow these recommendations for making image-copy data sets.

  • Consider using GDG (generation data groups) for backups to generate unique data set names for the image copy.

  • Use DISP=(MOD, CATLG) for the ability to restart the COPY utility.


Remember that GDG's are cataloged at the end of a job (not job step). If a job fails, the dataset name is already recorded in SYSIBM.SYSCOPY, but not the z/OS catalog. The next run will result in duplicate names being rejected by the COPY utility.

You can specify multiple objects in a single COPY utility, allowing you to take image copies of multiple objectstable space, partitions, and so onin one job and to use parallelism. This is performed by repeating the object clause as many times as needed:


This example provides the ability to copy multiple objects using three parallel streams (PARALLEL (3)). DB2 will attempt three streams, but storage constraints may cause this to be lessened or ignored. DB2 supports parallelism for image copies on disk or tape devices. You can control the number of tape devices to allocate for copy function by using TAPEUNITS with the PARALLEL keyword.


You can use the CHANGELIMIT feature of the COPY utility to tell DB2 to look for a specified percentage of changed pages in a table space or partition before taking a full or incremental image copy. You can specify value(s) in the CHANGELIMIT parameter to allow for an incremental image copy or full image copies to be taken only when those values are reached.

Another COPY feature that can be used to observe changes is REPORTONLY, which would allow you to see whether an image copy is recommended because the CHANGELIMIT values were met. This feature could help to report whether any changes occurred against an object, possibly for auditing purposes. The following example shows the use of the CHANGELIMIT and REPORTONLY features:


This example gives a recommendation for a full image copy if the number of changed pages is greater than 30 percent. It recommends an incremental image copy to be taken if the number of changed pages is greater than 5 percent and less than 30 percent. An image copy will not actually be taken, only recommended, because we are using the REPORTONLY feature.

Possibly, an image copy will not be taken when CHANGELIMIT is used, thus creating an empty-copy data set. This situation is not very desirable, especially with GDGs, because you could lose previous image copies. Using the REPORTONLY option will set the condition code for this job step. The condition code will depend on the advice given and can be used in conjunction with conditional JCL; for example, full copies go to cartridge and incremental copies go to disk. This option can also be used to prevent an empty-copy data set.

Access during Image Copying

During the taking of an image copy you can choose whether to allow concurrent access. Two methods are available. The first method is to simply start the object in utility mode, issuing the START DATABASE command and using the ACCESS(UT) option. Utility mode can be used for both table spaces and index spaces. Choosing this option will allow utilities to be executed only against the objects. Any other concurrent processes that try to access those objects will be rejected.

The second method to control concurrent access is to use the SHRLEVEL parameter on the COPY utility. The options are CHANGE and REFERENCE.

  • SHRLEVEL REFERENCE forces the COPY utility process to wait until all writers are not using the table space or index space. They must commit their changes before the utility can continue. The benefit of this option is that readers are allowed against the objects being copied during the utility execution. However, no updating is allowed. This option also guarantees that the copies are created in a single COPY utility and do not have any incomplete units of work.

  • SHRLEVEL CHANGE allows other applications to update the objects during the image copy. This means that some of the changes that were made during the copy may be on the log but not necessarily in the copy itself. An image copy created by this method is often called a fuzzy copy.

Regardless of the SHRLEVEL option that is chosen, DB2 will associate a log RBA or LRSN to the image copy and record this in SYSIBM.SYSCOPY. This is the point in the DB2 log from which DB2 will then need to apply log records during a recovery process.

Inline Copies

After using a LOAD REPLACE or reorganizing a table space, you must establish a full image copy so that you can avoid long log-apply phases in case recovery is necessary or if you are resolving a COPY-pending status. Taking a copy inline during the utility execution is much faster than executing the COPY utility afterward and avoids the setting of the COPY-pending status, allowing for increased availability of the table space.

This copy can easily be taken inline during the execution of the LOAD REPLACE or REORG utility. These inline copies are equivalent to a full image copy taken with SHRLEVEL REFERENCE, with a few minor differences, such as out-of-order pages or multiple versions. This would possibly cause the inline copy to be slightly larger than a normal full copy. But regardless, the inline copy is fine for recoveries, can be processed by all DB2 utilities, and can be the basis for future incremental image copies.

Inline copies can be requested on the COPYDDN keyword in the LOAD utility:

 LOAD....REPLACE    COPYDDN (local-primary,(local-backup))    (RECOVERYDDN (remote-primary,(remote-backup)) 

They can also be requested on the COPYDDN keyword of the REORG UTILITY:

 REORG    COPYDDN (local-primary,(local-backup))    (RECOVERYDDN (remote-primary,(remote-backup)) 

DFSMS Concurrent Copy

A DFSMS (data facility storage management system) concurrent copy can copy a data set concurrently with other processes. A concurrent copy can be used in two ways.

  1. If the COPY utility with the CONCURRENT keyword is used, DB2 records the copy in SYSIBM.SYSCOPY. The RECOVER utility can use these copies and the logs for recovery.

  2. A concurrent copy can be used to make copies outside DB2. In order to recover, the data sets will need to be restored before the logs can be applied.


CONCURRENT cannot be used if page size is > 4K or if the DSCVI DSNZPARM is set to allow the control-interval size to match the page size.


The MERGECOPY utility merges existing incremental image copies into a single copy to help lessen recovery time. This utility should be executed based on the amount of exposure perceived and the amount of down time allowed in a recovery. For recover-"to-current" to be effective, running MERGECOPY frequently would be beneficial. If point-in-time recoveries are more likely, MERGECOPY will not be beneficial.

MERGECOPY improves performance for "to-current" recoveries because the full copy and possibly only one incremental copy would be needed to recover, instead of having to read through multiple incremental copies. However, for a point-in-time recovery (TORBA or TOCOPY), MERGECOPY may not have any benefit.


The MERGECOPY utility cannot merge image copies that are from different share levels (SHRLEVEL), and like the RECOVER utility will allocate all copies at the same time. So, if you create more incremental image copies than you have tape drives, you will have a problem.

Consider the timeline in Figure 8-1. If you want to recover to May 20 and the MERGECOPY on June 5 has not yet been done, the incremental from May 20 will still be in SYSCOPY and can be used to recover to. After the MERGECOPY, the copy for May 20 will no longer be in SYSCOPY, and DB2 must then go back to the full image copy on May 1 and do a forward log apply to May 20, making the time for recovery longer because more of the log will have to be applied.

Figure 8-1. Sample recovery timeline

You can specify whether you want a new full copy or a merge of all the incremental into one new incremental copy. This is done with the NEWCOPY keyword: MERGECOPY…NEWCOPY YES or MERGECOPY…NEWCOPY NO.

When you perform a MERGECOPY and create a new incremental copy, all the rows in SYSIBM.SYSCOPY for the merged copies are deleted.


Another important reason to merge copy frequently is that if DB2 cannot mount all incremental copies during a recoveryfor example, if the incremental copies are on cartridge and there are not enough unitsDB2 will choose to apply changes from the log. This increases the amount of time needed for a recovery and could possibly cause the recovery to fail because this log is unavailable.

You can obtain a report that identifies all referential relationships to a given table by using the REPORT utility with the option TABLESPACESET. You can then determine what table spaces need to be quiesced and image copied together. Keep in mind that this report covers only the relationships defined in DB2; other, application-defined relationships between tables may have to be included in the same recovery scope. The TABLESPACESET option is available for all utilities in combination with TEMPLATES. This will automate utilities if you use DB2-enforced RI.

Index Copy

It is not necessary to have an image copy of the index in order to recover it. An index can be rebuilt from the data in the tables by using the REBUILD utility. You can also recover the index from an image copy. In some cases, it may be faster to recover from an image copy of an index rather than rebuild it, especially if the index has little or no change activity. Index recovery can also be done in parallel with the table space recovery when you recover an index from an image copy. Once you enable an index for image copies by using COPY YES on the CREATE/ALTER INDEX DDL, DB2 records recovery information in both SYSIBM.SYSCOPY and SYSIBM.SYSLGRNX. There are no changes to the log, because indexes are always logged to be able to roll back a unit of work. Copies of indexes can be only full image copies because the indexes do not have a space map to determine the updated pages. Incremental image copies do not apply to indexes.

DB2 for z. OS Version 8 DBA Certification Guide
DB2 for z/OS Version 8 DBA Certification Guide
ISBN: 0131491202
EAN: 2147483647
Year: 2003
Pages: 175
Authors: Susan Lawson © 2008-2017.
If you may any questions please contact us: