That depends on how you did the reorganization. Either backup/restore or
DEFINE DBVOL/DELETE DBVOL is probably how you did it, and niether of
those methods will accomplish your goal of spreading out the I/O load.
At least not right away. As time goes on, it should very gradually
spread itself out over all 4 volumes. This process might take months.
One way to speed that process up is the unload/reload sequence, as you
had feared.

In order to accomplish your spreading effect, you need to squeeze it and
force it to divide. Instead of moving it from the 88gb volume to four
22gb volumes, move it in two steps. 19% of 88gb = 16.72gb Therefore,
first, allocate four temporary dbvols only 4.5gb. Do a REDUCE DB down to
the capacity of your added dbvols. Temporarily, it should be nearly 100%
full. Then use the DEFINE DBVOL on each of the new 4.5gb dbvols, and
DELETE DBVOL on the old, to squeeze your 16.72gb of actual data to
almost fill up each of those 4.5gb dbvols. In Step 2, you're going to
replace each of those 4.5gb dbvols with a 22gb dbvol - one at a time -
and then when you're done you will be back to only 19% full, but that
19% which is data will now have been divided into four parts, instead of
remaining concentrated in the first dbvol. Exact precision in
calculating these sizes is unnecessary.

The TSM DB works best on plain ol' JBOD disks. By using the above
squeezing method, you can divide the I/O load without resorting to
striping.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
======I have not lost my mind -- it is backed up on tape somewhere.=====


On Wed, 30 Nov 2005, Troy Frank wrote:

>I previously had an 88G db @ 19% utilization spread over 3 dbvols.
>2 dbvols on D: (hardware mirrored drive), and one on E: & F: (tsm
>mirroring).
>These drives were all on the same scsi controller (and same channel on
>that controller).
>
>I reorganized this so that I now have 4 db vols, with each one on a
>separate disk. Tthe D: drive is still hardware mirrored, the other 3
>dbvols are tsm mirrored.
>During this reorg I sized them all the same (22GB), and also moved one
>of the backplanes (3 drives) to a separate scsi controller.
>
>The goal of all this was to spread the db i/o out over more spindles,
>and more scsi controllers.  Unfortunately, what seems to have happened
>is that tsm put pretty much all the db info into one dbvol, and is
>leaving the others mostly empty.  The db is still 88gb, and still 19%
>utilized.  End result was that I basically got no speed benefit out of
>all the reorganizing.  Is there some way to force tsm to evenly
>distribute the info, or does that involve the mythical unload/reload
>that I occasionally hear about?
>
>
>
>Troy Frank
>Network Services
>University of Wisconsin Medical Foundation
>608.829.5384
>
>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.
>