library cache相关知识点有哪些

library cache相关知识点有哪些，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

共享游标

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-/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相关知识点有哪些问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注行业资讯频道了解更多相关知识。