Automating recovery history file pruning

You can configure the database manager to automatically prune and update the status of recovery history file entries.

You can manually update the status of entries in the recovery history file using the UPDATE HISTORY command, the db2HistoryUpdate API, or the ADMIN_CMD procedure with the "UPDATE_HISTORY" parameter. You can use the PRUNE HISTORY command, the db2Prune API, or the ADMIN_CMD procedure with the "PRUNE_HISTORY" parameter to manually remove, or prune, entries from the recovery history file. However, it is recommended that you configure the database manager to manage the recovery history file instead of updating and pruning the recovery history file manually.

The database manager automatically updates and prunes recovery history file entries at the following times:

• After a full (non-incremental) database backup operation or full (non-incremental) table space backup operation completes successfully

• After a database restore operation, where a rollforward operation is not required, completes successfully

• After a database rollforward operation completes successfully

During automated pruning, the database manager performs two operations:

1. Updates the status of the recovery history file entries

2. Prunes expired recovery history file entries

The database manager updates the recovery history file entries in the following way:

• All active database backup images that are no longer needed are marked as expired.

• All database backup images that are marked as inactive and that were taken prior to the point at which an expired database backup was taken are also marked as expired. All associated inactive table space backup images and load backup copies are also marked as expired.

• If an active database backup image is restored, but it is not the most recent database backup recorded in the history file, any subsequent database backup images belonging to the same log sequence are marked as inactive.

• If an inactive database backup image is restored, any inactive database backups belonging to the current log sequence are marked as active again. All active database backup images that are no longer in the current log sequence are marked as inactive.

• Any database or table space backup image that does not correspond to the current log sequence, also called the current log chain, is marked inactive.

  The current log sequence is determined by the database backup image that has been restored, and the log files that have been processed. Once a database backup image is restored, all subsequent database backup images become inactive, because the restored image begins a new log chain. (This is true if the backup image was restored without rolling forward. If a rollforward operation has occurred, all database backups that were taken after the break in the log chain are marked as inactive. It is conceivable that an older database backup image will have to be restored because the rollforward utility has gone through the log sequence containing a damaged current backup image.)

• A table space-level backup image becomes inactive if, after it is restored, the current state of the database cannot be reached by applying the current log sequence.

• Any entries that have a status of do_not_delete are not pruned, and their associated log files, backup images, and load copy images are not deleted.

• When a database is upgraded, all online database backup entries and all online or offline table space backup entries in the history file are marked as expired, so that these entries are not selected by automatic rebuild as images required for rebuilding. Load copy images and log archive entries are also marked as expired, since these types of entries cannot be used for recovery purposes

The following database configuration parameters control which entries the database manager prunes:

num_db_backups

specifies the number of database backups to retain for a database

rec_his_retentn

specifies the number of days that historical information on backups will be retained

auto_del_rec_obj

specifies whether the database manager should delete log files, backup images, and load copy images that are associated with recovery history file entries that are pruned

To configure the database manager to automatically manage the recovery history file, set the following configuration parameters:

• num_db_backups

• rec_his_retentn

• auto_del_rec_obj

When auto_del_rec_obj is set to ON, and whenever there are more successful database backup entries than the num_db_backups configuration parameter, then the database manager will automatically prune recovery history file entries that are older than rec_his_retentn.