游标共享cursor是oracle学习过程中的一个重点和难点。oracle的cursor是建立在对sql解析parse消耗的优化上的。根据不同的内存缓存结构，我们经常可以听到诸如：硬解析hard parse、软解析soft parse和软软解析的名词概念。
严格的说，游标共享的概念基础是游标。oracle中，游标可以分为shared cursor和private cursor两个大的类型。理解游标的前提，一定要区分出这两个游标类型。
oracle 自适应游标共享--adaptive cursor sharing
oracle 11g新sql trace 10046方法
1、shared and private cursor
shared cursor大家谈的比较多，就是驻留在library cache里面的缓存对象，其中保存着之前解析好的执行计划。当一个sql语句第一次出现在系统中，oracle在library cache中没有找到对应的“现成”执行计划，就会启动硬解析hard parse过程，在library cache中生成一个shared cursor。注意：这个sql cursor可以被其他“符合游标共享条件”的其他会话session共享。在没有被age out或者flush出内存前，都是可以共享。如果第二次发出相同sql语句，共享了shared cursor，我们称之为soft parse。
而与shared cursor对应的就是private cursor。private cursor是驻留在server process的pga空间里的。当我们发出sql或者手工创建一个cursor，都会在server process对应的pga空间里创建出一个private cursor对象。
顾名思义，private cursor的含义是只能被当前session使用，不能实现session间共享。但是，相同一个session，如果多次执行，是不是需要多次的创建private cursor呢？这个过程涉及到的问题就是private cursor的共享问题。
我们在一些资料里面可以看到一些混淆概念。说一个sql只有执行三次之上，才能进行共享。如果我们进行简单的实验，就可以发现这个论断在shared cursor中并不成立。一旦sql执行一次，在library cache中会去生成shared cursor，何来三次之说？应该说，这个论断前提是private cursor共享。
2、软软解析和参数配置
我们接触很多的概念是“hard parse”和“soft parse”。两者的差异在于是否在library cache中发生执行计划生成的动作。如果我们将private cursor因素考虑进去之后，就会有一个新的解析类型“软软解析”。
即使是soft parse，我们在pga里面，每次执行sql的时候都会有private cursor的创建过程。按照cursor生命周期，当cursor执行结束之后，会有一个close动作将private cursor失效。oracle是可以尝试对private cursor进行缓存，也就是说，close动作并不是真正关闭消失，而是可以支持共享private cursor。
如果可以实现private cursor在pga中的重用，我们是可以将pga中创建cursor的部分成本消除掉。实现所谓的软软解析。
从oracle早期开始，我们接触过一个参数为open_cursor。最初这个参数起到两个层面作用，其一是控制一个会话可以同时打开的最大cursor数量，另一个是控制了pga里面能够共享private cursor缓存的最大个数。
之后oracle的设置出现了一些变化，引入了新参数session_cached_cursors，单独进行缓存区大小的限制。目前笔者实验的版本中，，这个参数是50。
sql> show parameter cached
name type value
------------------------------------ ----------- ---------------
session_cached_cursors integer 50
对于pga里面的private cursor共享情况，oracle会记录生成的次数。当执行三次的时候，就会建立pga内部缓存的结构机制。
本篇中我们使用10046来验证上面提到的机制。
3、环境准备
我们先找一个10046的trace文件作为实验对象。选择11.2.0.3作为实验对象。
sql> select value from v$diag_info where;
value
--------------------------------------------------------------------
/u01/app/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_6964.trc
清空shared pool和buffer cache，执行相同的sql语句10次。
sql> alter system flush shared_pool;
系统已更改。
sql> alter system flush buffer_cache;
系统已更改。
sql> alter session set events '10046 trace name context forever, level 12';
会话已更改。
sql> select count(*) from t;
count(*)
----------
0
sql> select count(*) from t;
count(*)
----------
0
（其余执行次数略……）
sql> alter session set events '10046 trace name context off';
会话已更改。
sql>
生成了trace文件之后，我们下面详细分析这个文件的细节。
更多详情见请继续阅读下一页的精彩内容：