Of course!!
I just laughed when he published that script, and didn't think anything more of it. Now I can use it to "drive home" my point. Excellent.
Thanks Kirti.
-----Original Message-----
Sent: Thursday, October 03, 2002 4:03 PM
To: Multiple recipients of list ORACLE-L
> some Oracle sites still believe in the myths and ratio based
> tuning. It can be difficult to convince a client that their long
> practiced tuning methodology is "obsolete".
In such cases, Connor's wonderful script comes very handy ;)
http://www.oracledba.co.uk/tips/choose.htm
I have used it to convince some old dogs....
-----Original Message-----
Sent: Thursday, October 03, 2002 12:44 PM
To: Multiple recipients of list ORACLE-L
they haven't been around as a company all that long so I doubt the doc
is from 7.3
as for the methodology, I've talked to their DBAs and they are forward
thinking, which is why the doc suprised me
- "Grabowy, Chris" <cgrabowy_at_fcg.com> wrote:
> Sort of putting on my devil's advocate hat...
>
> - "perhaps" the document is old and just hasn't been updated. A lot
> of the documentation that we have lying around is marked as 7.3, we
> just haven't had the time to update them, since were overwhelmed with
> real work, and can't hire additional DBAs.
> - some Oracle sites still believe in the myths and ratio based
> tuning. It can be difficult to convince a client that their long
> practiced tuning methodology is "obsolete". So for your specific
> case, perhaps they have dealt with these types of clients in the past
> so they "tread lightly".
>
> It will be interesting to see how the hosting company responds to
> your explanations.
>
> -----Original Message-----
> Sent: Wednesday, October 02, 2002 9:39 PM
> To: Multiple recipients of list ORACLE-L
>
>
> we're hiring a hosting company to manage and monitor our production
> apps... they handed me their spreadsheet of Oracle "things" to
> monitor... I finally found "wait events" on that list. Buffer cache
> hit
> ratios were high on the list and flagged as "critical"
>
> nuh uh, didn't have time to gently explain (with the two by four)
> that
> that was going to be unacceptable. But I will have loads of time
> tomorrow. What scares me is that this list was compiled by
> "experienced" DBAs.
>
> --- Jared.Still_at_radisys.com wrote:
> > Buffer Cache Hit Ratio?
> >
> > What's that?
> >
> >
> >
> >
> >
> >
> > "Inka Bezdziecka" <IBezdziecka_at_cupe.ca>
> > Sent by: root_at_fatcity.com
> > 10/02/2002 08:03 AM
> > Please respond to ORACLE-L
> >
> >
> > To: Multiple recipients of list ORACLE-L
> > <ORACLE-L_at_fatcity.com>
> > cc:
> > Subject: RE: Performance monitoring
> >
> >
> > Well ...
> > if you need short reports, look for:
> >
> > 1. waits
> > 2. buffer cache hit ratio
> > 3. dictionary hit ratio
> > 4. library hit ratio
> > 5. latches
> > 6. parsing/execution ratio
> > 7. data file i/o
> > 8. shared pool memory distribution
> > 9. session contention
> > 10. session memory usage
> >
> > inka
> >
> > -----Original Message-----
> > Sent: Wednesday, October 02, 2002 7:08 AM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Thak's Mark
> >
> > I agreed, but they have gotten an idea to get only couple
> > "most important" measurements from db, because they don't want
> > to have a huge reports with all possible statistics. Very
> > understandable, but as You wrote, there isn't any absolutely top
> ten.
> >
> > In any case, I have to do this (stupid) list, so give Your best
> shot,
> > please.
> >
> > t.Jorma
> > Ps. I heard, that Dave Ensor from BMC, has once presented that
> > kind of list?
> >
> > -----Original Message-----
> > Sent: 02 October, 2002 12:23
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Jorma,
> >
> > Performance tuning is a complex subject. There really isn't a list
> > of
> > 10 things to watch for. Every system is different.
> >
> > I would (attempt to) summarize tuning by these five steps:
> >
> > 1.) Have a capacity/performance target in mind. If you don't know
> > where you're going, how will you know if you have gotten there?
> >
> > 2.) Monitor your response times as load increases. Can you
> achieve
> > your response time target at the specified load? If so, you're
> done,
> > successful test, congratulations. If not, continue to next step.
> >
> > 3.) Actively monitor what's going on in the database, while it's
> > happening. It's always easier to see it in real time than just
> > looking
> > at random StatsPack snapshots taken at 5 or 10 or 15 minute
> > intervals.
> > (Not that I'm saying StatsPack shouldn't be collected. I'm just
> > saying
> > don't rely on StatsPack as your only source of info about the
> > database.) The V$ Wait Interface is your friend. If you're not
> > familiar with it, go to http://www.hotsos.com/ and get Mogens
> > Norgaard's
> > paper, Introducing the V$ Wait Interface. Where is the database
> > spending it's time? What's the bottleneck? If you identify a few
> > trouble sessions, you may want to dive deeper w/ some 10046 traces
> at
> > level 8 on specific sessions. You almost certainly do NOT want to
> do
> > this instance wide.
> >
> > 4.) Once you have some indication as to what's going on in the
> > database, you need to see how the system is doing overall. On most
> > flavors of *nix, where I'm comfortable, sar (System Activity
> > Reporter)
> > is an excellent tool. Use it to determine if you have any
> systemwide
> > CPU, memory, or I/O contention. (Other OSes almost certainly have
> > similar utilities.)
> >
> > 5.) Address the biggest bottleneck. This is where it can't be
> > summarized in a simple step. You need to understand the
> bottleneck,
> > so
> > that you can understand how to tune it. If may be latch
> contention.
> > Depending on the latch, it could be poorly tuned SQL, or lack of
> bind
> > variables, or simple CPU capacity limits, or a whole host of
> things.
> > I/O contention? Could be anything from poorly designed and/or
> > configured RAID array to poorly tuned SQL, or who knows what.
> > Determine
> > the cause of the biggest bottleneck and minimize or eliminate it.
> >
> >
> > There you have it, Mark's Simplified Performance Tuning, in five
> easy
> > steps! ;-)
> >
> > -Mark
> >
> >
> >
> > On Wed, 2002-10-02 at 02:08, Jorma.Vuorio_at_nokia.com wrote:
> > > Ave !
> > >
> > > I like to hear Your opinion about the most importat
> > > issues, what should be monitored from the database (8.1.7, SUN)
> > during
> > > perfomance testing. The purpose in this case, is limit the
> > > monitoring to concern only about 10 most important ones.
> > >
> > > I have difficulties to make my mind to pick up the right ones, so
> > > if You had to have made similar kind of decisions or have
> opinions,
> > > please let me know.
> > >
> > > TIA
> > > Jorma
> > > -----------------------------------------------------------------
> > > Name: Jorma Vuorio Phone: +358-9-7180 67759
> > > Company: Nokia Business Infrastucture Fax: +358-9-7180 67465
> > > Address: P.O.Box 321, FIN-00045 NOKIA GROUP, FINLAND
> > > Internet: jorma.vuorio_at_nokia.com Mobile: +358-50-486 8043
> > > -----------------------------------------------------------------
> > --
> > --
> > Mark J. Bobak
> > Oracle DBA
> > mark_at_bobak.net
> > "It is not enough to have a good mind. The main thing is to use it
> > well."
> > -- Rene Descartes
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> >
> >
> >
> >
>
=== message truncated ===
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
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.com
--
Author: Deshpande, Kirti
INET: kirti.deshpande_at_verizon.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.com
--
Author: Grabowy, Chris
INET: cgrabowy_at_fcg.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 Oct 03 2002 - 15:53:45 CDT
