Path: text.usenetserver.com!out02a.usenetserver.com!news.usenetserver.com!in02.usenetserver.com!news.usenetserver.com!postnews.google.com!w3g2000hsg.googlegroups.com!not-for-mail From: Niall Litchfield Newsgroups: comp.databases.oracle.server Subject: Re: Cache Hit Ratio from system views Date: Wed, 08 Aug 2007 20:51:15 -0000 Organization: http://groups.google.com Lines: 51 Message-ID: <1186606275.616321.166050@w3g2000hsg.googlegroups.com> References: <1186588653.996873.185140@l70g2000hse.googlegroups.com> <1186597870.627874@bubbleator.drizzle.com> <1186599766.578604.210630@q75g2000hsh.googlegroups.com> <1186604067.44579@bubbleator.drizzle.com> NNTP-Posting-Host: 217.33.8.61 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1186606275 5651 127.0.0.1 (8 Aug 2007 20:51:15 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 8 Aug 2007 20:51:15 +0000 (UTC) In-Reply-To: <1186604067.44579@bubbleator.drizzle.com> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2),gzip(gfe),gzip(gfe) X-HTTP-Via: 1.1 comp-lib-squid-1.lambeth.gov.uk:3128 (Squid/2.3.STABLE4-hno.CVS) Complaints-To: groups-abuse@google.com Injection-Info: w3g2000hsg.googlegroups.com; posting-host=217.33.8.61; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: usenetserver.com comp.databases.oracle.server:432679 X-Received-Date: Wed, 08 Aug 2007 16:51:15 EDT (text.usenetserver.com) On Aug 8, 9:14 pm, DA Morgan wrote: > Niall Litchfield wrote: > > sybra...@hccnet.nl wrote: > >> On Wed, 08 Aug 2007 12:02:46 -0700, Teresa Masino > >> wrote: > > >>> Alone, yea, but they can sometimes be an indicator that an instance > >>> needs attention. > >> Do you really think so? Yesterday I had a customer spouting flames > >> because of a RAC database coming down to a crawl due to buffer busy > >> waits in conjunction with both instances updating the same table over > >> and over again. > >> Nothing to be seen from the BCHR. > > >> But then of course BCHR is a MIPS (Meaningless Indicator of the > >> Performance of the System). > >> Only good old Don Burleson makes people erroneously believe they can > >> tune their database by throwing memory at the problem to crank up the > >> BCHR. > >> Savy professionals (a favorite phrase of Don) know better. > > > enough of you will recognise where I stand on ratios. Indeed I believe > > that I presented on the effectiveness or in fact otherwise of the BCHR > > on its own nearly 5 years ago. > > > I have some sympathy withe Teresa's sentiment above though. Imagine a > > system that has had a truly horrible burleson concerned hopelessness > > ratio of 75% since 2002. Today the BCHR is 25% (or indeed 98%). I > > venture to suggest that it's a change worth determining the reasons for, > > either way. Ratios don't mean anything much, abrupt changes in them > > often do. > > On the other hand monitoring things that matter would save you the > trouble of chasing after smoke in a house of mirrors. > > There are real things that can be monitored. And if Theresa has the > license to use AWR as it seems she'd be far better served looking at > things that matter. > -- > Daniel A. Morgan > University of Washington > damor...@x.washington.edu (replace x with u to respond) > Puget Sound Oracle Users Groupwww.psoug.org- Hide quoted text - > > - Show quoted text - Indeed. And since EM will do alerts based on user defined metrics, it's possible the whole thing is moot. Niall