Oracle 10.2.0.4 vs 10.2.0.5 SQL optimizer

Question

Hello,
Recently we upgraded from Oracle 10.2.0.4 to 10.2.0.5 deployed on AIX 5. Immediately we could see slowness for a particular SQL which used partition as well as indexed column in predicate clause.
e.g.
SELECT COL1, COL2
FROM TAB1 PARTITION (P1)
WHERE TAB1.COL3 = 123;
There is an index created on COL3. However explain plan for this SQL showed that this index was not getting used. Surprisingly, when we removed partition from SQL, itused the index
SELECT COL1, COL2
FROM TAB1
WHERE TAB1.COL3 = 123;
There is one more observation - When we reverted back to 10.2.0.4 optimization strategy on Oracle 10.2.0.5. The original SQL that had partition clause used the index as it should have been and explain plan matched to what was before the Oracle upgrade.
I have few questions based on these observations. Any help will be appreciated.
1. Are there any changes in the 10.2.0.5 optimizer that is making SQL becoming slow?
2. Is there any problem in SQL that is making it slow?
3. I believe moving to 10.2.0.4 optmizer on Oracle 10.2.0.5 is a short-term solution. Is there any permanent fix to this problem?
4. Does Oracle 11g support 10.2.0.4 optimizer?
Please let me know if more details are needed.
Thank you!

Answer 1

Onkar Talekar wrote:
1. Are there any changes in the 10.2.0.5 optimizer that is making SQL becoming slow?There are always changes with the CBO happening, it's a complicated bit of software. Some bugs will be fixed, others introduced. You may have been unfortunate enough to hit a bug, search MOS or raise a SR with Oracle support if you feel that is the case.
Onkar Talekar wrote:
2. Is there any problem in SQL that is making it slow?Entirely possible you have a poorly written SQL statement, yes.
Onkar Talekar wrote:
3. I believe moving to 10.2.0.4 optmizer on Oracle 10.2.0.5 is a short-term solution. Is there any permanent fix to this problem?Yes, raise a SR with Oracle.
Onkar Talekar wrote:
4. Does Oracle 11g support 10.2.0.4 optimizer?Yes, but i wouldn't recommend running an 11 instance with optimizer compatibility set to less than the current version without a very compelling reason (the one you've posted doesn't seem to be compelling to me at the moment).
What happens if you specify the partition column in the WHERE clause instead of the actual partition in the FROM clause ... Oracle should use partition elimination to visit only that partition and utilize the local index on COL3 (i am assuming there is a local index in play here).
I would guess, a very speculative guess, that you hit a bug pertaining to specifying the partition name, and that if you can get Oracle to do a partition elimination on it's own (instead of 'hard coding' the partition name) that it will smarten up and you'll get the execution plan you want / expect ... just a guess.