| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Database performance monitoring tool for developers.
The thing that Wall of Shame does so well is it shows everybody things that
are a bad idea to do. The real impact is not the denigration of souls, it's
the effect that happens when people walk by, see the horror, and then
realize, "Oh my gosh, *I* do that too. I better go fix it before anyone
notices."
The perfect Wall of Shame is one on which bad stuff shows up long before it ever makes its way into production. It ends up being a tribute to the disasters that never happened...
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Upcoming events:
- Hotsos Clinic 101 in London, Reykjavik, Ottawa, Denver, Sydney - Visit www.hotsos.com for schedule details... - IOUG-A Live 2003, Orlando, 10am Monday 28 April: "Oracle OperationalTiming Data"
-----Original Message-----
Carmichael
Sent: Thursday, April 17, 2003 1:17 PM
To: Multiple recipients of list ORACLE-L
works both ways. If I do something really stupid, I'm usually the first to tell people about it. But if I don't, then yea, I should have my name up there too.
How about a generic "Wall of Shame"?
--- "Spears, Brian" <BSpears_at_Limitedbrands.com> wrote:
>
> #4 could work if its done in the spirit of fun but... Just think of
> the
> DBA wall of shame... wouldn't that be fun. I like the coming from the
> other
> direction... tend reward to the improving stats about bad
> code/problem...
>
>
> Brian
>
> -----Original Message-----
> Sent: Wednesday, April 16, 2003 10:14 PM
> To: Multiple recipients of list ORACLE-L
>
>
> I vote for #4!
>
> --- Cary Millsap <cary.millsap_at_hotsos.com> wrote:
> > My $0.02...
> >
> > Developers usually don't have access to a high-concurrency test
> > environment
> > in which an expensive monitoring tool would make that much
> difference
> > anyway. The most powerful tools I've seen?
> >
> > 1. Performance specifications - Functional specs contain a budgeted
> > number
> > of LIO operations that the code is allowed to consume. A good rule
> of
> > thumb
> > is 10 LIOs per (non-aggregated) result set row per table. For
> > example, a
> > 4-way join returning one row gets a budget of no more than 40 LIOs.
> >
> > 2. Profiling (tkprof, autotrace, etc.) - EVERY piece of code gets
> > traced and
> > run through a profiler. If a piece of code breaks its specified LIO
> > budget,
> > then it's not approved for check-in.
> >
> > 3. Execution plan analysis (explain plan) - EVERY piece of code has
> > its
> > execution plan checked by a performance analyst. Execution plans
> are
> > generated with PRODUCTION db statistics, not test db statistics.
> >
> > 4. The Wall of Shame - Write inefficient code, and your code goes
> up
> > on the
> > Wall for everybody to see. People whose names appear continually on
> > the Wall
> > of Shame are not selected as candidates for reproduction.
> >
> > Who is the referee in all this? The performance analyst. Some
> > performance
> > analysts are DBAs, some are developers, some are architects, and
> some
> > are
> > none of the above. It doesn't matter who takes on the role, as long
> > as it's
> > someone competent and credible.
> >
> >
> > Cary Millsap
> > Hotsos Enterprises, Ltd.
> > http://www.hotsos.com
> >
> > Upcoming events:
> > - Hotsos Clinic 101 in London, Reykjavik, Ottawa, Dallas, Denver,
> > Sydney
> > - Visit www.hotsos.com for schedule details...
> > - IOUG-A Live 2003, Orlando, 10am Monday 28 April: "Oracle
> > Operational
> > Timing Data"
> >
> > -----Original Message-----
> > Faroult
> > Sent: Wednesday, April 16, 2003 3:24 PM
> > To: Multiple recipients of list ORACLE-L
> >
> > "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.
> > > > >
>
=== message truncated ===
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rachel Carmichael INET: wisernet100_at_yahoo.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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Cary Millsap INET: cary.millsap_at_hotsos.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).Received on Thu Apr 17 2003 - 20:56:41 CDT
 |
 |