[This message is not technical, but educational. Readers interested in technical info only may want to skip] Hi, Cary and Gopal, My last message is misunderstood. Nowadays most DBAs that still use buffer cache hit ratio as a primary performance tuning method are those that rarely browse public forums. When we convince them that's a wrong method, we should not say "Look. I can bump up BCHR to an arbitrary value". If he doesn't think, he'll say "Indeed. If I can get any value, it must be rubbish". But if he's a logical person and thinks for a few minutes, he'll say "It's unfair to run that choose_a_hit_ratio program to get an arbitrary hit ratio and say the method is wrong, because you can use the same logic to write a program to get an arbitrary library cache hit ratio, OS in-core inode cache hit ratio or directory name cache hit..." My last message is not meant to revive the outdated and probably never correct tuning method. Instead it's meant to let oracle-l members know that when you need to convince those DBAs that still use that method, you need to accuse the BCHR method for correct reason, namely, BCHR does not contain sufficient information for tuning, not because you can raise its value by constantly scanning a table in Oracle; you won't be able to convince some stubbon DBAs who enjoy thinking in a quiet place. I agree that "It's not the ratio that needs condemning, it's the advice about..." What I disagree is the wrong educational tool people on public forums have recently used again and again to show the inadequacy of the BCHR tuning method. Yong Huang Hi, Carel-Jan and Rich, Connor's script to bump up buffer cache hit ratios is meant to be a humor. Only if you carefully comtemplate it will you see that there's no relevance of the fact that you can get any hit ratio to the fact that hit ratios are insufficient in performance tuning. It would be equally easy to write scripts to bump up some wait event times. If you need very long db file reads, create a big table and keep scanning it. If you need long enqueue waits, create a table and insert a row. Create 10 or 100 sessions (depending on your patience) and delete from that table and wait. The fact that you can get arbitary wait times does not reduce the efficacy of wait event interface as a performance tuning tool. Buffer cache or library cache hit ratios are not sufficient, very insufficient used alone, to tune the database. The reason is that they don't contain enough information to tune the system with. This is the only reason we should not solely rely on them; in fact, not using them at all doesn't hurt much. The reason is not that we can get any value we want by playing pranks. Hit ratios are still used in other performance tuning and not condemned. Although in UNIX performance tuning one looks at absolute numbers such as scan rate, CPU usage and netstat output more often, hit ratios in some sar output are still occasionally used. Most ratios could still be distored by a rogue user repeatedly doing, say, "find /" for inodes or "find / -exec grep SomeThing {} \;" for page cache. In any tuning practice, Oracle or OS, artificially distorting usage patterns invalidates your numbers even if you're using a well respected tuning method. So only play pranks on a play box, not production. Yong Huang At 11:14 22-12-03 -0800, you wrote: >My BCHR is currently 96.62%. In the past, it was normally over 99%. What >should I do? > >I'll be waiting for Mladen's reply... :) > > >Rich > >Rich Jesse System/Database Administrator >rjesse AT qtiworld.com Quad/Tech Inc, Sussex, WI USA Go to www.oracledba.co.uk (Connor) or go to O'Reilly (download page of Cary's book), and download one of the fabulous BCHR enhancement scripts. Especially when your bonus depends on it, this is a good time to perform some BCHR tuning. Regards, Carel-Jan Hi Yong > I agree that "It's not the ratio that needs condemning, it's > the advice about..." What I disagree is the wrong educational > tool people on public forums have recently used again and > again to show the inadequacy of the BCHR tuning method. The thing is most people who have used this demonstration, use it for 2 reasons 1. It is immediately recognised and empathised with by the audience and 2. It is easily explained. "How does it work, by doing pointless io, hmmm I wonder if that is a problem with my real system." You are of course in principle correct that one could use the same technique against other ratios, my suggestion would be that this might also be appropriate for similar reasons. My CPU is 75% utilized on my web server, I wonder does this mean it is well specified or that I am doing pointless cpu work? If people are merely saying "the bchr is useless, here is a script that will create one for you" then I would agree with you, but in my experience the argument is more cogent than that. Niall