I actually tested this. Striping is very, very bad for the TSM Database.
1:1 is best.

TSM Database I/O is totally random. Response time is much more important
than throughput - it never transfers a large amount of data in a single
operation. It's all small amounts of data, scattered randomly across the
entire database. Therefore trying to get several physical disks working
at once to do one I/O operation just slows things down. It's faster to
move only one arm for one I/O, and let the other arms move for other
threads simultaneously. Most of the "experts" you talk to will focus on
Throughput, which is why they are wrong about the TSM Database. I had
those same experts telling me how to do things in my shop, which is why
I actually tried striping, and found out that it ran a lot slower.

However, you are correct that the Log and Storage Pool volumes are
different than the database. Especially in the case of Storage Pool
volumes, you want throughput. Let our experts have their way here.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu


On Sat, 12 Apr 2003, Paul Ripke wrote:

>My gut feel (and the advice from an IBM TSM support guru here in
>Australia) is to have 3 or 4 volumes per spindle for database disks.
>Those "spindles" may be logical RAID5 arrays as in a shark, etc. The
>reason, is to allow 3 or 4 outstanding requests to each disk, which
>the disk can then re-order to minimise over-all seek times. Since the
>TSM DB is primarily hit with random read I/O, this *should* be a win.
>
>Of course, trying to test this and come up with some hard numbers
>would be a right-royal PITA... The Sun TSM servers I manage used to
>have the "big & few" DB volume design, but I have since migrated to
>3 volumes per spindle, mirrored in TSM design. I can't say if
>performance is greatly improved, and I have no numbers, but it
>"feels" faster. Makes me wish I had recorded expiration start and
>finish times (although, that's probably a single thread in TSM and
>won't prove anything)...
>
>Since log volumes are sequential read-write, this does not apply to
>them. And storage pool volumes? That depends on a whole bunch of
>other factors.
>
>Cheers,
>--
>Paul Ripke
>Unix/OpenVMS/TSM/DBA
>101 reasons why you can't find your Sysadmin:
>68: It's 9AM. He/She is not working that late.
>-- Koos van den Hout
>