当cursor_sharing采用相似语句共享游标的时候，硬解析转换为软解析。注意，由于判断语句相似性的附加成本，软解析比已使用绑定变量的应用的软解析（用绑定变量在内部替换文字标量）花费要昂贵一些。但是，完全保存在CPU内部，内存和锁竞争任然需要考虑。
对于cursor_sharing，Oracle任然首先搜索一个精确匹配。只有当一个完全相同文本语句的游标没有找到时，Oracle搜索一个相似语句的游标。这样做是为了确保当遇到相同的没有硬编码文字标量的SQL文本的时候，不会对性能有所影响。
因为在寻找游标之前置换文字标量，其他的Oracle优化，像session_cached_cursors和cursor_space_for_time 可以方便地和cursor_sharing整合。例如，将cursor_sharing和session_cached_cursors设置为一个合理的值，在文字标量被内部绑定变量置换之后，相似语句就可以使用缓冲打开游标。
主要好处的概要如下：
l 应用程序不需要做改变
l 对已经使用绑定变量的语句没有副作用
l 使用SIMILAR，经常共享的游标不会影响执行计划
l 作为最后的办法，所有的相似语句都可以用FORCE强制共享游标
忠告
混合语句(Mixed statements)
混合语句是既有绑定变量也有硬编码文字标量的语句。如：
INSERT INTO T VALUES(5, ‘alpha’, :X)
如果是使用Oracle7 OCI的客户端，混合的相似语句不会通过cursor_sharing共享游标；在更新的版本中可以共享游标（从Oracle8 OCI开始）。实际上，这也同样适用于在服务器上的PL/SQL存储过程的SQL语句，因为在服务器上的PL/SQL使用了较老的客户端接口。
通过PL/SQL的静态SQL
Cursor_sharing对于在PL/SQL中的静态（嵌入）SQL没有任何影响。
存储概要（Stored outlines）
任何存储概要建立都没有将cursor_sharing设置为FORCE或SIMILAR，当cursor_sharing被设置时（FORCE或 SIMILAR）速度并不会有提升。那是因为存储概要被SQL文本索引，当前的cursor_sharing实现修改语句文本。为了使用带有游标共享的存储概要，它们必须使用create_stored_outlines参数重建（并且不要使用创建概要语句）。
耗费（Overhead）
使用FORCE或SIMILAR参数，搜索为相似语句创建的游标存在一个耗费。像前面提及的，这包括：
l 用原始语句文本搜索游标
l 用内部绑定变量替换文字标量，并且基于新文本的搜索
当共享游标工作的时候，这个耗费并不重要，因为大量的硬解析会被花费很小的软解析替换。但是，当游标共享没有明显的增加的时候，这些耗费会对性能产生负面的影响。在三种情况下它会发生时：
1. 应用程序没有使用绑定变量，发布相同的语句，并且没有相似语句
如果应用程序一直用同样的文字标量硬编码执行同样的语句，它会发生。这样的应用程序默认使用软解析，并且设置游标共享为FORCE或SIMILAR，会使软解析更昂贵。
针对这样一个应用的情况，有一个窍门可以使用：在共享池暖启动以后，也就是，在所有有相同文字标量的语句都被编译了以后，cursor_sharing可以被设置为FORCE或SIMILAR。这种情况下，Oralce会立刻发现哪些语句的游标，避免额外的消耗。
如果在一个应用中，有一些语句使用同样的文字标量而有一些语句改变文字标量，这非常的有用。
2. 应用程序发布不同结构的语句，因而没有任何相似语句
这样的应用默认使用硬解析，设置cursor_sharing为FORCE或SIMILAR会使硬解析更昂贵一些。
3. 没有使用绑定变量的应用，设置cursor_sharing为SIMILAR，大部分相似语句被次最优化共享
这样的应用默认采用硬解析，将cursor_sharing设为FORCE，大量使用软解析。设置cursor_sharing为SIMILAR，将使硬解析更昂贵一些。
使用FORCE
使用FORCE可能会导致一个非常坏的执行计划被使用。在有些情况下，坏的执行计划和好的执行计划之间的差异是非常重要的，如，DSS环境。因此，Oralce不推荐在这种情况下使用FORCE。上一页 [1] [2] [3] 下一页 |
