Re: testing memory parameters

From: Serge Rielau <srielau_at_ca.ibm.com>
Date: Mon, 17 Mar 2008 00:09:28 -0400
Message-ID: <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 that 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.

Cheers
Serge

PS: Is there similar wisdom on "rows fetched vs. rows read"? Fetched == Rows returned by the cursor
Read = Rows touched to produce the above.

-- 
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab
Received on Sun Mar 16 2008 - 23:09:28 CDT

Original text of this message