UPDATE HISTORY command

Authorization

Required connection

Database

Command syntax

>>-UPDATE HISTORY--+-FOR--object-part-+--WITH------------------->
                   '-EID--eid---------'         

>--+-LOCATION--new-location--DEVICE TYPE--new-device-type-+----><
   +-COMMENT--new-comment---------------------------------+   
   '-STATUS--new-status-----------------------------------'   

Command parameters

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. 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:

D

Disk

K

Diskette

T

Tape

A

Tivoli® Storage Manager

F

Snapshot backup

f

Snapshot backup that was generated by a custom script.

U

User exit

P

Pipe

N

Null device

X

XBSA

Q

SQL statement

O

Other

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 values are:

A

Active. The backup image is on the active log chain. Most entries are active.

I

Inactive. Backup images that no longer correspond to the current log sequence, also called the current log chain, are flagged as inactive.

E

Expired. Backup images that are no longer required, because there are more than NUM_DB_BACKUPS active images, are flagged as expired.

D

Deleted. Backup images that are no longer available for recovery should be marked as having been deleted.

X

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.

Example

   db2 update history for 19970413100000001 with
      location /backup/dbbackup.1 device type D

Usage notes

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.