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.
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.
An inactive database backup is one that, if restored, moves the database back to a previous state.
An expired database backup image is one that is no longer needed, because more recent backup images are available.
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.
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: