right, if it's not re-parsed (hard parsed) then you'd think it's using
existing parsed sql. But then you might also think that would mean
that "parse count (total)" which includes "parse count (hard)" would
equal "execute count". But in all of my bstat/estat reports, they
don't. By the way, it seems that the more hard parses you have the
closer the numbers get to being equal.
Thank,
Scott
In article <91thf7$hdl$1_at_nnrp1.deja.com>,
steveee_ca_at_my-deja.com wrote:
> Hi Scott,
>
> Also,if an SQL statement is issued that's identical to one that's
> already in the Shared Pool it doesn't have to be re-parsed.
>
> Hth,
>
> Steve
>
> In article <91tbo6$c4j$1_at_nnrp1.deja.com>,
> H2oStyle <sdempsey_at_my-deja.com> wrote:
> > Anyone know why in the bstat/estat report the number of total parses
> > doesn't equal the execute count?
> >
> > The other related or underlying question was that if it's not a hard
> > parse, what is it? Most people say its a soft parse meaning that it
> > found a shared sql statement in the cache to use. But then we come
> > back to the original question.
> >
> > I'm wondering if perhaps it might have something related to do with
the
> > way the client tries to exec sql or rather the way it passes it to
> > oracle.
> >
> > Thanks,
> > Scott
> >
> > Sent via Deja.com
> > http://www.deja.com/
> >
>
> Sent via Deja.com
> http://www.deja.com/
>
Sent via Deja.com
http://www.deja.com/
Received on Thu Dec 21 2000 - 13:12:32 CST
