Explain Plan vs. V$SQL_PLAN

Question

Hello everyone,
I'm trying to understand the difference between those two, I'm relying on the following Tom Kyte article :
http://tkyte.blogspot.com/2007/04/when-explanation-doesn-sound-quite.html
In my following example I didn't use TKPROF as he did but AUTOTRACE / V$SQL_PLAN instead (since EXPLAIN PLAN shows a theoretical plan that can be used if this statement were to be executed and V$SQL_PLAN contains the actual plan used)
That's my code :
>
HR> ALTER SYSTEM FLUSH shared_pool ;
HR>
HR> create table test
2 as
3 select a.*, 1 id
4 from all_objects a
5 where rownum = 1;
Table created.
HR>
HR> create index t_idx on test(id);
Index created.
HR>
HR> -- AUTOTRACE vs V$SQL round 1 ...
HR> ---------------------------------
HR>
HR> SET AUTOTRACE ON EXPLAIN
HR>
HR> select id, object_name from test where id = 1;
ID OBJECT_NAME
1 ICOL$
Execution Plan
Plan hash value: 2783519773
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 30 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 30 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | T_IDX | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("ID"=1)
Note
- dynamic sampling used for this statement (level=2)
HR>
HR> SET AUTOTRACE OFF
HR>
HR>
HR> select operation, options, object_name, cost
2 from v$sql_plan
3 where hash_value= ( SELECT hash_value
4 FROM v$sqlarea
5 WHERE sql_text LIKE 'select id, object_name from test where id = 1'
6 AND sql_text NOT LIKE '%v_sql%');
OPERATION OPTIONS OBJECT_NAME COST
SELECT STATEMENT 2
TABLE ACCESS BY INDEX ROWID TEST 2
INDEX RANGE SCAN T_IDX 1
>
Ok so in round 1, the optimizer decided to get the 1 row back using Index Range Scan both in "theory" and in "reality", it make sense.
Now its time for round 2 ... :)
>
HR> insert into test select a.*, 1 from all_objects a where rownum < 1001 ;
1000 rows created.
HR>
HR> commit ;
Commit complete.
HR>
HR>
HR> -- AUTOTRACE vs V$SQL round 2 ...
HR> ---------------------------------
HR>
HR> SET AUTOTRACE ON EXPLAIN
HR>
HR> select id, object_name from test where id = 1;
ID OBJECT_NAME
1 ICOL$
1 I_VIEWTRCOL1
1001 rows selected.
Execution Plan
Plan hash value: 2783519773
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1001 | 30030 | 6 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1001 | 30030 | 6 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | T_IDX | 1001 | | 5 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("ID"=1)
Note
- dynamic sampling used for this statement (level=2)
HR>
HR> select operation, options, object_name, cost
2 from v$sql_plan
3 where hash_value= ( SELECT hash_value
4 FROM v$sqlarea
5 WHERE sql_text LIKE 'select id, object_name from test where id = 1'
6 AND sql_text NOT LIKE '%v_sql%');
OPERATION OPTIONS OBJECT_NAME COST
SELECT STATEMENT 2
TABLE ACCESS BY INDEX ROWID TEST 2
INDEX RANGE SCAN T_IDX 1
HR>
>
since explain plan is using always Hard Parse (and it used dynamic sampling) I would expect to see FTS in "theory"
can anyone explain me why in round 2 they both presented Index Range Scan.
Thanks ! :)

Answer 1

Explain plan can lie, autotrace - which just does an explain plan - can lie.
See:
http://oracle-randolf.blogspot.com/2012/01/autotrace-polluting-shared-pool.html
http://kerryosborne.oracle-guy.com/2010/02/autotrace-lies/
http://hoopercharles.wordpress.com/2010/01/11/explain-plan-lies-autotrace-lies-tkprof-lies-what-is-the-plan/
V$SQL_PLAN is the truth.
You didn't mention version but DBMS_XPLAN is the most convenient way to get your plan.
If the plan is cached, inserting 1000 rows is not going to change the plan.
SQL> create table test
  2  as
  3  select a.*, 1 id
  4  from all_objects a
  5  where rownum = 1;
Table created.
SQL>
SQL> create index t_idx on test(id);
Index created.
SQL>
SQL> select id, object_name from test where id = 1;
        ID OBJECT_NAME
         1 ORA$BASE
SQL>
SQL> select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
SQL_ID  3qan6s0j3uab5, child number 0
select id, object_name from test where id = 1
Plan hash value: 2783519773
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |       |       |       |     2 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST  |     1 |    30 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | T_IDX |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("ID"=1)
Note
   - dynamic sampling used for this statement (level=4)
23 rows selected.
SQL> insert into test select a.*, 1 from all_objects a where rownum < 1001 ;
1000 rows created.
SQL> commit;
Commit complete.
SQL> select id, object_name from test where id = 1;
SQL> select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
SQL_ID  3qan6s0j3uab5, child number 0
select id, object_name from test where id = 1
Plan hash value: 2783519773
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |       |       |       |     2 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST  |     1 |    30 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | T_IDX |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("ID"=1)
Note
   - dynamic sampling used for this statement (level=4)
23 rows selected.
SQL>