ADSM-L

Re: [ADSM-L] Including logs in DB2 backups

2011-02-24 01:23:57
Subject: Re: [ADSM-L] Including logs in DB2 backups
From: Steven Harris <steve AT STEVENHARRIS DOT INFO>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 24 Feb 2011 19:20:53 +1300
Thomas, Chris

Since the archive logs are TSM archives, use a different destination for
the archive copygroup in the DB2 managementclass  to move the logs to a
different stgpool hierarchy from the DB backups..  That way  they will
never conflict at the volume level.  I put mine onto a file pool with a
migdelay  of 1 (wish I could use 0.5) so that when they are retrieved I
also avoid pre-emption because of a shortage of drives, but you may have
more log to handle than I do


Regards

Steve.

Steven Harris
TSM Admin
Paraparaumu New Zealand.



On 24/02/2011 10:35 AM, chris rees wrote:
Hi

I'm not a fan of include logs for the same reasons you mentioned, we had backup 
failures caused by the retrieve processes stealing mount points.  We've 
excluded the logs and thoroughly tested recovery. It doesn't cause any issues 
as long as your normal archive log backups to TSM are working.

Have you got a test environment you can use to convince your DBA's?

Cheers

Date: Wed, 23 Feb 2011 14:16:04 -0500
From: Thomas.Denier AT JEFFERSONHOSPITAL DOT ORG
Subject: Including logs in DB2 backups
To: ADSM-L AT VM.MARIST DOT EDU

Some months ago I reported that some of the DB2 servers at our site were 
retrieving
archived files during database backups. The TSM server ended up cancelling at 
least
one and sometimes more than one of our offsite tape reclamation processes to 
make
tape drives available for the retrieve operations. I got a response from Michael
Garnebode explaining that the fix was to put "exclude logs" in the configuration
files for DB2 backups. When I asked our DBAs to do this I found out that 
including
the logs in DB2 backups was a deliberate choice which they were very reluctant 
to
give up. At the time I was willing to settle for a compromise: keep including 
the
logs but reschedule some DB2 backups so that there was never more than one 
concurrent
retrieve, and never more than one reclamation process cancelled. The TSM 
workload
has increased since then, and I would rather not have any reclamation processes
cancelled on a routine basis. My impression is that the "include logs" option is
completely pointless in a TSM environment. Is this correct?
                                        

<Prev in Thread] Current Thread [Next in Thread>