UPDATE HISTORY command
The UPDATE HISTORY command updates the location, device type, comment, or status in a database history records entry.
- FOR object-part
- Specifies the identifier for the history entry to be updated. It is a time stamp with an
optional sequence number from 001 to 999. For history entries, such as backups, that make use of the
sequence number, if the sequence number is not included in the object-part, the default sequence
number 001 will be used. That is, if there are history entries with the same time stamp but
different sequence numbers, and only the time stamp is used as the object-part, the
UPDATE HISTORYcommand will only update the matching entry with sequence number 001.
This parameter cannot be used to update the entry status. To update the entry status, specify an EID instead.
- EID eid
- Specifies the history entry ID.
- LOCATION new-location
- Specifies the new physical location of a backup image. The interpretation of this parameter depends on the device type.
- DEVICE TYPE new-device-type
- Specifies a new device type for storing the backup image. Valid device types are:
- Tivoli® Storage Manager
- Snapshot backup
- Snapshot backup that was generated by a custom script.
- User exit
- Null device
- SQL statement
- COMMENT new-comment
- Specifies a new comment to describe the entry. The size of new-comment cannot exceed 30 ASCII characters.
- STATUS new-status
- Specifies a new status for an entry. Only backup entries can have their status updated. Valid
- Active. The backup image is on the active log chain. Most entries are active.
- Inactive. Backup images that no longer correspond to the current log sequence, also called the current log chain, are flagged as inactive.
- Expired. Backup images that are no longer required, because there are more than NUM_DB_BACKUPS active images, are flagged as expired.
- Deleted. Backup images that are no longer available for recovery should be marked as having been deleted.
- Do not delete. Recovery database history records file entries that are marked DB2HISTORY_STATUS_DO_NOT_DELETE will not be pruned by calls to the PRUNE HISTORY command, running the ADMIN_CMD procedure with PRUNE HISTORY, calls to the db2Prune API, or automated recovery database history records pruning. You can use the DB2HISTORY_STATUS_DO_NOT_DELETE status to protect key recovery file entries from being pruned and the recovery objects associated with them from being deleted. Only log files, backup images, and load copy images can be marked as DB2HISTORY_STATUS_DO_NOT_DELETE.
db2 update history for 19970413100000001 with location /backup/dbbackup.1 device type D db2 update history for 19970413100000002 with location /backup/dbbackup.2 device type D
The primary purpose of the database history records is to record information, but the data contained in the history is used directly by automatic restore operations. During any restore where the AUTOMATIC option is specified, the history of backup images and their locations will be referenced and used by the restore utility to fulfill the automatic restore request. If the automatic restore function is to be used and backup images have been relocated since they were created, it is recommended that the database history record for those images be updated to reflect the current location. If the backup image location in the database history is not updated, automatic restore will not be able to locate the backup images, but manual restore commands can still be used successfully.