In my last article "DB2 Database and Tivoli Storage Manager," we prepared an entire backup system for performing a first TSM database backup.
This article examines the procedure for making a database backup using Tivoli Storage Manager, (TSM).
This article covers:
- Performing Database Backup using TSM
- DB2 Backup Control
- DB2 Archive Logs Control
Performing Database Backup using TSM
In general, all Tivoli Storage Manager Client versions work with every version of DB2. In our setup we have DB2 UDB V7.1 and Tivoli Storage Manager Client API V126.96.36.199. A short remainder on the existing setup:
Click for larger image
Picture 1: TSM Infrastructure
A DB2 database is delivered with several utilities and database configuration parameters for TSM support. The DB configuration parameters, related to the TSM Server are as follows:
The presented database configuration parameters should not be configured. The database settings for the TSM management class, TSM node name, TSM owner and TSM password is taken from the TSM API environment configuration files. In the IBM documentation, IBM emphasized that database TSM parameters are designed in the first place for redirected database restore. Nevertheless, I have seen many installations where some or all TSM database parameters were used, overriding settings provided over TSM API configuration.
The DB2 database backup is being saved directly to the TSM server backup medium, without storing an intermediate copy on the local server, which results in a decline of storage costs and easy handle of large databases. Generated database backups are TSM backup objects. Every TSM backup object is transformed between 4 different states:
- Active backup - backup is needed for recovery, actual on the TSM
- Inactive backup - backup is deleted from database history file, has inactive status on the TSM, retention period for this backup has been started
- Expired backup - retention period has elapsed and backup can be physically deleted
- Deleted backup - backup is deleted from the TSM storage
Each new backup has a unique name and newly created database backup do not deactivate previous backups. Manual action is needed, using the db2adutl command in order to change backup status from active to the inactive. The predefined management class is the control hold period for every database backup.
Producing an online database backup using TSM, for the test DB2 database ARTIST:
Producing an offline database backup using TSM, for the test DB2 database ARTIST:
Additional backup parameters used in performing backup (sessions, buffers, parallelism), are useful for tuning backup execution time. Backup buffers are allocated on demand, on backup start and deallocated at the backup end. Backup buffers are taken from the utility heap (util_heap_size) database manager memory area.
Each system needs some control mechanism. Use the command
line TSM client or the graphical TSM client to
check for the presence and size of the DB2 database backups and archive log
files. Before starting work with the TSM server, ask your TSM administrator for the proper account on the TSM server. Without a TSM server account, you cannot check or restore backup copies and archived log files directly on the TSM server without use the DB2 database utilities.
It would be helpful to obtain one additional right from the TSM administrator--the right to use a graphical TSM console, for a quick and informative summary of the TSM server backup content.
Picture 2: TSM Graphical User Interface
The status for the current, active TSM connection and ongoing backup progress is managed by tracking changes in the TSM server log file. An instance of the TSM log file content: