Well, that got me thinking. I would welcome one person's opinion and
those of several others on the following approach.
We are supporting a growing client-company, and it is their intention to
grow not only in market share, but in territory serviced. Any
projections are, as far as I am concerned, educated guesses, with room
for significant error. I hope that we will always catch near-capacity
conditions, and increase the current capacity during batch processing on
non-business hours. I will probably mull over optimal scenarios
regularly, wanting to 'ride the edge' on slack space, and having to
decide cost-benefit on which side to err. I will probably have to
justify admin time on how frequently we examine the statistics, or how
often DDX / MDX occurs, to different parties with conflicting interests.
Do we want to be increasing capacity daily, or weekly, or err on the
side of large margins, and do this as needed / ad hoc? It is apparent to
me based on the difficulty I have had following the learned discussions
of such issues, that I have much to learn about how to make good choices
here. We are going to use Adager to change capacity in batch of course,
and the Adager Console to track growth over time, to help make better
guesses, and will likely use DDX and MDX as a safety net. How does that
sound?
> -----Original Message-----
> From: Dirickson Steve [SMTP:[log in to unmask]]
> Sent: Thursday, July 30, 1998 3:01 PM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] Image Dynamic Dataset Expansion
>
> FWIW, here's One Person's Opinion on the subject: DDX is a Bad
> Idea, and MDX
> is a Worse Idea.
>
> Neither is inherently a Bad Idea; the problem is that common
> usage turns too
> often out to be "mis usage", and the database's performance is
> where the hit
> shows up.
>
> DDX, and especially MDX, were created to provide interim
> solutions to a
> show-stopping problem: filling up a set at a time when it would
> be really
> painful to take down the database long enough to expand the set.
>
<snip>
|
