Re: Competition for OraPerf

joel garry wrote:
> >
> > Cary Millsap's book is currently the state of the art in regards to how
> > to approach this area.
>
> I agree, and yet, even it has some shortcomings. Sometimes ordering
> everything by business priority misses technical problems (for example,
> rating the 15th most important problem as identified by the
> methodology, when in actuality it should be a topper), and there are
> perhaps some unspoken assumptions in the methodology. Unless I am
> mistaken (quite possible, as I haven't looked at it too closely), one
> assumption is that there are a few issues that cause most of the
> problems.

Umm no that's all covered in chapter 1 which documents what method R is and how it operates.

If that's the level of understanding that you hard regarding the book I suggest re-reading the preface and chapters 1 thru 4 at a minimum.

> This is often true, but not always, especially in newbie
> systems and systems that have many different apps. So any testimonials
> would be suspect.

What testimonials are you referring to? Sorry you completely lost me with the last 2 sentences.

>
> >
> > 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.
>
> But would that be for a technical reason, or a not invented here
> reason?

I don't think Carry is a big believer in either technical reasons or the not invented here reasons.

Again it's all covered in the chapters cited above.

>
> >
> > "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.
>
> Ah, sorry, I wasn't clear that I was referring in general to trying to
> make things better, as the sort of scientific inquiry Richard and
> others champion, not in evaluating a specific situation. Absolutely,
> doing nothing is often correct in the latter. I should have made a new
> paragraph at "The important thing..." and explained the transition.

Sorry you lost me again. Richard who?

>
> >
> > 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.
>
> Agreed. But that needs to exist within the greater business context,
> where overall business considerations can be at odds with tuning
> specific workloads.
>
> What do you think Cary would say about tuning an arbitrary SQL that is
> one of 10000 bad SQL's? Of course his methodology orders the badness
> so you may never get there. The "wrong" throwing of hardware works
> when it solves a more global problem (including the cost of hardware v.
> cost of people, and postponing proper fixes until they can be made).
> They are not necessarily mutually exclusive, there's only a problem
> when people say they are mutually exclusive, or use one when the other
> is appropriate. Throwing hardware at an untuned newbie system would be
> inappropriate - I've seen some pretty old systems that could be
> described that way (maybe every Oracle system put together by people
> who think it is another db, too...), and I think the Competition for
> OraPerf would be particularly egregious for those.

Are you postulating that sometimes throwing hardware is viable?

Or that it's only bad when it doesn't work? ( You have me worried with the sentence that reads "The "wrong" throwing of hardware ... then you say "use one when the other is appropriate" ).

Well hindsight is always 20-20 once a problem is solved. Cary's approach guides you to the correct solution from the beginning if it is followed correctly.

The other approach sounds suspiciously like Method C except that you front end it by throwing hardware first? Received on Thu Nov 09 2006 - 06:21:01 CST