WHERE sql_text LIKE 'insert into felix%';?

SQL_TEXT VERSION_COUNTPARSE_CALLS EXECUTIONS

-------------------------------- ------------------------ ----------

insert into felix values(9) 1 1 1

insert into felix values(5) 1 1 1

insert into felix values(8) 1 1 1

insert into felix values(1) 1 1 1

insert into felix values(4) 1 1 1

insert into felix values(6) 1 1 1

insert into felix values(3) 1 1 1

insert into felix values(7) 1 1 1

insert into felix values(2) 1 1 1

insert into felix values(10) 1 1 1

10 rows selected.?

重构测试表，进行第二次测试：?

scott@felix SQL>drop table felix purge;?

scott@felix SQL>create table felix (id number);?

begin

for i in1..10 loop

executeimmediate 'insert into felix values(:v1)' using i;

end loop;

commit;

end;

/?

对于该SQL，在共享池中只存在一份，解析一次，执行10次，这就是绑定变量的优势所在：

SELECT sql_text, version_count, parse_calls,executions

FROMv$sqlarea

WHEREsql_text LIKE 'insert into felix%';?

SQL_TEXT VERSION_COUNT PARSE_CALLSEXECUTIONS

-------------------------------- ------------------------ ----------

insert into felix values(:v1) 1 1 1?

在应用程序开发的过程中，都应该优先考虑使用绑定变量（在JAVA应用中可以使用PreparedStatement进行变量绑定），但是如果应用没有很好地使用绑定变量，那么Oracle从8.1.6开始提供了一个新的初始化参数用以在Server 端进行强制变量绑定，这个参数就是cursor_sharing。最初这个参数有两个可选设置：exact和force。

缺省值是exact，表示精确匹配；force表示在Server端执行强制绑定。在8i的版本里使用这个参数对某些应用可以带来极大的性能提高，但是同时也存在一些副作用，比如优化器无法生成精确的执行计划，SQL执行计划发生改变等（所以如果启用cursor_sharing参数时，一定确认用户的应用在此模式下经过充分的测试）。?

从Oracle 9i开始，Oracle引入了绑定变量Peeking的机制，SQL在第一次执行时，首先在Session的PGA中使用具体值生成精确的执行计划，以期可以提高执行计划的准确性，然而Peeking的方式只在第一次硬解析时生效，所以仍然可能存在问题，导致后续的SQL错误的执行；同时，在Oracle 9i中，cursor_sharing参数有了第3个选项：similar。该参数指定Oracle在存在柱状图信息时，对于不同的变量值，重新解析，从而可以利用柱状图更为精确地制定SQL执行计划。也即当存在柱状图信息时，similar的表现和exact相同；当柱状图信息不存在时，similar的表现和force相同。

除了Bug之外，在正常情况下，由于Similar的判断机制，可能也会导致SQL无法共享。在收集了柱状图（Hisogram）信息之后，如果SQL未使用绑定变量，当SQL使用具备柱状图信息的Column时，数据库会认为SQL传递过来的每个常量都是不可靠的，需要为每个SQL生成一个Cursor，这种情况被称为UNSAFE BINDS。大量的Version_Count可能会导致数据库产生大量的cursor: pin S wait on X等待。解决这类问题，可以设置CURSOR_SHARING为Force或者删除相应字段上的柱状图信息。

1.2.7.3 使用Flush Shared Pool缓解共享池问题

一种应急处理方法，强制刷新共享池。

alter system flushshared_pool;

刷新共享池可以帮助合并碎片（smallchunks）， 强 制 老 化SQL，释放共享池，但是这通常是不推荐的做法，这是因为：

（1）Flush Shared Pool会导致当前未使用的cursor被清除出共享池，如果这些SQL随后需要执行，那么数据库将经历大量的硬解析，系统将会经历严重的CPU争用，数据库将会产生激烈的Latch竞争。

（2）如果应用没有使用绑定变量，大量类似SQL不停执行，那么Flush Shared Pool可能只能带来短暂的改善，数据库很快就会回到原来的状态。

（3）如果Shared Pool很大，并且系统非常繁忙，刷新Shared Pool可能会导致系统挂起，对于类似系统尽量在系统空闲时进行。?

1.2.7.4 SHARED_POOL_RESERVED_SIZE参数的设置及作用?

shared_pool_reserved_size，该参数指定了保留的共享池空间，用于满足将来的大的连续的共享池空间请求。当共享池出现过多碎片，请求大块空间会导致Oracle 大范围的查找并释放共享池内存来满足请求，由此可能会带来较为严重的性能下降，设置合适的shared_pool_reserved_size参数，结合shared_pool_reserved_min_alloc参数可以用来避免由此导致的性能下降。?

这个参数理想值应该大到足以满足任何对RESERVED LIST的内存请求，而无需数据库从共享池中刷新对象。这个参数的缺省值是shared_pool_size 的5%，通常这个参数的建议值为shared_pool_size参数的10%～20%大小，最大不得超过shared_pool_size的50%。?

shared_pool_reserved_min_alloc这个参数的值控制保留内存的使用和分配。如果一个足够尺寸的大块内存请求在共享池空闲列表中没能找到，内存就从保留列表（RESERVED LIST）中分配一块比这个值大的空间。

如果你的系统经常出现的ORA-04031错误都是请求大于4400的内存块，那么就可能需要增加shared_pool_reserved_size参数设置。?