ADSM-L

Re: [ADSM-L] Backup Stgpool using 2 drives taking too long

2009-08-03 16:46:18
Subject: Re: [ADSM-L] Backup Stgpool using 2 drives taking too long
From: Bob Levad <blevad AT WINNEBAGOIND DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 3 Aug 2009 15:44:18 -0500
Mario,

Based on your server level (5.5) you may be experiencing the following:

IC57855: TSM SERVER DELAYS TRANSACTIONS BY 1 SECOND WHEN RECOVERY LOG
UTILIZATION EXCEEDS 80% RESULTING IN PERFORMANCE DEGRADATION

Please check your recovery log utilization to see if this may be the issue.

With only two tape drives, you may be blocking the system's attempts to run
an incremental DB backup.

If this is the issue, you may want to direct incrementals to a disk or file
devclass.


Bob.


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
John D. Schneider
Sent: Monday, August 03, 2009 3:32 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Backup Stgpool using 2 drives taking too long

Mario,
So, if I understand this correctly, the primary storage pool is LTO4, and
the copy storage pool is LTO4, and so the whole "backup stgpool" is straight
tape to tape.  Is that correct?

When you say the process becomes "idle" for 20 minutes, how can you tell it
is idle?  Do you mean the number of bytes copied doesn't get any bigger?
The total byte count only gets updated at the end of each aggregated file.
That is, if the copy stream hits a 300GB single file, then the copy will
proceed to copy that file as fast as tape performance permits, but the total
byte count won't increase until that huge file completes.  And a
multi-hundred GB file could easily take 20 minutes or more.

Next time you catch it in this state, look at the size of the current file,
and do the arithmetic.  Is it possible that is what you are seeing?

If you can look at the tape drives themselves, you can tell if the tape
drives themselves are reading and writing, or sitting idle, can't you?
I suspect that the tape drives will be buzzing away, even though it seems
like you aren't making progress.

If I have misunderstood, and you can tell that the drives are really idle,
then I would look at drive firmware next, then at IBMtape drivers.
 Make sure you are up-to-date  We have 6 TSM Windows servers with IBM
libraries and drives, and we are not seeing the symptom you describe, that
is, periods of actual stalled backup stgpools.

Feel free to contact me offline if you have not done the firmware and driver
updates before, and need any assistance.


Best Regards,

 John D. Schneider
 The Computer Coaching Community, LLC
 Office: (314) 635-5424 / Toll Free: (866) 796-9226
 Cell: (314) 750-8721


  -------- Original Message --------
Subject: [ADSM-L] Backup Stgpool using 2 drives taking too long
From: Mario Behring <mariobehring AT YAHOO DOT COM>
Date: Mon, August 03, 2009 1:34 pm
To: ADSM-L AT VM.MARIST DOT EDU

Hi list,

The environment is TSM Server 5.5 running on a Windows 2003 box with a IBM
ULT3580-TD4 SCSI (2 drives) connected.

There is a backup stgpool process running on background for more than 12
hours (several schedules were missed during this time).

The process is using both drives, one reading the data and the other
writing, as expected. The problem is that, at some point, both drives stay
IDLE for more than 20 minutes...then start reading/writing again (for a
short time I might add).

The process would be long over by now if this was not happening...what could
be wrong and how can I put the drives to work non-stop, if possible...??

Any process that uses both drives in this fashion, like an EXPORT for
example, is behaving the same way...

Thanks

Mario

This electronic transmission and any documents accompanying this electronic 
transmission contain confidential information belonging to the sender.  This 
information may be legally privileged.  The information is intended only for 
the use of the individual or entity named above.  If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, distribution, 
or the taking of any action in reliance on or regarding the contents of this 
electronically transmitted information is strictly prohibited.