Re: testing memory parameters
Date: Mon, 17 Mar 2008 04:19:21 GMT
Serge Rielau <srielau_at_ca.ibm.com> wrote in news:64697qF29ubhfU1 @mid.individual.net:
> Ana C. Dent wrote:
>> Serge Rielau <srielau_at_ca.ibm.com> wrote in news:6460opF29k6iqU1 >> @mid.individual.net: >> >>> Is my reasoning wrong as far as Oracle is concerned? If so where? >>> >>> Cheers >>> Serge >> >> http://oratips-ddf.blogspot.com/2007/07/bchr-follies-my-two-cents.html
>> >> Obtain any value of BCHR that you deem appropriate. >> >> >> http://www.google.com/search?sourceid=navclient&ie=UTF-8&rlz= >> 1T4TSHB_enUS209US211&q=oracle+BCHR >> >> beware a line wrap in URL above
> Faszinating. I use similar examples when I teach about how good hit
> ratio does not mean the application is good.
> Stuff like (instant doubling of hit ratio for the row):
> IF EXISTS(SELECT 1 FROM T WHERE pk = 1) THEN
> UPDATE T SET c1 = 5 WHERE pk = 1;
> END IF;
> But from an admittedly cursory read I fail to see how this implies
> a bad hit ratio can also imply that the application is good?
> If it doesn't blink it's no reason to relax.
> But when it blinks I better pay attention.
> PS: Is there similar wisdom on "rows fetched vs. rows read"?
> Fetched == Rows returned by the cursor
> Read = Rows touched to produce the above.
Below what value is BCHR "bad"?
Above what value is BCHR "good"?
What are the exceptions to the two answer to above questions? What are the exceptions to the exceptions? Received on Sun Mar 16 2008 - 23:19:21 CDT