RE: Execution plan changing
From: Allen, Brandon <Brandon.Allen_at_OneNeck.com>
Date: Fri, 14 Sep 2012 04:07:25 +0000
Message-ID: <A250F0C68C23514CA9F3DF63D60EE10E1A8385C9_at_onews32>
Sounds like time for some 10046 and 10053 tracing, but to start with, I'd use the following query to pull the details out of the shared pool for a good execution and again for a bad execution and check to see for sure if it's doing bind variable peeking and if so, what are the differences in bind variables and cardinality estimates, and if both queries are in the shared pool at the same time, maybe v$sql_shared_cursor would give some indication of why it's parsing them differently. Maybe the developer isn't successfully setting that parameter in both cases.
Date: Fri, 14 Sep 2012 04:07:25 +0000
Message-ID: <A250F0C68C23514CA9F3DF63D60EE10E1A8385C9_at_onews32>
Sounds like time for some 10046 and 10053 tracing, but to start with, I'd use the following query to pull the details out of the shared pool for a good execution and again for a bad execution and check to see for sure if it's doing bind variable peeking and if so, what are the differences in bind variables and cardinality estimates, and if both queries are in the shared pool at the same time, maybe v$sql_shared_cursor would give some indication of why it's parsing them differently. Maybe the developer isn't successfully setting that parameter in both cases.
select * from table(dbms_xplan.display_cursor('<sql_id>','<child_number>','ALLSTATS LAST PEEKED_BINDS'));
Regards,
Brandon
Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it.
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Sep 13 2012 - 23:07:25 CDT