Complete recovery cycles

In planning for recovery, you determine how often to take image copies or system-level backups and how many complete cycles to keep. Those values tell how long you must keep log records and image copies or system-level backups for database recovery.

In deciding how often to take image copies or system-level backups, consider the time needed to recover a table space. The time is determined by all of the following factors:

  • The amount of log to traverse
  • The time that it takes an operator to mount and remove archive tape volumes
  • The time that it takes to read the part of the log that is needed for recovery
  • The time that is needed to reprocess changed pages

In general, the more often you make image copies or system-level backups, the less time recovery takes, but the more time is spent making copies. If you use LOG NO without the COPYDDN keyword or the FCCOPYDDN keyword when you run the LOAD or REORG utilities, Db2 places the table space in COPY-pending status. You must remove the COPY-pending status of the table space by making an image copy before making further changes to the data.

However, if you run REORG or LOAD REPLACE with the COPYDDN keyword or the FCCOPYDDN keyword, Db2 creates a full image copy of a table space during execution of the utility, so Db2 does not place the table space in COPY-pending status. Inline copies of indexes during LOAD and REORG are not supported.

If you use LOG YES and log all updates for table spaces, an image copy of the table space is not required for data integrity. However, taking an image copy makes the recovery process more efficient. The process is even more efficient if you use MERGECOPY to merge incremental image copies with the latest full image copy. You can schedule the MERGECOPY operation at your own convenience, whereas the need for a recovery can arise unexpectedly. The MERGECOPY operation does not apply to indexes.

Even if the BACKUP SYSTEM is used, it is important to take full image copies (inline copies) during REORG and LOAD to avoid the COPY-pending status on the table space.

Recommendation: Copy your indexes after the associated utility has run. Optionally, you can take a FlashCopy® image copy when running the REBUILD INDEX or REORG INDEX utilities. Indexes are placed in informational COPY-pending (ICOPY) status after running the LOAD TABLESPACE, REORG TABLESPACE, REBUILD INDEX, or REORG INDEX utilities. Only structural modifications of the index are logged when these utilities are run, so the log does not have enough information to recover the index.

Use the CHANGELIMIT option of the COPY utility to let Db2 determine when an image copy should be performed on a table space and whether a full or incremental copy should be taken. Use the CHANGELIMIT and REPORTONLY options together to let Db2 recommend what types of image copies to make. When you specify both CHANGELIMIT and REPORTONLY, Db2 makes no image copies. The CHANGELIMIT option does not apply to indexes.

In determining how many complete copy and log cycles to keep, you are guarding against damage to a volume that contains an important image copy or a log data set. A retention period of at least two full cycles is recommended. For enhanced security, keep records for three or more copy cycles.