==> In article <OFD41C28C7.910E9B0E-ONCA256ECB.001EBECF-CA256ECB.0021432F AT db 
DOT com>, Gordon Woodward <gordon.woodward AT DB DOT COM> writes:


> Before I upgrade our TSM server to v5.2 (seems to be taking forever to do
> due to small outage windows) I want to reorganise our database volumes so they
> are a little more efficient. Is there any recommended maximum number of
> database volumes a TSM database should have? Ours is spread across about 20
> different volumes of varying sizes, not the best makeup I am sure, hence why I
> want to re-arrange it before hand.

I'd say that your maxima would be ruled by other factors, such as some of
those to which you allude:  size &c.

Best recommendation:  try to keep your volumes on a 1:1 basis with your
physical spindles.  It's the best possible way to convey to TSM what the
architecture of your underyling disk is.

There'll be places where this breaks down.  Huge disks is one place;    You'll
want multiple volumes just because you don't want to constrain the threads of
execution operating on your DB.

disk aggregation NAS devices (e.g. Shark) are another: you're so far from the
physical abstraction there that you can forget much of the conventional wisdom
of how to keep your DB safe.  For example, you might not be nuts to ride
without DB copies if you're using shark space.

But for simple count-of-volumes, not really any limit.  I've had as many as
.. 34?  32, and four logvols.  Two drawers of 9G SSA.


- Allen S. Rout