If I didn't say it before, I'll say it now: This was one of the better messages I've seen for a very long time. Jolly good laugh, as the English would say.
Remind me to take you to lunch next time I'm in Melbourne (as if I'm in Australia very often ... ).
Take care.
Mogens
mantfield wrote:
Morgens is very correct in saying tha all sorts of measurements have their place. Actually, the length-of-skirt measurement works very well for me. Here is the algorithm:Heat-by-day in inversely proportional to length of skirt which again is inversely proportional to my desire to have lunch outdoors at sidewalk cafe, but which directly affects my enjoyment of the day and inversely affects my productivity (much like this posting). Right now (Jan / Feb), we are experiencing our heatwaves (30+ Celsius by day, 20 by night = absolute bliss), so I get a lot of opportunity to streamline the algorithm and processes. Melbourne is the place to be, unless you can get to work on Bondi beach in Sydney, where the skirt length = zero. Of course, if you study the skirts or lack of it TOO intensely, this leads a high jealous-boyfriend-hit-ratio, which inversely affects my overall well-being and morale, so you need to find that optimal balance between appreciation and blatant gawking or technically put : maximum benefit within minimized response time. Ferenc Mantfeld -----Original Message----- From: Mogens Norgaard [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, January 14, 2003 12:00 PM To: Multiple recipients of list ORACLE-L Subject: Re: BCHR Tuning Something here doesn't compute. If you tried to use time-based measurements and didn't find out where the time went - well, bad for you. If you then stumbled on something, say the database startup/database shutdown ratio (would normally be fairly close to 1, but could vary) or the log file switch/archive log file ratio (again, could be close to 1 or 100% or something - or could vary) or the ratio of blocks from a certain index found in the permanent pool versus the number of PIO's required for that statement - or whatever - it would still be guesswork, checklist tuning, or what you'd prefer to call it. All sorts of measures have their place. All sorts of measures could prove interesting. When I went to school the famous example was the wolf population of Canada which seemed to follow the birthrate of children in Denmark. Or the length of skirts versus economic prosperity in the Western world, which also proved rather closely matched. If you want to measure response time (what else?) it just might be of interest to find out where the time is spent. The BCHR, the x/y, the DBStarup/DBShutdown ratio or other ratios or measurements might be important to find out symptoms of things - but to say that that kind of guesswork still has it's place is like saying that we should still carefully watch the wolf population of Canada or the skirt length in the Western World...because you never know. And that just might be the case: You never (will) know until you adopt an approach that is hierachical (spelling?) and which you can use to prioritize and quantify your efforts (try that with the BCHR - the x$kcbrbh, etc. of course are grossly wrong in those respects). Yep, I've been there, I've used it all, I've tried to use all the notes and articles regarding the wonderful statistics available in bstat/estat - I've been through the stages of collecting more and more queries and numbers and ratios until my file with scripts and queries was bigger than Holland. Yet it never gave me solutions, just a lot of things to check and change and fiddle with - without knowing which one to choose first, and how much it would help. The YAPP method works. There are cases where it is not 100% accurate. In most cases it's spot on. Watch where the monitoring tools are going. Spotlight in the latest edition have the YAPP method built in. Let's see what Oracle does in 10i. Precise has it. Steve Adams' scripts has it. This is not about the BCHR being low or high or in between. This is about using a METHOD instead of 100s of different numbers that don't mean anything. Mogens [EMAIL PROTECTED] wrote:I too think the BCHR has its place, as a problem indicator. It can tell me theres something wrong with my database. Say, I have this database performing well, the users are happy, the BHR is mostly at 90%, and now it suddenly shoots down to 70%, or it suddenly increases to 98. Somethings amiss. Its less tasking, to code for scripts that query v$sysstat to indicate me of some problems, rather than querying v$sqlarea. Or I need to code for some intelligent scripts to query v$session_wait or V$system_event. Or I need to look at the statspack reports every hour. The point is when do I look at wait events? When the user calls me up? All the papers out there, asking us rightly, to look at wait events, trash the BCHR. I think what the authors intended was to tell us that increasing DB_BLOCK_BUFFERS was not the solution to a low BCHR, and that a BCHR of99%does not mean a highly efficient database. Vice Versa, a BCHR of 50% does not indicate a poorly performing database. Give me a database with a 45% BHR, and I can get it to 99% by running a few queries. Point well understood. It does not mean in any way that I should now ignore PIO's and start tuning LIO's. I still use BCHR. "What you infer from the BCHR is what counts". Raj"YechielAdar" To: Multiple recipients oflist ORACLE-L <[EMAIL PROTECTED]><adar76@inter cc: .net.il> Subject: Re: BCHR Tuning Sent by:root@fatcity.comJanuary 13,2003 10:58 AMPleaserespond toORACLE-LHello Anjo I just had a tuning session with Dov Hit, from ACS in Israel. He used some of the scripts that you showed him 2 years ago when you did some work for Amdocs. Anyway, after doing some search on the waits, he checked the BCHR andfoundout that this database has only 40%. That led us on further checks and we found more offending SQL's. The BCHR has it's place. Just do not measure yourself JUST by it. Yechiel Adar Mehish ----- Original Message ----- To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Sent: Monday, January 13, 2003 3:03 AMHmm, Lately? That actually started publicly in 1998 as far as I am concerned;-)And acutally long before that. Anjo. ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Sunday, January 12, 2003 11:43 PMOn Friday 10 January 2003 14:48, Mogens Norgaard wrote:Obviously, we don't know what we're talking about. I can see there'sapresentation by Rich Niemich at IOUG-A where he'll address all those idiots who are saying you should ignore the Cash Hit Ratio (and whoareall just after making big money on their products - I loved thatone).Or modify the set up of these tools to take action when BCHRfalls......Here's the session info: Date: Mon, Apr 28, 2003 @ 11:45 AM - 12:15 PM Venue: Southern Hemisphere 2, Walt Disney World Dolphin, Lake Buena Vista, FL Abstract: Lately, there has been a big push to ignore your hit ratio with claims that it is meaningless. This shallow minded view (usually by people who sell a tuning tool) ignores why people look at hit ratios and what they are looking for. This quick tip talk will show you what to look for and why. You will definitely know when, where & why to look at your hit ratio in the future. Show you why your hit ratio matters. How to analyze the hit ratio. Fallacies by those who want to sell you products and tools instead. Shallow Minded ?! Jared --
