ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 通过查询V$SQL_SHARED_CURSOR 得到详细关于子游标不能共享的原因

通过查询V$SQL_SHARED_CURSOR 得到详细关于子游标不能共享的原因

原创 Linux操作系统 作者:DataKW 时间:2013-07-01 19:43:25 0 删除 编辑
通过查询V$SQL_SHARED_CURSOR 得到详细关于子游标不能共享的原因
http://www.2cto.com/database/201204/126502.html
HASH_VALUE都相同,但是他们的子游标就不同了,这就会产生High Version Counts,由于HASH_VALUE相同,持有LATCH会不放,所以当PARSE的时候就会产生LATCH FREE。这是产生High Version的一个方面。另外正如大家前面所说的,数据库的BUG也会引发这个问题。至于第一个问题,可以通过查询V$SQL_SHARED_CURSOR 得到详细关于子游标不能共享的原因
父游标下子游标数:
select sql_id,count(0) from gv$sql group by sql_id order by 2 desc;
version_count对应子游标数:
select sql_id,sql_text,executions,version_count from gv$sqlarea where sql_id='a5fx6057fy9z4';
sql_id对应的子游标数和执行计划hash值(sql_id对应hash_value和address):
select sql_id,child_number,sql_text,optimizer_mode,plan_hash_value from gv$sql where sql_id='a5fx6057fy9z4';
查子游标不能共享(失效的原因,如optimizer_mode_mismatch,BIND_MISMATCH等原因)的原因:
select child_number,optimizer_mode_mismatch,BIND_MISMATCH  from gv$sql_shared_cursor where sql_id='a5fx6057fy9z4';
绑定失效的时候,查看一下每次绑定变量的值:
select position,LAST_CAPTURED,datatype_string,value_string from gv$sql_bind_capture where sql_id='a5fx6057fy9z4';
查历史sql的绑定值情况,是gv$sql_bind_capture的历史记录:
select * from dba_hist_sqlbind where  sql_id='a5fx6057fy9z4';
sql_id和sql_text关系:
select * from dba_hist_sqltext;
绑定变量字段长度变化的情况:
select * from DBA_HIST_SQL_BIND_METADATA where sql_id='a5fx6057fy9z4';
 不知道这两个东西是什么用途的:
select * from GV$SQL_BIND_DATA;
select * from GV$SQL_BIND_METADATA;
 
select * from v$fixed_table where name like '%BIND%';
select * from dict where table_name like '%BIND%';--很多视图在sys用户才能查到,比如dba_hist_sqlbind
select * from v$sql where sql_id='a5fx6057fy9z4';
select * from v$sql_shared_cursor where sql_id='a5fx6057fy9z4';
执行计划查看:
select * from v$sql_plan where sql_id='a5fx6057fy9z4';
v$sql_shared_cursor    bind_mismatch

http://hi.baidu.com/dba_gongchang/item/02da3f9cf8dd97ca1f42712e
可以看到由于bind_mismatch游标没有被共享,oracle认为绑定变量之间的值不一致。
BIND_MISMATCH VARCHAR2(1) (Y|N) The bind metadata does not match the existing child cursor
VERSION_COUNT NUMBER Number of child cursors that are present in the cache under this parent
 
由 bind_mismatch引起的 大量 version_count 问题
http://blog.csdn.net/tianlesoftware/article/details/6566658
 在v$sqlarea 中保存了SQL的cursor,当有大量的version_count,说明虽然SQL 语句相同,但是Oracle 发现因为某些原因不可重用这些SQL。当这类SQL执行次数很多,就会占用大量的shared pool,引起library cache pin和library cache 的等待事件。
bind_mismatch一般是由于bind value的长度不同导致bind buffer无法重用,最终导致cursor无法重用。
例如:对于字符类型的字段,进行绑定变量的时候,第一次会使用32字节的BUFFER,如果该值小于32字节的话,第二次执行这个SQL的时候,如果小于32字节,那么可以共享这个CURSOR,如果大于,就无法共享,原因就是BIND_MISMATCH,此时会产生一个子CURSOR,同时分配128字节的BIND BUFFER,以此类推。
 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/27573546/viewspace-765223/,如需转载,请注明出处,否则将追究法律责任。

下一篇: fuser 命令小结
请登录后发表评论 登录
全部评论

注册时间:2012-08-12

  • 博文量
    132
  • 访问量
    298651