BHR has taken quite a beating. I am sure the point everyone's trying to
make is that a 99% BHR does not indicate a well tuned database, and a 50%
BHR does not indicate a poorly peforming database. A low BHR does not mean
I need to increase db_buffers as was believed and practiced earlier. Point
well taken and understood. But, it "CAN" be an indicator that something out
of the ordinary is happening in my well tuned database. I emphasize on
"CAN". Why have the PIO's increased so suddenly? Say, if the BHR is
consistently around 80, and suddenly, it drops to 70, or rises to 95, I
want to know why? What you infer from the BHR is what counts. There would
definitely be other ways of finding this out. Or are there?
Regards
Raj
"Grabowy,
Chris" To: Multiple recipients of list ORACLE-L
<[EMAIL PROTECTED]>
<cgrabowy@fcg cc:
.com> Subject: RE: Performance monitoring
Sent by:
root@fatcity.
com
October 03,
2002 04:53 PM
Please
respond to
ORACLE-L
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....
- Kirti
-----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" <[EMAIL PROTECTED]> 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.
>
> --- [EMAIL PROTECTED] wrote:
> > Buffer Cache Hit Ratio?
> >
> > What's that?
> >
> >
> >
> >
> >
> >
> > "Inka Bezdziecka" <[EMAIL PROTECTED]>
> > Sent by: [EMAIL PROTECTED]
> > 10/02/2002 08:03 AM
> > Please respond to ORACLE-L
> >
> >
> > To: Multiple recipients of list ORACLE-L
> > <[EMAIL PROTECTED]>
> > 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, [EMAIL PROTECTED] 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
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
