Locked table stats on volatile IOT result in suboptimal execution plan

Question

Hello,
since upgrading to 10gR2 we are experiencing weird behaviour in execution plans of queries which join tables with a volatile IOT on which we deleted and locked statistics.
Execution plan of the example query running ok (SYS_IOT... is the volatile IOT):
   0       SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=12 Card=1 Bytes=169)
   1    0    SORT AGGREGATE (Card=1 Bytes=169)
   2    1      NESTED LOOPS OUTER (Cost=12 Card=1 Bytes=169)
   3    2        NESTED LOOPS OUTER (Cost=10 Card=1 Bytes=145)
   4    3          NESTED LOOPS (Cost=6 Card=1 Bytes=121)
   5    4            NESTED LOOPS OUTER (Cost=5 Card=1 Bytes=100)
   6    5              NESTED LOOPS (Cost=5 Card=1 Bytes=96)
   7    6                INDEX FAST FULL SCAN ...SYS_IOT_TOP_76973 (Cost=2 Card=1 Bytes=28)
   8    6                TABLE ACCESS BY INDEX ROWID ...VSUC (Cost=3 Card=1 Bytes=68)
   9    8                  INDEX RANGE SCAN ...VSUC_VORG (Cost=2 Card=1)Since 10gR2 the index on the joined table is not used:
   0       SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=857 Card=1 Bytes=179)
   1    0    SORT AGGREGATE (Card=1 Bytes=179)
   2    1      NESTED LOOPS OUTER (Cost=857 Card=1 Bytes=179)
   3    2        NESTED LOOPS OUTER (Cost=855 Card=1 Bytes=155)
   4    3          NESTED LOOPS (Cost=851 Card=1 Bytes=131)
   5    4            NESTED LOOPS OUTER (Cost=850 Card=1 Bytes=110)
   6    5              NESTED LOOPS (Cost=850 Card=1 Bytes=106)
   7    6                TABLE ACCESS FULL ...VSUC (Cost=847 Card=1 Bytes=68)
   8    6                INDEX RANGE SCAN ...SYS_IOT_TOP_76973 (Cost=3 Card=1 Bytes=38)I did a UNLOCK_TABLE_STATS and GATHER_TABLE_STATS on the IOT and everything worked fine - the database used the first execution plan.
Also, setting OPTIMIZER_FEATURES_ENABLE to 10.1.0.4 results in the correct execution plan, whereas 10.2.0.2 (standard on 10gR2) doesn't use the index - so i suppose it's an optimizer problem/bug/whatever.
I've also tried forcing the index with a hint - it's scanning the index but the costs are extremly high.
Any help would be greatly appreciated,
regards
-sd

Answer 1

sdeng,
The first thing you should do is to switch to using the dbms_xplan package for generating execution plans. Amongst other things, this will give you the filter and access predicates as they were when Oracle produced the execution plan. It will also report comments like: 'dynamic sampling used for this statement'.
If you have deleted and locked stats on the IOT, then 10gR2 will (by default) be using dynamic sampling on that object - which means (in theory) it gets a better picture of how many rows really are there, and how well they might join to the next table. This may be enought to explain the change in plan.
What you might try, if the first plan is guaranteed to be good, is to collect stats on the IOT when there is NO data in the IOT, then lock the stats. (Alternatively, fake some stats that say the table is empty if it never is really empty).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk