Re: Database performance monitoring tool for developers.

"Grabowy, Chris" wrote:
>
> Yes, they are teaching you what to look for...
>
> > 1) Dictionary Cache Hits (ARGH!!!!!!!!!!!!!!!!!)
> > 2) Percentage of Current Processes (as in we have 30 processes
> > attached and 300 processes configured in the init.ora)
> > 3) Sessions Waiting for Lock
> > 4) Total Sort Rate (rate of sorts per minute) on disk and in memory)
>
> ;)
>
> And in my dealings with account execs, to close a deal, the hosting AE
> will make sure the client gets whatever reports they want...
>
> Can I go back into my corner now?
>
> -----Original Message-----
> Sent: Wednesday, April 16, 2003 11:29 AM
> To: Multiple recipients of list ORACLE-L
>
> it should be the hosting company's job to teach the clients what to
> really be looking at.
>
> --- "Grabowy, Chris" <cgrabowy_at_fcg.com> wrote:
> > (stumbling out of my lurker corner)
> >
> > Is it possible that some clients expect to see those cache hit ratio
> > reports? Arent there still quite a few Oracle sites that are still
> > hung up on RBO and cache hit ratios??
> >
> > -----Original Message-----
> > Sent: Wednesday, April 16, 2003 9:44 AM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Ah but see, I didn't say 'DBA privs'. Most of the tools can be used by
> > an account that has select only on any of the v$ or dba_ views.
> >
> > I also said "database aware". Which means they understand what the
> > results mean.
> >
> > And then there are things like....
> >
> > the hosting company we use has reports on performance etc that
> > authorized users can look at. Reports are on CPU, Webservers, page
> > downloads and Oracle. Here's the sad part. There are 4 Oracle
> > reports:
> >
> > 1) Dictionary Cache Hits (ARGH!!!!!!!!!!!!!!!!!)
> > 2) Percentage of Current Processes (as in we have 30 processes
> > attached and 300 processes configured in the init.ora)
> > 3) Sessions Waiting for Lock
> > 4) Total Sort Rate (rate of sorts per minute) on disk and in memory)
> >
> > NONE of these are really useful, as they are reported on a daily
> > basis.
> >
> >
> > The first we know is really useless, and one of these days I'm going
> > to install a cron job to run Connor's BCHR script, just for giggles.
> >
> > The percentage of current processes makes no sense to me, as we run
> > with connection pooling.
> >
> > Sessions waiting for Lock on a daily basis? I suppose it could be
> > useful, if only to point me to an app to start tuning.
> >
> > And what really worries me is that the Sort Rate report is the "most
> > popular" (most viewed) of all of them. Not by me, I just learned about
> > these reports yesterday.
> >
> > I need to have a LONG talk with the hosting company.
> >
> >
> > --- April Wells <awells_at_csedge.com> wrote:
> > >
> > > I will go along with that.
> > > Whole heartedly in fact
> > > But with a disclaimer.
> > > They (the users with access to the tools) have to be willing to
> > learn
> > > the
> > > tool, and what the results MEAN. If they are willing to learn
> > > (really learn, not just hear part then think they know all there is
> > > to know about
> > > tuning code), I will give them access to the tools in a min.
> > >
> > > We have one developer who I trust implicitly. She wants to learn,
> > > tries to use good coding standards and tries to write the tightest
> > > code possible. I
> > > would give her DBA privs on the development instance in a
> > heartbeat,
> > > and any
> > > tool at my disposal to help her do her job.
> > >
> > > BUT...
> > >
> > > When you deal with parts of the user base (some of the developers)
> > > that think it is really cool to have a tool that has a really neat
> > > button that
> > > does everything for them, so they don't have to worry about the
> > > details of
> > > their code (SQL Navigator is our company's code generator of
> > > choice... not
> > > toad, that would be silly), then you have to deal with them having
> > > been
> > > 'educated' about tuning and what they should tell the DBAs to do to
> > > the
> > > system to tune it... and then they get an ORA-4030 error and decide
> > > that
> > > there needs to be a UNIX Kernel change because that will make their
> > > code
> > > run... you find out that a little bit of knowledge is a truly
> > > horrible
> > > thing.
> > >
> > >
> > > April
> > > -----Original Message-----
> > > To: Multiple recipients of list ORACLE-L
> > > Sent: 4/16/2003 5:58 AM
> > >
> > > If the developer is database-aware enough to want to use something
> > > like Spotlight, or any tool that does not degrade performance, I'll
> >
> > > give it
> > > to them if I can.
> > >
> > >
> > > --- Shamita & Chiran Ghosh <shamita-chiran_at_attbi.com> wrote:
> > > > Hello, How does the list feel about providing developers access
> > to
> > > > ad-hoc/real-time, problem solving diagnostics tool such as
> > > Spotlight,
> > > > Mamba
> > > > etc. to developers to provide first-line support. I'm not so
> > crazy
> > > > about the it; but was wondering on what the list's opinion would
> > be.
> >
> > > > Comments please.
> > > > Thanks.
> > > >
> > > >
> > > > Chiran Ghosh
> > > >
> > > > email: Shamita-Chiran_at_attbi.com

I have followed this thread with interest, and I fear that I don't share the usual enthusiasm for putting monitoring tools in the hands of developers - *some* developers, certainly, but not as a general rule. As Rachel pointed out, many monitoring tools, and sometimes purely for reasons of 'give the customer what s/he wants to get for his/her money', display mostly irrelevant values. Even if the values were relevant, would a young developer be able to tell what is abnormal, and what is just the normal consequence of crazy requirements, especially among a huge number of values, many of which are different symptoms of a same illness? Not so sure. I am fully in favour of educating developers, and I fear that very often throwing a tool to them may just be an excuse for not teaching them. I would be content enough if they were just able to feel that something is not as it ought to be.

Regards,

Stephane Faroult
Oriole Software

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Stephane Faroult
  INET: sfaroult_at_oriole.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).