Oracle 统计量NO_INVALIDATE参数配置（上）

转载：http://blog.itpub.net/17203031/viewspace-1067312/

Oracle统计量对于CBO执行是至关重要的。RBO是建立在数据结构的基础上的，DDL结构、约束会将SQL语句分为不同的成本结构等级。而CBO是在数据结构的基础上，加入数据表细粒度信息，将成本结构细化为成本cost值。

相对于数据表的DDL结构，统计量反映了当下数据表数据分布情况，可变性更强。我们经常遇到这样的场景，数据导入操作之后，原有一个运行良好的作业突然效率低下。当我们手工收集一下统计量之后，作业效率提升。这种现象也就是反映了统计量和执行计划的关系。

SGA中的shared pool是进行执行计划缓存的位置。Shared Cursor是SQL语句共享的主要对象。一句SQL语句，如果在Shared Pool中有缓存的执行计划。这个时候，有新的统计量收集动作，有新统计量收集到数据字典中，进而以为了新的执行计划需求。那么，Oracle是如何进行抉择呢？

答案就是dbms_stats的no_invalidate参数。通过不同的参数配置，可以实现对Oracle失效共享游标行为的控制。

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

--------------------------------------------------------------------------------

| Id  | Operation                   | Name     | Rows  | Bytes | Cost (%CPU)| Ti

--------------------------------------------------------------------------------

|   0 | SELECT STATEMENT            |          |       |       |     2 (100)|

|   1 |  TABLE ACCESS BY INDEX ROWID| T        |     1 |    11 |     2   (0)| 00

|*  2 |   INDEX RANGE SCAN          | IDX_T_ID |     1 |       |     1   (0)| 00

--------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("OBJECT_ID"=1000)

19 rows selected

此时，最优的执行计划是索引路径。在shared pool中有一个父游标和子游标（version count=1），执行次数为1。

第二次执行之后，Shared Pool中有共享现象。相同的共享游标执行两次。

SQL> select sql_id, executions, version_count from v$sqlarea where sql_text like ‘select /*+demo*/%‘;

SQL_ID        EXECUTIONS VERSION_COUNT

------------- ---------- -------------

cnb0ktgvms6vq          2             1

之后，我们更新数据，修改数据分布结构。

SQL> update t set object_id=1000;

72729 rows updated

SQL> commit;

Commit complete

此时，如果执行SQL语句，我们发现依然是使用原有的索引路径。此时全部T表中object_id都是1000，走索引不是好的选择。

SQL> select /*+demo*/object_id, owner from t where object_id=1000;

已选择72729行。

统计信息

------------------------------------------

0  recursive calls

0  db block gets

11157  consistent gets

0  physical reads

72729  rows processed

SQL> select sql_id, executions, version_count from v$sqlarea where sql_text like ‘select /*+demo*/%‘;

SQL_ID        EXECUTIONS VERSION_COUNT

------------- ---------- -------------

cnb0ktgvms6vq          3             1

此时的路径依然是Index Range Scan。这个明显是由于统计量的过时，外加游标共享，引起的错误路径。下面我们重新收集一下统计量，采用no_invaliate为true的情况。

SQL> exec dbms_stats.flush_database_monitoring_info;

PL/SQL procedure successfully completed

SQL> exec dbms_stats.gather_table_stats(user,‘T‘,cascade => true,no_invalidate => true,method_opt => ‘for columns size 10 object_id‘);

PL/SQL procedure successfully completed

新统计量生成，我们使用explain plan查看一下，此时SQL应该采用的执行计划是什么？

SQL> explain plan for select /*+demo*/object_id, owner from t where object_id=1000;

Explained

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT

--------------------------------------------------------

Plan hash value: 1601196873

---------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 72722 |   639K|   266   (1)| 00:00:04 |

|*  1 |  TABLE ACCESS FULL| T    | 72722 |   639K|   266   (1)| 00:00:04 |

--------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("OBJECT_ID"=1000)

13 rows selected

此时，FTS全表扫描是更好的选择。但是我们查看一下实际执行时候，路径情况。

SQL> select /*+demo*/object_id, owner from t where object_id=1000;

已选择72729行。

统计信息

----------------------------------------------------------

0  recursive calls

0  db block gets

10907  consistent gets

0  physical reads

0  redo size

72729  rows processed

SQL> select sql_id, executions, version_count from v$sqlarea where sql_text like ‘select /*+demo*/%‘;

SQL_ID        EXECUTIONS VERSION_COUNT

------------- ---------- -------------

cnb0ktgvms6vq          4             1

此时，Oracle依然选择了原来的Index路径，原有的shared cursor没有失效！！如果我们此时将shared pool清空，新的FTS执行计划也就生成。

SQL> alter system flush shared_pool;

System altered

SQL> select sql_id, executions, version_count from v$sqlarea where sql_text like ‘select /*+demo*/%‘;

SQL_ID        EXECUTIONS VERSION_COUNT

------------- ---------- -------------

SQL> select /*+demo*/object_id, owner from t where object_id=1000;

已选择72729行。

统计信息

----------------------------------------------------------

243  recursive calls

0  db block gets

5855  consistent gets

0  physical reads

72729  rows processed

--新的shared cursor形成

SQL> select sql_id, executions, version_count from v$sqlarea where sql_text like ‘select /*+demo*/%‘;

SQL_ID        EXECUTIONS VERSION_COUNT

------------- ---------- -------------

cnb0ktgvms6vq          1             1

--FTS执行计划

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: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      |       |       |   266 (100)|          |

|*  1 |  TABLE ACCESS FULL| T    | 72722 |   639K|   266   (1)| 00:00:04 |

--------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("OBJECT_ID"=1000)

18 rows selected

结论：当我们使用no_invalidate为true的时候，原有的shared cursor不会被失效，可以支持共享。只有当被age out或者flush out出shared pool之后，新执行计划才能生成。

3、no_invalidate=false

下面我们看看取值为false的情况，实验场景相同。为避免影响，我们重新构建数据表。

SQL> drop table t purge;

Table dropped

SQL> alter system flush shared_pool;

System altered

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语句，形成Index路径执行计划。

SQL> select /*+demo*/object_id, owner from t where object_id=1000;

统计信息

----------------------------------------------------------

164  recursive calls

0  db block gets

23  consistent gets

1  rows processed

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

--------------------------------------------------------------------------------

| Id  | Operation                   | Name     | Rows  | Bytes | Cost (%CPU)| Ti

--------------------------------------------------------------------------------

|   0 | SELECT STATEMENT            |          |       |       |     2 (100)|

|   1 |  TABLE ACCESS BY INDEX ROWID| T        |     1 |    11 |     2   (0)| 00

|*  2 |   INDEX RANGE SCAN          | IDX_T_ID |     1 |       |     1   (0)| 00

--------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("OBJECT_ID"=1000)

19 rows selected

第二次执行相同SQL，我们可以看到生成的shared cursor进行共享。

SQL> select sql_id, executions, version_count, first_load_time from v$sqlarea where sql_text like ‘select /*+demo*/%‘;

SQL_ID        EXECUTIONS VERSION_COUNT FIRST_LOAD_TIME

------------- ---------- ------------- ----------------------------------------------------------------------------

cnb0ktgvms6vq          2             1 2014-01-06/00:04:29

修改数据object_id取值，改变数据分布。

SQL>  update t set object_id=1000;

72729 rows updated

SQL> commit;

Commit complete

第三次执行。

SQL> select /*+demo*/object_id, owner from t where object_id=1000;

已选择72729行。

统计信息

--------------------------------------

0  recursive calls

0  db block gets

11157  consistent gets

72729  rows processed

此时shared cursor状态如下：

SQL> select sql_id, executions, version_count, first_load_time from v$sqlarea where sql_text like ‘select /*+demo*/%‘;

SQL_ID        EXECUTIONS VERSION_COUNT FIRST_LOAD_TIME

------------- ---------- ------------- ----------------------------------------------------------------------------

cnb0ktgvms6vq          3             1 2014-01-06/00:04:29

执行计划是进行Index Range Scan动作。

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

--------------------------------------------------------------------------------

| Id  | Operation                   | Name     | Rows  | Bytes | Cost (%CPU)| Ti

--------------------------------------------------------------------------------

|   0 | SELECT STATEMENT            |          |       |       |     2 (100)|

|   1 |  TABLE ACCESS BY INDEX ROWID| T        |     1 |    11 |     2   (0)| 00

|*  2 |   INDEX RANGE SCAN          | IDX_T_ID |     1 |       |     1   (0)| 00

--------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("OBJECT_ID"=1000)

19 rows selected

收集统计量，使用no_invalidate为false取值。

SQL> exec dbms_stats.flush_database_monitoring_info;

PL/SQL procedure successfully completed

SQL> exec dbms_stats.gather_table_stats(user,‘T‘,cascade => true,no_invalidate => false,method_opt => ‘for columns size 10 object_id‘);

PL/SQL procedure successfully completed

第四次执行过程。

SQL> select /*+demo*/object_id, owner from t where object_id=1000;

已选择72729行。

统计信息

----------------------------

141  recursive calls

0  db block gets

5835  consistent gets

72729  rows processed

SQL> select sql_id, executions, version_count, first_load_time from v$sqlarea where sql_text like ‘select /*+demo*/%‘;

SQL_ID        EXECUTIONS VERSION_COUNT FIRST_LOAD_TIME

------------- ---------- ------------- -------------------

cnb0ktgvms6vq          1             1 2014-01-06/00:04:29

注意：在相同的sql_id情况下，version_count和executions都为1。Executions是不可能减少的。所以，这个父游标是新生成的！

此时，执行计划如下：

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: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      |       |       |   266 (100)|          |

|*  1 |  TABLE ACCESS FULL| T    | 72722 |   639K|   266   (1)| 00:00:04 |

--------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("OBJECT_ID"=1000)

18 rows selected

这也就是说明了，新的执行计划已经生成了！也就是原有的游标被废弃。

结论：当我们收集统计量使用no_invalidate为false的时候，原有的共享游标被失效，下一次在执行SQL的时候，Oracle会重新为其生成执行计划，也就是一次hard parse过程。

True和false取值是比较简单的。我们接下来讨论dbms_stats.auto_invalidate取值情况。

时间： 2024-10-13 07:27:27

Oracle 统计量NO_INVALIDATE参数配置（上）的相关文章

Oracle 统计量NO_INVALIDATE参数配置（下）

转载:http://blog.itpub.net/17203031/viewspace-1067620/ 本篇我们继续讨论NO_INVALIDATE参数. 从上篇(http://blog.itpub.net/17203031/viewspace-1067312/)讨论情况看,无论是取值true还是false,Oracle进行的行为都是缺乏考量的.如果选择true,表示旧的执行计划会持续的在shared pool中驻留,新的执行计划不会生成,如果系统SQL运行比较频繁.Age Out现象比较少,更

静默安装oracle 11g及参数配置优化详解

一.安装前准备工作1.修改主机名#vi /etc/hosts   //并添加内网IP地址对应的hostname,如下127.0.0.1           localhost::1                   localhost localhost.localdomain localhost6 localhost6.localdomain6192.168.8.151          linux-test 2.修改standby数据库的/etc/sysconfig/iptables文件,

阿里云上Oracle 11g RAC安装配置手册

有印象的用户可能发现,阿里云早在2016年深圳云栖大会就官方发布了对Oracle RAC的支持,但是相关产品却一直没能同步推出,相信大家都翘首以盼了许久许久.一个好消息是,近期阿里云将紧密推出两款新产品:共享块存储和ECS多网卡.这两款产品将打通众多关键云下应用上云的最后一公里,为用户提供更多的便利.在我们能正式体验到新产品之前,阿里云技术服务团队也将云上的Oracle RAC安装配置手册放出,希望能给大家提供更多不同的体验和选择. 一.安装说明 阿里云上Oracle RAC的安装部署,重点需要

Oracle Study之案例--安装Oracle内核参数配置

Oracle Study之案例--安装Oracle内核参数配置 在Linux系统下,安装Oracle之前,除了检查操作系统的硬件和软件是否满足安装需要之外,一个重点就是修改内核参数,其中最主要的是和内存相关的参数设置. 案例分析: 查看当前系统的内核参数配置: [[email protected] ~]# sysctl -p net.ipv4.ip_forward = 0 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.acce

线上机器JVM参数配置

记录一下线上机器的JVM参数配置: CATALINA_OPTS="$CATALINA_OPTS -server -Djava.awt.headless=true -Xms2560m [JVM初始分配的堆内存 2.5G]-Xmx2560m [JVM最大可用堆内存 2.5G]-Xss256k [每个线程的堆栈大小]-XX:PermSize=128m [永久代大小]-XX:MaxPermSize=384m [永久代最大值]-XX:NewSize=1024m [新生代初始内存大小]-XX:MaxNewS

Oracle 学习之RMAN（七）参数配置

配置RMAN备份环境 对于大多数备份操作而言,RMAN为持久化的参数配置提供了合理的默认值,使您能够执行基本的备份和恢复.但是如果你了解更多的配置,你可以更有效的使用RMAN实现基于RMAN的备份策略. 使用SHOW ALL命令查看RMAN的配置 RMAN> show all; RMAN configuration parameters for database with db_unique_name DEVDB are: CONFIGURE RETENTION POLICY TO REDUND

springmvc笔记(基本配置,核心文件,路径,参数,文件上传,json整合)

首先导入jar包 大家注意一下我的springmvc,jackson,common-up的jar包版本.其他版本有可能出现不兼容. src文件: webroot目录: web.xml 1 <?xml version="1.0" encoding="UTF-8"?> 2 <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http:/

oracle rac 监听配置

一.总体概述 Oracle RAC 监听器的配置与单实例稍有不同,但原理和实现方法基本上是相同的.在Oracle服务端中 tns进程用于为指定网络地址上的一个或多个Oracle 实例提供服务注册,并响应来自客户端对该服务提出的连接请求.一旦连接请求到达,并派生出一个服务器进程建立服务器与用户端之间的连接(专有服务器dedicated server)或转发服务请求(共享服务器模式shared server).如果监听器知道多于一个实例提供所请求的服务,则可能会根据客户端与服务器端相关配置将请求定位

Oracle数据库GLOBAL_NAMES参数的详细研究 (创建DBLINK时有用)

Oracle数据库GLOBAL_NAMES参数的相关知识是本文我们主要要介绍的内容,当GLOBAL_NAMES参数设置为TRUE时,使用DATABASE LINK时,DATABASE LINK的名称必须与被连接库的GLOBAL_NAME一致.下面做一个测试,在测试中,创建数据库链接的库为XJ(WINDOWS 2003 ORACLE 10g 10.2.0.1),被链接的库为DMDB(LINUX AS5 ORACLE 10g 10.2.0.1 RAC). 首先查看DMDB的相关配置: 以下是代码片段