【Oracle 优化器】自适应游标共享(Adaptive Cursor Sharing)功能

概述

我们知道，由于绑定变量窥视(Bind Peeking)功能，SQL文在进行硬解析（Hard Parse）时，会代入绑定变量的值来估算选择基数（cardinality ）并做成执行计划，而相同的SQL文以后在执行过程中，都会共享初次执行时做成的执行计划。

如果表的数据分布不均或者数据倾斜时，用于估算的变量值和以后执行中的用到的变量值估算选择基数（cardinality ）差异很大时，通过绑定变量窥视(Bind Peeking)功能做成的执行计划，针对某些变量值的执行可能都是最优的，甚至可能引起很严重的性能问题。

因此，优化器在11.1以后的版本上，为了解决绑定变量窥视(Bind Peeking)的问题，推出了自适应游标共享(Adaptive Cursor Sharing 以后简称ACS）功能，使包含绑定变量的同一条SQL语句在多次执行时，不会盲目的共享执行计划，而会根据绑定变量值和执行过程中收集信息的反馈，可以使用多个不同执行计划，避免性能问题。

下面我们将通过几个例子来进一步了解ACS功能。

例子1（ACS无效）

首先，我们看一下在绑定变量窥视(Bind Peeking)功能有效，但是自适应游标共享功能无效的情况下，执行以下SQL文的动作。（基于10.2.0.5版本测试）

0.准备测试用表和数据

SQL> conn scott/tiger
Connected.
SQL> create table TEST_ACS(c1 number, c2 varchar2(100));

Table created.

SQL> BEGIN
FOR i IN 1 .. 1000 LOOP
FOR j IN 1 .. 10 LOOP
INSERT INTO TEST_ACS
VALUES     (i,'a');
COMMIT;
END LOOP;
END LOOP;
END;
/  2    3    4    5    6    7    8    9   10

PL/SQL procedure successfully completed.

SQL> create index ind1 on TEST_ACS(c1);

Index created.

SQL> exec dbms_stats.gather_table_stats(ownname => 'SCOTT',tabname => 'TEST_ACS',CASCADE => TRUE);

PL/SQL procedure successfully completed.

---我们准备了一个表包含10000条数据，c1列有1~1000的值，并且每个值都有10条数据。
---并且在c1列有个索引ind1

SQL> SELECT count(c1), count(DISTINCT c1), min(c1), max(c1) FROM TEST_ACS;

COUNT(C1) COUNT(DISTINCTC1)    MIN(C1)    MAX(C1)
---------- ----------------- ---------- ----------
10000              1000          1       1000

1.首先我们指定变量值为3，执行下面的SQL文

SQL> var x number;
SQL> exec :x := 3 ;

PL/SQL procedure successfully completed.

SQL> SELECT * FROM TEST_ACS WHERE c1 <= :x;

C1 C2
------ --------------------
1 a
...
3 a

30 rows selected.

SQL>

2.因为绑定变量窥视(Bind Peeking)功能的影响，所以硬解析选择执行计划时，

会把绑定变量值3代入到SQL文中计算基数，SQL文在10000条数据中选择了30条数据，

所以，选择了索引IND1进行INDEX RANGE SCAN。

SQL> set line 200
SQL> set pagesize 9999
SQL> select * from table(dbms_xplan.display_cursor(null,null,'NOTE ALLSTATS LAST'));

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------
SQL_ID  cuf4u4th4w0nz, child number 0
-------------------------------------
SELECT * FROM TEST_ACS WHERE c1 <= :x

Plan hash value: 3882350253

---------------------------------------------------------
| Id  | Operation                   | Name     | E-Rows |
---------------------------------------------------------
|   0 | SELECT STATEMENT            |          |        |
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST_ACS |     30 |
|*  2 |   INDEX RANGE SCAN          | IND1     |     30 |
---------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("C1"<=:X)
...

25 rows selected.

3.我们再指定变量值为9，再次执行下面的SQL文。

虽然这时候SQL文在10000条数据中选择了9000条数据，选择率高达90%,但是因为SQL文已经解析过了，所以会继续用之前的执行计划，E-Rows还是30，使用用INDEX RANGE SCAN.

SQL> exec :x := 9 ;

PL/SQL procedure successfully completed.

SQL> SELECT * FROM TEST_ACS WHERE c1 <= :x;

C1 C2
------ --------------------
1 a
...
900 a

9000 rows selected.

SQL>
SQL> set line 200
SQL> set pagesize 9999
SQL> select * from table(dbms_xplan.display_cursor(null,null,'NOTE ALLSTATS LAST'));

PLAN_
4000
TABLE_OUTPUT
----------------------------------------------------------------------------------
SQL_ID  cuf4u4th4w0nz, child number 0
-------------------------------------
SELECT * FROM TEST_ACS WHERE c1 <= :x

Plan hash value: 3882350253

---------------------------------------------------------
| Id  | Operation                   | Name     | E-Rows |
---------------------------------------------------------
|   0 | SELECT STATEMENT            |          |        |
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST_ACS |     30 |
|*  2 |   INDEX RANGE SCAN          | IND1     |     30 |
---------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("C1"<=:X)
....

25 rows selected.

SQL>
SQL> select child_number, executions, buffer_gets,plan_hash_value
from v$sql
where sql_id = 'cuf4u4th4w0nz';  2    3

CHILD_NUMBER EXECUTIONS BUFFER_GETS PLAN_HASH_VALUE
------------ ---------- ----------- ---------------
0          2        1239      3882350253

4.我们再次指定变量值为9，执行下面的SQL文。

这时候SQL文还是在10000条数据中选择了9000条数据，但是因为SQL文已经解析过了，所以会继续用之前的执行计划，使用用INDEX RANGE SCAN

SQL> exec :x := 900 ;

PL/SQL procedure successfully completed.

SQL> SELECT * FROM TEST_ACS WHERE c1 <= :x;

C1 C2
------ --------------------
1 a

...
900 a

9000 rows selected.

SQL>

5.无论以后指定变量值是什么，执行计划都会用最初做成的执行计划。

这样通过绑定变量窥视(Bind Peeking)功能做成的执行计划，针对某些变量值的执行可能不是最优的，甚至可能引起很严重的性能问题。

SQL> exec :x := 800 ;

PL/SQL procedure successfully completed.

SQL> SELECT * FROM TEST_ACS WHERE c1 <= :x;

C1 C2
------ --------------------
1 a
...
SQL> select * from table(dbms_xplan.display_cursor(null,null,'NOTE ALLSTATS LAST'));

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------
SQL_ID  cuf4u4th4w0nz, child number 0
-------------------------------------
SELECT * FROM TEST_ACS WHERE c1 <= :x

Plan hash value: 3882350253

---------------------------------------------------------
| Id  | Operation                   | Name     | E-Rows |
---------------------------------------------------------
|   0 | SELECT STATEMENT            |          |        |
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST_ACS |     30 |
|*  2 |   INDEX RANGE SCAN          | IND1     |     30 |
---------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("C1"<=:X)

...

25 rows selected.

通过上面的例子，我们看到由于绑定变量窥视(Bind Peeking)的影响，对于变量值为9时，虽让本应该选择Table Full Scan才是最优的执行计划，还是使用了初次执行时根据变量值为3时做成的执行计划。

因此，如果最初用于估算的变量值不能代表大多数变量值时的特点时，对于生产系统，有时候可能是灾难性的。

例子2（ACS有效）

下面让我们看看，在11g后的版本上自适应游标共享(Adaptive Cursor Sharing 以后简称ACS)功能有效时，是如何改善这种这个问题。

ACS相关的动态视图

在以后执行过程中，我们可以通过观察相关的动态视图，来看看在这个过程中都发生了什么。

首先，我们介绍下在以后过程中用到的主要4个视图，下面是相关内容的简单介绍。

V$SQL视图
在这个视图中主要有3个和ACS相关的列：
is_bind_sensitive:用于监视SQL游标是否是绑定敏感(bind sensitive)，是否可用ACS。
is_bind_aware：用于监视SQL游标是否意识到需要根据绑定变量值来选择执行计划（bind aware）。
is_shareable：用于监视SQL游标是否可以被共享。

V$SQL_SHARED_CURSOR
用于查看SQL游标没有共享的原因。

V$SQL_CS_SELECTIVITY视图
主要用来监视SQL游标的各个变量的选择率范围（SELECTIVITY CUBE）。
它包含着各个条件谓词、绑定变量值以及它的最大值和最小值等信息。

V$SQL_CS_HISTOGRAM
根据所操作的行数，记录每个子游标执行的次数直方图。

V$SQL_CS_STATISTICS
每个子游标执行的执行状况。（采样信息）

关于以上视图的定义和内容详细可以参考在线文档。

Oracle Database Online Documentation 11g Release 2 (11.2) / Database Reference

V$SQL

V$SQL_SHARED_CURSOR

V$SQL_CS_SELECTIVITY

V$SQL_CS_HISTOGRAM

V$SQL_CS_STATISTICS

下面开始我们的测试 （基于11.2.0.4版本测试）：

准备测试用表和数据

0.准备测试用表和数据

SQL>
SQL> conn scott/tiger
Connected.
SQL>
SQL> drop table TEST_ACS;
Table dropped.
SQL> create table TEST_ACS(c1 number, c2 varchar2(100));
Table created.
SQL>
SQL> BEGIN
2      FOR i IN 1 .. 1000 LOOP
3      FOR j IN 1 .. 10 LOOP
4          INSERT INTO TEST_ACS
5          VALUES (i,'a');
6          COMMIT;
7      END LOOP;
8      END LOOP;
9  END;
10  /
PL/SQL procedure successfully completed.
SQL>
SQL> create index ind1 on TEST_ACS(c1);
Index created.
SQL> exec dbms_stats.gather_table_stats(ownname => 'SCOTT',tabname => 'TEST_ACS',CASCADE => TRUE);
PL/SQL procedure successfully completed.

---我们准备了一个表包含10000条数据，c1列有1~1000的值，并且每个值都有10条数据。
---并且在c1列有个索引ind1
SQL> SELECT count(c1), count(DISTINCT c1), min(c1), max(c1) FROM TEST_ACS;
COUNT(C1) COUNT(DISTINCTC1)MIN(C1)MAX(C1)
---------- ----------------- ---------- ----------
10000  1000  1   1000

Test1：指定变量值为3，首次执行

首先我们指定变量值为3，首次执行下面的SQL文

SQL> var x number;
SQL> exec :x := 3 ;

PL/SQL procedure successfully completed.

SQL> SELECT * FROM TEST_ACS WHERE c1 <= :x;

C1 C2
------ --------------------
1 a
...
3 a

30 rows selected.

SQL>

1.因为绑定变量窥视(Bind Peeking)功能的影响，所以硬解析选择执行计划时，会把绑定变量值3代入到SQL文中计算基数，SQL文在10000条数据中选择了30条数据，所以，选择了索引IND1进行INDEX RANGE SCAN。

SQL> set line 200
SQL> set pagesize 9999
SQL> select * from table(dbms_xplan.display_cursor(null,null,'NOTE ALLSTATS LAST'));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------
SQL_ID  cuf4u4th4w0nz, child number 0
-------------------------------------
SELECT * FROM TEST_ACS WHERE c1 <= :x

Plan hash value: 3882350253

---------------------------------------------------------
| Id  | Operation   | Name | E-Rows |
---------------------------------------------------------
|   0 | SELECT STATEMENT|  ||
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST_ACS | 30 |
|*  2 |   INDEX RANGE SCAN  | IND1 | 30 |
---------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("C1"<=:X)

当SQL文第一次被执行的时候，因为绑定变量窥视(Bind Peeking)功能的影响，所以硬解析选择执行计划时，会把绑定变量值3代入到SQL文中计算选择率。

因为SQL文在10000条数据中选择了30条数据，选择率为0.03，所以优化器选择了通过索引IND1进行访问数据（INDEX RANGE SCAN）。

SQL> col PREDICATE format a20
SQL> ---sql_id:cuf4u4th4w0nz
SQL> select sql_id,child_number, executions, buffer_gets,
2     is_bind_sensitive BS, is_bind_aware BA,IS_SHAREABLE SH,plan_hash_value
3  from v$sql
4  where sql_id = 'cuf4u4th4w0nz';

SQL_ID CHILD_NUMBER EXECUTIONS BUFFER_GETS B B S PLAN_HASH_VALUE
------------- ------------ ---------- ----------- - - - ---------------
cuf4u4th4w0nz0  1   7 Y N Y  3882350253

---1.V$SQL.is_bind_sensitive为Y，游标被标示成bind-sensitive，可以使用ACS。
---V$SQL.IS_SHAREABLE为Y，游标可以被共享
---V$SQL.is_bind_aware为N，没有意识到绑定变量不同会影响执行计划

SQL>
SQL> select sql_id, child_number, BIND_EQUIV_FAILURE, LOAD_OPTIMIZER_STATS
2  from V$SQL_SHARED_CURSOR
3  where sql_id = 'cuf4u4th4w0nz';

SQL_IDCHILD_NUMBER B L
------------- ------------ - -
cuf4u4th4w0nz0 N N

---1.游标共享信息V$SQL_SHARED_CURSOR.BIND_EQUIV_FAILURE为N
---V$SQL_SHARED_CURSOR.LOAD_OPTIMIZER_STATS为N （供以后做对比）

SQL>
SQL> select *
2  from v$sql_cs_statistics
3  where sql_id='cuf4u4th4w0nz';

ADDRESS  HASH_VALUE SQL_IDCHILD_NUMBER BIND_SET_HASH_VALUE P EXECUTIONS ROWS_PROCESSED BUFFER_GETS   CPU_TIME
---------------- ---------- ------------- ------------ ------------------- - ---------- -------------- ----------- ----------
000000008A976370 1615725215 cuf4u4th4w0nz0  2706503459 Y  1 60   7  0

---1.v$sql_cs_statistics采样信息中，记录了游标执行的执行状况，包括处理的行数，消耗的Buffer等信息

SQL>
SQL> ---no data in V$SQL_CS_SELECTIVITY for the first time.
SQL> select *
2  from v$sql_cs_selectivity
3  where sql_id = 'cuf4u4th4w0nz';

no rows selected

---1.V$SQL_CS_SELECTIVITY 中还没有任何信息。

SQL>
SQL> select *
2  from V$SQL_CS_HISTOGRAM
3  where sql_id='cuf4u4th4w0nz';

ADDRESS  HASH_VALUE SQL_IDCHILD_NUMBER  BUCKET_ID  COUNT
---------------- ---------- ------------- ------------ ---------- ----------
000000008A976370 1615725215 cuf4u4th4w0nz0  0  1 ★
000000008A976370 1615725215 cuf4u4th4w0nz0  1  0
000000008A976370 1615725215 cuf4u4th4w0nz0  2  0

---1.V$SQL_CS_HISTOGRAM里根据变量值做成的执行次数直方图中，本次执行计算到BUCKET_ID：0中，1次。

根据上面的相关信息，我们可以知道，当包含绑定变量信息的SQL文第一次执行的时候，会发生下面的一些动作：

・SQL文进行硬解析（HARD Parse）
・根据最初绑定变量值为3，进行估算选择率（Bind Peeking）
・游标被标示成bind-sensitive
・选择出最优执行计划

保存：
・记录了游标执行的执行状况，包括处理的行数，消耗的Buffer等信息
・记录了游标执行次数直方图

Test2：指定变量值为9，执行SQL文

下面我们传递一个变量9，再次执行SQL文。

SQL> --var x number;
SQL> exec :x := 900 ;

PL/SQL procedure successfully completed.

SQL> SELECT * FROM TEST_ACS WHERE c1 <= :x;

C1 C2
------ --------------------
1 a
1 a
...
900 a
900 a

9000 rows selected.

---还是使用最初的执行计划索引扫描。

SQL> set line 2000
SQL> set pagesize 9999
SQL> select * from table(dbms_xplan.display_cursor(null,null,'NOTE ALLSTATS LAST'));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------
SQL_ID  cuf4u4th4w0nz, child number 0
-------------------------------------
SELECT * FROM TEST_ACS WHERE c1 <= :x

Plan hash value: 3882350253

---------------------------------------------------------
| Id  | Operation   | Name | E-Rows |
---------------------------------------------------------
|   0 | SELECT STATEMENT|  ||
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST_ACS | 30 |
|*  2 |   INDEX RANGE SCAN  | IND1 | 30
11d5d
|
---------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("C1"<=:X)

虽然SQL文在10000条数据中选择了9000条数据，选择率应该为0.9，

但是因为该SQL文已经硬解析过了，所以这次是软解析，使用以前的执行计划，通过索引IND1进行访问数据（INDEX RANGE SCAN）。

再次观察相关动态视图的变化：

SQL>
SQL> col PREDICATE format a20
SQL> ---sql_id:cuf4u4th4w0nz
SQL> select sql_id,child_number, executions, buffer_gets,
2     is_bind_sensitive BS, is_bind_aware BA,IS_SHAREABLE SH,plan_hash_value
3  from v$sql
4  where sql_id = 'cuf4u4th4w0nz';

SQL_IDCHILD_NUMBER EXECUTIONS BUFFER_GETS B B S PLAN_HASH_VALUE
------------- ------------ ---------- ----------- - - - ---------------
cuf4u4th4w0nz0  21239 Y N Y  3882350253

---2.V$SQL中的内容没有变化，和指定变量值为3时一样。

SQL>
SQL> select sql_id, child_number, BIND_EQUIV_FAILURE, LOAD_OPTIMIZER_STATS
2  from V$SQL_SHARED_CURSOR
3  where sql_id = 'cuf4u4th4w0nz';

SQL_IDCHILD_NUMBER B L
------------- ------------ - -
cuf4u4th4w0nz0 N Y

----2.但是因为估算的选择率（0.03）和实际执行的选择率（0.9）差距很大，
V$SQL_SHARED_CURSOR游标共享信息中LOAD_OPTIMIZER_STATS变为Y

SQL> select *
2  from v$sql_cs_statistics
3  where sql_id='cuf4u4th4w0nz';

ADDRESS  HASH_VALUE SQL_IDCHILD_NUMBER BIND_SET_HASH_VALUE P EXECUTIONS ROWS_PROCESSED BUFFER_GETS   CPU_TIME
---------------- ---------- ------------- ------------ ------------------- - ---------- -------------- ----------- ----------
000000008A976370 1615725215 cuf4u4th4w0nz0  2706503459 Y  1 60   7  0

---2.v$sql_cs_statistics采样信息并没有变化。(因为是采样，所以不一定随时变化)

SQL>
SQL> select *
2  from v$sql_cs_selectivity
3  where sql_id = 'cuf4u4th4w0nz';

no rows selected

---2.V$SQL_CS_SELECTIVITY 中还是没有任何信息。

SQL> select *
2  from V$SQL_CS_HISTOGRAM
3  where sql_id='cuf4u4th4w0nz';

ADDRESS  HASH_VALUE SQL_IDCHILD_NUMBER  BUCKET_ID  COUNT
---------------- ---------- ------------- ------------ ---------- ----------
000000008A976370 1615725215 cuf4u4th4w0nz0  0  1
000000008A976370 1615725215 cuf4u4th4w0nz0  1  1
000000008A976370 1615725215 cuf4u4th4w0nz0  2  0

---2.V$SQL_CS_HISTOGRAM里根据变量值做成的执行次数直方图中，本次执行计算到BUCKET_ID：1中，1次。

根据上面的相关信息，我们可以知道，当SQL文第二次执行，

并且绑定变量值和之前的绑定变量值的选择率很大时，会发生下面的一些动作：

・SQL文进行软解析（Soft Parse）
・使用以前的执行计划执行
・比较统计信息 （估算的选择率：0.03和实际执行的选择率：0.9）
・如果差距很大时，V$SQL_SHARED_CURSOR游标共享信息中LOAD_OPTIMIZER_STATS变为Y。(激活ECS)

保存：
・记录了游标执行的执行状况，包括处理的行数，消耗的Buffer等信息
・记录了游标执行次数直方图（根据行数选择BUCKET）
・SQL变为BIND Aware

Test3：指定变量值为9，再次执行SQL文

下面我们传递一个变量9，再次执行SQL文:

SQL> --var x number;
SQL> exec :x := 900 ;

PL/SQL procedure successfully completed.

SQL> SELECT * FROM TEST_ACS WHERE c1 <= :x;

C1 C2
------ --------------------
67 a
...
900 a

9000 rows selected.

SQL>

---通过全表扫描执行。

SQL> set line 2000
SQL> set pagesize 9999
SQL> select * from table(dbms_xplan.display_cursor(null,null,'NOTE ALLSTATS LAST'));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------
SQL_ID  cuf4u4th4w0nz, child number 1
-------------------------------------
SELECT * FROM TEST_ACS WHERE c1 <= :x

Plan hash value: 3781643149

-----------------------------------------------
| Id  | Operation | Name | E-Rows |
-----------------------------------------------
|   0 | SELECT STATEMENT  |  ||
|*  1 |  TABLE ACCESS FULL| TEST_ACS |   9009 |
-----------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - filter("C1"<=:X)

由于上次执行时发现，由于变量值的影响，SQL文的选择率预估值和实际执行时的差别很大（Bind Aware），所以这次执行SQL文重新编译，执行计划发生了变化，通过全表扫描执行。

再次观察相关动态视图的变化：

SQL> col PREDICATE format a20
SQL> ---sql_id:cuf4u4th4w0nz
SQL> select sql_id,child_number, executions, buffer_gets,
2     is_bind_sensitive BS, is_bind_aware BA,IS_SHAREABLE SH,plan_hash_value
3  from v$sql
4  where sql_id = 'cuf4u4th4w0nz';

SQL_IDCHILD_NUMBER EXECUTIONS BUFFER_GETS B B S PLAN_HASH_VALUE
------------- ------------ ---------- ----------- - - - ---------------
cuf4u4th4w0nz0  21239 Y N N  3882350253
cuf4u4th4w0nz1  1 622 Y Y Y  3781643149

---3.V$SQL中生成了一个新的游标，
并且新生成的游标1IS_BIND_SENSITIVE, IS_BIND_AWARE, IS_SHAREABLE都是Y.
原来那个游标0，IS_SHAREABLE变为N.

SQL> select sql_id, child_number, BIND_EQUIV_FAILURE, LOAD_OPTIMIZER_STATS
2  from V$SQL_SHARED_CURSOR
3  where sql_id = 'cuf4u4th4w0nz';

SQL_IDCHILD_NUMBER B L
------------- ------------ - -
cuf4u4th4w0nz0 N Y
cuf4u4th4w0nz1 Y N

---3. V$SQL_SHARED_CURSOR中生成一条BIND_EQUIV_FAILURE为Y的游标。
（绑定变量值的选择率和存在的游标不符）

SQL> select *
2  from v$sql_cs_statistics
3  where sql_id='cuf4u4th4w0nz';

ADDRESS  HASH_VALUE SQL_IDCHILD_NUMBER BIND_SET_HASH_VALUE P EXECUTIONS ROWS_PROCESSED BUFFER_GETS   CPU_TIME
---------------- ---------- ------------- ------------ ------------------- - ---------- -------------- ----------- ----------
000000008A976370 1615725215 cuf4u4th4w0nz1  3116944019 Y  1   9000 622  0
000000008A976370 1615725215 cuf4u4th4w0nz0  2706503459 Y  1 60   7  0   ★

---3. v$sql_cs_statistics采样信息中追加了一条最新的采样

SQL> select *
2  from v$sql_cs_selectivity
3  where sql_id = 'cuf4u4th4w0nz';

ADDRESS  HASH_VALUE SQL_IDCHILD_NUMBER PREDICATE  RANGE_ID LOWHIGH
---------------- ---------- ------------- ------------ -------------------- ---------- ---------- ----------
000000008A976370 1615725215 cuf4u4th4w0nz1 <=X   0 0.810810   0.990990

---3. V$SQL_CS_SELECTIVITY 中记录了新追加的游标的选择率范围（依赖于绑定变量值）

SQL>
SQL> select *
2  from V$SQL_CS_HISTOGRAM
3  where sql_id='cuf4u4th4w0nz';

ADDRESS  HASH_VALUE SQL_IDCHILD_NUMBER  BUCKET_ID  COUNT
---------------- ---------- ------------- ------------ ---------- ----------
000000008A976370 1615725215 cuf4u4th4w0nz1  0  0
000000008A976370 1615725215 cuf4u4th4w0nz1  1  1 ★
000000008A976370 1615725215 cuf4u4th4w0nz1  2  0
000000008A976370 1615725215 cuf4u4th4w0nz0  0  1
000000008A976370 1615725215 cuf4u4th4w0nz0  1  1
000000008A976370 1615725215 cuf4u4th4w0nz0  2  0

6 rows selected.

---3. V$SQL_CS_HISTOGRAM里记录了新追加的游标的直方图，并记录执行次数到BUCKET_ID：1中，1次。

根据上面的相关信息，我们可以知道，当SQL文第三次执行时（和第二次相同的变量），会发生下面的一些动作：

・SQL文进行硬解析（Hard Parse）
・生成新的执行计划
・V$SQL_SHARED_CURSOR游标共享信息中BIND_EQUIV_FAILURE变为Y。
・V$SQL中生成IS_BIND_SENSITIVE, IS_BIND_AWARE, IS_SHAREABLE都是Y的新游标1.
原来那个游标0，IS_SHAREABLE变为N

保存：
・记录游标执行的执行状况，包括处理的行数，消耗的Buffer等信息
・记录游标执行次数直方图（根据行数选择BUCKET）
・SQL变为BIND Aware
・记录游标的选择率范围（selectivity cube）

Test4：指定变量值为3，再次执行SQL文 　（SELECTIVITY CUBE）

指定变量值为3 (和最初执行时一样)，再次执行SQL文

SQL> --var x number;
SQL> exec :x := 3 ;

PL/SQL procedure successfully completed.

SQL> SELECT * FROM TEST_ACS WHERE c1 <= :x;

C1 C2
------ --------------------
1 a
...
3 a

30 rows selected.

---SQL文重新解析，通过索引扫描执行

SQL> set line 200
SQL> set pagesize 9999
SQL> select * from table(dbms_xplan.display_cursor(null,null,'NOTE ALLSTATS LAST'));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------
SQL_ID  cuf4u4th4w0nz, child number 2
-------------------------------------
SELECT * FROM TEST_ACS WHERE c1 <= :x

Plan hash value: 3882350253

---------------------------------------------------------
| Id  | Operation   | Name | E-Rows |
---------------------------------------------------------
|   0 | SELECT STATEMENT|  ||
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST_ACS | 30 |
|*  2 |   INDEX RANGE SCAN  | IND1 | 30 |
---------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("C1"<=:X)

这次执行计划发生了变化，SQL文重新解析，通过索引扫描执行。

再次观察相关动态视图的变化：

SQL> ---sql_id:cuf4u4th4w0nz
SQL> col PREDICATE format a20
SQL> ---sql_id:cuf4u4th4w0nz
SQL> select sql_id,child_number, executions, buffer_gets,
2     is_bind_sensitive BS, is_bind_aware BA,IS_SHAREABLE SH,plan_hash_value
3  from v$sql
4  where sql_id = 'cuf4u4th4w0nz';

SQL_ID　CHILD_NUMBER EXECUTIONS BUFFER_GETS B B S PLAN_HASH_VALUE
------------- ------------ ---------- ----------- - - - ---------------
cuf4u4th4w0nz0  21239 Y N N  3882350253
cuf4u4th4w0nz1  1 622 Y Y Y  3781643149
cuf4u4th4w0nz2  1   7 Y Y Y  3882350253  ★

---4.V$SQL中生成了一个新游标CHILD# 2，
并且新生成的游标IS_BIND_SENSITIVE, IS_BIND_AWARE, IS_SHAREABLE都是Y.

SQL> select *
2  from v$sql_cs_statistics
3  where sql_id='cuf4u4th4w0nz';

ADDRESS  HASH_VALUE SQL_IDCHILD_NUMBER BIND_SET_HASH_VALUE P EXECUTIONS ROWS_PROCESSED BUFFER_GETS   CPU_TIME
---------------- ---------- ------------- ------------ ------------------- - ---------- -------------- ----------- ----------
000000008A976370 1615725215 cuf4u4th4w0nz2  2706503459 Y  1 60   7  0★
000000008A976370 1615725215 cuf4u4th4w0nz1  3116944019 Y  1   9000 622  0
000000008A976370 1615725215 cuf4u4th4w0nz0  2706503459 Y  1 60   7  0

---4. v$sql_cs_statistics采样信息中追加了一条最新的采样

SQL>
SQL> ---select CHILD_NUMBER,PREDICATE,RANGE_ID,LOW,HIGH
SQL> select *
2  from v$sql_cs_selectivity
3  where sql_id = 'cuf4u4th4w0nz';

ADDRESS  HASH_VALUE SQL_ID　CHILD_NUMBER PREDICATE  RANGE_ID LOWHIGH
---------------- ---------- ------------- ------------ -------------------- ---------- ---------- ----------
000000008A976370 1615725215 cuf4u4th4w0nz2 <=X   0 0.002702   0.003302   ★
000000008A976370 1615725215 cuf4u4th4w0nz1 <=X   0 0.810810   0.990990

---4. V$SQL_CS_SELECTIVITY 中记录了新追加游标CHILD# 2的选择率范围（依赖于绑定变量值）

SQL> select *
2  from V$SQL_CS_HISTOGRAM
3  where sql_id='cuf4u4th4w0nz';

ADDRESS  HASH_VALUE SQL_IDCHILD_NUMBER  BUCKET_ID  COUNT
---------------- ---------- ------------- ------------ ---------- ----------
000000008A976370 1615725215 cuf4u4th4w0nz2  0  1 ★
000000008A976370 1615725215 cuf4u4th4w0nz2  1  0
000000008A976370 1615725215 cuf4u4th4w0nz2  2  0
000000008A976370 1615725215 cuf4u4th4w0nz1  0  0
000000008A976370 1615725215 cuf4u4th4w0nz1  1  1
000000008A976370 1615725215 cuf4u4th4w0nz1  2  0
000000008A976370 1615725215 cuf4u4th4w0nz0  0  1
000000008A976370 1615725215 cuf4u4th4w0nz0  1  1
000000008A976370 1615725215 cuf4u4th4w0nz0  2  0

9 rows selected.

---4. V$SQL_CS_HISTOGRAM里记录了CHILD# 2的直方图，并记录执行次数到BUCKET_ID：0中，1次。

根据上面的相关信息，我们可以知道，当SQL文第四次执行时（和第一次相同的变量），

由于第一次生成的游标变成IS_SHAREABLE为N,会发生下面的一些动作：

・SQL文进行硬解析（Hard Parse）
・生成新的执行计划
・V$SQL中生成IS_BIND_SENSITIVE, IS_BIND_AWARE, IS_SHAREABLE都是Y的新游标.

保存：
・记录游标执行的执行状况，包括处理的行数，消耗的Buffer等信息
・记录游标执行次数直方图（根据行数选择BUCKET）
・记录游标的选择率范围（selectivity cube）

Test5：指定变量值为5，再次执行SQL文 (Merge)

指定变量值为5，再次执行SQL文.

我们知道对于本条SQL文变量值为5时符合条件的选择率是50/10000=0.005，并不在以前执行过游标的选择率范围内（变量值为3的选择率范围为0.002702～0.003302；变量值为9的选择率范围为0.810810～0.990990)，

所以SQL文 依然是进行了硬解析。

SQL> --var x number;
SQL> exec :x := 5 ;

PL/SQL procedure successfully completed.

SQL> SELECT * FROM TEST_ACS WHERE c1 <= :x;

C1 C2
------ --------------------
1 a
...
5 a
5 a

50 rows selected.
---SQL文选择了最优的执行计划，通过索引扫描。
SQL> set line 200
SQL> set pagesize 9999
SQL> select * from table(dbms_xplan.display_cursor(null,null,'NOTE ALLSTATS LAST'));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------
SQL_ID  cuf4u4th4w0nz, child number 3
-------------------------------------
SELECT * FROM TEST_ACS WHERE c1 <= :x

Plan hash value: 3882350253

---------------------------------------------------------
| Id  | Operation   | Name | E-Rows |
---------------------------------------------------------
|   0 | SELECT STATEMENT|  ||
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST_ACS | 50 |
|*  2 |   INDEX RANGE SCAN  | IND1 | 50 |
---------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("C1"<=:X)

SQL文重新解析，通过索引扫描执行。再次观察相关动态视图的变化：

SQL> col PREDICATE format a20
SQL> ---sql_id:cuf4u4th4w0nz
SQL> select sql_id,child_number, executions, buffer_gets,
2     is_bind_sensitive BS, is_bind_aware BA,IS_SHAREABLE SH,plan_hash_value
3  from v$sql
4  where sql_id = 'cuf4u4th4w0nz';

SQL_IDCHILD_NUMBER EXECUTIONS BUFFER_GETS B B S PLAN_HASH_VALUE
------------- ------------ ---------- ----------- - - - ---------------
cuf4u4th4w0nz0  21239 Y N N  3882350253
cuf4u4th4w0nz1  1 622 Y Y Y  3781643149
cuf4u4th4w0nz2  1   7 Y Y N  3882350253
cuf4u4th4w0nz3  1  11 Y Y Y  3882350253  ★

---5.V$SQL中生成了一个新游标CHILD#3，
CHILD#3游标的IS_BIND_SENSITIVE, IS_BIND_AWARE, IS_SHAREABLE都是Y；
而且我们注意到和新生成CHILD#3拥有相同执行计划的CHILD#2的IS_SHAREABLE变成了N,
也就所说CHILD#2不再被共享进入了age out队列。

SQL> select *
2  from v$sql_cs_statistics
3  where sql_id='cuf4u4th4w0nz';

ADDRESS  HASH_VALUE SQL_IDCHILD_NUMBER BIND_SET_HASH_VALUE P EXECUTIONS ROWS_PROCESSED BUFFER_GETS   CPU_TIME
---------------- ---------- ------------- ------------ ------------------- - ---------- -------------- ----------- ----------
000000008A976370 1615725215 cuf4u4th4w0nz3   365452098 Y  1100  11  0★
000000008A976370 1615725215 cuf4u4th4w0nz2  2706503459 Y  1 60   7  0
000000008A976370 1615725215 cuf4u4th4w0nz1  3116944019 Y  1   9000 622  0
000000008A976370 1615725215 cuf4u4th4w0nz0  2706503459 Y  1 60   7  0

---5. v$sql_cs_statistics采样信息中追加了一条最新的采样

SQL> select *
2  from v$sql_cs_selectivity
3  where sql_id = 'cuf4u4th4w0nz';

ADDRESS  HASH_VALUE SQL_IDCHILD_NUMBER PREDICATE  RANGE_ID LOW HIGH
---------------- ---------- ------------- ------------ -------------------- ---------- ---------- ----------
000000008A976370 1615725215 cuf4u4th4w0nz3 <=X   0 0.002702   0.005504★
000000008A976370 1615725215 cuf4u4th4w0nz2 <=X   0 0.002702   0.003302
000000008A976370 1615725215 cuf4u4th4w0nz1 <=X   0 0.810810   0.990990

---5. V$SQL_CS_SELECTIVITY 中记录了新追加游标CHILD# 3的选择率范围（依赖于绑定变量值5）而且CHILD#3的选择率范围（0.002702～0.005504）把CHILD#2的选择率范围也包含了在内（0.002702～0.003302）。

SQL> select *
2  from V$SQL_CS_HISTOGRAM
3  where sql_id='cuf4u4th4w0nz';

ADDRESS  HASH_VALUE SQL_ID CHILD_NUMBER  BUCKET_ID  COUNT
---------------- ---------- ------------- ------------ ---------- ----------
000000008A976370 1615725215 cuf4u4th4w0nz 3  0  1 ★
000000008A976370 1615725215 cuf4u4th4w0nz 3  1  0 ★
000000008A976370 1615725215 cuf4u4th4w0nz 3  2  0 ★
000000008A976370 1615725215 cuf4u4th4w0nz 2  0  1
000000008A976370 1615725215 cuf4u4th4w0nz 2  1  0
000000008A976370 1615725215 cuf4u4th4w0nz 2  2  0
000000008A976370 1615725215 cuf4u4th4w0nz 1  0  0
000000008A976370 1615725215 cuf4u4th4w0nz 1  1  1
000000008A976370 1615725215 cuf4u4th4w0nz 1  2  0
000000008A976370 1615725215 cuf4u4th4w0nz 0  0  1
000000008A976370 1615725215 cuf4u4th4w0nz 0  1  1
000000008A976370 1615725215 cuf4u4th4w0nz 0  2  0

12 rows selected.

---5. V$SQL_CS_HISTOGRAM里记录了CHILD# 3的直方图，并记录执行次数到BUCKET_ID：0中，1次。

根据上面的相关信息，我们可以知道，当SQL文第五次执行时（不在之前的变量值的选择率范围内），会发生下面的一些动作：

・SQL文进行硬解析（Hard Parse）
・生成新的执行计划
・V$SQL中生成IS_BIND_SENSITIVE, IS_BIND_AWARE, IS_SHAREABLE都是Y的新游标.
・把之前有相同执行计划的游标IS_SHAREABLE标记为N，成为age out的对象。
・合并具有相同计划的游标（Merge）

保存：
・记录游标执行的执行状况，包括处理的行数，消耗的Buffer等信息
・记录游标执行次数直方图（根据行数选择BUCKET）
・记录合并后游标的选择率范围（selectivity cube）

ACS通过这种游标合并的操作，可以尽量减少子游标的数量，避免生成过多的子游标，减少内存等资源的浪费。

补充

我们也看到，在V$SQL_CS_HISTOGRAM视图中，每个子游标都有3行直方图数据，分别为Bucket 0、Bucket 1和Bucket 2，针对SQL文的每次执行，Oracle都会在相应的Bucket 行中记录子游标的执行次数。

子游标的执行次数到底记录在哪个Bucket 呢？

事实上，Oracle是根据实际执行所操作的总行数（Row Source Processing）来生成直方图的。

一般条数较多时，记录的方式如下：

Bucket 0: <1024(1K)行 ，
Bucket 1：大于或等于1024行小于1024*1024 (1M)行，
Bucket 2：大于或等于1024*1024 (1M)行。

而这个直方图最大的作用在于，比较SQL文的Child#0的Bucket 的高度（COUNT），如果其中Bucket的高度满足一定条件时，就会启用ACS功能(Bind Aware)。

※注意：

这仅仅是判断逻辑中的最简单的一种方式，还有其他更为复杂的判断逻辑，在这里暂时不做介绍。

ACS 的处理流程

下面引用一下Oracle ACE Mohamed Houri做的一个ACS流程图，来总体的回顾一下ACS的处理过程。

总结

通过上面的例子，我们基本了解了ACS的基本处理流程和ACS的好处：

解决由于绑定变量窥视功能导致的性能问题。

参考

Oracle Database Online Documentation 12c Release 1 (12.1) / Database SQL Tuning Guide

>Adaptive Cursor Sharing

版权声明：本文为博主原创文章，转载请注明出处,谢谢。http://blog.csdn.net/lukeunique