RE: Caching sql query not happening

Not being found as a cache hit resulting in an additional parse is different from not being in the cache. Oh a happy thing indeed if you could actually tell Oracle not to use the cache at all for a specific one time query or whole sessions running outdated vendor code full of literals! Then the penalty would only be the cost of extra parses (if any) to the single query or application instead of cache lock pile up and cache consumption for the code designed to be reparsible. But alas, the hegemony of cache fanatics is complete and brooks no exception.

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Vikas Gautam Sent: Friday, June 03, 2005 5:29 PM
To: paul.baumgartel_at_gmail.com
Cc: oracle-l_at_freelists.org
Subject: Re: Caching sql query not happening

I am looking at the SQL area and this has

load count 335
parse calls 335
executions 335

and it seems that it is being parsed every time.

Vikas
----- Original Message -----
From: "Paul Baumgartel" <paul.baumgartel_at_gmail.com> To: <g_vikas_at_hotmail.com>
Cc: <oracle-l_at_freelists.org>
Sent: Friday, June 03, 2005 4:17 PM
Subject: Re: Caching sql query not happening

> What's your evidence that it's never stored in the shared pool? Do
> you not find it in V$SQL/V$SQLAREA after a parse?
>
>
> --=20
> Paul Baumgartel
> paul.baumgartel_at_aya.yale.edu
>
> On 6/3/05, Vikas Gautam <g_vikas_at_hotmail.com> wrote:
>>=20
>> > Does anyone know why a statement such as:
>> >
>> > SELECT ID
>> > FROM ELSR dups
>> > WHERE (dups.directoryID =3D :"SYS_B_0"
>> > AND dups.DeviceIdentifier =3D :"SYS_B_1"
>> > AND dups.serviceStartTime BETWEEN TIMESTAMP:"SYS_B_2" AND
>> > TIMESTAMP:"SYS_B_3")
>> >
>> > will never cache in the Shared Pool?
> --
> http://www.freelists.org/webpage/oracle-l
>

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l