Oracle not using its own explain plan

Question

When I run a simple select query on an indexed column on a large (30 million records) table oracle creates a plan using the indexed column and at a cost of 4. However, what it actually does is do a table scan (I can see this in the 'Long Operations' tab in OEM).
The funny thing is that I have the same query in a ADO application and when the query is run from there, the same plan is created but no table scan is done - and the query returns in less than a second. However, with the table scan it is over a minute.
When run through SQL plus Oracle creates a plan including the table scan at a cost of 19030.
In another (dot net) application I used the: "Alter session set optimizer_index_caching=100" and "Alter session set optimizer_index_cost_adj=10" to try to force the optimizer to use the index. It creates the expected plan, but still does the table scan.
The query is in the form of:
"Select * from tab where indexedcol = something"
Im using Oracle 9i 9.2.0.1.0
Any ideas as I'm completely at a loss?

Answer 1

Hello
It sounds to me like this has something to do with bind variable peeking which was introduced in 9i. If the predicate is
indexedcolumn = :bind_variablethe first time the query is parsed by oracle, it will "peek" at the value in the bind variable and see what it is and will generate an execution plan based on this. That same plan will be used for matching SQL.
If you use a litteral, it will generate the plan based on that, and will generate a separate plan for each litteral you use (depending on the value of the cursor_sharing initialisation parameter).
This can cause there to be a difference between the execution plan seen when issuing EXPLAIN PLAN FOR, and the actual exectuion plan used when the query is run.
Have a look at the following example:
tylerd@DEV2> CREATE TABLE dt_test_bvpeek(id number, col1 number)
  2  /
Table created.
Elapsed: 00:00:00.14
tylerd@DEV2> INSERT
  2  INTO
  3      dt_test_bvpeek
  4  SELECT
  5      rownum,
  6      CASE
  7          WHEN MOD(rownum, 5) IN (0,1,2,3) THEN
  8              1
  9          ELSE
10              MOD(rownum, 5)
11          END
12      END
13  FROM
14      dual
15  CONNECT BY
16      LEVEL <= 100000
17  /
100000 rows created.
Elapsed: 00:00:00.81
tylerd@DEV2> select count(*), col1 from dt_test_bvpeek group by col1
  2  /
  COUNT(*)       COL1
     80000          1
     20000          4
2 rows selected.
Elapsed: 00:00:00.09
tylerd@DEV2> CREATE INDEX dt_test_bvpeek_i1 ON dt_test_bvpeek(col1)
  2  /
Index created.
Elapsed: 00:00:00.40
tylerd@DEV2> EXEC dbms_stats.gather_table_stats( ownname=>USER,-
tabname=>'DT_TEST_BVPEEK',-
method_opt=>'FOR ALL INDEXED COLUMNS SIZE 254',-
cascade=>TRUE -
);PL/SQL procedure successfully completed.
Elapsed: 00:00:00.73
tylerd@DEV2> EXPLAIN PLAN FOR
  2  SELECT
  3      *
  4  FROM
  5      dt_test_bvpeek
  6  WHERE
  7      col1 = 1
  8  /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
  2  /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id  | Operation         | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT  |                | 78728 |   538K|    82  (52)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| DT_TEST_BVPEEK | 78728 |   538K|    82  (52)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("COL1"=1)
13 rows selected.
Elapsed: 00:00:00.06The execution plan for col1=1 was chosen because oracle was able to see that based on the statistics, col1=1 would result in most of the rows from the table being returned.
tylerd@DEV2> EXPLAIN PLAN FOR
  2  SELECT
  3      *
  4  FROM
  5      dt_test_bvpeek
  6  WHERE
  7      col1 = 4
  8  /
Explained.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
  2  /
PLAN_TABLE_OUTPUT
Plan hash value: 3223879139
| Id  | Operation                   | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |                   | 21027 |   143K|    74  (21)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| DT_TEST_BVPEEK    | 21027 |   143K|    74  (21)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | DT_TEST_BVPEEK_I1 | 21077 |       |    29  (28)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("COL1"=4)
14 rows selected.
Elapsed: 00:00:00.04This time, the optimiser was able to see that col1=4 would result in far fewer rows so it chose to use an index. Look what happens however when we use a bind variable with EXPLAIN PLAN FOR - especially the number of rows the optimiser estimates to be returned from the table
tylerd@DEV2> var an_col1 NUMBER
tylerd@DEV2> exec :an_col1:=1;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2>
tylerd@DEV2> EXPLAIN PLAN FOR
  2  SELECT
  3      *
  4  FROM
  5      dt_test_bvpeek
  6  WHERE
  7      col1 = :an_col1
  8  /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
  2  /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id  | Operation         | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT  |                | 49882 |   340K|   100  (60)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| DT_TEST_BVPEEK | 49882 |   340K|   100  (60)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("COL1"=TO_NUMBER(:AN_COL1))
13 rows selected.
Elapsed: 00:00:00.04
tylerd@DEV2>
tylerd@DEV2> exec :an_col1:=4;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.01
tylerd@DEV2>
tylerd@DEV2> EXPLAIN PLAN FOR
  2  SELECT
  3      *
  4  FROM
  5      dt_test_bvpeek
  6  WHERE
  7      col1 = :an_col1
  8  /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
  2  /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id  | Operation         | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT  |                | 49882 |   340K|   100  (60)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| DT_TEST_BVPEEK | 49882 |   340K|   100  (60)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("COL1"=TO_NUMBER(:AN_COL1))
13 rows selected.
Elapsed: 00:00:00.07For both values of the bind variable, the optimiser has no idea what the value will be so it has to make a calculation based on a formula which results in it estimating that the query will return roughly half of the rows in the table, and so it chooses a full scan.
Now when we actually run the query, the optimiser can take advantage of bind variable peeking and have a look at the value the first time round and base the execution plan on that:
tylerd@DEV2> exec :an_col1:=1;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
  2      *
  3  FROM
  4      dt_test_bvpeek
  5  WHERE
  6      col1 = :an_col1
  7  /
80000 rows selected.
Elapsed: 00:00:10.98
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
  2  /
PREV_SQL_ID
9t52uyyq67211
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
  2      operation,
  3      options,
  4      object_name
  5  FROM
  6      v$sql_plan
  7  WHERE
  8      sql_id = '9t52uyyq67211'
  9  /
OPERATION                      OPTIONS                        OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS                   FULL                           DT_TEST_BVPEEK
2 rows selected.
Elapsed: 00:00:00.03It saw that the bind variable value was 1 and that this would return most of the rows in the table so it chose a full scan.
tylerd@DEV2> exec :an_col1:=4
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
  2      *
  3  FROM
  4      dt_test_bvpeek
  5  WHERE
  6      col1 = :an_col1
  7  /
20000 rows selected.
Elapsed: 00:00:03.50
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
  2  /
PREV_SQL_ID
9t52uyyq67211
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
  2      operation,
  3      options,
  4      object_name
  5  FROM
  6      v$sql_plan
  7  WHERE
  8      sql_id = '9t52uyyq67211'
  9  /
OPERATION                      OPTIONS                        OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS                   FULL                           DT_TEST_BVPEEK
2 rows selected.
Elapsed: 00:00:00.01Even though the value of the bind variable changed, the optimiser saw that it already had a cached version of the sql statement along with an execution plan, so it used that rather than regenerating the plan. We can check the reverse of this by causing the statement to be invalidated and re-parsed - there's lots of ways, but I'm just going to rename the table:
Elapsed: 00:00:00.03
tylerd@DEV2> alter table dt_test_bvpeek rename to dt_test_bvpeek1
  2  /
Table altered.
Elapsed: 00:00:00.01
tylerd@DEV2>
20000 rows selected.
Elapsed: 00:00:04.81
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
  2  /
PREV_SQL_ID
6ztnn4fyt6y5h
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
  2      operation,
  3      options,
  4      object_name
  5  FROM
  6      v$sql_plan
  7  WHERE
  8      sql_id = '6ztnn4fyt6y5h'
  9  /
OPERATION                      OPTIONS                        OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS                   BY INDEX ROWID                 DT_TEST_BVPEEK1
INDEX                          RANGE SCAN                     DT_TEST_BVPEEK_I1
3 rows selected.
80000 rows selected.
Elapsed: 00:00:10.61
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
  2  /
PREV_SQL_ID
6ztnn4fyt6y5h
1 row selected.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT
  2      operation,
  3      options,
  4      object_name
  5  FROM
  6      v$sql_plan
  7  WHERE
  8      sql_id = '6ztnn4fyt6y5h'
  9  /
OPERATION                      OPTIONS                        OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS                   BY INDEX ROWID                 DT_TEST_BVPEEK1
INDEX                          RANGE SCAN                     DT_TEST_BVPEEK_I1
3 rows selected.This time round, the optimiser peeked at the bind variable the first time the statement was exectued and found it to be 4, so it based the execution plan on that and chose an index range scan. When the statement was executed again, it used the plan it had already executed.
HTH
David