DB2 Storage

Image Copies

There are two kinds of image copies, FULL and INCREMENTAL, the terms having the usual meaning. Incremental copies can be merged with a previous full copy, to make a new full copy. There are also different levels of data sharing during backup.

SHRLEVEL REFERENCE guarantees a consistent database backup by locking out write access to the data. The data can be read alongside the copy.
SHRLEVEL CHANGE allows updates to run alongside the image copies. If a recovery is needed, then DB2 uses the image copy, plus updates from the logfiles to reconstruct the database.

DB2 also supports Snapshot / Concurrent copy within its DB2 COPY utility, to take an instant image copy without needing rollforward logs. This only works with StorageTek's SVA DASD, or older IBM RVAs.

Recovery using FDRinstant

It is possible to take fast backups from any disks using FDRinstant . The problem with this is that FDRinstant does not interface with recognised image copy utilities. Traditionally, a Tablespace recovery has been performed using the RECOVER command of DB2 to automatically restore the Tablespace from the most recent Imagecopy backup. Updates from the DB2 Log are then applied to bring the Tablespace as up-to-date as possible. However, a variation of the RECOVER command (RECOVER LOGONLY) allows the application of just the Log records to a Tablespace that has already been restored outside of DB2 control - i.e. with FDR/ABR.

The RECOVER LOGONLY technique could be used as follows. First, restore the Tablespace from the ABR incremental backup system. Then, issue the following DB2 command to re-apply the log records.

 RECOVER TABLESPACE Tablespacename LOGONLY

If a recovered Tablespace has Indexes associated with it, users have the option of rebuilding the Indexes once the Tablespace recovery is complete. This process can be time-consuming. As a much faster alternative he can restore them from the backups made with ABR InstantBackup, and then update them from the Log using a RECOVER command, in much the same way that Tablespaces are updated. The relevant command is-

RECOVER INDEX indexname LOGONLY

There are two considerations -

1. Firstly, Indexspaces that you wish to Recover in this way must have the COPY YES attribute set at some time before they are backed up. This can be done when the Indexes are created; for existing Indexes, this attribute can be set using the ALTER command. Setting the COPY YES attribute is a one-time operation, so should not cause any difficulties.
2. The second consideration is determining which Index relates to which Tablespace. DB2 V7 has a LIST command which reports the Tablespaces and Indexes.

With these considerations taken into account, recovery of Indexes from backups taken with InstantBackup is very quick and simple process.

Cross site mirroring

If you have a second datacentre, and use PPRC (or equivalent) for remote replication of data, then you still need to take image copies. That's obvious to Storage Manager, but its surprising how many non-storage people think that replication does away with the need for backups. Apart from the obvious need to recover from individual database corruption, there is also a requirement to handle a rolling disaster. This happens when disks when disks do not all fail at once, so some updates fail, while others succeed. If this causes databases to become corrupt, then full recovery may be needed. PPRC and SDRF mirroring both support consistency groups, which safeguards against rolling disasters. See the article Remote Data Mirroring for details on PPRC and also GDPS, the product which helps prevent rolling disasters.

back to top