librarycache相关知识点有哪些
library cache相关知识点有哪些,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
创新互联建站从2013年开始,是专业互联网技术服务公司,拥有项目成都网站设计、网站制作网站策划,项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命,1280元蒲县做网站,已为上家服务,为蒲县各地企业和个人服务,联系电话:18982081108
共享游标
Sql首次解析后会生成父游标和1个子游标(DDL除外),其可共享的部分包括解析树,执行计划,绑定变量和sql文本等;
父游标主要保存游标名即sql text,文本一致的sql即可共享;
子游标保存剩余信息,只有当执行计划/绑定变量/环境变量(NLS & optimization mode)/实际引用对象一致时才可共享,否则新建1个子游标;
硬解析:没有可重用的共享游标,仅仅共享父游标也是硬解析;
软解析:重用父游标和子游标;
软软解析:缓存PGA中关闭的session cursor,相比软解析省去了游标open/close,同时可快速定位library cache中的共享游标;仅供当前session使用;
游标的生命周期
正常情况为open – parse – bind – execute – fetch - close
而应用据此可分4种类型
1 不使用绑定变量
每次执行都经历一遍open/close,游标不可重用,每次都进行硬解析;设置cursor_sharing=force/similar可使用软解析;
2 使用绑定变量
每次执行都经历一遍open/close,游标可重用,后续执行进行软解析;设置session_cached_cursors可使用软软解析,而且避免每次都open/close游标;
3 open once + parse-bind-execute-fetch loop + close once
开启HOLD_CURSOR=NO & RELEASE_CURSOR=NO选项的oracle precompilers采用此种应用;每次都执行软解析,但避免了频繁的开关游标;
4 open once + parse + bind + execute-fetch loop + close once
设计良好的OCI或precompiler可能采用此应用;设置cursor_space_for_time=true可提升性能(11g废弃)
如何优化软解析
V$statname中的session cursor cache hits/session cursor cache count/parse count (total)分别代表会话游标缓存命中次数/缓存总数/解析总数,当hits/total比例很低时说明软解析很严重,而软解析同样需要library cache latch;
1 服务器: 调整session_cache_cursor
2 应用: 改写pl/sql,采用上述第4种类型的应用
Library cache
由KGL管理,采用哈希表结构,每个bucket由handle链表组成,每个handle包含一系列heap,其指向heap 0;
Handle存储有对象名/命名空间/标志位
Lock & Pin
作用
Library cache lock manages concurrency between processes, whereas library cache pin manages cache coherence。
In order to access an object in library cache, a process must first lock the library cache object handle, and then pin the object data heap itself.
Acquiring a library cache lock is also the only way to locate an object in cache—a process locates and locks an object in a single operation.
If the process wants to actually examine or modify the object, then it must acquire a library cache pin on the object data heap itself (after acquiring a library cache lock on the library cache object handle.
lock保护handle pin保护heap,要想访问library cache中的对象必须先后获取lock和pin;
10202采用mutex替换了针对cursor的library cache pin;
模式
Library cache lock和pin都是enqueue锁,
lock分为S,X和null(cursor只能用null维护依赖一致性),pin只有S和X;
软解析使用S pin,硬解析使用X pin;无论硬解析还是软解析,cursor只是用null lock;可使用10049跟踪http://www.dbsnake.net/library-cache-pin-and-lock-continue.html
关于pin,
An X request (3) will be blocked by any pins held S mode (2) on the object.
An S request (2) will be blocked by any X mode (3) pin held, or may queue behind some other X request.
X pin会让null lock失效,相应cursor必须重新解析方可再次运行,即如果对表作DDL相应游标都会失效,极容易爆发library cache pin等待;
pin和lock都是添加于handle之上的;
Library cache latch:用于串行访问library cache中的对象;lock并非原子操作,上锁前后需要latch保护;
Library cache load lock latch/library cache load lock—对象不在内存时无法lock,此时需先加载;前者避免对象被多次加载,先获取前者直到load lock被分配,由后者负责将对象加载至内存;
找出blocker
select
waiter.sid waiter,
waiter.event wevent,
to_char(blocker_event.sid)||','||to_char(blocker_session.serial#) blocker,
substr(decode(blocker_event.wait_time, 0, blocker_event.event, 'ON CPU'),1,30) bevent
from
x$kglpn p,
gv$session blocker_session,
gv$session_wait waiter,
gv$session_wait blocker_event
where
p.kglpnuse=blocker_session.saddr
and p.kglpnhdl=waiter.p1raw
and waiter.event in ( 'library cache pin' , 'library cache lock' , 'library cache load lock')
and blocker_event.sid=blocker_session.sid
and waiter.sid != blocker_event.sid
order by waiter.p1raw,waiter.sid;
select
ash.session_id sid,
ash.blocking_session bsid,
nvl(o.object_name,to_char(CURRENT_OBJ#)) obj,
o.object_type otype,
CURRENT_FILE# filen,
CURRENT_BLOCK# blockn,
ash.SQL_ID,
nvl(rc.name,to_char(ash.p3)) row_cache
from v$active_session_history ash, ( select cache#, parameter name from v$rowcache ) rc, all_objects o
where event='row cache lock'
and rc.cache#(+)=ash.p1
and o.object_id (+)= ash.CURRENT_OBJ#
and ash.session_state='WAITING'
and ash.sample_time > sysdate - &minutes/(60*24)
Order by sample_time;
关于library cache相关知识点有哪些问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注创新互联行业资讯频道了解更多相关知识。
新闻名称:librarycache相关知识点有哪些
当前地址:http://hbruida.cn/article/igiego.html