One more thing while I'm kind of on the topic... Guys, my ratio of screw-ups
to attempts is as high as anyone's. But the fastest I've ever learned has
been by paying attention to those screw-ups, calling them what they were,
and then for heaven's sake writing them down so I could remember them. And
in fact so that other people can remember them too. Hiding them helps no
one.
There should be no actual shame in screwing up if the attempt is honorable,
and if you're not making the same dumb mistake a second or third time. I
think there's a big difference between "I am an idiot" and "I on occasion
have done idiotic things." The cemeteries are full of people who didn't
learn from their own mistakes...
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 Operational
Timing Data"
-----Original Message-----
Sent: Thursday, April 17, 2003 10:47 AM
To: Multiple recipients of list ORACLE-L
#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.
> > > >
> > > > 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
>
=== message truncated ===
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
--
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: Spears, Brian
INET: BSpears_at_Limitedbrands.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 - 21:06:55 CDT
