Jeff,

The answer is: "It depends". :-)

In a shop like yours (very large system, very large disk farm, lots of
users) it is quite likely that splitting the three databases onto three
volume sets will provide a more *consistent* response time.  The headaches
that Craig Solomon astutely refers to I believe are more related to the
operational issues in having one application or one database split across
multiple volume sets.  I do not recommend, as a general practice, having an
account reside on multiple volume sets (although some do it and for valid
reasons).

The main operational negative about the implementation of the Transaction
Manager is that the journaled writes eventually need to be posted to disk
(pesky things!).  This is called a "checkpoint".  (There are many
activities that can trigger a checkpoint, none of which are particularly
relevant for this discussion (and not just because I don't know them all!)
except for fullness.)  When a checkpoint occurs because the XM log files
are full, it can have a fairly significant impact on overall performance.
In fact, in the "old days" (circa MPE/XL 3.something and before) the XM
post would occur in the AS subqueue rendering the system virtually dead for
45-90 seconds depending on the size of the system.  Nowadays, XM postings
generally have less impact but it is still measurable, like all things
performance.

In your case, (again, a very large system, very large disk farm, and lots
of users *and* running through a single volume set) you are likely to be
"victimized" by frequent fullness-related XM postings.  Essentially, this
victimization would likely be inconsistent response times.

As with most performance issues in a large symmetric multiprocessing
system, the real advantage you are looking at is to increase the
parallelization of the XM postings on your system.  Since each volume set
gets its own XM, you can spread the impact of postings out more evenly with
more volume sets.  This assumes that the three databases in question
represent a fairly even I/O distribution.

I do agree with Goetz that you were ill-served in the advice given you.  If
you can minimize the operational downside by avoiding too many
cross-account volume sets you would probably be well served by attempting
to parallelize the XM activity.

Bill Lancaster

At 10:14 AM 3/1/99 -0800, Jeff Mikolai wrote:
>I am having a discussion about private volumes and performance issues. I
>have a relatively large account with 3 large databases. At one point in
>time, these three databases have been split across 3 private volumes. Now
>they all reside on one private volume. According to HP back when we did
>this, they said this would not be a performance issue. Could someone
>enlighten me on this issue a bit.
>
>Thank you,
>Jeff Mikolai
>
>