DB2 Contingency Planning Guidelines

When developing your DB2 disaster recovery plan be sure to consider the following tips and techniques.

Plan Before a Disaster Strikes

Ensure that an adequate disaster recovery plan is in place for the DB2 subsystem. This involves backing up system data sets and system table spaces and integrating the timing of the backups with the needs of each DB2 application.

Remember, the absolute worst time to devise a disaster recovery plan is during a disaster!

Create a Schedule to Ship Vital Image Copies Offsite Regularly

Remember that the RECOVER utility can recover only with the backup tapes sent to the remote site. Updates on the active log at the time of the disaster are lost, as are all archive logs and image copy backup tapes not sent offsite.

Ensure that every table space has a valid offsite image copy backup.

Do Not Forget to Back Up Other Vital DB2 Data

Copying DB2 table space data is not sufficient to ensure a complete disaster recovery plan. Be sure to back up and send offsite all related DB2 libraries, such as

• Any DB2 DDL libraries that might be required

• JCL and proc libraries

• DBRM libraries

• Application program load libraries

• Libraries and passwords for critical third party DB2 products

• Stored procedure program load libraries

• Application program, stored procedure source code, and copy book libraries

Use SHRLEVEL REFERENCE for Offsite Copies

SHRLEVEL CHANGE means that other processes can read and modify the table space as the COPY is running. SHRLEVEL REFERENCE means that other processes are permitted only to read the table space data during the COPY utility execution.

When running the COPY utility for offsite backup needs:

• Stop concurrent data modification to all table spaces in the table space set using the STOP command or START ... ACCESS(RO) .

• Use the SHRLEVEL REFERENCE clause.

If you run COPY with SHRLEVEL CHANGE for an offsite image copy be sure to send the archive logs, or a copy of the archive logs offsite, too. Additionally, ensure that related table spaces are assigned the same quiesce point for recoverability.

Beware of Compression

If your site uses tape-compression software, be sure that the offsite location to be used for disaster recovery uses the same tape-compression software. If it does not, specify the following JCL parm for any offsite image copy data set:

 DCB=TRTCH=NOCOMP 

Document Your Strategy

Document the backup strategy for each table space (sledgehammer, scalpel, DSN1COPY, or some other internally developed strategy). Document the state of each DB2 application and the DB2 subsystem by producing DB2 Catalog, DB2 Directory, and BSDS reports after producing your offsite backups. Send this information daily to your remote site.

Use an Appropriate Active Log Size

Keep the active log relatively small, but not so small that it affects system performance. Active logging poses a logistical problem. If a disaster strikes, the active log will be lost. Therefore, you will not be able to restore all DB2 data to its state just prior to the disaster. Remember, a disaster implies total loss of your machine or site. At best, data can be restored only back to the last archive log sent offsite. This is one reason to have small active logs, thereby forcing more frequent log archival. If DB2 provided the capability to remote log and remote copy, it would be technically possible to recover data back to its most recent state using remote logs and remote copies.

When the active log is small, consider increasing the maximum number of archive logs for the DB2 subsystem. This maximum is controlled using the MAXARCH DSNZPARM parameter.

As of DB2 V8, the maximum value acceptable for MAXARCH is 10000. The previous maximum was 1000.

Automate Use of the ARCHIVE LOG Command

The ARCHIVE LOG command can be used within a job that is submitted periodically, forcing an archive log and creating a copy of the archive log for offsite recovery. This is an important component of the DB2 disaster recovery plan because the BSDS and the SYSIBM.SYSCOPY table, which play a substantial role in the recovery process, are backed up at log archival time. Be sure to put the appropriate procedures in place to move the archive log copies offsite as soon as feasible after the job completes. A tape that is still sitting in the shop when a disaster strikes will be useless for disaster recovery purposes.

The general recommendation for logging is to enable dual logging ”both active and archive. If this is the case, be sure to do one of the following:

• Keep both archive log sets on site, but make a copy of one of the archive log sets and send that copy offsite.

• Keep one archive log set on site and send the second set offsite. This alternative creates a greater exposure to the primary site because only one backup of the logs is available on site.

Copy Each Table Space After an Offsite Recovery

Back up each application's table spaces at the remote site immediately after each application has been recovered.

Validate Your Offsite Recovery

Run a battery of SELECT statements against the recovered application tables to validate the state of the data.

Test Your Offsite Recovery Plan

Test your disaster recovery plan before a disaster occurs. This gives you time to correct problems before it is too late. It is wise to schedule at least yearly disaster recovery tests in which disaster conditions are mimicked. The DB2 environment should be recovered at the offsite location minimally once a year to ensure that the plan is up-to-date and able to be implemented in case of a disaster.

CAUTION

If you fail to test your disaster recovery plan, you are basically planning to fail. Without regularly scheduled disaster recovery testing there is no way to be sure that your plan is up-to-date and workable in the event of a disaster.

Appropriate Copying Is Dependent Upon Each Application

DB2 disaster recovery is a complex topic that deserves substantial attention. Each application must be analyzed to uncover its optimal disaster recovery strategy. The frequency of copying will be dependent upon the volatility of the data, the size of the batch window, the length of time allowable for an eventual recovery, and the frequency of log archival.

Include Resumption of Normal Business in Your DR Plan

Be sure to include a section in your disaster recovery plan for returning to "normal" business at a new, real data center. Conducting business from a disaster recovery site can be very costly. A disaster recovery plan with a well-thought-out strategy for resuming normal business practices after the disaster can save time and money.