Oracle 9i/10g - Parses/Invalidations

Question

Hello guys,
i have seen something weird in oracle 10g, while parsing and validating the sql statements... maybe you can explain...
So the following situation with my statements:
alter system flush shared_pool;
drop table a;
create table a as select * from dba_objects;
create index i1#a on a(object_id);
exec dbms_stats.gather_table_stats(null,'a');
variable v number
begin
:v := 1000;
end;
prompt first
select sum(data_object_id) from a where object_id=:v;
select loads, invalidations, parse_calls, object_status, plan_hash_value
from v$sql where sql_text='select sum(data_object_id) from a where object_id=:v';
prompt changes
update a set object_id=1000;
commit;
exec dbms_stats.gather_table_stats(null,'a');
select loads, invalidations, parse_calls, object_status, plan_hash_value
from v$sql where sql_text='select sum(data_object_id) from a where object_id=:v';
prompt second
select sum(data_object_id) from a where object_id=:v;
select loads, invalidations, parse_calls, object_status, plan_hash_value
from v$sql where sql_text='select sum(data_object_id) from a where object_id=:v';
exit;
And now the outputs of the oracle 9i and 10g..
9i:
first
LOADS INVALIDATIONS PARSE_CALLS OBJECT_STATUS PLAN_HASH_VALUE
1 0 1 VALID 3844206385
changes
LOADS INVALIDATIONS PARSE_CALLS OBJECT_STATUS PLAN_HASH_VALUE
1 1 0 0
second
LOADS INVALIDATIONS PARSE_CALLS OBJECT_STATUS PLAN_HASH_VALUE
2 1 1 VALID 3918351354
Setting new stats on the table is setting parse_calls to 0 and invalidations to 1. At the next execution of the statement, it is reparsed and a new exectuion plan( hash value 3918351354) is created.
Ok under 9i it is clear... but now have a look at 10g (with exact the same statements)
10g:
LOADS INVALIDATIONS PARSE_CALLS OBJECT_STATUS PLAN_HASH_VALUE
1 0 1 VALID 3844206385
changes
LOADS INVALIDATIONS PARSE_CALLS OBJECT_STATUS PLAN_HASH_VALUE
1 0 1 VALID 3844206385
second
LOADS INVALIDATIONS PARSE_CALLS OBJECT_STATUS PLAN_HASH_VALUE
1 0 2 VALID 3844206385
The execution plan is all the time valid and a new one is not created (see hash_value). Only a new parse occurs. But the execution plan changed after the creating the new "stats" (from index range scan to table access full)
Can you explain this... why the hash_value of the execution plan is the same, although it is a new plan?
Thanks and regards
Stefan

Answer 1

I recall a Jonathan Lewis blog about DBMS_STATS changing default values significantly in 10g.
If you compare the 9.2 declaration of the no_invalidate parameter...
no_invalidate boolean default FALSE...with that in 10g...
no_invalidate boolean default to_no_invalidate_type (get_param ('NO_INVALIDATE'))...they initially appear similiar - you would think that 'NO_INVALIDATE' means 'FALSE', right? Wrong...
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
SQL> SELECT dbms_stats.get_param ('NO_INVALIDATE')
  2  FROM   DUAL;
DBMS_STATS.GET_PARAM('NO_INVALIDATE')
DBMS_STATS.AUTO_INVALIDATE
SQL>...which means that the default behavior in 10g is AUTO_INVALIDATE, which bizarre double negative, according to documentation, means 'to have Oracle decide when to invalidate dependent cursors', which apparently means Oracle won't typically invalidate every dependent cursor, whereas in 9i it did, with potential performance problems.
Exactly how this is related to your issue I am not sure, but it seems likely you can return to the previous behaviour if so desired by using no_invalidate = FALSE, or setting this parameter value with SET_PARAM procedure.