Oracle 11g 新特性 -- 自适应游标共享(Adaptive Cursor Sharing： ACS) 说明（转载）

一．自适应游标共享（Adaptive Cursor Sharing） 说明
 
1.1 ACS概述
绑定变量使Oracle DB 可以为多条SQL 语句共享单个游标，以减少分析SQL 语句所使用的共享内存量。然而，游标共享和SQL 优化是两个相互冲突的目标。用文字编写SQL 语句为优化程序提供了更多的信息，这无疑会导致更好的执行计划，但大量的硬分析会导致内存和CPU 开销增加。
 
Oracle9i Database首次尝试推出了一个折衷的解决方案:允许共享使用不同文字值的相似SQL 语句。对于使用绑定变量的语句，Oracle9i 还引入了绑定扫视(Bind Peek)概念。使用绑定扫视，优化程序会在首次执行语句时查看绑定值。然后，它使用这些值来确定一个执行计划，语句的所有其它执行均共享该执行计划。为了从绑定扫视中受益，假定使用游标共享，且假定语句的不同调用使用相同的执行计划。如果语句的不同调用从不同的执行计划中获得很大收益，则绑定扫视对生成有效的执行计划就不再有用。
 
一个计划并不总是适用于所有绑定值,为了尽可能解决此问题，Oracle Database 11g 引入了自适应游标共享。此功能是一项更复杂的策略，它并不会盲目地共享游标，如果与分析时间和内存使用量开销相比，使用多个执行计划所带来的收益更重要，则会为使用绑定变量的每条SQL 语句生成多个执行计划。然而，由于使用绑定变量的目的是共享内存中的游标，因此对于需要生成的子游标数目必须采取一种折衷的方法。
 
Adaptive Cursor Sharing 作用如下：
• 通过自适应游标共享，可以仅针对使用绑定变量的语句智能地共享游标。
• 自适应游标共享用于协调游标共享和优化之间的矛盾。
• 自适应游标共享具有如下优点：
– 自动检测不同执行受益于不同执行计划的时间
– 将生成的子游标数限制到最小
– 是自动机制，无法关闭
 
1.2 ACS体系结构
 
1.2.1示例
 

 
上图使用自适应游标共享执行下列步骤：
 
1. 游标照常随硬分析启动。如果发生绑定扫视(BindPeek)，且使用直方图计算包含绑定变量的谓词选择性，则该游标将被标记为对绑定敏感的游标。此外，还会存储一些有关包含绑定变量的谓词的信息，包括谓词选择性。在上图中，所存储的谓词选择性是一个以(0.15,0.0025) 为中心的立方体。由于进行了初始硬分析，将使用已扫视的绑定确定初始执行计划。执行游标后，绑定值和游标的执行统计信息存储在该游标中。
当使用新的一组绑定值执行下一语句时，系统会执行常规软分析，并查找供执行使用的相匹配的游标。执行结束时，会将执行统计信息与当前存储在游标中的执行统计信息进行比较。然后，系统观察所有先前运行的统计信息模式并确定是否将游标标记为能识别绑定的游标。
 
2. 下一次对此查询进行软分析时，如果游标能够识别绑定，则会使用能识别绑定的游标匹配。假定具有新的一组绑定值的谓词选择性现在是(0.18,0.003)。由于选择性用作能识别绑定的游标匹配的一部分，并且该选择性位于现有立方体中，因此该语句使用现有子游标的执行计划运行。
 
3. 下一次对此查询进行软分析时，假设具有一组新绑定值的谓词选择性是(0.3,0.009)。由于该选择性不在现有立方体中，所以找不到子游标匹配项。因此，系统会执行硬分析，在本例中生成了一个具有第二个执行计划的新子游标。此外，新选择性立方体将存储为该新子游标的一部分。执行该新子游标后，系统会将绑定值和执行统计信息存储在该游标中。
 
4. 下一次对此查询进行软分析时，假设具有一组新绑定值的谓词选择性是(.28,0.004)。由于该选择性不在现有的某个立方体中，系统将执行硬分析。假设此时硬分析生成与第一个执行计划相同的执行计划。因为该计划与第一个子游标相同，所以将合并这两个子游标。也就是说，这两个立方体将合并为一个较大的新立方体，并删除其中一个子游标。下次执行软分析时，如果选择性位于该新立方体中，子游标将匹配。
 
 
1.2.2 说明
在Oracle 10g 和11g中对绑定变量的处理，已经有所不同， 在Oracle 10g中，绑定变量相对比较简单，当使用绑定变量的SQL 第一次执行时，会进行硬解析，生成plan 和cursor。 在这个过程中，Oracle 会使用bind peeking，即将绑定变量的值带入，从而选择最优的一个plan。以后每次执行都使用这个plan。
在以后的执行时，如果因为其他原因导致cursor 不可重用，那么就会生成一个child_cursor. 这个cursor 不可重用的原因可以查看：v$sql_shared_cursor视图。
 
那么这就有一个问题。如果列上有列上有严重的数据倾斜，某个字段中99%是值1，1%是值0. 当我们用0 来进行peeking的时候，这时候会走索引，并且以后的所有plan 都是使用这个。 如果我们的绑定值变成了1. 这个时候，明显走全表扫描比索引划算。
但是Oracle 10g 下还是会使用第一次的plan，即使这个plan 不是最优的。所以在Oracle 10g下，如果数据存在数据倾斜，那么最好不要使用绑定变量。
 
在Oracle 11g 以后在绑定变量这块有所以改变，会生成一个范围值的执行计划。然后每次传变量进去就对比范围，选择最优的执行计划。与这个功能相关的参数保存在v$sql视图中：is_bind_sensitive,is_bind_aware,is_shareable。这几个字段，在Oracle 10g的v$sql 视图里是没有的。
 
我们这里要说明的Adaptive Cursor Sharing特性，其允许一个使用绑定变量的SQL语句使用多个执行计划。对于同一个SQL, 为了得到合适的查询，oracle 会监控使用不同绑定变量的情况，已确保对不同绑定变量值的cursor（执行计划）都是最优的。比如因为数据倾斜的原因对绑定变量值A 使用执行计划A，对绑定变量值B 使用执行计划B。虽然他们的SQL 是相同的，但执行计划不同。
 
Adaptive Cursor Sharing 默认启动的。不过要注意的是，该特性只有在绑定变量的参数个数不超过14个的情况才有效。
 
有关Oracle 10g和11g 绑定变量更多区别参考：
Oracle 10g 与 11g 绑定变量（Bind Variable） 区别 说明
http://www.cndba.cn/Dave/article/1390
 
1.3自适应游标共享视图
 
1.3.1 V$SQL 中已新增了两个新列
（1）IS_BIND_SENSITIVE：指示游标是否为对绑定敏感，值为YES | NO。符合以下情况的查询称为对绑定敏感的查询：计算谓词选择性时优化程序为其扫视绑定变量值，并且绑定变量值的更改可能导致不同计划。
（2）IS_BIND_AWARE：指示游标是否为能标识绑定的游标，值为YES | NO。游标高速缓存中已标记为使用能识别绑定的游标共享的游标称为能标识绑定的游标。
 
1.3.2 V$SQL_CS_HISTOGRAM
显示跨三个存储桶执行历史记录直方图的执行计数的分布情况。
 
1.3.3 V$SQL_CS_SELECTIVITY
显示为包含绑定变量且在游标共享检查中使用了其选择性的每个谓词存储在游标中的选择性立方体或范围。它包含谓词文本和选择性范围的下限值和上限值。
 
1.3.4 V$SQL_CS_STATISTICS
自适应游标共享监视查询的执行，并在一段时间内收集相关的信息，使用此信息可确定是否切换到对该查询使用能识别绑定的游标。该视图汇总了所收集的信息以让您作出以下决定：对于执行示例，它跟踪已处理的行数、缓冲区获取数和CPU 时间。如果使用绑定集来构建游标，则PEEKED 列的值为YES，否则为NO。
 
 
二．MOS 说明
MOS上对ACS的说明：
Adaptive Cursor Sharing in 11G[ID 836256.1]
Adaptive Cursor SharingOverview [ID 740052.1]
 
2.1 Introduction  介绍
With the introduction of theCBO a number of changes were made to calculate the selectivity of a predicate, whichin turn affected how the query was optimized.  The selectivity was basedon the number of distinct values for a given column or a predefined percentageof
 rows depending on the relational operator that was used. This worked wellfor data that was evenly distributed but had limitations in applications wheredata was skewed.
 
Note:68992.1 "PredicateSelectivity".
 
With 9i a new feature"Bind Peeking" was introduced to try to get around the issuesassociated with guessing the selectivity of the bind. This meant that duringhard parsing of a query using bind variables, we would peek at the binds andgenerate selectivity
 based on the bind and the underlying column statistics. Thismethod could sometimes lead to plans being generated that were notrepresentative of the general query usage if the bind selectivity of theinitial execution of a statement varied from the selectivity
 of subsequentexecutions with different sets of binds.
 
In Oracle 10g, this wasespecially noticeable as the default statistical gathering methodology changedto gather histograms automatically. This meant that selectivity that previouslyused only a formula based on the number of distinct values was now generatedbased
 on histograms, which gave the optimizer better information about thedistribution data that was skewed.
 
The impact of this was that endusers were reliant on the first execution of a query using binds that wouldgenerate an execution plan that was representative of the general query usage.
Note:387394.1 Query usingBind Variables is suddenly slowNote:430208.1 Bind PeekingBy Example
In Oracle 11g Adaptive CursorSharing has been introduced to get around some of these  issues. Thisfeature monitors the execution statistics for candidates queries and makes itpossible for  the same query to generate and use different execution plansfor different
 set of binds values.
--在Oracle 11g中引入了AdaptiveCursor Sharing 特性，该特性监控查询语句执行的统计信息，并尽可能的根据相同的SQL语句，不同的绑定变量值，使用不同的执行计划。

2.2 Advantages of Adaptive Cursor Sharing(ACS的优势)

Adaptive cursor sharing is asolution to give us the shareability of binds, with the plan adaptability of literals.With adaptive cursor sharing the database can adapt execution plans based onthe selectivity of values used in binds.
This is a workaround to issueswhere different sets of bind values for a given query may have differentselectivity, leading to a situation where there may be suboptimal plans fordifferent bind sets.
 
Previously, workaroundsemployed would either use literal values instead of binds, which could lead toexcessive hard parsing, or apply a fixed plan that would be a compromise ofperformance between different bind selectivities.
2.3 Disadvantages of Adaptive Cursor Sharing（ACS的劣势）
There is some extra overheadassociated with Adaptive Cursor Sharing in the form of :-
（1）More Hard Parses (CPU) -Extra Hard Parses will be required when a cursor becomes "Bind Aware"as we attempt to generate the better matched execution plans for the bindselectivity.
（2） More Child Cursors(SGA) - It is recommended that some consideration be taken to increase the sizeof the shared_pool on upgrade from 10g to 11g, given the extra cursors that maybe required to  accommodate this feature.
（3）More Work to Match theCursor (CPU) - More Child Cursors and the requirement to match a query to thebest execution plan for its predicate selectivity.
 
2.4 Extended Cursor Sharing ( Bind Sensitivity)
When a query is executed withbind peeking and binds using either one of the following relational operators =< > <= >= !=, or a user defined bind operator e.g.contains(e.job,:job,1)>0, and a change  in the bind variable value maylead to a different plan,
 the cursor will be marked as bind sensitive.
    --当我们在SQL中使用<= 等操作时，在改变绑定变量就会生成一个不同的执行计划（Cursor），并将这个cursor标记为bind sensitive，Bind-Sensitive Cursor是根据绑定变量值得到的最优执行计划的一个cursor。这个就是ECS。
 
The "LIKE" operatoris supported from 11.2.0.2 onwards.
 
Apart from checking for a validoperator there are also a number of subsequent bind sensitivity checks thatneed to be performed before it can be marked as bind sensitive, if it fails anyof these the cursor will not be marked as bind sensitive and adaptive
 cursorsharing would not occur. 
 
If any of the following checks fail ECS will bedisabled :
--在以下情况会禁用ECS：
（1）Extended cursor sharingis disabled
（2）The query has no binds
（3）Parallel query is used
（4）Certain parameters like("bind peeking"=false) are set
（5）You are using a /*+NO_BIND_AWARE */ hint
（6）Outlines are being used
（7）It is a recursive query
（8）The number of binds in agiven sql statement are greater than 14.
这里绑定变量个数不能超过14个，因为ACS 在绑定变量超过14个的时候会失效。
 
When using SQL Plan Baselines,and there is more than one plan enabled,  ACS will still be enabled to usethose plans.
 
When all the criteria are metthe cursor is marked as bind sensitive and a "sharing context"containing information about execution statistics of the cursor is created andstored against the cursor.
 
Cursors that are marked asbind-sensitive can been identified by the column IS_BIND_SENSITIVE=Y in V$SQL orV$SQLAREA.
 
2.5 Adaptive Cursor Sharing (Bind Aware)
If there is significantvariation in the row source cardinality for executions of the same sqlstatement in consecutive executions a cursor will be marked as bind aware.
 
For more information about this please see :-Note:836256.1 AdaptiveCursor Sharing in 11G
 
2.6 Monitoring
V$SQL can be used to see if acursor is_bind_sensitive, is_bind_aware, or is_shareable.
The bind context informationcan be viewed via V$SQL_CS_SELECTIVITY, V$SQL_CS_STATISTICS andV$SQL_CS_HISTOGRAM
 
V$SQL_CS_SELECTIVITY exposesthe valid selectivity ranges for a child cursor in extended cursor sharingmode. A valid range consists of a low and high value for each predicatecontaining binds. Each predicate's selectivity (with the current bind value)must fall
 between the corresponding low and high values in order for thechild cursor to be shared.
 
V$SQL_CS_STATISTICS containsthe raw execution statistics used by the monitoring component  of adaptivecursor sharing. A sample of the executions is monitored.

 
This view exposes whichexecutions were sampled, and what the statistics were for those  executions.The statistics are cumulative for each distinct set of bind values.
 
V$SQL_CS_HISTOGRAM summarizesthe monitoring information stored by adaptive cursor  sharing. Thisinformation is used to decide whether to enable extended cursor sharing for aquery. It  is stored in a histogram, whose bucket's contents are exposedby this view.
 
2.7 Issues with Excessive Child Cursors
There is also a possibilitythat Adaptive Cursor Sharing may compound problems in whichexcessive numbers of child cursors are generated.  This may lead toperformance degradation as large numbers of child cursor can put spacepressure on the shared pool, and
 may also lead to an increase in mutex X waitsfor that cursor.
 
Things to check.
1. Ensure that cursor_sharing is not set to SIMILAR. In 11g, this setting isnot recommended and this parameter will eventually be deprecated.Note:1169017.1:ANNOUNCEMENT:Deprecating the cursor_sharing = 'SIMILAR' setting

2. If there are high version counts check v$sql_shared_cursor. And search MyOracle Support for notes that may allude to the cause of the excessive cursors.
 Note:438755.1 :Formated V$SQL_SHARED_CURSOR Report by SQLID or Hash Value
 
If there are still excessivechild cursors, then Oracle Support should be contacted to assist withdiagnosing the issue.
 
三．ACS 启用与关闭
 
与ACS 相关的3个参数是：
_optimizer_adaptive_cursor_sharing
_optimizer_extended_cursor_sharing
_optimizer_extended_cursor_sharing_rel
 
在Oracle 11gR2的参考手册里并没有搜到这个参数的解释，不过我们可以通过查看Oracle 的参数来了解这3个参数的作用。
 
    这里我们要用到一个视图：all_parameters. 该视图的源码参考：
Oracle all_parameters 视图
http://blog.csdn.net/tianlesoftware/article/details/6641281
 
SQL>select *
from all_parameters where
name
like '%_optimizer_%_cursor_sharing%';
 
返回结果：
 
 
我们可以在db 运行时修改这3个参数，并且能即时生效。
 
关闭ACS的操作如下：
SQL> alter session set"_optimizer_extended_cursor_sharing_rel"=none;
SQL> alter session set"_optimizer_extended_cursor_sharing"=none;
SQL> alter session set"_optimizer_adaptive_cursor_sharing"=false;
 
 
关于ACS的问题，itpub上的
viadeazhu 有个更深入的研究，写得非常详细，网址如下：http://space.itpub.net/15415488/viewspace-621535
 
 
关于Oracle 10g和11g中这些参数值的变化，MOS上有篇文档说明：
PARAMETERS TO CHANGE 11.2.0.1 TO 10.2.0.4 [ID1274553.1]
 
These are the parameters thatare changed when setting optimizer_features_enable=10.2.0.4 in 11.2.0.1database. These values represent OFE=10.2.0.4 and -- is the 11.2.0.1 value
 
alter session set "_optimizer_undo_cost_change"= '10.2.0.4'; -- 11.2.0.1
alter session set "_optimizer_null_aware_antijoin" = false; -- true
alter session set "_optimizer_extend_jppd_view_types" = false; --true
alter session set "_replace_virtual_columns" = false; -- true
alter session set "_first_k_rows_dynamic_proration" = false; --true
alter session set "_bloom_pruning_enabled" = false; -- true
alter session set "_optimizer_multi_level_push_pred" = false; --true
alter session set "_optimizer_group_by_placement" = false; -- true
alter session set "_optimizer_extended_cursor_sharing_rel" = none; --simple
alter session set "_optimizer_adaptive_cursor_sharing" = false; --true
alter session set "_optimizer_improve_selectivity" = false ; -- true
alter session set "_optimizer_enable_density_improvements" = false;-- true
alter session set "_optimizer_native_full_outer_join" = off; -- force
alter session set "_optimizer_enable_extended_stats" = false; -- true
alter session set "_nlj_batching_enabled" = 0; -- 1
alter session set "_optimizer_extended_stats_usage_control" = 255; --224
alter session set "_bloom_folding_enabled" = false; -- true
alter session set "_optimizer_coalesce_subqueries" = false; -- true
alter session set "_optimizer_fast_pred_transitivity" = false; -- true
alter session set "_optimizer_fast_access_pred_analysis" = false; --true
alter session set "_optimizer_unnest_disjunctive_subq" = false; --true
alter session set "_optimizer_unnest_corr_set_subq" = false; -- true
alter session set "_optimizer_distinct_agg_transform" = false; --true
alter session set "_aggregation_optimization_settings" = 32; -- 0
alter session set "_optimizer_connect_by_elim_dups" = false; -- true
alter session set "_optimizer_eliminate_filtering_join" = false; --true
alter session set "_connect_by_use_union_all" = old_plan_mode; --true
alter session set "_optimizer_join_factorization" = false; -- true
alter session set "_optimizer_use_cbqt_star_transformation" = false;-- true
alter session set "_optimizer_table_expansion" = false ; -- true
alter session set "_and_pruning_enabled" = false ; -- true
alter session set "_optimizer_distinct_placement" = false ; -- true
alter session set "_optimizer_use_feedback" = false ; -- true
alter session set "_optimizer_try_st_before_jppd" = false ; -- true
 
 
 
 
 
 
-------------------------------------------------------------------------------------------------------
版权所有，文章允许转载，但必须以链接方式注明源地址，否则追究法律责任!
QQ:492913789
Email:ahdba@qq.com
Blog:  http://www.cndba.cn/dave
Weibo:    http://weibo.com/tianlesoftware
Twitter: 
http://twitter.com/tianlesoftware
Facebook:
http://www.facebook.com/tianlesoftware
Linkedin:
http://cn.linkedin.com/in/tianlesoftware
————————————————
版权声明：本文为CSDN博主「Dave」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/tianlesoftware/article/details/7573502