收集统计信息中的no_invalidate选项对执行计划的影响

郑全

在分析表的是否有一个参数no_invalidate：缺省值是DBMS_STATS.AUTO_INVALIDATE.

        10g中默认是AUTO_INVALIDATE，就是说分析表后，游标不会马上invalidate，已经存在的SQL的执行计划不会受新的统计信息影响。可以手工DDL
invalidate游标。又或者等待隐藏参数_optimizer_invalidation_period(time window for invalidation of cursors of analyzed objects)秒后,
Oracle自动invalidate游标并使SQL能够读取新的统计信息产生新的执行计划。

        如果想要dbms_stats分析立马见效,需要使用no_invalidate=false option或者DBA自己手工invalidate游标。

--说明一下，我个人感觉这个参数理解起来很烦，validate表示有效，no_invalidate反了2次,也是表示有效的意思。

dbms_stats收集统计信息时候no_invalidate参数
用于是否与收集相关object的cursor失效，defalut(9i false, 10g dbms_stats.auto_invalidate(既null))
true：当收集完统计信息后，收集对象的cursor不会失效（不会产生新的执行计划，子游标）
false:当收集完统计信息后，收集对象的cursor会立即失效（新的执行计划，新的子游标）
no_invalidate=>DBMS_STATS.AUTO_INVALIDATE，分析表后，游标不会马上invalidate，已经存在的SQL的执行计划不会受新的统计信息影响。可以手工
DDL invalidate游标。又或者等待隐藏参数_optimizer_invalidation_period(time window for invalidation of cursors of analyzed objects)秒后,
Oracle自动invalidate游标并使SQL能够读取新的统计信息产生新的执行计划。

缺省隐藏参数_optimizer_invalidation_period设置的时间太长=18000。

再建立一个例子来说明问题：
1.建立测试环境:

SQL> select * from v$version ;
BANNER--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - ProductionCORE    11.2.0.1.0      Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

create table t as select rownum id ,'test' name from dual connect by level <=10000;
create index i_t_id on t(id);

SQL> select dbms_stats.get_param('no_invalidate') from dual;

DBMS_STATS.GET_PARAM('NO_INVALIDATE')
-------------------------------------------------------------
DBMS_STATS.AUTO_INVALIDATE
--可以发现缺省no_invalidate=DBMS_STATS.AUTO_INVALIDATE.
--如果查看dbms_stats文档，可以发现实际上就是等于NULL。
-- oracle decides when to invalidate dependend cursors
AUTO_INVALIDATE CONSTANT BOOLEAN := null;


SQL> exec dbms_stats.gather_table_stats(user,'t',cascade=>true,method_opt=>'for all columns size 254',no_invalidate=>DBMS_STATS.AUTO_INVALIDATE);

PL/SQL procedure successfully completed.
--分析表T，并且在表T上建立直方图。


SQL> select column_name,data_type,histogram from dba_tab_cols where wner=user and table_name='T';
COLUMN_NAME  DATA_TYPE  HISTOGRAM
------------           ----------       ---------------
ID                     NUMBER       HEIGHT BALANCED
NAME                CHAR            FREQUENCY


2.测试：

SQL> select * from t where id=10001;
no rows selected

SQL> @dpc
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------
SQL_ID  0yzrd8s6vbfcc, child number 0
-------------------------------------
select * from t where id=10001
Plan hash value: 4153437776
--------------------------------------------------------------------
| Id  | Operation                   | Name   | E-Rows | Cost (%CPU)|
--------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |        |     2 (100)||   1
|  TABLE ACCESS BY INDEX ROWID| T      |      1 |     2   (0)|
|*  2 |   INDEX RANGE SCAN          | I_T_ID |      1 |     1   (0)|
--------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------   
2 - access("ID"=10001)

--测试发现可以选择索引。

但是如果我改变id的分布，加入大量id=10001,在分析后是什么情况呢?


SQL> insert into t  select 10001 id ,'book' name from dual connect by level<=10000;
10000 rows created.
SQL> commit ;
Commit complete.

3.分析表后在测试：

SQL> exec dbms_stats.gather_table_stats(user,'t',cascade=>true,method_opt=>'for all columns size 254',no_invalidate=>DBMS_STATS.AUTO_INVALIDATE);
PL/SQL procedure successfully completed.
--正常按照许多人的理解如果查询：
select * from t where id=10001;
应该不会使用索引，实际情况呢？


select * from t where id=10001;
SQL> @dpc
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------
SQL_ID  0yzrd8s6vbfcc, child number 0
-------------------------------------
select * from t where id=10001
Plan hash value: 4153437776
--------------------------------------------------------------------
| Id  | Operation                   | Name   | E-Rows | Cost (%CPU)|
--------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |        |     2 (100)||   1
|  TABLE ACCESS BY INDEX ROWID| T      |      1 |     2   (0)|
|*  2 |   INDEX RANGE SCAN          | I_T_ID |      1 |     1   (0)|
--------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------   
2 - access("ID"=10001)
--可以发现执行计划并没有因为我们分析表而改变执行计划。

修改语句，select换成大写，再测试可以很好的说明问题：

SQL> @dpc
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------
SQL_ID  0sf1updb7x3xf, child number 0
-------------------------------------
SELECT * from t where id=10001
Plan hash value: 1601196873
--------------------------------------------------------
| Id  | Operation         | Name | E-Rows | Cost (%CPU)|
--------------------------------------------------------
|   0 | SELECT STATEMENT  |      |        |    14 (100)|
|*  1 |  TABLE ACCESS FULL| T    |  10039 |    14   (0)|
--------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------   
1 - filter("ID"=10001)

--可以发现执行计划选择全表扫描。

4.而隐藏参数_optimizer_invalidation_period缺省测试＝18000.

$ P _optimizer_invalidation_period
NAME                                 DESCRIPTION                                                                  DEFAULT_VA SESSION_VALUE        SYSTEM_VALUE
------------------------------------ ---------------------------------------------------------------------------- ---------- -------------------- --------------------
_optimizer_invalidation_period       time window for invalidation of cursors of analyzed objects                  TRUE       18000                18000

我在.bashrc中定义了一个shell函数P。
P()
{
echo '  '
if [ -z "$1" ];
  then sqlplus -S "/ as sysdba" <<EOF
set echo off lin 9999 trimsp on feedb off head on pages 0 newp 0 tab off
col name for a36
col description format a76
col default_value format a10
col session_value format a20
col system_value format a20

select a.ksppinm name, a.ksppdesc DESCRIPTION, b.ksppstdf DEFAULT_VALUE, b.ksppstvl SESSION_VALUE, c.ksppstvl SYSTEM_VALUE
from sys.x\$ksppi a, sys.x\$ksppcv b, sys.x\$ksppsv c
EOF

else
   sqlplus -S "/ as sysdba" <<EOF  | grep -i $1 -B 2 -A 2
set echo off lin 9999 trimsp on feedb off head on pages 0 newp 0 tab off
col name for a36
col description format a76
col default_value format a10
col session_value format a20
col system_value format a20
select a.ksppinm name, a.ksppdesc DESCRIPTION, b.ksppstdf DEFAULT_VALUE, b.ksppstvl SESSION_VALUE, c.ksppstvl SYSTEM_VALUE
from sys.x\$ksppi a, sys.x\$ksppcv b, sys.x\$ksppsv c
EOF
fi
echo '  '}

18000/3600=5 ,要5个小时后，select * from t where id=10001;执行计划才会变成full 扫描，显然测试不能等这么长时间。


SQL> select sql_id,child_number,executions,parse_calls,loads,invalidations from v$sql
where sql_id ='0yzrd8s6vbfcc';

SQL_ID        CHILD_NUMBER EXECUTIONS PARSE_CALLS      LOADS INVALIDATIONS
------------- ------------ ---------- ----------- ---------- -------------
0yzrd8s6vbfcc            0          2           2          1             0
SQL> alter system set "_optimizer_invalidation_period" = 10 scope=memory;
System altered.
--等待10秒............
SQL> @dpc
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------
SQL_ID  0yzrd8s6vbfcc, child number 1
-------------------------------------
select * from t where id=10001
Plan hash value: 1601196873
--------------------------------------------------------
| Id  | Operation         | Name | E-Rows | Cost (%CPU)|
--------------------------------------------------------
|   0 | SELECT STATEMENT  |      |        |    14 (100)|
|*  1 |  TABLE ACCESS FULL| T    |  10039 |    14   (0)|
--------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------   
1 - filter("ID"=10001)

--可以发现执行计划变成了全表扫描。


SQL> select sql_id,child_number,executions,parse_calls,loads,invalidations from v$sql where sql_id ='0yzrd8s6vbfcc';
SQL_ID        CHILD_NUMBER EXECUTIONS PARSE_CALLS      LOADS INVALIDATIONS
------------- ------------ ---------- ----------- ---------- -------------
0yzrd8s6vbfcc            0          2           2          1             0
0yzrd8s6vbfcc            1          1           1          1             0
--可以发现执行计划生成了新的子光标。


总结：
    oracle系统缺省存在自动分析一般在晚上10点分析，而no_invalidate的缺省值正好是DBMS_STATS.AUTO_INVALIDATE.这样缺省分析
DBMS_STATS.AUTO_INVALIDATE，如果处理不好，一些性能问题会延迟出现，在优化SQL应该引起注意。