The second option is actually what we're doing right now.

We extract the logs with db2adutl locally and rsync them over to the DR
site. The other option was granting proxy access for a node to read the
logs for the PROD node directly from TSM. This has a bit of an issue if
you lose the primary site. You'll have to update the remote
dsm.opt/dsm.sys and point to a local server. The nice thing is that the
remote node can only read the backups or logs from the TSM server and
not write.

I was just looking for any other ideas. The export node option won't
really work because we don't have the pipe between datacenters to
actually push a full node export across the pipe. We MIGHT be able to
pull the log files though.

Allen S. Rout wrote:

On Wed, 8 Feb 2006 10:28:14 -0500, "John E. Vincent" <adsm-l-alias AT clacorp DOT 
com> said:

We've been working on our DR site and wanted to try and leverage TSM
for DB2 logs.

We currently run v8.2.2 of DB2 UDB. We archive our logs to TSM. What
we'd like to do is use a remote storage pool on our TSM server at
the DR site to copy those logs and replay them on our DB2 server at
the DR site.

Is there something like that in TSM EE that we can use? I thought
about using storage pools on remote servers but we actually want to
connect to the local TSM server.

You've got two distinct problems here: One is getting the logs to your
hot-backup DB2 instance.  The other is keeping the DR operations from
fotching the production instance.

I've looked at this in at least shallow detail, and here are the
options I came up with before the whole DR-site thing did the lead
ballon mambo:


1) offsite TSM instance.

 On some periodic basis, you EXPORT the node from the production TSM
 instance to the hot-backup instance, merging filespaces.  Then, your
 hot-backup DB2 can connect to the hot-backup TSM on an ongoing basis,
 periodically playing the logs.

2) Extra copy of logs.

 On some periodic basis you use db2adutl to EXTRACT the logs.  This
 needs to happen under some auspices other than that of the hot-backup
 DB2 instance, because for Gods' sake you don't want the backup
 instance committing a log to the same TSM node as production. Then
 you play the logs from some local disk repository.


I liked the second option, because it made for very clear deliniation
between the prod system and the hot-backup.

I understand that V8 has some capacities similar to PROXYNODE stuff;
you can grant other instances and other nodes access to the
backups. This is documented in the v8 db2adutl docs.

If you play logs with these additional arguments, I'd expect the DB2
internals will be smart enough to disambiguate "where I download logs
to play" from "where I send my logs".  That might be profitable.


- Allen S. Rout