从10046 Trace RAW File看Cursor

游标共享Cursor是Oracle学习过程中的一个重点和难点。Oracle的Cursor是建立在对SQL解析Parse消耗的优化上的。根据不同的内存缓存

游标共享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文件之后，我们下面详细分析这个文件的细节。

更多详情见请继续阅读下一页的精彩内容：