库缓存的相关知识点有哪些？

共享游标
Sql第一次解析后，会生成父游标和子游标（DDL除外）。可共享的部分包括解析树、执行计划、绑定定义变量和sql文本等；
父游标主要保存游标名、sql文本，文本相同的sql可以共享；
子游标保存剩余信息，只有当执行计划/绑定变量/环境变量（NLS&优化模式）/共享实际引用对象一致时才能进行，否则会创建一个新的子游标；

硬解析：没有可重用的共享游标，只有父级是共享的 游标也是硬解析的;
软解析：复用父游标和子游标；
软解析：将关闭的会话游标缓存在PGA中。与软解析相比，省略了光标的打开/关闭，可以快速定位。库缓存中的共享游标；只被当前会话使用；

游标的生命周期
正常情况是打开-解析-绑定-执行– fetch – close
据此可以将应用程序分为4种
1不要使用绑定变量
每次执行都会经过open/close，游标无法复用。进行硬解析；设置cursor_sharing=force/similar使用软解析；
2使用绑定变量
每次执行都会经过open/close，游标可以复用，后续执行进行软解析；设置session_cached_cursors可以使用软解析，避免每次打开/关闭游标；
3打开一次+parse-bind-execute-fetch循环+关闭一次
开启HOLD_CURSOR=NO&RELEASE_CURSOR=NO options Oracle预编译器采用这种应用；每次都会执行软解析，但避免了游标的频繁切换；
4打开一次+解析+绑定+执行获取循环+关闭一次
设计良好的OCI或预编译器可能会使用此应用程序；设置cursor_space_for_time=true可以提高性能（11g中已废弃）

V$statname中如何优化软解析
会话游标缓存命中数/会话游标缓存计数/解析计数( Total) 分别表示会话游标缓存命中数/总缓存数/总解析数。当命中/总比很低时，说明软解析严重，软解析也需要库。 cacheatch；
1服务器：调整session_cache_cursor
2应用：重写pl/sql，采用上面第4种应用

库缓存
由KGL管理，采用哈希表结构，每个桶由一个句柄列表组成，每个句柄共同组成包含一系列堆，指向堆0；

锁定和固定
功能
库缓存锁管理进程之间的并发性，而库缓存引脚管理缓存一致性。
为了访问库缓存中的对象，进程必须首先锁定库缓存对象句柄，然后锁定对象数据堆本身。
获取库缓存锁也是定位的唯一方法缓存中的对象——进程在单个操作中定位并锁定对象。
如果进程想要实际检查或修改该对象，则它必须获取对象数据堆本身上的库缓存引脚（在获取之后）库缓存对象句柄上的库缓存锁。
锁保护句柄 pin 保护堆。如果要访问库缓存中的对象，必须先获取锁和 pin；
10202使用 mutex 替换游标的library cache pin；

模式
library cache lock和pin都是enqueue锁，
lock分为S 、X和null（光标只能使用null来保持依赖一致性），pin只有S和X；
/>软解析使用S pin，硬解析使用-continue.html
关于pin ,
X 请求 (3) 将被对象上持有 S 模式 (2) 的任何引脚阻止。
S 请求 (2) 将被持有的任何 X 模式 (3) 引脚阻止，或者可能会排队落后于其他一些故障，很容易导致库缓存 pin 等待；

pin 和 lock 都添加到句柄中；

Librarycachelatch：用于串行访问librarycache中的对象； lock不是原子操作，加锁前后都需要latch保护；
库缓存加载锁latch/库缓存加载锁——对象不在内存时无法加锁，需要加载第一的;前者阻止物体多次加载，前者直到分配加载锁才获得，后者负责将对象加载到内存中；

查找拦截者
选择
服务员。 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
来自
       br/>                                                                                      使用 using ' sp.kglpnhdl=waiter.p1raw
和 waiter.event in ( '库缓存 pin' 、 '库缓存锁定' 、 '库缓存加载锁定')
和 blocker_event.sid=blocker_session.sid
和 waiter.sid != blocker_event.sid
由服务员订购.p1raw,waiter.sid;

选择
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
来自 v$active_session_history ash, （从 v$rowcache 中选择cache#，参数名称） rc, all_objects o
其中 event='rowcache lock'
和 rc.cache#(+)=ash.p1
和 o。 object_id (+)= ash.CURRENT_OBJ#
和 ash.session_state='WAITING'
和 ash.sample_time > sysdate - & 分钟/(60*24)
按sample_time 排序；

这里分享了库缓存相关知识点问题的解答。 ，希望以上内容能够对大家有所帮助。如果您还有很多疑问没有得到解答，您可以关注行业资讯频道，了解更多相关知识。