我用同一个查询的另外两次执行来说明了这个概念，但使用了完全不同的绑定变量，如列表4所示：
列表4：
-- Execution #2
-----
BEGIN
:cust_start := 42999;
:cust_end := 50000;
:time_start := '01 JAN 1997';
:time_end := '31 MAR 1998';
SELECT
SUM(amount_sold)
，SUM(quantity_sold)
INTO
:total_sold
，:total_qty
FROM sh.sales
WHERE cust_id BETWEEN :cust_start AND :cust_end
AND time_id BETWEEN :time_start AND :time_end;
END;
/
-----
-- Execution #3
-----
BEGIN
:cust_start := 1000;
:cust_end := 1400;
:time_start := '01 JAN 1996';
:time_end := '31 MAR 1997';
SELECT
SUM(amount_sold)
，SUM(quantity_sold)
INTO
:total_sold
，:total_qty
FROM sh.sales
WHERE cust_id BETWEEN :cust_start AND :cust_end
AND time_id BETWEEN :time_start AND :time_end;
END; |
为查询游标指定的自适应游标共享元数据产生的变化显示在列表5中。 列表5：
SQL Statements With Bind Sensitivity Enabled
(from V$SQL)
Plan Bind
Hash Hash Sensi- Bind
SQL ID Value Value tive？ Aware？ SQL Text
---------------- ------------ ------------ ------ ------
87qtpurhk664g 3777173647 2855975716 Y Y SELECT SUM(AMOUNT_SOLD) ，SUM(QUANTITY_SOLD) FROM SH.SALES WHERE CUST_ID BETWEEN
:B4 AND :B3 AND TIME_ID BETWEEN :B2 AND :B1
87qtpurhk664g 3777173647 787661731 Y N SELECT SUM(AMOUNT_SOLD) ，SUM(QUANTITY_SOLD) FROM SH.SALES WHERE CUST_ID BETWEEN
:B4 AND :B3 AND TIME_ID BETWEEN :B2 AND :B1
Histograms for Adaptive Cursor Sharing
(from V$SQL_CS_HISTOGRAM)
Exec-
Hash Chld Bckt ution
Value SQL ID # ID# Count
------------ ---------------- ----- ----- -------
3777173647 87qtpurhk664g 1 0 1
3777173647 87qtpurhk664g 1 1 0
3777173647 87qtpurhk664g 1 2 0
3777173647 87qtpurhk664g 0 0 1
3777173647 87qtpurhk664g 0 1 1
3777173647 87qtpurhk664g 0 2 0
Selectivity Metrics for Adaptive Cursor Sharing
(from V$SQL_CS_STATISTICS)
# of
Hash Chld Hash Exec- # of Buffer CPU
Value SQL ID # Value Peek？ utions Rows Gets Time
------------ ---------------- ----- ------------ ----- ------- -------
3777173647 87qtpurhk664g 1 1601990286 Y 1 1 2 0
3777173647 87qtpurhk664g 0 4302390 Y 1 1098 3178 0
Selectivity Metrics for Adaptive Cursor Sharing
(from V$SQL_CS_SELECTIVITY)
Hash Chld Rng
Value SQL ID # ID# Low Value High Value Predicates
------------ ---------------- ----- ----- ------------ ------------
3777173647 87qtpurhk664g 1 0 0.000616 0.000753 <=B1
3777173647 87qtpurhk664g 1 0 0.900000 1.100000 >=B2
3777173647 87qtpurhk664g 1 0 0.109520 0.133858 <=B3
3777173647 87qtpurhk664g 1 0 0.821710 1.004312 >=B4 |
注意，Oracle 11g已经为hash值为2855975716的SQL语句创建了新的子游标，不将它们都标记为绑定敏感和绑定感知，元数据中为这些游标指定的选择性度量值也更新了。
当绑定变量的值超出了现有绑定感知游标影响的范围时，执行包含这个绑定变量的查询会发生什么？在语句的硬解析期间，优化器可能只会选择扩大选择范围，以包括新的绑定值，这是通过创建新的子游标结合这两套绑定变量值，然后删除旧的、范围小的游标来实现的，显然，这样只会产生几个的确需要的几个子游标。
那么如何激活这一新功能呢？好消息是在Oracle 11g中默认就已经启动了，它完全与CURSOR_SHARING初始化参数无关，这大大增加了在OLTP/DSS系统中SQL语句使用绑定变量的机会。
对SQL计划管理(SPM)的影响：如果你读过我之前写的SQL计划管理方面的文章，你可能会疑惑自适应游标共享是否会影响SQL计划管理捕获和保存SQL执行计划到SQL管理基础库中的功能，下面列出它们之间交互的摘要信息：
如果初始化参数OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES被设置为TRUE以激活自动捕获执行计划，那么带有绑定变量的SQL语句也会被标记为启用和接收执行计划。
如果同一个语句构建了第二个执行计划 – 并不是自适应游标共享 – 那么该计划只会简单地添加到语句的计划历史中，但它不会立即被使用，因为SPM首先会要求校验这个新的执行计划。
不幸的是，这意味着一个很好的执行计划会被忽略，解决这个问题的一个好办法是将自动捕获计划设置为FALSE，然后在库缓存中将所有子游标捕获到SMB中，这样将会强制所有子游标的计划被标记为SQL计划基线。
结束语
Oracle 11g的新特性自适应游标共享为包含有绑定变量的SQL语句有效共享执行计划提供了一个更简单的方法，但只有绑定变量有值时才有意义，自适应游标共享有时也会产生新的执行计划，但共享的游标会保持相对小的数量。