DB2 and TSM – How to put them to work together (Part I)
Norberto 2000000SR8 Comments (2) Visits (6041)
Hi fellows… I have been busy for a couple of weeks, and one of the tasks I dealt with was configuring DB2 to target its backups and log archives to TSM. I then thought it would be nice if I shared the related tips and tricks in my blog. Hope it will be useful.
As this text got bigger than I expected, I decided to divide it in 2 entries, so you won’t be tired reading it all in a single one. Enjoy! If you see any errors or need any clarification, please let me know.
First, some concepts about TSM…
DB2 Backups and Log archives
As we DBAs know, every change made in a DB2 database is previously written on its log files. As the logs are being released (changed from “online” to “offline” state), they are no longer used by the database, so they can be archived (and there’s where TSM starts to play).
These logs are used for, in case of a disaster, reapplying changes made to the restored database, enabling a database backup to be restored - having the same data as in the moment the disaster took place (in case all the logs are intact). That can be done through the “ROLLFORWARD” command.
We can’t rely on the server’s disk to store backup images and log archives. What if our disks got corrupt? Yep, our backups would be gone as well. And we wouldn’t be able to restore anything!
Through TSM, we can easily retrieve an specific backup image, and apply all the logs necessary to have all the info up to a point in time we can specify. All that can be done through commands db2adutl, RESTORE and ROLLFORWARD (TSM client is invoked by those commands and gives DB2 the right files based on the parameters received).
BA x API client methods
Backup Archive is the method TSM uses to transfer the filesystems selected in the TSM include/exclude list (a file you specify which dirs will be included to or excluded from the transfers). There is no interaction between DB2 and TSM in this mode. But till today I already saw lots of servers configured to just throw log archives and backup images to an specific dir in the server, relying on TSM daily transfer. I consider this as a bad practice. It generates a lot of unnecessary network traffic (same backup images will be transferred to TSM as well as logs) and it is harder to restore a database when you need. Restoring a database backed up using this method can take time and can also require someone from TSM team to help.
Through API, DB2 interacts with TSM, and they work together. Backups can be sent directly to TSM (through USE TSM clause on BACKUP DATABASE command), and logs can be archived directly too, through LOGARCHMETH1 or LOGARCHMETH2 parameters. There are no “staging” filesystems used in the database servers – so storage is used more wisely, as well as network traffic between DB2 and TSM servers. Another point I cannot forget to mention is that the TSM daily backups (files) will take less time.
Linux or Unix?
As a DBA, you’ll likely not have to install TSM client (usually someone with specialized skills will do that for you).
AIX – TSM is usually installed on dir /usr. E.g.: /usr/tivoli/tsm
Also, if your Linux is 32 bit, TSM binaries will be on dir “bin” instead of “bin64”. E.g.: /usr
On the next part of this blog you’ll know the steps to configure DB2 and TSM so you can properly take your backups and log archives directly to TSM.
I plan to publish the final part of this blog shortly (yet this week). This entry will have a link to it.