shared pool latch/ library cache latch /lock pin介绍

latch:library cache --desc v$librarycache;

latch:library cache用于保护hash bucket.

library cache lock保护HANDLE。

library cache pin保护library cache object--LCO.

从10G开始,library cache lock和library cache pin被MUTEX部分取代。暂时不讨论MUTEX。

latch:library cache的数量:

SYS@ bys3>select name from v$latch_children where name like '%librarycache%';

隐含参数:_kgl_bucket_count,默认值大于等于系统中CPU个数的最小素数-不超过67。查询时会显示为0--BUG。

一个latch:library cache管理着多个librarycache buckets.

latch:library cache多是因为局部latch:library cache访问比较频繁,增大其数量并不能解决。

如果shared pool过小,也会引发librarycache latch竞争,进而引起shared pool latch竞争---参考AWR--Shared Pool Advisory

具有高version_count的SQL也容易导致latch:library cache,因为在搜索到子LCO前会一直持有latch:library cache。

#########

library cache lock保护HANDLE--父游标和子游标的handle

在硬解析时,需要以独占模式(EXCLUSIVE)持有librarycache lock和library cache pin。

进程访问LCO,首先需要在latch:librarycache的保护下获得library cache lock,才能访问和修改HANDLE;然后获取library cache pin,才能访问和LCO。

子游标的HANDLE和LCO的访问和上面一样。

MODE有三类: null 1;shared 2;exclusive 3;  

null 1;空锁:空锁和独占锁互相不阻塞,主要起“标记”目的。标记对象正在使用中,或者标记对象以后还会用。保证对象内存不会被覆盖或释放。--可以执行三次,查看

查看本栏目更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/database/storage/

select kglhdadr,kglhdpar,kglhdlmd,kglobhs0,kglobhd0,kglobhd6 from x$kglob wherekglnaobj like 'select * from aaa';

查看游标是否关闭。执行不大于3次,不会缓存,如有其它语句,则将未缓存的清空。

select * from bys.dept 执行三次,

SYS@ bys3>select kglhdadr,kglhdpar,kglhdlmd,kglhdpmd,kglobhs0,kglobhd0,kglobhd6from x$kglob where kglnaobj like 'select * from bys.dept';

KGLHDADR KGLHDPAR   KGLHDLMD   KGLHDPMD  KGLOBHS0 KGLOBHD0 KGLOBHD6

-------- -------- ---------- ---------- ---------- -------- --------

2499B1C0 24965DB4         1        0       4372 246C5CE0 252F0DD0 ----被缓存的子游标,

24965DB4 24965DB4         1         0       4500 23CC848C 00

被缓存的游标:当内存不足时,子游标堆6可以被覆盖,其它HADNLE等不可被覆盖。--原因是:重建执行计划的信息--父堆0,子堆0等都有可以快速重建执行计划-也算硬解析,但是消耗资源比正常硬解析少。

等待事件的P1 P2 P3分别是:

P1=HANDLE ADDRESS

P2=LOCK/PIN ADDRESS

PS=MODE*100+NAMESPACE

NAMESPACE分以下类型:

1.SQL AREA

2.TABLE/PROCEDURE/FUNCTION/PACKAGE HEADER

3.PACKAGE BADY

4.TRIGGER

5.INDEX

6.CLUSETER

7.PIPE

13.JAVA SOURCE

14.JAVE RESOURCE

32.JAVA DATA

常见的library cache lock持有模式的情况:

以独占持有的语句是:

ALTER TABLE……,

CREATE OR REPLACE PROCEDURE;

共享模式持有:SQL解析阶段

在SQL执行阶段,由共享模式转换为NULL。

定位引起library cache lock等待事件的语句:

select b.sid from x$kgllk a,v$session b where a.kgllkhdl in (select p1raw fromv$session_wait where wait_time=0 and event='library cache lock') and a.kgllkmod<>0and b.saddr=a.kgllkuse;

常见的library cache pin持有模式的情况:

以独占模式持有的是:

ALTER PROCEDURE ..COMPLE;

硬解析产生执行计划过程中需要

以共享模式持有的是:SQL执行阶段、PROCEDURE执行阶段。

定位引起library cache pin等待事件的会话:

select a.sid from x$kglpn b,v$session a where b.kglpnhdl in (select c.p1rawfrom v$session_wait c where c.wait_time=0 and c.event like 'library cachepin%') and b.kglpnmod<>0 and a.saddr=b.kglpnuse;

时间: 2024-08-31 06:27:24

shared pool latch/ library cache latch /lock pin介绍的相关文章

[转载】&amp;mdash;&amp;mdash;故障排除:Shared Pool优化和Library Cache Latch冲突优化 (文档 ID 1523934.1)

原文链接:https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrlstate=23w4l35u5_4&id=1523934.1用途   提出问题,得到帮助并分享您的心得   排错步骤   什么是shared pool?   专用术语   Literal SQL   Hard Parse(硬解析)   Soft Parse(软解析)   完全相同的语句?   Sharable SQL   语句的版本   Library Cac

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列4

CURSOR_SHARING 参数 (8.1.6 以上)        这个参数需要小心使用.如果它被设为FORCE,那么Oracle会尽可能用系统产生的绑定变量来替换原来SQL中的literals部分.对于很多仅仅是literal不一样的相似的语句,这会让它们共享cursor.这个参数可以在系统级别或者session级别动态设置: ALTER SESSION SET cursor_sharing = FORCE; 或者 ALTER SYSTEM SET cursor_sharing = FOR

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列1

什么是Shared Pool?        Oracle的实例主要包括共享内存(主要是SGA,还有PGA)和Background Processes,其中SGA中又包括了Shared Pool.Buffer Cache.Redo Log Buffer以及其它一些内存区.        Oracle在SGA的一个特定区域中保留SQL语句.Package是.对象信息以及其它一些内容,这就是Shared Pool.这个共享内存区域是由一个复杂的cache和heap manager 构成的.它需要解决

shared pool latch和library cache latch

shared pool latch和library cache latch    >                                   >                                                                                                                                                                           

ASMM 导致的latch: library cache 和latch: shared pool

核心系统故障及调整报告核心系统数据库在2012年7月13日下午2点到4点和2012年7月16上午11点出现了高负载,影响了核心系统的正常使用,我随即进行了性能分析.得出报告如下:2012年7月13日 Snap Id Snap Time Sessions Cursors/SessionBegin Snap: 28264 13-Jul-12 14:00:26 173 14.3End Snap: 28265 13-Jul-12 15:00:17 189 15.0Elapsed:   59.84 (mi

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列5

Flushing(清空) SHARED POOL        在使用大量literal SQL的系统中,shared pool随时间推移会产生大量碎片进而导致并发能力的下降.Flushing shared pool能够使得很多小块碎片合并,所以经常能够在一段时间内恢复系统的性能.清空之后可能也会产生短暂的性能下降(补充:因为需要做第一次的硬解析),因为这个操作同时也会把没造成shared pool碎片的共享SQL也清除了.清空shared pool的命令是: ALTER SYSTEM FLUS

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列2

下面来谈一谈系列1中讲到的Literal SQL和Shared SQL的比较. 首先是Literal SQL: 在有完整的统计信息并且SQL语句在predicate(限定条件)中使用具体值时,基于成本的优化器 (CBO)能工作的最好.比较下面 的语句: SELECT distinct cust_ref FROM orders WHERE total_cost < 10000.0; 和 SELECT distinct cust_ref FROM orders WHERE total_cost <

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列3

减轻Shared Pool负载 Parse一次并执行多次        在OLTP类型的应用中,最好的方法是只让一个语句被解析一次,然后保持这个cursor的打开状态,在需要的时候重复执行它.这样做的结果是每个语句只被Parse了一次(不管是soft parse还是hard parse).显然,总会有些语句很少被执行,所以作为一个打开的cursor维护它们是一种浪费.        请注意一个session最多只能使用参数:open_cursors定义的cursor数,保持cursor打开会增加

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列6

使用SQL 查看Shared Pool问题        这一章节展示了一些可以用来帮助找到shared pool中的潜在问题的SQL语句.这些语句的输出最好spool到一个文件中. 注意:这些语句可能会使latch竞争加剧,我们在上面的"使用 V$ 视图 (V$SQL 和 V$SQLAREA)" above. 查找literal SQL SELECT substr(sql_text,1,40) "SQL",                count(*) ,