我用同一个查询的另外两次执行来说明了这个概念，但使用了完全不同的绑定变量，如列表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语句有效共享执行计划提供了一个更简单的方法，但只有绑定变量有值时才有意义，自适应游标共享有时也会产生新的执行计划，但共享的游标会保持相对小的数量。