oracle统计量对于cbo执行是至关重要的。rbo是建立在数据结构的基础上的，ddl结构、约束会将sql语句分为不同的成本结构等级。而cbo是在数据结构的基础上，加入数据表细粒度信息，将成本结构细化为成本cost值。
相对于数据表的ddl结构，统计量反映了当下数据表数据分布情况，可变性更强。我们经常遇到这样的场景，数据导入操作之后，原有一个运行良好的作业突然效率低下。当我们手工收集一下统计量之后，作业效率提升。这种现象也就是反映了统计量和执行计划的关系。
sga中的shared pool是进行执行计划缓存的位置。shared cursor是sql语句共享的主要对象。一句sql语句，如果在shared pool中有缓存的执行计划。这个时候，有新的统计量收集动作，有新统计量收集到数据字典中，进而以为了新的执行计划需求。那么，oracle是如何进行抉择呢？
答案就是dbms_stats的no_invalidate参数。通过不同的参数配置，可以实现对oracle失效共享游标行为的控制。
--------------------------------------分割线 --------------------------------------
oracle 11g 数据统计量pending处理
--------------------------------------分割线 --------------------------------------
1、no_invalidate参数
no_invalidate参数从字面上比较纠结。no和in都是否定含义，“负负得正”。参数含义就是validate，也就是是否有效。它决定了新统计量生成之后，如何处理此时已经生成的执行计划，也就是在shared pool中的执行计划。
统计量决定sql执行计划，是cbo的一个特征。但是这个过程是针对新生成的执行计划，也就是新的parse过程。对于已经生成的执行计划，oracle是通过no_invalidate参数来处理shared cursor的失效过程。
一个对象（数据表、索引）新统计量生成之后，最简单的方法是一次性将在shared pool中有依赖关系的shared cursor失效。下一次再进行sql执行的时候，必然会用新的执行计划parse解析过程。另一个极端是无视新统计量的差异，维持现有的shared cursor，不会去让其失效。
从性能角度看，两个极端都是有其问题的。如果是一次性将其全部失效，会引起后续作业过程的“解析峰值”。因为，如果系统负载比较高，突然间缓存的执行计划全部被失效，oracle作业必然要进行一些额外的成本进行执行计划重新生成。这个会体现在系统运行有一个峰值。
如果不将共享游标失效，那么新的统计量不会很快体现在更好执行计划生成的过程。性能提升无从谈起。
所以，是否将游标失效，是一个“左右为难”的问题。
在oracle中，no_invalidate参数包括三个取值。
sql> select * from v$version;
banner
--------------------------------------------------------------------------------
oracle database 11g enterprise edition release 11.2.0.1.0 - production
pl/sql release 11.2.0.1.0 - production
core 11.2.0.1.0 production
tns for linux: version 11.2.0.1.0 - production
nlsrtl version 11.2.0.1.0 - production
-- no_invalidate - do not invalide the dependent cursors if set to true.
-- the procedure invalidates the dependent cursors immediately
-- if set to false.
-- use dbms_stats.auto_invalidate to have oracle decide when to
-- invalidate dependend cursors. this is the default. the default
-- can be changed using set_param procedure.
-- when the 'cascade' argument is specified, not pertinent with certain
-- types of indexes described in the gather_index_stats section.
oracle支持true、false和dbms_stats.auto_invalidate取值。如果取值为true，表示不进行游标失效动作，原有的shared cursor保持原有状态。如果取值为false，表示将统计量对象相关的所有cursor全部失效。如果设置为auto_invalidate，根据官方文档，oracle自己决定shared cursor失效动作。
从10g开始，oracle就将auto_invalidate作为默认的统计量收集行为。
sql> select dbms_stats.get_param(pname => 'no_invalidate') from dual;
dbms_stats.get_param(pname=>'n
--------------------------------------------------------------------------------
dbms_stats.auto_invalidate
下面，笔者将通过一系列的实验，来证明no_invalidate参数取值的效果。
2、no_invalidate取值为yes
取值为yes，表示不经心共享游标失效动作，即使这个过程中，共享的游标已经不是最优的执行计划。
我们创建实验数据表。
sql> create table t as select * from dba_objects;
table created
sql> create index idx_t_id on t(object_id);
index created
--第一次统计量收集
sql> exec dbms_stats.gather_table_stats(user,'t',cascade => true);
pl/sql procedure successfully completed
目标sql语句，注意：出于篇幅原因，笔者将结果屏蔽。
sql> select /*+demo*/object_id, owner from t where object_id=1000;
统计信息
----------------------------------
164 recursive calls
0 db block gets
23 consistent gets
0 physical reads
(有省略……)
1 rows processed
此时shared pool中情况如下，出现第一个执行计划缓存对象。
sql> select sql_id, executions, version_count from v$sqlarea where sql_text like 'select /*+demo*/%';
sql_id executions version_count
------------- ---------- -------------
cnb0ktgvms6vq 1 1
sql> select * from table(dbms_xplan.display_cursor(sql_id=>'cnb0ktgvms6vq'));
plan_table_output
--------------------------------------------------------------------------------
sql_id cnb0ktgvms6vq, child number 0
-------------------------------------
select /*+demo*/object_id, owner from t where object_id=1000
plan hash value: 514881935