Re: Competition for OraPerf

joel garry wrote:
> > >
> > >> I'm a consultant and I'm not the slightest bit worried. That's because I
> > >> don't rely on reports that recommend throwing hardware at problems that
> > >> don't exist and solve problems that really do exist by determining what's
> > >> actually wrong ...
> > >
> > > Richard, such a statement would hold water if the world was clearly cut
> > > into right and wrong things but, alas, it is not. I thought it was us
> > > Americans who tend to over-simplify things, but I see that Aussies are not
> > > immune to that, either.
> >
> > Hi Mladen
> >
> > Ummmm, such a statement holds all the water I need in this desert called
> > Oracle consulting because it's exactly what I do.
> >
> > It's not a simplification, it's a fact. Perhaps a rather simple fact but a
> > statement of fact nonetheless ...
> >
>
> Perhaps you guys are talking at cross-purposes here because of the
> different ways one can determine a problem statement. It is certainly
> near-trivial to come up with realistic examples of how a dumb profiler
> can spit out inanity - the example on the web site is ironically one of
> those, as Richard demonstrated. And I think Mladen's example is a good
> one - it demonstrates that short-circuiting a proper tuning methodology
> by someone who knows what he is doing can be more cost-effective to a
> business. Will it always be? Of course not, but that is only a
> problem when it is always used by the business, which removes the
> "knows what he is doing" from the solution. Will it _never_ be?
> Also, of course not, there is implicit value to experience, the problem
> domain allows intuition to extrapolate correctly from past experience.
> Will it be the optimal solution to the problem? Most likely not - but
> then, when you insert business valuation into the process, optimal no
> longer necessarily equals best. Or maybe the other way round.
>
> I often see people (yes, including myself) making extrapolations that
> are ridiculously wrong. When it blows up in some huge project, that
> can be both educational and entertaining. On the other hand, many
> incorrect assumptions may be innocuous or lead to correct results
> through fallacies. With the limited resources we all have, it has to
> be a judgement call about many things. The important thing is that we
> make an effort to make things more rational, while accepting that some
> things will be difficult to change. Doing nothing invites
> irrationality. Limiting the solution domain too severely can also be
> destructive. The trick is to know how and when to use observation to
> feedback control to go in the right direction.
>
> Sometimes it's good to throw the hardware at it first, because that
> doesn't rule out tuning it properly later, whereas if you got it going
> good enough, you suffer when you do need the capacity and can't get it
> due to arcane capital expenditure rules. So fight BS with BS :-)
>

Cary Millsap's book is currently the state of the art in regards to how to approach this area.

I have a feeling that he wouldn't exactly agree with the proposition of throwing hardware first into any of the scenarios that this thread is discussing.

"Doing nothing invites irrationality" ... sorry I can't buy that statement at all.

Often doing nothing is the best decision that can be made in many situations. It all centers around whether you will provide a tangible benefit to a business function that yields a better rate of return than doing nothing, as well as the cost of the resources and hardware ( if any ) needed to implement some kind of change.

Eliminating workload that's un-necessary and fixing needed SQL so that it uses less resources ... that's what should be driving any competent DBA. Received on Tue Nov 07 2006 - 19:19:21 CST