Re: Same Query, same database, same application, new plan from one environment but not from another

I've got the results of the traces back and it looks like the Access code is now passing a date bind variable in as something that prevents the proper use of the indexed date column. I say this because when I look at the trace I see the internal_function on the indexed column and when I run the query, with the only modification being adding 0 to the date column I get my bad explain plan.

What's perplexing is that everyone claims that there were no changes made. What I know for sure is that there was an upgrade to a new release of the Oracle Windows ODBC driver -- 10.2.0.4 ( supposedly migrated a few weeks prior to our problem start) and that the Oracle statistics collection procedure was changed from a 30% estimate to COMPUTE on the day the problem was first reported.

On 8/27/08, Rumpi Gravenstein <rgravens_at_gmail.com> wrote:
>
> <snip>
> 10g stores previous version of stats for 30 days by default, you can
> revert stats to see if the better performing plans return and if so
> you can compare the different versions of the stats and plans to
> identify the culprit and correct it.
> </snip>
>
> The queries from the two environments are run within a few minutes of each
> other, sometimes the Toad version first and sometimes the Access version.
> Each run uses the same, single bind value. Given that I can't see how the
> problem can be related to differences in statistics.
>
> I'll check meta-link for odbc slow-down bugs.
>

-- 
Rumpi Gravenstein

--
http://www.freelists.org/webpage/oracle-l