Database Recovery Concepts

DB2 has several methods for recovering data in the event of failures or when errors occur or disaster strikes. DB2 allows you to recover data to the current state or to an earlier state.

Many of the objects in DB2 can be recovered using various methods. You can recover

• Table spaces

• Index spaces

• Indexes

• Partitions of a table space

• Individual data sets

• Pages within an error range

• Individual pages

In order to ensure consistent operation and integrity of data, a DBA must develop a strategy for several recovery scenarios. These scenarios can include but are not limited to recovery from

• Application failures

• Hardware failures

• z/OS failures

• Space failures

It is possible to recover the DB2 catalog and directory, data, and objects to a point of consistency. This point of consistency can be the situation that is most currentcalled "to current" or to the end of the logor to a prior point in time when the data was still consistent.

With current technology, hardware failures hardly ever happen anymore. Most likely, you have to perform a recovery because errors in program logic deleted too much or because update runs were run twice.

You can recover from failures only if you have taken the proper backups: image copies and log records. DB2 has its own copy utility that allows you to save the data by producing an image copy. Saving all data is called a full copy; saving only the changes since the last copy is called an incremental copy. DB2 for z/OS does its backup and recovery on a table space level or on an index space level. This means that if you perform a recovery to a table space and go back in time, all tables in this table space go back in time. It is not possible to perform a backup and recovery at a more granular object, or table, level, but you can recover at a more granular level, down to an individual page.

NOTE

DB2 will save only data, not the layout of your structures. Also, if you drop your structures, all recovery information is lost, and recovery cannot be performed. When you change your application, you often have to drop the structures and recreate them. In this case, you have to develop special scenarios whereby you have to unload and reload the tables.

A unit of workalso referred to as a unit of recovery, or a commit scopeis a series of recoverable changes within an application sequence. An application can have several units of work within it. If an error occurs, you can perform a rollbackback out of changesof all the changes within the unit of work.

DB2 can perform a rollback only on a unit of work. Once a unit of work is committed, it cannot be rolled back in time. An example of a unit of work that can't be rolled back is a mass delete, which will update only the segment table, which is the only thing logged for a mass delete. After the mass delete is committed, the data no longer exists, and changes cannot be rolled back. The only information the log contains is the single update to the segment table.