2.Primary key. This is a
3.Archive date. This is automatically assigned by DB2 Manager during archival processing, and will be equal to the system date on which the row is archived.
4.Record offset. This is the record number within the object, which contains the migrated row (starting at 0, and continuing up to
A concatenation of these four values will uniquely index each migrated row within the Archive Manager database. This information is held in the archive stub used by DB2 Manager to replace the migrated row in the DB2 table.
All facilities supplied by the base Archive Manager product for managing data within the Archive Manager database are available for use with an DB2 Manager implementation. This includes the following:
•Multiple tape copies
•Disk (‘K’) copy processing
•Disaster recovery support
•Multiple storage levels per database
•Tape recycling
•Tape backup/recovery support
•Dynamic load balancing
Product implementation
Implementation of DB2 archival solutions using DB2 Manager is aimed at tables and applications with the following characteristics:
•A high proportion of row retrieval requests are satisfied from a small proportion of the rows (eg) 90% of the requests reference only 10% of the rows. This can occur with tables which hold historical information – customer transactions etc.
Data access patterns of this nature will permit an aggressive row archive policy to be implemented while limiting the impact on overall DB2 response times, giving significant benefits in terms of reduced disk space utilization and/or DB2 housekeeping overhead.
•Once archived, data rows are unlikely to be updated frequently. Updating of an archived row via SQL command will cause the row to be returned from Archive Manager storage to DB2 storage (ie) “unarchiving” the row. The row will be subsequently
14 | DB2 Manager User Guide |
| StorageTek Proprietary |