ITPub博客

首页 > Linux操作系统 > Linux操作系统 > [20120829]分析表与no_invalidate=AUTO_INVALIDATE.txt

[20120829]分析表与no_invalidate=AUTO_INVALIDATE.txt

Linux操作系统 作者:rovige 时间:2015-07-09 16:56:06 0 删除 编辑
[20120829]分析表与no_invalidate=AUTO_INVALIDATE.txt

以前写过一篇blog。

在分析表的是否有一个参数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 - 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

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" <
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" <
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应该引起注意。



来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/18900329/viewspace-1727856/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2015-07-09

  • 博文量
    21
  • 访问量
    67927