made to the database. These logs allow DB2 to recover all changes made to the database since the time
of the last database backup, forward to the time when DB2 was stopped by a crash, hardware fail ure,
power outage or whatever. It is vital that the DB2 log files be hosted on a highly reliable disk systems.
Furthermore, DB2 log mirroring must be used to protect this information on two separate disk systems.
The disks systems must also be protected using RAID 1 or RAID 5 configurations. Reliable access to the
log files is more important than performance. Loss of the DB2 log files can result in a signifi cant impact
to the operation of the system, extensive downtime to repair, and potential loss of end-user data. Proper
protection of the DB2 log files and associated archived backups is critical to a site's HPSS operations.
Similarly, the HPSS administrator must regularly verify that completed DB2 log files are being stored on
reliable media until they are no longer needed. Many sites make multiple copies of DB2 log files a nd
store them in separate physical locations.
In case of a catastrophic failure of the HPSS database host computer, the database can be restored to a
consistent state at the point in time of the failure, if the administrat or has a reliable series of backup
images and log files. After the failure that caused the database failure i s corrected, the HPSS databases
can be restored using the backup files, and then by replaying the DB2 log files. Much of this process
happens automatically when DB2 is restarted, but if you have any questions about these requirements and
procedures, please contact your HPSS Support Representative.
Another responsibility of the HPSS administrator is to periodically perform RUNSTATS ope rations on
the database tables. RUNSTATS is a DB2 process that analyzes the tables and produces statistics that
are vital to DB2's performance. Without good statistics, DB2 may create very inefficient database a ccess
plans that result in very poor performance. Although frequent RUNSTATS are not necessary on HPSS
databases, the administrator should have a plan to perform them on some sort of regular schedule
consistent with local requirements. You should discuss this with your HPSS Support Represe ntative.
It is also important to have a plan to perform REORGCHK operations from time to time to monitor the
organization of the database tables. As a consequence of normal use, a database table may become
significantly disorganized. Database performance can be enhanced by periodic reorganizations, some of
which can be performed with HPSS in operation. You should also discuss this with your HPSS Support
Representative.
15.1.2. Overview of the D B2 Backup Process
Without proper and systematic metadata backup, a database failure could result in total loss of the HPSS
system. For this reason, backing up the DB2 databases containing HPSS metadata is essential.
DB2 databases can be backed up in one of two ways:
1. Online backups are made that can be restored t o the point of failure by “rolling forward”
archived logs of transaction activity since the backup.
This is the recommended method for making HPSS backups.
2. An offline snapshot of the database data is taken at a particular point in time.
Offline backups provide recovery only to the point in time at which they were made, and they
require that there be no other activity in the database while they are being made. Ther efore, this
method is not recommended for use with HPSS.
Since HPSS installations require the use of online backups, it is useful to understand the types of backup
and restore operations that can be performed with this backup type. Online backups can be descri bed as
HPSS Management Guide November 2009
Release 7.3 (Revision 1.0) 357