深入理解shared pool共享池之library cache的library cache pin系列三
关于library cache相关的LATCH非常多，名称差不多，我相信一些人对这些概念还是有些晕，我之前也有些晕，希望此文可以对这些概念有个更为清晰的理解，本文主要学习library cache pin
前期相关文章
http://blog.itpub.net/9240380/
结论
1,library cache pin是用于并发的一种特殊锁，它不是LATCH
2,library cache pin适用于正在执行存储过程时，不能同时去编译存储过程，后者则会产生此等待事件，目的即防止并发修改存储过程的定义
3,library cache pin的分析可采用如下脚本：
整合下上述的SQL为一个SQL，便于运维使用,直接查出造成library cache pin的原凶
SQL> select sid,serial#,event,v$sql.sql_id,v$sql.sql_text from dba_kgllock,v$session,v$sql where kgllktype='Pin' and kgllkmod<>0 and dba_kgllock.kgllkuse=v$session.saddr and v$session.sql_id=v$sql.sql_id;
SID SERIAL# EVENT SQL_ID SQL_TEXT
---------- ---------- ------------------------------ ------------- --------------------------------------------------
116 153 SQL*Net message from client 6t5v50dgh7paq SELECT COUNT(1) FROM T_LOCK_TEST
4，如果产生了library cache pin，是基于存储过程对应的library cache bucket,
同时会在BUCKET中产生PIN OWNER及PIN WAITER，否则会消失
通过pin waiter及pin owner结合v$session及dba_kgllock可以定位PIN的持有者及等待者
5,所以在业务高峰期间，一实不要执行编译存储过程的工作
6,dba_kgllock不止记录pin也记录lock,关于dba_kgllock含义请见官方手册
7,library cache pin不会在v$lock及dba_dml_locks和dba_waiters,dba_blockers出现相关任何信息
可见不同的字典适用于不同的场景，一定要深入理解这些字典的用途
测试
----oracle version
SQL> select * from v$version where rownum=1;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
----与library cache相关的latch，概念极为容易迷惑人
SQL> select latch#,name from v$latch where lower(name) like '%library cache pin%';
LATCH# NAME
---------- ------------------------------
220 library cache pin allocation
219 library cache pin
---与library cache相关的锁，有控制并发访问lco,lco内容的，控制跨节点访问lco的失效的
SQL> select type,name,id1_tag,id2_tag,is_user,description from v$lock_type where lower(name) like '%library%';
TYPE NAME ID1_TAG ID2_TAG IS_ DESCRIPTION
-------------------- ------------------------------ ------------------------------ -------------------- --- ----------------------------------------------------------------------
V Library Cache Lock 3 hash value hash value NO Synchronizes accesses to library cache objects
E Library Cache Lock 2 hash value hash value NO Synchronizes accesses to library cache objects
L Library Cache Lock 1 hash value hash value NO Synchronizes accesses to library cache objects
Y Library Cache Pin 3 hash value hash value NO Synchronizes accesses to the contents of library cache objects
G Library Cache Pin 2 hash value hash value NO Synchronizes accesses to the contents of library cache objects
N Library Cache Pin 1 hash value hash value NO Synchronizes accesses to the contents of library cache objects
IV Library Cache Invalidation object # time stamp NO Synchronizes library cache object invalidations across instances
7 rows selected.
---library cache lock模拟小记
http://blog.itpub.net/9240380/viewspace-759281/,可见是如果某对象正在执行时，会对其对象相引用的对象加library cache lock
SQL> select latch#,name from v$latch_children where lower(name) like '%library cache lock%';
LATCH# NAME
---------- ------------------------------
218 library cache lock
218 library cache lock
218 library cache lock
218 library cache lock
218 library cache lock
218 library cache lock
218 library cache lock
218 library cache lock
218 library cache lock
218 library cache lock
218 library cache lock
---library cache lock的含义，引自官方手册 Oracle? Database Reference 11g Release 2 (11.2)之Descriptions of Wait Events
library cache lock含义
1,用于并发控制对于library cache的访问，在library cache 的library cache handle加锁，这个目的：
a,防止同一时间只能一个应用访问相同的对象
b,确保在一个操作的既定时间内，确保相互信赖对象的一致性，即确保依赖对象不能被修改
c,同时会持一个锁用于library cache object
library cache lock的参数
handle address 加载的对象地址
lock address 加载的锁地址，它不是正常的哪个锁或LATCH，它是一个状态对象
mode 指定加载对象是以何种模式加载
namespace 命名空间
namespace
The name of the object namespace as it is displayed in V$DB_OBJECT_CACHE view.
name and type
The name or "type" of the enqueue or global lock can be determined by looking at the two high order bytes of P1 or P1RAW. The name is always two characters. Use the following SQL statement to retrieve the lock name.
select chr(bitand(p1,-16777216)/16777215)||
chr(bitand(p1,16711680)/65535) "Lock"
from v$session_wait
where event = 'DFS enqueue lock acquisition';
---namespace的信息源自v$db_object_cache,也可以直观理解不同的对象类型，当然不完全一致
SQL> select distinct namespace from v$db_object_cache order by 1;
NAMESPACE
----------------------------
BODY
CLUSTER
CURSOR
INDEX
INVALID NAMESPACE
PUB_SUB
RSRC CONSUMER GROUP
RSRC PLAN
RULESET
STORED OUTLINE
SUBSCRIPTION
NAMESPACE
----------------------------
TABLE/PROCEDURE
TRIGGER
13 rows selected.
可见如下前者是latch地址,后者是library cache handle address,到底有何区别呢
SQL> select name,parameter1,parameter2,parameter3,wait_class from v$event_name where lower(name) like '%library cache lock%';
NAME PARAMETER1 PARAMETER2 PARAMETER3 WAIT_CLASS
------------------------------ ------------------------------ ------------------------------ ------------------------------ --------------------
latch: library cache lock address number tries Concurrency
library cache lock handle address lock address 100*mode+namespace Concurrency
---为了直观分析，形成测试用例
SQL> select sid from v$mystat where rownum=1;
SID
----------
116
SQL> create table t_lock_test(a int,b int);
Table created.
SQL> insert into t_lock_test select level,level from dual connect by level<=1500000;
1500000 rows created.
SQL> commit;
Commit complete.
SQL> insert into t_lock_test select level,level from dual connect by level<=1500000;
1500000 rows created.
SQL> commit;
Commit complete.
SQL> insert into t_lock_test select level,level from dual connect by level<=1500000;
1500000 rows created.
SQL> commit;
Commit complete.
SQL> create or replace procedure proc_hard_parse
2 as
3 v_cnt pls_integer;
4 begin
for i in 1..100000000 loop
6 select count(1) into v_cnt from t_lock_test;
7 end loop;
8 end;
9 /
Procedure created.
SQL> exec proc_hard_parse;
SQL> select sid from v$mystat where rownum=1;
SID
----------
121
SQL> alter procedure proc_hard_parse compile;
hang住
--从这里可见library cache pin的p1text可见它不是latch
SQL> select sid,event,p1text,p2text,p3text,wait_class from v$session_wait where sid in (116,121);
SID EVENT P1TEXT P2TEXT P3TEXT WAIT_CLASS
---------- ------------------------------ ------------------------------ ------------------------------ ------------------------------ -------------------------
116 SQL*Net message from client driver id #bytes Idle
121 library cache pin handle address pin address 100*mode+namespace Concurrency
SQL> select sid,event,p1,p2,p3 from v$session_wait where sid in (116,121);
SID EVENT P1 P2 P3
---------- ------------------------------ ---------- ---------- ----------
116 SQL*Net message from client 1650815232 1 0
121 library cache pin 2739958280 2663017760 301
可见library cache pin不是锁
SQL> select sid,type,id1,id2,lmode,request from v$lock where sid in (121,116);
no rows selected
通过dba_ddl_locks可以查询出相关的信息,可见在测试的存储过程上加了排它锁，但是通过dba_ddl_locks查不出到底什么原因引发了library cache pin
SQL> select session_id,name,type,mode_held,mode_requested from dba_ddl_locks where session_id in (116,121) and name='PROC_HARD_PARSE';
SESSION_ID NAME TYPE MODE_HELD MODE_REQU
---------- ------------------------------ ---------------------------------------- --------- ---------
116 PROC_HARD_PARSE Table/Procedure/Type Null None
121 PROC_HARD_PARSE Table/Procedure/Type Exclusive None
SQL> select count(*) from dba_dml_locks;
COUNT(*)
----------
0
SQL> select count(*) from dba_waiters;
COUNT(*)
----------
0
SQL> select count(*) from dba_blockers;
COUNT(*)
----------
0
---查看与LOCK相关的字典，想办法找到产生这个library cache pin的源头是什么
SQL> select table_name from dict where lower(table_name) like '%lock%';
TABLE_NAME
------------------------------
DBA_KGLLOCK
DBA_LOCK
DBA_LOCK_INTERNAL
DBA_DML_LOCKS
DBA_DDL_LOCKS
SQL> desc dba_kgllock;
Name Null? Type
----------------- -------- ------------
KGLLKUSE RAW(8)
KGLLKHDL RAW(8)
KGLLKMOD NUMBER
KGLLKREQ NUMBER
KGLLKTYPE VARCHAR2(4)
SQL> select kgllkuse,kgllkhdl,kgllkmod,kgllkreq,kgllktype from dba_kgllock where rownum<=1;
KGLLKUSE KGLLKHDL KGLLKMOD KGLLKREQ KGLL
---------------- ---------------- ---------- ---------- ----
00000000A4748578 00000000A3AE6128 1 0 Lock
---转化上述的library cache pin的p1text,即handle address
SQL> select to_char('2739958280','xxxxxxxx') from dual;
TO_CHAR('
---------
a3507208
经查官方手册可见kgllkuse即会话的地址
SQL> select kgllkuse,kgllkhdl,kgllkmod,kgllkreq,kgllktype from dba_kgllock where kgllkhdl='00000000A3507208';
KGLLKUSE KGLLKHDL KGLLKMOD KGLLKREQ KGLL
---------------- ---------------- ---------- ---------- ----
00000000A4726CC0 00000000A3507208 1 0 Lock
00000000A472D818 00000000A3507208 3 0 Lock
00000000A472D818 00000000A3507208 0 3 Pin --等待pin
00000000A4726CC0 00000000A3507208 2 0 Pin --持有pin
SQL> select sid,saddr from v$session where sid in (116,121);
SID SADDR
---------- ----------------
116 00000000A4726CC0
121 00000000A472D818
查询持pin的会话及SQL
SQL> select sid,serial#,sql_id from v$session where saddr='00000000A4726CC0';
SID SERIAL# SQL_ID
---------- ---------- -------------
116 153 6t5v50dgh7paq
SQL> col sql_text for a50
SQL> select sql_id,sql_text from v$sql where sql_id='6t5v50dgh7paq';
SQL_ID SQL_TEXT
------------- --------------------------------------------------
6t5v50dgh7paq SELECT COUNT(1) FROM T_LOCK_TEST
整合下上述的SQL为一个SQL，便于运维使用,直接查出造成library cache pin的原凶
SQL> select sid,serial#,event,v$sql.sql_id,v$sql.sql_text from dba_kgllock,v$session,v$sql where kgllktype='Pin' and kgllkmod<>0 and dba_kgllock.kgllkuse=v$session.saddr and v$session.sql_id=v$sql.sql_id;
SID SERIAL# EVENT SQL_ID SQL_TEXT
---------- ---------- ------------------------------ ------------- --------------------------------------------------
116 153 SQL*Net message from client 6t5v50dgh7paq SELECT COUNT(1) FROM T_LOCK_TEST
然后与应用人员沟通后，可以运行如下命令，杀死原凶会话即可
alter system kill session '116,153'
--可见产生library cache pin后，是基于存储过程，同时会在bucket的数据结构新增lock owner,pin owners,pin waiters
BUCKET 59215:
LIBRARY OBJECT HANDLE: handle=a3507208 mtx=0xa3507338(0) lct=22 pct=24 cdp=0
name=SCOTT.PROC_HARD_PARSE
hash=84bc90d61f9452e79e7fe2d54c82e74f timestamp=11-24-2015 02:02:36
namespace=TABL flags=KGHP/TIM/SML/[02000000]
kkkk-dddd-llll=0000-001d-20bf lock=X pin=S latch#=9 hpc=0008 hlc=0008 --pin正以共享模式持有，却有会话请求排它模式pin,见下面的pin wqiters
lwt=0xa35072b0[0xa35072b0,0xa35072b0] ltm=0xa35072c0[0xa35072c0,0xa35072c0]
pwt=0xa3507278[0x9eba6d50,0x9eba6d50] ptm=0xa3507288[0xa3507288,0xa3507288]
ref=0xa35072e0[0xa35072e0,0xa35072e0] lnd=0xa35072f8[0xa34de600,0xa34fed28]
DEPENDENCY REFERENCES:
reference latch flags
--------- ----- -------------------
98c7ce28 2 DEP[01] whr=0 timestamp=11-24-2015 02:02:36
LOCK OWNERS:
lock user session count mode flags
-------- -------- -------- ----- ---- ------------------------
9ec58960 a472d818 a472d818 1 X [00]
9eb1fd70 a4726cc0 a4726cc0 1 N PNC/[400]
PIN OWNERS:
pin user session lock count mode mask
-------- -------- -------- -------- ----- ---- ----
9eae0c20 a4726cc0 a4726cc0 9eb1fd70 3 S 0011 --可见PIN正以共享模式持有，这个user对应v$session.saddr即会话的地址，也对应dba_kgllock的KGLLKUSE
PIN WAITERS:
pin user session lock count mode mask
-------- -------- -------- -------- ----- ---- ----
9eba6d20 a472d818 a472d818 0 0 X 0000 ---可见请求排它模式的PIN
LIBRARY OBJECT: object=9d949488
type=PRCD flags=EXS/LOC[0005] pflags=NST[0001] status=VALD load=0
DEPENDENCIES: count=3 size=16
dependency# table reference handle position flags
----------- -------- --------- -------- -------- -------------------
0 9d94b210 9d94af50 a3a1b6f0 0 DEP[01]
1 9d94b210 9d94afa8 a351ce38 33 DEP[01]
2 9d94b210 9d94b000 a3929db0 0 DEP[01]
READ ONLY DEPENDENCIES: count=1 size=16
dependency# table reference handle flags
----------- -------- --------- -------- -------------------
0 9d9288d0 9d9285e8 a34fa2c8 /ROD[20]
ACCESSES: count=1 size=16
dependency# types
----------- -----
1 0009
TRANSLATIONS: count=1 size=16
original final
-------- --------
a351ce38 a351ce38
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
----- -------- -------- --------- ---- ------ --- -------- --------
0 a3507148 9d9495a0 I/P/A/-/- 0 NONE 00 0.37 1.09
2 9d9497a0 97745578 I/-/A/-/- 0 NONE 00 13.27 16.00
4 9d928540 97b67850 I/P/A/-/- 1 NONE 00 2.26 4.00
解决library cache pin后的存储过程对应的library cache bucket内容
BUCKET 59215:
LIBRARY OBJECT HANDLE: handle=a3507208 mtx=0xa3507338(0) lct=22 pct=24 cdp=0
name=SCOTT.PROC_HARD_PARSE
hash=84bc90d61f9452e79e7fe2d54c82e74f timestamp=11-24-2015 02:02:36
namespace=TABL flags=KGHP/TIM/SML/[02000000]
kkkk-dddd-llll=0000-001d-20bf lock=N pin=0 latch#=9 hpc=0008 hlc=0008 --可见pin=0，可见pin有种状态，即pin=0,pin=s,pin=x(pin=0我估计是null模式的pin)
lwt=0xa35072b0[0xa35072b0,0xa35072b0] ltm=0xa35072c0[0xa35072c0,0xa35072c0]
pwt=0xa3507278[0xa3507278,0xa3507278] ptm=0xa3507288[0xa3507288,0xa3507288]
ref=0xa35072e0[0xa35072e0,0xa35072e0] lnd=0xa35072f8[0xa34de600,0xa34fed28]
DEPENDENCY REFERENCES:
reference latch flags
--------- ----- -------------------
98c7ce28 2 DEP[01] whr=0 timestamp=11-24-2015 02:02:36
LOCK OWNERS:
lock user session count mode flags
-------- -------- -------- ----- ---- ------------------------
9eb1fd70 a4726cc0 a4726cc0 1 N [00]
9ec58960 a472d818 a472d818 0 N [4044]
LIBRARY OBJECT: object=9d949488 --而且与出现等待事件library cache pin出现的pin owner及pin waiter也消失了
type=PRCD flags=EXS/LOC[0005] pflags=NST[0001] status=VALD load=0
DEPENDENCIES: count=3 size=16
dependency# table reference handle position flags
----------- -------- --------- -------- -------- -------------------
0 9d94b210 9d94af50 a3a1b6f0 0 DEP[01]
1 9d94b210 9d94afa8 a351ce38 33 DEP[01]
2 9d94b210 9d94b000 a3929db0 0 DEP[01]
READ ONLY DEPENDENCIES: count=1 size=16
dependency# table reference handle flags
----------- -------- --------- -------- -------------------
0 9d9288d0 9d9285e8 a34fa2c8 /ROD[20]
ACCESSES: count=1 size=16
dependency# types
----------- -----
1 0009
TRANSLATIONS: count=1 size=16
original final
-------- --------
a351ce38 a351ce38
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
----- -------- -------- --------- ---- ------ --- -------- --------
0 a3507148 9d9495a0 I/-/A/-/- 0 NONE 00 0.37 1.09
2 9d9497a0 97745578 I/-/A/-/- 0 NONE 00 13.27 16.00
4 9d928540 97b67850 I/-/A/-/- 0 NONE 00 2.26 4.00
BUCKET 59215 total object count=1
深入理解shared pool共享池之library cache的library cache pin系列三的更多相关文章
- 深入理解shared pool共享池之library cache的library cache lock系列四
本文了解下等待事件library cache lock,进一步理解library cache,之前的文章请见: 深入理解shared pool共享池之library cache的library ca ...
- 深入理解shared pool共享池之library cache系列二
背景 继续上文:深入理解shared pool共享池之library cache系列一,学习library cache数据结构,本文主要学习library cache object(lco)的数据结构 ...
- 深入理解shared pool共享池之library cache系列一
结论 1,oradebug dump library_cache不同级别dump的library cache内容及粒度会有所区别,具体见测试开始部分2,本文测示基于oradebug dump libr ...
- shared pool详解
共享池shared pool的概念用户提交的命令:解析.执行用户命令的解析解析的过程是一个相当复杂的过程,它要考虑各种可能的异常情况比如SQL语句涉及到的对象不存在.提交的用户没有权限等等而且还需要考 ...
- Oracle数据库体系结构-Shared Pool
Oracle数据库简单介绍 对象关系型数据库 重点:一致性+性能 一致性优于性能 处理模型:C/S模型 Client:用户和用户进程 Server:服务器进程,实例,数据库本身 ...
- [转载】——故障排除：Shared Pool优化和Library Cache Latch冲突优化 (文档 ID 1523934.1)
原文链接:https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrlstate=23w4l35u5_4&id=152393 ...
- [20190319]shared pool latch与library cache latch的简单探究.txt
[20190319]shared pool latch与library cache latch的简单探究.txt --//昨天看Oracle DBA手记3:数据库性能优化与内部原理解析.pdf 电子书 ...
- 关于shared pool的深入探讨(二)【转载】
关于shared pool的深入探讨(二) 作者:eygle |English [转载时请标明出处和作者信息]|[恩墨学院 OCM培训传DBA成功之道]链接:http://www.eygle.co ...
- Oracle数据库案例整理-Oracle系统执行时故障-Shared Pool内存不足导致数据库响应缓慢
1.1 现象描写叙述 数据库节点响应缓慢,部分用户业务受到影响. 查看数据库告警日志,開始显示ORA-07445错误,然后是大量的ORA-04031错误和ORA-00600错误. 检查数据 ...
随机推荐
- 如用使用高版本framework，比如支持iOS5及以上的工程中使用Social.framework
在Targets -> Build Phases里的 Link Binary With Libraries项中,将高版本的framework,如Social.framework 设置成Optio ...
- ELK之topbeat部署
topbeat定期收集系统信息如每个进程信息.负载.内存.磁盘等等,然后将数据发送到elasticsearch进行索引,最后通过kibana进行展示. 下面是具体的安装及配置步骤: 1.安装topbe ...
- ssh 登录出现的几种错误以及解决办法
首先.确保server端的ssh服务是开的(service shhd start) 然后在client端输入: ssh usrname@serverip (远程登录) scp filename usr ...
- JS思维导图
- （转载）mysql decimal、numeric数据类型
(转载)http://www.cnblogs.com/qiantuwuliang/archive/2010/11/03/1867802.html 可能做程序的人都知道,float类型是可以存浮点数(即 ...
- HDU 5949 Relative atomic mass 【模拟】 （2016ACM/ICPC亚洲区沈阳站）
Relative atomic mass Time Limit: 2000/1000 MS (Java/Others) Memory Limit: 65536/65536 K (Java/Oth ...
- Redis主从实现原理分析 [转]
原文地址:http://blog.sina.com.cn/s/blog_7530db6f0100vegl.html 一, 实现原理图 (1)Slave服务器连接到Master服务器. (2)Slave ...
- 理解wait notify的好例子
import java.util.concurrent.TimeUnit; public class Example2 { /** * @param args */ public static voi ...
- jni编译non-numeric second argument to `wordlist' function错误
在jni编译过程中,遇到non-numeric second argument to `wordlist' function错误,个人遇到这个错误的原因,是因为从windows中拷贝了Android. ...
- HTML头部<head>学习
元素是所有头部元素的容器. 元素包含了所有的头部标签元素.在 元素中你可以插入脚本(scripts), 样式文件(CSS),及各种meta信息. 以下标签都可以添加到 head 部分: 1.title ...