Re: Different Plans for Literal Vs Bind Variables

From: Ian MacGregor <ian_at_slac.stanford.edu>
Date: Fri, 09 Jan 2009 16:15:05 -0800
Message-ID: <C58D2889.16236%ian_at_slac.stanford.edu>



It was more than an assumption. The database had just been rebooted and no one was working at that time, and the statement was not run that would have been generated by someone else. However, just in case I got the SQL_id and then flush the shared pool and checked to see if the statement was in the library cache via v$sql. It was not so I tried the experiment again

Again the query plans differ. I know they should not but they do.

Ian

On 1/9/09 3:14 PM, "Allen, Brandon" <Brandon.Allen_at_OneNeck.com> wrote:

> The phrase "would not have been" indicates an assumption to me and you know
> what happens when we assume :-) I would leave nothing to chance and chec
> v$sql for the specific hash_value that appears in your raw 10046 trace file to
> be 100% positive that the query is not loaded in your library cache before you
> run it with the desired bind variable value. Then, if you verify that it gets
> hard parsed with the desired bind value and still doesn't get the same plan as
> the literal, I think your next step is to run two 10053 traces and diff them.
> In case you're not familiar with the 10053 trace, here's a good place to
> start:
>
> http://www.centrexcc.com/A%20Look%20under%20the%20Hood%20of%20CBO%20-%20the%20
> 10053%20Event.pdf
>
> Regards,
> Brandon
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On
> Behalf Of Ian MacGregor
>
> The statements were new so they
> would not have been in the library cache, and the values reported for the
> 10046 level 12 trace matched those in the query with literals
>
>
> 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-l
Received on Fri Jan 09 2009 - 18:15:05 CST

Original text of this message