10.2.0.3 does not use a index

Question

Hi
I have a simple query which in 9i uses a index but after upgrading to 10.2.0.3 has stopped useing the index and instead prefers a hash join and a full table scan.
Any idea if this is a bug in 10.2.0.3 or how do i go about doing this investigation
SELECT sum((col1)/(col2+col1))*col1*100/(col3)
    FROM tab1a, tab2 b 
    WHERE     a.tab2_id  = b.id 
          AND a.col2 = 26538  
          AND b.col3    > 0 
| Id  | Operation                     | Name                     | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
|   1 |  SORT AGGREGATE               |                          |      1 |      1 |      1 |00:00:00.30 |   64362 |      2 |
|   2 |   NESTED LOOPS                |                          |      1 |  23662 |  21348 |00:00:00.27 |   64362 |      2 |
|   3 |    TABLE ACCESS BY INDEX ROWID| tab1                 |      1 |  23662 |  21348 |00:00:00.03 |     316 |      1 |
|*  4 |     INDEX RANGE SCAN          | col2_idx    |      1 |  23662 |  21348 |00:00:00.01 |      51 |      0 |
|*  5 |    TABLE ACCESS BY INDEX ROWID| tab2                |  21348 |      1 |  21348 |00:00:00.21 |   64046 |      1 |
|*  6 |     INDEX UNIQUE SCAN         | tab2_PK             |  21348 |      1 |  21348 |00:00:00.12 |   42698 |      0 |
Predicate Information (identified by operation id):
   4 - access("A"."col2"=26538)
   5 - filter("B"."col3">0)
   6 - access("A"."tab2_ID"="B"."ID")
Plan in 10g 10.2.0.3
PLAN_TABLE_OUTPUT
Plan hash value: 2369063540
| Id  | Operation                     | Name                     | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
|   1 |  SORT AGGREGATE               |                          |      1 |      1 |      1 |00:00:45.80 |     196K|    193K|       |       |          |
|   3 |    TABLE ACCESS BY INDEX ROWID| tab1                |      1 |  24189 |  21348 |00:00:00.02 |     318 |      0 |       |       |          |
|*  4 |     INDEX RANGE SCAN          | col2_idx |      1 |  24189 |  21348 |00:00:00.01 |      51 |      0 |       |       |          |
|*  5 |    TABLE ACCESS FULL          | tab2                |      1 |     12M|     12M|00:00:37.20 |     196K|    193K|       |       |          |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   2 - access("A"."tab2_ID"="B"."ID")
   4 - access("A"."col2"=26538)
   5 - filter("B"."col3">0)Any idea how do i find out why the index usage has been stopped

Answer 1

Hi
Here are the plans on the 10gr2 database with and without the hints.
The index plan uses some milliseconds to get the answer whereas the full table acesses gets the result in about 2 minutes which is not acceptable
I am trying to generate the 10053 trace
I am not in favour of fiddling around with the Optimizer parameters as i am not sure what could go wrong with other queries
| Id  | Operation                     | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                          |     1 |    36 |  8955  (16)| 00:00:43 |
|   1 |  SORT AGGREGATE               |                          |     1 |    36 |            |          |
|*  2 |   HASH JOIN                   |                          | 24605 |   865K|  8955  (16)| 00:00:43 |
|   3 |    TABLE ACCESS BY INDEX ROWID| tab1                     | 24605 |   360K|   374   (1)| 00:00:02 |
|*  4 |     INDEX RANGE SCAN          | tab1_col2_I              | 24605 |       |    61   (2)| 00:00:01 |
|*  5 |    TABLE ACCESS FULL          | tab2                     |    12M|   248M|  8398  (15)| 00:00:40 |
Predicate Information (identified by operation id):
   2 - access("A"."tab2_ID"="B"."ID")
   4 - access("A"."col2"=31108)
   5 - filter("B"."col3">0)
19 rows selected.
Elapsed: 00:00:00.01
explain plan for
SELECT /*+ INDEX(b tab2_PK) */
     sum((col1)/(col2+col1))*col1*100/(col3)
FROM tab1 a, tab2 b
WHERE     a.tab2_id  = b.id
AND a.col2 = 31108
AND b.col3    > 0
PLAN_TABLE_OUTPUT
Plan hash value: 3651119713
| Id  | Operation                     | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                          |     1 |    36 | 49644   (1)| 00:03:56 |
|   1 |  SORT AGGREGATE               |                          |     1 |    36 |            |          |
|   2 |   NESTED LOOPS                |                          | 24605 |   865K| 49644   (1)| 00:03:56 |
|   3 |    TABLE ACCESS BY INDEX ROWID| tab1                       | 24605 |   360K|   374   (1)| 00:00:02 |
|*  4 |     INDEX RANGE SCAN          | tab1_col2_I            | 24605 |       |    61   (2)| 00:00:01 |
|*  5 |    TABLE ACCESS BY INDEX ROWID| tab2                     |     1 |    21 |     2   (0)| 00:00:01 |
|*  6 |     INDEX UNIQUE SCAN         | tab2_PK                  |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - access("A"."col2"=31108)
   5 - filter("B"."col3">0)
   6 - access("A"."tab2_ID"="B"."ID")
20 rows selected.
Elapsed: 00:00:00.01
{code}
regards
Hrishy
Edited by: hrishy on Dec 19, 2008 2:10 AM
Edited by: hrishy on Dec 19, 2008 2:15 AM