Back Up a DB2 Database using Tivoli Storage Manager
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
- Conclusion
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 V4.2.2.1. 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:
$db2 get db cfg for artist | grep TSM TSM management class (TSM_MGMTCLASS) = TSM node name (TSM_NODENAME) = TSM owner (TSM_OWNER) = TSM password (TSM_PASSWORD) =
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:
db2 => backup db ARTIST online use tsm (open 4 sessions with 8 buffers buffer 1024 parallelism 2) Backup successful. The timestamp for this backup image is : 20040112104447
Producing an offline database backup using TSM, for the test DB2 database ARTIST:
db2 => backup db ARTIST use tsm (open 4 sessions with 8 buffers buffer 1024 parallelism 2) Backup successful. The timestamp for this backup image is : 20040112132311
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.
$ db2 get dbm cfg | grep BUFSZ Backup buffer default size (4KB) (BACKBUFSZ) = 1024 Restore buffer default size (4KB) (RESTBUFSZ) = 1024
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.
$ dsmc q fil Tivoli Storage Manager Command Line Backup Client Interface - Version 4, Release 2, Level 2.1 (C) Copyright IBM Corporation, 1990, 2001, All Rights Reserved. ANS1216E Not authorized to run TSM. See the administrator for your system
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:
root@ARTIST:/home/adsm/adsmconf/logs # tail dsmserv.log 1020916-050916: ANR0406I Session 5711 started for node ARTIST_DB2 (DB2) (Tcp/Iroot@ARTIST:/home/adsm/adsmconf/logs 1020916-060056: ANR4554I Backed up 8736 of 11705 database pages. 1020916-060100: ANR4554I Backed up 10192 of 11705 database pages. 1020916-060104: ANR4554I Backed up 11648 of 11705 database pages. 1020916-060105: ANR1361I Output volume 04EDB0 closed. 1020916-060105: ANR4550I Full database backup (process 847) complete, 11705 pages copied. 1020916-060105: ANR0985I Process 847 for DATABASE BACKUP running in the BACKGROUND completed 1020916-060105: with completion state SUCCESS at 06:01:05. 1020916-060109: ANR8336I Verifying label of 3570 volume 04EDB0 in drive RMT0 (/dev/rmt0). 1020916-060126: ANR8468I 3570 volume 04EDB0 dismounted from drive RMT0 (/dev/rmt0) in library 1020916-060126: MAGSTARMP.
DB2 Backup Control
As a part of the default installation, a utility called db2adutl is automatically installed into the /$HOME/sqllib/bin directory as a link to the DB2 software installation directory.
$ pwd$ /home/artist/sqllib/bin$ >> ls -lrt db2adutl lrwxrwxrwx 1 root other 30 Jul 26 2002 db2adutl -> /opt/IBMdb2/V7.1/adsm/db2adutl
The DB2 system command db2adutl is used to directly manage database backup and database archived log files on the TSM. Functionality integrated in the db2adutil makes the TSM server content management possible. Operations such a list, delete or retrieve database backups, load copy images and archived database logs are achievable without the need to use dedicated TSM client tools. Supplementary, db2adutil provides the database backup history file content management.
Performing the full database backup management on the TSM using db2adutl program:
$ db2adutl query Retrieving full database backup information. full database backup image: 1, Time: 20040119130942,Oldest log: S0000005.LOG, Sessions used: 1 full database backup image: 2, Time: 20040119142241,Oldest log: S0000006.LOG, Sessions used: 1 Retrieving table space backup information. table space backup image: 1, Time: 20040119094003,Oldest log: S0000004.LOG, Sessions used: 1 table space backup image: 2, Time: 20040119093043,Oldest log: S0000005.LOG, Sessions used: 1 Retrieving log archive information. Log file: S0000005.LOG Log file: S0000006.LOG $ db2adutl delete full taken at 20040119130942 db artist Query for database ARTIST Retrieving full database backup information. Please wait. full database backup image: ARTIST.0.artist.0.20040119130942.000 Do you want to deactivate this backup image (Y/N)? y Are you sure (Y/N)? y $ db2adutl query Query for database artist Retrieving full database backup information. full database backup image: 2, Time: 20040119142241,Oldest log: S0000006.LOG, Sessions used: 1 Retrieving table space backup information. table space backup image: 1, Time: 20040119094003,Oldest log: S0000004.LOG, Sessions used: 1 table space backup image: 2, Time: 20040119093043,Oldest log: S0000005.LOG, Sessions used: 1 Retrieving log archive information. Log file: S0000005.LOG Log file: S0000006.LOG
The DB2 system command db2adutil cannot be used to delete individual incremental or delta backups. The db2adutil command syntax covers only full, tablespace or load copy backup delete operations. For deleting incremental and delta backups, we are obligated to use time options such as OLDER THAN or OLDER.
+-DELETE--+-------------------------------------------------------+----------+ | +-+------------+---+----------------------------------+-+ | | | +-TABLESPACE-+ +-KEEP--n--------------------------+ | | | | +-FULL-------+ +-OLDER--+-------+---+-timestamp-+-+ | | | | '-LOADCOPY---' | '-THAN--' '-n--days---' | | | | | '-TAKEN AT--timestamp--------------' | | | '-LOGS--+-------------------------+---------------------' | | '-BETWEEN--sn1--AND--sn2--'
DB2 Archive Logs Control
The database archive log files are saved in a separate management class: archive management class. A default setting for the archive management class, affecting all archive files, causes them to never expire. Archived log files have to be deleted manually.
Performing check for the archived log files on the TSM server using db2adutl program:
>>more /opt/tivoli/tsm/client/ba/bin/inclexcl.def include /ARTIST/NODE0000/S*.LOG MGMT_LOGS >> dsmc query archive "/ARTIST/NODE0000/S*.LOG" API 40.968.192 B 01.02.2004 09:01:03 /ARTIST/NODE0000/S0000001.LOG Log file for DB2 database ARTIST API 40.968.192 B 01.02.2004 09:01:47 /ARTIST/NODE0000/S0000002.LOG Log file for DB2 database ARTIST API 40.968.192 B 02.02.2004 03:02:18 /ARTIST/NODE0000/S0000003.LOG Log file for DB2 database ARTIST API 40.968.192 B 03.02.2004 15:01:03 /ARTIST/NODE0000/S0000004.LOG Log file for DB2 database ARTIST API 40.968.192 B 04.02.2004 02:01:47 /ARTIST/NODE0000/S0000005.LOG Log file for DB2 database ARTIST
> db2adutl DELETE LOGS BETWEEN S0000000 and S0000002 Query for database ARTIST Retrieving LOG ARCHIVE information. Log file: S0000000.LOG, Node: 1, Taken at: 2004-02-01-09.01.03 Do you want to delete this log image (Y/N)? Y Are you sure (Y/N)? Y Error: dsmEndTxn failed with ADSM reason code 27
In the example above, deleting archived log files from the TSM server, using db2adutl was unsuccessfully terminated with the reason code 27. As stated before, a standard TSM configuration prohibits the immediately deletion of the archive log files from the TSM server, using db2adutil command, signaling for a delete command as not authorized.
/* ----------------------------------------------------------------- */ /* User Exit Supported Return Codes */ /* NOTE: DB2 will reinvoke the user exit for the same request */ /* after 5 minutes if return code is 4 or 8. */ /* */ /* For other non-zero return codes, DB2 will not invoke */ /* user exit for the database for at least 5 minutes. */ /* If this request is to archive a log file, DB2 will not */ /* make another archive request for this file, or other */ /* log files produced during the 5 minute time period. */ /* These log files will only be archived when all */ /* applications disconnect from and the database, and the */ /* database is reopenned. */ /* ----------------------------------------------------------------- */ #define RC_OK 0 /* ok */ #define RC_RES 4 /* resource allocation error */ #define RC_OPATTN 8 /* operator/user attention required*/ #define RC_HARDWARE 12 /* hardware error */ #define RC_DEFECT 16 /* software error */ #define RC_PARM 20 /* invalid parameters */ #define RC_AUDIT 21 /* error open audit file */ #define RC_NOTFOUND 24 /* db2uext2() / file not found */ #define RC_UNKNOWN 28 /* unknown error */ #define RC_OPCAN 32 /* operator/user terminated */
An instance of the user exit archive log for the successfully externalized archive log and for the error due to system error (error code 16):
>> vi USEREXIT.ERR | more ******************************************************************************** Time Started: Wed Jan 24 17:18:12 2004 Parameter Count: 8 Parameters Passed: Database name: ARTIST Logfile name: S0000378.LOG Logfile path: /ARTIST/NODE0000/ Node number: NODE0000 Operating system: Solaris Release: SQL07025 Request: ARCHIVE System Action: ARCHIVE from /ARTIST/NODE0000/ file S0000378.LOG to ADSM for database ARTIST Media Type: ADSM User Exit RC: 0 ' saving archive log successfully executed Time Completed: Wed Jun 24 17:18:12 2004 ******************************************************************************* Time of Error: Fri Jan 26 13:02:15 2004 Parameter Count: 8 Parameters Passed: Database name: ARTIST Logfile name: S0000394.LOG Logfile path: /ARTIST/NODE0000/ Node number: NODE0000 Operating system: Solaris Release: SQL07025 Request: ARCHIVE Audit Log File: /home/sqllib/tsm/ARCHIVE.LOG System Call Parms: Media Type: TSM User Exit RC: 16 ' software error
The reason, for this behavior is quite obvious. Missing one archive log file from many of saved on the TSM server, entirely disables the recovery chain. Accidental deletion is not possible with the default setting. On the other hand, we can change these default settings, enabling the database administrator the purging rights for the database archive log files on the TSM server.
Conclusion:
Regular notes from IBM do not cover some "situations" which appear during regular TSM usage. For this reason, I will pay special attention to a group of interesting situations I have found working with the TSM, on the Sun Solaris operating system, in the next article.