> 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 > > > ----------------------------------------------------------------- > > > 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: [EMAIL PROTECTED] Mobile: +358-50-486 8043 > > > ----------------------------------------------------------------- > > -- > > -- > > Mark J. Bobak > > Oracle DBA > > [EMAIL PROTECTED] > > "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: [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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Deshpande, Kirti 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).
