Matt, I'm in agreement with Troy's posting below. If you are seeing high i/o wait on your TSM database volume(s), then this is a good contender for the root of some/all of your problem. The interesting point is your post says 'volume' singular.
I would be a good idea to get your database spread across as many physical disks as possible and preferably on a different controller and different bus to that which is handling your diskpool and tape operation. If your server is from the Unix world, then consider using raw disk for your DB volumes instead of a filesystem. Try to configure TSM db volumes the same size as you have configured the raw disk. If you can afford 15Krpm disk then go for this. A 'possible' configuration for TSM database disk layout could be a separate SCSI attached chassis of 12 x 18GB 15Krpm disks. Only configure each disk with a raw partition of 4GB starting from the outermost sector (ie limit the head movement). Configure TSM for 12 x 4GB db volumes. If using TSM s/w database mirroring, consider duplicating the above arrangement on a separate controller. I appreciate that there is wastage here but it IMO it's worth it, if better performance is required. The main thing is to get your DB spread over as many physical spindles as possible, if RAW disk is an option, use it. Configure TSM db volumes equal to your physical partitions and use the outer most sectors of the disk where possible. Leigh -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Troy Frank Sent: 24 October 2005 21:35 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Slow restoratoins when large backups are happening? 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.