Re: Evaluating overall performance

From: Helma <helma.vinke_at_hotmail.com>
Date: Fri, 9 Apr 2010 08:01:33 -0700 (PDT)
Message-ID: <5c7efe49-5e3e-4347-b752-bbd38c6b3728_at_b23g2000yqn.googlegroups.com>



On Apr 9, 1:54 am, joel garry <joel-ga..._at_home.com> wrote:
> On Apr 8, 1:53 pm, Helma <helma.vi..._at_hotmail.com> wrote:
>
>
>
> > On Apr 8, 4:58 pm, AD <alain.den..._at_gmail.com> wrote:
>
> > > Hi,
>
> > > I've been on the development side of things most of the time for the
> > > past years,
> > > but lately getting to do more dba work.
>
> > > I yet need to find material on "seeing the big picture" so to be able
> > > to describe and evaluate the performance of an Oracle system.
>
> > > The books I own are very good on drilling down to the fine details of
> > > a query, but I need to do the opposite and improve my skill on
> > > "measuring" the performance of the whole server, enabling me to
> > > communicate with others why the system is in good shape or why it
> > > needs attention.
>
> > > ..sort of the opposite of "tuning" for a specific tasks, and more like
> > > assessing the actual performance of the server...
>
> > > any good books, articles and links are welcomed,
>
> > > Thanks,
>
> > > Alain
>
> > Hello Alain,
>
> > As others have pointed out, there is a business dimension to
> > performance.  This means that even if the ' big picture' isn't good,
> > ( e.g. with lots of inefficient queries), this still can be acceptable
> > and not worth tuning. Tuning without the business dimension can often
> > lead to behavior what is called 'Compulsory Tuning Disorder' : keep on
> > tuning without goal.
>
> > Having said that, there are indeed ways to get ' the big picture' -
> > this is mainly used for capacity planning. ( e.g. can the database
> > handle an load of 50 extra users?).
>
> > The person to check out is Craig Shallahamer. His ' Forcasting Oracle
> > Performance' and ' Performance firefighting'  books are very good for
> > the big picture of the system. He stresses the point that there are 3
> > area's ( OS, application and RDBMS) that need to participate in this
> > big picture.
>
> > Helma
>
> There are some unspoken assumptions in both Mladen's application
> centric view and the business-centric view, the former usually being
> that the system is somewhat in the ballpark and the latter that the
> business has a rational view of system performance.
>
> Most of us have seen how really, really bad some applications can be
> developed.  While it is true that most of these problems come from bad
> design and bad coding, it often goes hand-in-hand with myths or other
> incompetence configuring systems for Oracle.  In the past, it was a
> much bigger deal on the Oracle side, though these days the defaults
> are fairly reasonable, they can still be out of whack when
> installations are done by drones.  The advisors are somewhat helpful
> if one takes the time to learn what they are really saying.  On the OS
> side, things can be way out of whack, even by experienced admins.
> Think of all the variants on async just to start.  Throw in ISM, GUI
> monitoring bugs, paging algorithms, NUMA, emctl and its shenanigans,
> java, perl, and there is a big ugly picture that needs to be seen.  So
> while you can say that most problems come from bad SQL, the unspoken
> assumption is that all those other things are not a problem - and
> that's just wrong.
>
> The business-centric viewpoint really is rationalization for outside
> consultants.  Not that there's anything wrong with that, it just needs
> to be admitted.  Many places have docile users who have been convinced
> (or just plain told) that whatever performance they see is the way the
> system works.  It may be true, or not, but business people often make
> snap myth-based judgment calls about computer systems.  Sometimes they
> think they are being rational by looking at pretty pictures from
> expensive tools they have bought.  That of course implies that the
> tools are good and they are being interpreted correctly.  Sometimes
> that is true.  Performance consultants are likely to have a skewed
> view of what to do, as they are usually called in when the myths hit
> reality, so they assume most things are close to properly configured.
> But it is also a big opportunity for BS artists to come in and
> unnecessarily throw hardware at it, or worse (ie, twiddle with
> undocumented init.ora parameters).  So there is definitely a need for
> an unbiased big picture for local staff.  In addition, a business may
> not see justification for proper tools, kind of like people can never
> properly evaluate their own risks, so they won't buy insurance unless
> compelled.  Even free tools are expensive, and Oracle options are ripe
> for a rant.
>
> By the way, Craig has a lot of free tool downloads at orapub.com, but
> I haven't had time to check them out.
>
> jg
> --
> _at_home.com is bogus.http://api.ning.com/files/shK09qQmvXLD4jLnouPQyt9AyjX0Xsk0wdAwqaPfHgb...

"The business-centric viewpoint really is rationalization for outside consultants."

Perhaps outside consultants need to prove their value to the business better than those with a permanent contract? To discard this demonstration of value as a mere 'rationalization' is not my way to view the economic side of the DBA work. Performance problems cost money - so does solving them.

"There are some unspoken assumptions in ...... that the business has a rational view of system performance."

I am not sure if you used the word 'rational' properly here. Did you mean 'correct'? Rationality has no relation with the correctness of information. I think that the business often tries to get a rational view ( add ego's and powerstruggles into the equation to blurr it a bit) based on bad, incomplete or sometimes missing performance information from the IT department.

"Performance consultants are likely to have a skewed view of what to do, as they are usually called in when the myths hit reality, so they assume most things are close to properly configured."

This sounds like a stack of casual assumptions to me. Received on Fri Apr 09 2010 - 10:01:33 CDT

Original text of this message