Re: Different Plans for Literal Vs Bind Variables
- From: Ian MacGregor <ian@xxxxxxxxxxxxxxxxx>
- To: Oracle-L Freelists <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 09 Jan 2009 15:04:30 -0800
It;s 10.2.0.3. And the problem is that the plans are not the same. Bind
Variable peeking has not been switched off. 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. Bind
variable peeking is on by default. The optimizer_features_enable is set to
10.2.0.3 and I have not set _optim_peek_user_binds=false
Sql tuning advisor offered no help for this. Interestingly it did suggest a
profile for
SELECT MAX(B.EFFDT) FROM PS_DEPT_SCRTY_VW B
WHERE B.EFFDT<=TO_DATE(:A2,'YYYY-MM-DD')
The value of SETID is always SLAC.
Ian
On 1/9/09 2:47 PM, "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx> wrote:
> What's the DB version? If it's 9i+, are you using bind variable peeking? If
> so, then the plan with the literal should be the same as the plan with the
> bind variable unless the bind statement is already cached with a plan
> optimized based on a significantly different bind value. If you're not using
> bind variable peeking, the usual solution is to provide a hint or stored
> outline. If you can't do a hint since it's coming from PeopleSoft, then the
> outline is the way to go, or if you're in 10g and have the tuning pack, can
> use a SQL Profile, but if you're in 10g, then you should probably be using
> bind variable peeking.
>
> 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.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
