RE: kkslce [KKSCHLPIN2] mutex contention on hard parse of PQ with binds

Stefan,

That's the sort of thing.

I guess the bug aspect of that example is that the "describe" parse call is used for the execute even though the binds haven't been peeked (because they weren't there). 

More commonly the first plan wasn't used (and people were puzzled by seeing two child cursors with two plans) which would happen because the first parse call would  (just like "explain plan") assume the bind variables were character types and the real bind variables turned out to have a different type when the second parse call appeared.



Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
_at_jloracle

________________________________________
From: Stefan Koehler [contact_at_soocs.de]
Sent: 15 September 2015 11:49
To: Jonathan Lewis; oracle-l-freelists
Subject: RE: kkslce [KKSCHLPIN2] mutex contention on hard parse of PQ with binds

Hi Jonathan,
i guess you are talking about what Mauro and me have talked about here:

- https://www.freelists.org/post/oracle-l/In-what-circumstances-might-optimizer-not-choose-the-lowest-cost,15
- https://www.freelists.org/post/oracle-l/In-what-circumstances-might-optimizer-not-choose-the-lowest-cost,18

Basically it is OCI and fix 9630092 is also disabled by default with 12c (or at least with 12.1.0.1 as i have no 12.1.0.2 at hand right now).

Best Regards
Stefan Koehler

Freelance Oracle performance consultant and researcher
Homepage: http://www.soocs.de
Twitter: _at_OracleSK


> Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk> hat am 15. September 2015 um 12:25 geschrieben:
>
>  What's the environment from which you are calling the SQL ? Is it a basic SQL*Plus session, or some type of front-end that might be causing the
> double parse with binds anyway ?  I forget which mid-tier, or driver it was but there used to be common questions about seeing statement with bind
> variables being parsed twice, once with no values for the bind variable, then a second time because the values were only sent on a second call.
--