What's the layout of the db volumes? ie. how many dbvol's do you have, and how many arrays/spindles/controllers are they spread out across? The other thing I forgot to ask before was what OS the tsm server is on. Another thing to look at is what your db cache-hit percentage is. Could be there's a lot of disk contention due to insufficient db buffering.
Troy Frank Network Services University of Wisconsin Medical Foundation 608.829.5384 >>> [EMAIL PROTECTED] 10/24/2005 2:58 PM >>> > There's also performance internal to the tsm server to consider. > The large server backups could be monopolizing your network > throughput, scsi card throughput, pci/pci-x bus throughput, or some > combination of all the above. > System performance monitoring shows hardly any network I/O during this situation. After all there is incremental backups running, it's not backing up much. On the restorations, it was 10,000 files for 8 GB. again not much. One issue I have seen is high i/o wait on the TSM database volume, which is why I know I have a database I/O issue, but, cancelling the larger backups should not cause the restoration to suddenly jump from sending a few hundred mb per hour to a gig every 5 minutes. Which is why I think it's an internal TSM issue and not a hardware performance issue. But maybe it is. I Just need more input into what to look for. Matt Glanville Confidentiality Notice follows: The information in this message (and the documents attached to it, if any) is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken, or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this message in error, please delete all electronic copies of this message (and the documents attached to it, if any), destroy any hard copies you may have created and notify me immediately by replying to this email. Thank you.
