RE: Caching sql query not happening
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <g_vikas@xxxxxxxxxxx>, <paul.baumgartel@xxxxxxxxx>
- Date: Sun, 5 Jun 2005 07:53:42 -0400
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Vikas Gautam
Sent: Friday, June 03, 2005 5:29 PM
To: paul.baumgartel@xxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxx>
To: <g_vikas@xxxxxxxxxxx>
Cc: <oracle-l@xxxxxxxxxxxxx>
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@xxxxxxxxxxxx
>
> On 6/3/05, Vikas Gautam <g_vikas@xxxxxxxxxxx> 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?
> --
> //www.freelists.org/webpage/oracle-l
>
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
