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) =


Listing 1: TSM related database parameters

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
Listing 2: Online TSM database backup

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

Listing 3: Offline TSM database backup

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

Listing 4: Backup and Restore Buffer Size

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
Listing 5: TSM server authorization failure

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.


Listing 6: Monitor TSM server backup progress
Marin Komadina
Marin Komadina
Marin was born June 27, 1968 in Zagreb, Croatia. He graduated in 1993 form The Faculty for Electrotechnology and Computer Sciences, University of Zagreb in Croatia. He started his professional career as a System specialist and DBA for the Croatian company Informatika System. His most important project was the development and implementation of the enterprise, distributed point of sales solution, based on the Oracle technology. In 1999, Marin became the company CTO, where he played an active role in company development and technical orientation. After Informatika System, Marin worked as an IT Manager Assistant for the Austrian international retail company "Segro," on location in Graz (Austria) and Zagreb (Croatia). He was responsible for the company's technical infrastructure and operational support. Segro used IBM technology, OS/400 operating system and DB2 database. In 1998, Marin joined the international telecommunication company VIPNet GSM that was a part of greater concern, Mobilkom Austria& Western Wireless Int. USA. After one year, Marin took over the IT System Manager position, where he managed many multi-platform, telecommunication projects and was leading the IT system department. In 2001, Marin started to work in Germany as a senior system architect. He is currently working for German banks on different banking projects.

Get the Free Newsletter!

Subscribe to Cloud Insider for top news, trends & analysis

Latest Articles