共計 3508 個字符，預計需要花費 9 分鐘才能閱讀完成。
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.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 相關知識點有哪些問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注丸趣 TV 行業資訊頻道了解更多相關知識。
