DB2 10.5 for Linux, UNIX, and Windows

Recovery history file entry status

The database manager creates entries in the recovery history file for events such as a backup operation, a restore operation, table space creation, and others. Each entry in the recovery history file has an associated status: active, inactive, expired, pending delete, deleted, or do_not_delete.

The database manager uses the status of a recovery history file entry to determine whether the physical files associated with that entry would be needed to recover the database. As part of automated pruning, the database manager updates the status of recovery history file entries.

Active database backup

An active database backup is one that can be restored and rolled forward using the current logs to recover the current state of the database.

Figure 1. Active Database Backups. The value of num_db_backups has been set to four.
RECACT

Inactive database backup

An inactive database backup is one that, if restored, moves the database back to a previous state.

Figure 2. Inactive Database Backups
RECINACT

Expired database backups

An expired database backup image is one that is no longer needed, because more recent backup images are available.

Figure 3. Expired Database Backups
RECEXP

Entries marked do_not_delete

You can remove (prune) recovery history file entries using the PRUNE HISTORY command or the db2Prune API. The database manager also prunes the recovery history file entries as part of automated pruning.

There are only three ways to prune entries marked do_not_delete:

Those entries that are marked do_not_delete will never be pruned from the recovery history file unless you perform one of these three actions.

The database manager does not set the status of recovery history file entries to do_not_delete. You can set the status of a recovery history file entry to do_not_delete using the UPDATE HISTORY command.

Entries marked delete_pending

An entry marked pending_delete is in the process of being removed. It may remain if a prune operation was terminated part way through. In this case, the file associated with the entry may or may not still exist, and is treated as if it did not exist (as with deleted entries).

Here are more examples of the status of different recovery history file entries:

Figure 4. Mixed Active, Inactive, and Expired Database Backups
RECCOM1
Figure 5. Expired Log Sequence
RECCOM2