I don't really think putting 1 volume on each drive spindle would improve
performance, especially when TSM DB is doing sequential read/write. On the
contrary, if you could put the volume on multiple spindle, each sequential
I/O will be spreaded on multiple spindle, which should dramatically increase
IO throughput. And if the disk subsystem have large cache, random read/write
could benefit from the multiple spindle also.

-Fred

-----Original Message-----
From: asr AT UFL DOT EDU [mailto:asr AT UFL DOT EDU]
Sent: Friday, April 11, 2003 12:09 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Limitation of TSM DB Volumes


=> On Thu, 10 Apr 2003 16:50:32 -0400, Fred Yang <FYang AT NSHS DOT EDU> said:

> Since we estimated our DB size will grow to around 180G, and performance
is
> our primary concern. So if increasing DB volumes could really benefit
> performance, I don't mind the addtional space used for LVM overhead unless
> the overhead affect performance consequently.

IMHO, "number of threads" is probably not an interesting knob to turn unless
you are pretty confident that all the -other- performance implications of
your
differing designs are close to identical.  If I'm recalling correctly, the
distilled Advice From The List is less focused on actual count of volumes,
and
more focused on making the volumes align neatly with what's underneath them.


So, if you've got (say) a full drawer of 9-GB SSA disks (*koff* like me)
then
you have 12 DB volume mirrors, for a total of 6*9 GB raw space, two more log
volumes, and two volumes waiting in the wings to be thrown in, in case of
emergency.

If I had a quarter-drawer of 36-GB drives, I'd have four volumes, one per
drive spindle.  At that point you have to debate

increase-in-performance-from-two-threads
 vs.
decrease-in-performace-from-head-contention

which in my prejudice is no contest.  I want my reads and writes serialized
over drive heads.  Of course, that prejudice is not informed by
experimentation, which state I'll remedy as soon as one of you would like to
donate some 36GB SSA to me. ;)


If your database is deployed on a Shark, then you don't care about the
heads,
you're writing to RAM.  Make the volumes big enough that they aren't a pain
to
manage, and don't worry about the threading; it won't be your bottleneck.


- Allen S. Rout