DB2 Database and Tivoli Storage Manager

My first DB2 article,
"Who needs incremental delta backup" published on January 29, 2003 was an introduction to the DB2
backup and recovery technology on the SUN Solaris platform. Since then, I have
been asked many times to write on some very interesting topics that are not covered
in detail in the existing IBM documentation. All requests from the readers have
been collected, resulting in this new series of DB2 articles. This first
article examines DB2 backup techniques with the Tivoli Storage Manager (TSM) Application
programming interface (API) on the Sun Solaris operating system.

This article covers:

  • TSM System

  • TSM Server
    Configuration

  • UNIX Server
    Configuration

  • DB2 Database
    Setup for TSM usage

  • DB2 Database
    Features using TSM

  • Conclusion

TSM System

For those who have worked with the
ADSM -ADSTAR Distributed Storage Manager, this product was replaced 1999 with
the new Tivoli Storage Manager (TSM) from Tivoli Systems Inc. The TSM is just a
part of the Tivoli Storage Management product set intended for providing
universal, enterprise-wide backup, archive, restore and retrieve solution. The
most recent TSM commercial version has many new, integrated functions, such as
disaster recovery and specific storage management functions. Nevertheless, the
basic TSM functions remain unchanged, providing the network cross-platform
backup and archive solutions. The focus of this article is on TSM’s integration
with the DB2 database; however, even though the DB2 database has integrated
support for Tivoli Storage Manager, TSM is sold as a completely separate
product.

Figure 1. The TSM system infrastructure consisting of the TSM
Server with the DB2 TSM flat database and TSM Storage. Depending upon the data
type, various storage mediums are used; for example, variable data is stored on
magnetic tape and permanent data is stored on optical or magneto-optical discs.

The TSM backup system and the main
components:

a.) TSM Administrator
Workstation,
with an installed TSM administrator console, manages a
transparent database network backup to the TSM System.

b.) TSM server, provides
backup, archive, and space management services storage for the defined clients.
The TSM server uses the local DB2 database for logging and storing activity
logs.

c.) TSM API client
turns a local machine into the TSM client node, making backup, archive, restore,
and retrieve services feasible on the TSM Server. The TSM API provides wide
flexibility for making database backups with opened database files for full or
table space level backup.

d.) The DB2 database
comes packaged with the TSM support, in the form of special utilities for
handling data on the TSM server or integrated DB2 database parameters.

Figure 2. Functional DB2 TSM backup using TSM API exhibits of
distinction between archive log files and database backup files.

Next, just a few words about
internal TSM server structure. Several database servers, nodes in TSM
terminology, are logically grouped into a policy domain. The members of one
policy domain distribute the common storage requests. Every policy domain has one
policy set, constituted of several management classes, associated with it. The
management classes are the marrow of whole structure and main configuration
point. The rules defined in the management class govern data flow to an
appropriate media and control how the data is managed by TSM. Most important to
mention, the management class is used for setting an expiration period for the
backup or the archive log files. The TSM API client sends the backup and archive data to
the TSM Server, together with a description of the object and management class
for the object. The database backups and the table space backups result in the
TSM backup objects, while the database log file results in the TSM archive
objects.

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.

Latest Articles