Tips for using Tivoli Storage Manager with DB2
April 28, 2004
As a final word about Tivoli Storage Manager (TSM) database backup, here are a few tips I have found working with the TSM system. Only the most interesting tips are included since presenting all of them would be beyond the scope of this article.
This article covers:
Tips Using TSM
Tip 1.User Exit is archiving log files more than once
An unusual and confusing DB2 feature is the existence of duplicated archived log files on the TSM server. One theory is that once a database log file is full a database manager is creating a user exit program queue entry. The user exit program is starting with a log file copy to the archive log destination. In our case, the archive log destination is on the TSM server. Upon finishing, a database log file is renamed to a new name with higher sequence log number. This explanation is as expected, unless a TSM inventory is made.
Listing 1: Listing archived log files directly from the TSM server
The database log file S0000021.LOG had occurred two times on the TSM server. Both archived log files have the same size; however, there is a difference in the timestamp.
Knowing that the main principle of database integrity is the existence of a unique archive log file, there may be uncertainty about which one is the right one. The secret lies in the imperfection of the user exit program and not in the DB2 database itself.
To demonstrate my claim, I have created a scenario for generating duplicate archive log files on the TSM server:
Listing 2: Generation of duplicated archive log files on the TSM server
Following this explanation, the user exit program, initiated from DBM is creating two copies on the TSM server. It has been my experience that we can even find two identical files with different sizes, where the first file is smaller than the second one. Generally speaking, this is not a problem, because the file with the later timestamp is only considered during recovery.
Tip 2. Backup restored from the TSM server having wired timestamp
During a DB2 database redirected, restore operation there was an occasion to retrieve a database backup image from the TSM on the local file system. After restoring the backup image, the restored file has "strange" timestamp information associated.
Listing 3: Restoring database backup image from the TSM server to the local filesystem
The restored backup image file has an incorrect date-stamp, showing a file date-stamp of 15.08.1995, instead the regular one of 01.16.2004. Searching for an explanation of these phenomena, all I found was a "small incompatibility" between the Sun Solaris operating system and the TSM Server. Ignoring that, the restored database backup was fully usable.