4、FORCE——强制共享执行计划

默认值EXACT的作用是不对非字面SQL绑定变量进行替换操作。而FORCE值和SIMILAR取值意味着Oracle需要对输入的SQL语句进行处理，首先就是对条件值进行绑定变量化，其次就是针对不同的取值采用不同的执行计划共享策略。

当选择FORCE值的时候，意味着Oracle会对SQL字面值进行绑定变量处理。一个语句形成父游标和仅有的一个子游标。子游标执行计划通过Oracle binds peeking技术实现，以后所有类似形态的SQL都是先共享。

将当前会话的cursor_sharing设置为force，同时清空library cache。之后使用三条SQL语句进行试验。

如果在EXACT取值的时候，三个执行语句一定会生成三个父游标和三个子游标的。每一个游标对应一个单独的执行计划。第一和第二条SQL对应全表扫描FTS方案较好，而第三条SQL显然索引路径较优。我们看看在FORCE取值的时候，生成计划情况如何呢？

此时，我们观察到三次执行之后SQL游标共享情况。首先，三次的SQL语句从字面值上完全不同，差异只是存在在条件id1取值上。如果在cursor_sharing为EXACT模式下，是不能实现游标共享的。设置为FORCE之后，我们发现Oracle自动将id1=后面的条件替换为绑定变量。三次SQL调用均使用相同的父游标，而子游标只存在一个，意味著三次调用均是使用这个唯一的子游标。一个子游标对应一个执行计划，三个SQL使用相同的执行计划。

我们使用抽取手段抽取出执行计划，如下：

注意，这个执行计划进行的是数据表的全表扫描。三次调用中，id1取定D\P因为数据量大，都可以使用FTS。但是G取值量少，应该使用索引路径较为合适。所以，在第一次生成执行计划之后，Oracle都会使用该执行计划作为相同SQL结构的语句计划。

这类问题很类似于大名鼎鼎的bind peeking。在执行计划中，我们也的确看到了bind peeking信息，说明其中是使用‘D’值peeking出的执行计划。

此处，我们已经可以知道FORCE取值的效果，当cursor_sharing参数选择FORCE的时候：

üOracle对输入的SQL值，会将where条件取值自动替换为绑定变量。以后在输入相同的结构SQL语句时，会进行cursor sharing共享游标；

ü在第一次进行自动替换绑定变量的时候，Oracle会依据bind peeking取值，获取到一个执行计划，对应成子游标；

ü在以后的SQL语句中，只要出现父游标可共享的情况，Oracle都会强制使用生成的唯一子游标进行sharing。不去在乎是不是对SQL是最优的执行计划；

FORCE取值的规则思想很简单，对SQL语句进行强制的绑定变量替换。使用第一次的bind peeking值生成执行计划，之后全部使用这个执行计划。这种方式实现了游标共享，避免出现大量的library cache硬解析，限制一个父游标的version_count数量。

如果这种SQL语句本身是“Good SQL”，也就是条件列分布比较平均，没有出现过大的偏移分布。我们认为这种FORCE是很有益的。但是如果数据列分布不平均，这样借用第一次输入的bind peeking生成并且共享执行计划就很成问题。我们说，在cursor_sharing取定FORCE遇到的潜在问题，和我们使用绑定变量时候使用的bind peeking值问题是相同的。