==> On Fri, 11 Feb 2005 15:38:58 -0500, "Martinez, Matt" <[EMAIL PROTECTED]> said:
> I have an opportunity to redesign the disk pool and db layout of our TSM > Server , and I was wondering if my fellow TSMers can help me with it. First > things first our environment is as follows, TSM Version: 5.1.7 soon to be > 5.2.? on Win2k, the Disk the DB will be stored on will be a RAID 5 Disk on a > EMC CX700 array. > My main question is can TSM read/write multiple streams to a single Disk or > DB vol? Multiple backup streams to a DISK stgpool volume: Yes. Multiple streams to a DB vol: not well formed question: there aren't streams of data hitting the DB vols. I suggest you hit the archives for some of the older discussions about optimization points for DB volumes. My own solution to these has been to deploy a large number of relatively slow spindles for DB, and some very fast disk for recovery log, but that's a completely different hardware regime. > The reason I would do this is to optimize the I/O across all the > spindles. If you want to have large RAIDs (to minimize loss of space to parity drives) then you might as well have large volumes as small. While there are multiple streams permitted to hit a DISK volume at a time, there's only one thread of execution talking to a given volume at a time. This means that if you have two volumes in the same stgpool on the same RAID, that you're going to engender some contention. If you've only got one volume in the stgpool, then you've serialized on the stgpool, which isn't so bad because you need to serialize on the underlying RAID anyway. To solve this on my own system, I've got my SSA chopped up into 5-disk RAIDs, which I understand to be a performance sweet-spot for 36-G SSA disks. Then every DISK pool I've got has a volume on each RAID. It's really kind of cool to watch a high-throughput session run, because you can see a throughput spike drift from RAID to RAID as the incoming session round-robins through the available disk volumes. - Allen S. Rout