简单分析shared pool(三) (r5笔记第94天)

提到shared pool，都会不由得和sql语句的解析过程联系起来，因为shared pool所做的主要工作就是解析sql语句，生成执行计划，在之前的两篇中对于shared pool的存储进行了简单的分析，在10g，11g都是保留了255个bucket，可见这个值还是一个最优的默认值了。在第二篇中分析了一些关于绑定变量的内容，一般一提到sql语句的解析，都会多多少少提到绑定变量，其实有时候也给我们带来一些困扰，其实直接使用绑定是一种情况，还可以通过其它的方式间接使用。比如下面的例子。 declare cursor test_cur is select object_id,object_name from t ; begin for i in test_cur loop insert into t values(i.object_id,i.object_name); end loop; commit; end; / 我们在pl/sql中使用游标的方式，可能我们都没有意识到我们已经在使用了。不过还有一个细节之处就是在pl/sql里面直接调用sql语句的时候， shared pool里都是转换成大写来处理的。

select  hash_value,sql_id,child_latch,version_count,sql_text,parse_calls from v$sqlarea
  where sql_text like 'INSERT%';

HASH_VALUE SQL_ID        CHILD_LATCH  VERSION_COUNT SQL_TEXT  PARSE_CALLS
---------- ------------- -----------  ------------- --------------------
1681598159 c0rddkpk3q9qg            3             1 INSERT INTO T  VALUES(:B2 ,:B1 )    1

如果在另一种场景中使用绑定变量的方式，结果会略有不同 declare cursor test_cur is select object_id,object_name from t ; begin for i in test_cur loop execute immediate 'insert into t values(:a,:b)' using i.object_id,i.object_name; end loop; commit; end; / 使用下面的语句就不会得到需要的信息了。

select  hash_value,sql_id,child_latch,version_count,sql_text,parse_calls from v$sqlarea  where sql_text like 'INSERT%'

而是需要使用

select  hash_value,sql_id,child_latch,version_count,sql_text,parse_calls from v$sqlarea  where sql_text like 'insert%'
HASH_VALUE SQL_ID        CHILD_LATCH  VERSION_COUNT SQL_TEXT PARSE_CALLS
---------- ------------- -----------  ------------- --------------------
4026877341 54wqkdbs0ajcx            1             1 insert into t values  (:a,:b)     1

得到的sql_id也会大大不同。如果更近一步我们再来考虑一些额外的影响，我们会发现同样的sql语句在不同的上下文环境中还会有一些不同，因为在cursor_sharing=EXTRACT的默认模式下反复尝试，Oracle都处理的很好，不会产生大量的child cursor。为了验证，我们只好动用一些其他的方法，比如修改优化器的一些默认配置，使得两条sql语句运行中的上下文环境会一些明显的不同。

SQL>  alter system flush shared_pool;  --先来刷新shared pool
System altered.
SQL> alter session set optimizer_index_caching=100  ; --然后修改这个优化器参数
Session altered.
SQL> select hash_value,sql_id,version_count,parse_calls,sql_text from  v$sqlarea where sql_text like 'select sum(object_id) from test.test%';  --sql语句还么有运行，所以没有任何记录
no rows selected
SQL> select sum(object_id) from test.test;  --引用了sum函数，使得优化器参数生效
SUM(OBJECT_ID)
--------------
      20545604

这个时候去查看父游标的信息，发现version_count只有一个

SQL>  select hash_value,sql_id,version_count,parse_calls,sql_text from  v$sqlarea where sql_text like 'select sum(object_id) from test.test%';
HASH_VALUE SQL_ID        VERSION_COUNT PARSE_CALLS    SQL_TEXT
--------------------------------------------------------------------------------
4120698675  afrus1buttrtm             1           1       select sum(object_id) from  test.test

然后我们修改优化器参数，运行同样的sql语句

SQL>  alter session set  optimizer_index_caching=60;
Session altered.
SQL> select sum(object_id) from test.test;
SUM(OBJECT_ID)
--------------
       20545604

这个时候会发现还是出现了不同之处。version_count变为了2

SQL>  select hash_value,sql_id,version_count,parse_calls,sql_text from  v$sqlarea where sql_text like 'select sum(object_id) from test.test%';
HASH_VALUE SQL_ID        VERSION_COUNT PARSE_CALLS   SQL_TEXT
--------------------------------------------------------------------------------
4120698675  afrus1buttrtm             2           2    select sum(object_id) from  test.test

如果这个时候查看子游标的信息，就会发现child_number会有2个。这也是我们希望看到的不同之处。


SQL>  select child_address,hash_value,sql_id,child_number from v$sql where  hash_value='4120698675';

CHILD_AD HASH_VALUE SQL_ID        CHILD_NUMBER
-------- ----------  ------------- ------------
2F155C88 4120698675 afrus1buttrtm             0
2F3A26D8 4120698675 afrus1buttrtm             1

总结一下，在sql语句的执行中，cursor是一个很重要的概念，可能会贯穿整个shared pool的各个层面，通过一些补充的实验可以验证我们原本固有的思想，可能会发现绑定变量在特定的场景下使用效果是很明显的，有时候我们可能都没有意识到本身就在使用。