library cache lock/pin

原创:转载请说明

X$KSMLRU that tracks allocations in the shared pool that cause other objects in th e shared pool to be aged out
诊断 library cache lock/pin类型:
不管是访问还是修改library中的heap的信息,都需要先获得library cache lock这个锁实际是对handle进行锁定,修改需要加独占模式,访问需要共享模式,然后访问heap0的信息
访问heap的信息通过library cache pin进行锁定,访问加共享,修改加独占。下面是一些诊断时需要的x$视图说明,另外还说明一年v$session_wait中p3值是模式和对象类型的和,比如
301=3(mode)*100+1(namespace) 3是独占,1是table/procedure
mode 1=null 2=shared 3=exclusive
namespace
0=cursor(sql area)
1=table,procedure and others
2=package body
3=trigger
4=index
5=cluster
6=object
7=pipe
13=java source
14=java resource
32=java data
x$kgllk 找到引起library cache lock 的信息,其中KGLLKSES对应了session saddr,KGLHDPAR对应了P1的值,KGLLKADR对应了P2的值是一个lock 的地址,KGLNAOBJ就是当前等待的对象
KGLlkREQ定义了需要的模式>0为等待用户1为null 2 为 share 3 Exclusive,通过这个字段然后找到KGLLKSES可以确定是那个会话堵塞。KGLLKMOD是持有模式,KGLLKSNM是SID,其实KGLLKSES也可以找到

SQL> select * from v$session_wait where wait_class'Idle';

        SID       SEQ# EVENT                                                            P1TEXT                                                                   P1 P1RAW            P2TEXT                                                                   P2 P2RAW            P3TEXT                                                                   P3 P3RAW            WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS                                                        WAIT_TIME SECONDS_IN_WAIT STATE               WAIT_TIME_MICRO TIME_REMAINING_MICRO TIME_SINCE_LAST_WAIT_MICRO

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

          139      11264 library cache lock                                               handle address                                                   1949336832 0000000074308500 lock address                                                     1959726640 0000000074CF0E30 100*mode+namespace                                               3301842008 00012C4D00010003    3875070507           4 Concurrency                                                               0               0 WAITING                          87                   -1                          0

 

SQL>  select  KGLLKSNM ,INST_ID,KGLLKSES,KGLLKMOD,KGLLKREQ,USER_NAME,KGLNAOBJ from x$kgllk  where KGLHDPAR='0000000074308500'; 这里是P1RAW

 

  KGLLKSNM    INST_ID KGLLKSES           KGLLKMOD   KGLLKREQ USER_NAME                      KGLNAOBJ

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

       139          2 000000007CBF6228          0          3 SYS                            LIB_TEST

        31          2 000000007CA55248          3          0 SYS                            LIB_TEST

 

这里明显的31 堵塞了139

x$kglob 可以通过library cache lock/pin的p1raw值对应KGLHDPAR即可找到,KGLHDPAR就是句柄的地址(handle address),kglobtyp是对象类型的代码
SQL> select * from x$kglob  where KGLHDPAR='39E43150';
 
ADDR           INDX    INST_ID KGLHDADR KGLHDPAR   KGLHDCLT KGLNAOWN                                                         KGLNAOBJ                                                                         KGLFNOBJ                                                                         KGLNADLK                                                           KGLNAHSH KGLNAHSV                          KGLNATIM    KGLNAPTM      KGLHDNSP   KGLHDLMD   KGLHDPMD   KGLHDFLG KGLHDOBJ   KGLHDLDC   KGLHDIVC   KGLHDEXC   KGLHDLKC   KGLHDKMK   KGLHDDMK   KGLHDAMK   KGLOBFLG   KGLOBSTA   KGLOBTYP   KGLOBHMK   KGLOBHS0   KGLOBHS1   KGLOBHS2   KGLOBHS3   KGLOBHS4   KGLOBHS5   KGLOBHS6   KGLOBHS7 KGLOBHD0 KGLOBHD1 KGLOBHD2 KGLOBHD3 KGLOBHD4 KGLOBHD5 KGLOBHD6 KGLOBHD7   KGLOBPC0   KGLOBPC6 KGLOBTP0   KGLOBT00   KGLOBT01   KGLOBT02 KGLOBT03        KGLOBT04   KGLOBT05   KGLOBT35   KGLOBT06   KGLOBT07   KGLOBT08   KGLOBT09   KGLOBT10   KGLOBT11   KGLOBT12   KGLOBT13   KGLOBT14   KGLOBT15   KGLOBT16   KGLOBT17   KGLOBT18   KGLOBT19   KGLOBT20   KGLOBT21   KGLOBT22   KGLOBT23   KGLOBT24   KGLOBT25   KGLOBT26   KGLOBT28   KGLOBT29   KGLOBT30   KGLOBT31   KGLOBT27   KGLOBT32   KGLOBT33   KGLOBWAP   KGLOBWCC   KGLOBWCL   KGLOBWUI   KGLOBWDW   KGLOBT42   KGLOBT43   KGLOBT44   KGLOBT45   KGLOBT46   KGLOBT47   KGLOBT49   KGLOBT50   KGLOBTL0   KGLOBTL1 KGLOBTS0                                                         KGLOBTS1                                                           KGLOBTN0   KGLOBTN1   KGLOBTN2   KGLOBTN3   KGLOBTN4   KGLOBTN5 KGLOBTS2                                                         KGLOBTS3                                                         KGLOBTS5                                                         KGLOBTT0    KGLOBCCE                                                                          KGLOBCCEH KGLOBCLA      KGLOBCLC   KGLOBCCC KGLOBTS4                       KGLOBCBCA                                                                          KGLOBT48   KGLOBDS
-------- ---------- ---------- -------- -------- ---------- ---------------------------------------------------------------- -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- ---------------------------------------------------------------- ---------- --------------------------------- ----------- ----------- ---------- ---------- ---------- ---------- -------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- -------- -------- -------- -------- -------- -------- -------- -------- ---------- ---------- -------- ---------- ---------- ---------- ------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ----------- -------------------------------------------------------------------------------- ---------- ----------- ---------- ---------- ------------------------------ -------------------------------------------------------------------------------- ---------- ---------
B7DCCF88       3310          1 39E43150 39E43150          1 SYS                                                              LIB_TEST                                                                         LIB_TEST                                                                                                                                          2173132718 486d0dbc99f10bc85579090681875fae  2012/5/4 22 2012/5/4 22          1          1          0   33554432 40749120     302370          0          0          4          0        157          0          5          1          7          0        348          0       4096          0       4096          0          0       1072 43E9EAA4 00       407492F0 00       40749340 00       00       40749390          0          0 00                0          0          0                        0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              0                      0          0                                                                                                                          0         
 

v$kglpn:用于找到library cache pin 的相关信息,KGLPNSES对应了session 的saddr,KGLPNHDL对应了P1RAW,KGLPNADR对应了PIN的地址 也就是P2RAW,如果要查找对象可以在x$kglob通过KGLHDPAR对应P1RAW找到。

P3同样是模式和对象,参考上面。

但是注意V$KGLPN中不会有实际的对象,如果要找到实际的对象必须通过X$KGLPN的kglpnhdl字段或者直接用P1RAW连接X$KGLOB视图的 kglhdpar字段

找到相应的object

同时在进行诊断的时候实际上堵塞源头是不会出现在V$SESSION_WAIT中的

SQL> select KGLPNADR,KGLPNHDL,KGLPNMOD,KGLPNREQ,KGLPNSES from x$kglpn  where KGLPNHDL='E760DDE4';
 
KGLPNADR KGLPNHDL   KGLPNMOD   KGLPNREQ KGLPNSES
-------- -------- ---------- ---------- --------
EDD0E97C E760DDE4          0          2 F0ADAB5C
EE650D7C E760DDE4          0          2 F0B4B65C
EDC11F14 E760DDE4          0          2 F0AD9894
EDB4B8C8 E760DDE4          3          0 F0B1B454
 
SQL> select event,p1RAW,p2raw from v$session_wait where wait_Class'Idle';
 
EVENT                                                            P1RAW    P2RAW
---------------------------------------------------------------- -------- --------
library cache pin                                                E760DDE4 EDC11F14
library cache pin                                                E760DDE4 EDD0E97C
SQL*Net message to client                                        54435000 00000001
library cache pin                                                E760DDE4 EE650D7C

可以看到EDB4B8C8并不出现在V$SESSION_WAIT中,它就是堵塞源头,通过KGLPNSES找到SID干掉它即可。

KGLPNREQ定义了需要的模式>0为等待用户1为null 2 为 share 3 Exclusive,通过这个字段然后找到KGLLKSES可以确定是那个会话堵塞了那个会话。而KGLPNMOD则是持有模式。
SQL> select * from x$kglpn  where KGLPNHDL='39E43150'; 这里也是P1RAW
 
ADDR           INDX    INST_ID KGLPNADR KGLPNUSE KGLPNSES KGLPNHDL KGLPNLCK   KGLPNCNT   KGLPNMOD   KGLPNREQ   KGLPNDMK   KGLPNSPN
-------- ---------- ---------- -------- -------- -------- -------- -------- ---------- ---------- ---------- ---------- ----------
B7F44128          9          1 41FA7F30 442F7E38 442F7E38 39E43150 00                0          0          3          0   55077698
B7F4415C         10          1 423F9DF8 4430268C 4430268C 39E43150 423F128C         -2          2          0         17   28437228
  
 我遇到一次ORA - 04021就是有大量的PIN照成的

学习,持续更新中

时间: 2024-10-23 02:32:43

library cache lock/pin的相关文章

Library Cache Lock的解决

cache|解决 昨晚业务系统导入资料并重建索引时一个会话突然停滞不前,用TOAD一看,一直在等待Library Cache Lock.TOAD.OEM中都看不到此锁,会话每三秒启动一次,但每次都是等待这个锁.显然,这和数据字典有关,应该是一个索引的数据字典中的记录被锁住了,导致无法重建.可是杀光了其他ACTIVE的会话,问题仍然没有得到解决,看来是某一个被杀死的会话持有该锁,而会话尚未回滚完全,进程仍然吊死着.现在的问题就是找这个会话了.首先想到的文档就是Oracle9i Database R

彻底搞清楚library cache lock的成因和解决方法(一)

cache|解决 问题描述:接到应用人员的报告,说是在任何对表CSNOZ629926699966的操作都会hang,包括desc CSNOZ629926699966,例如: ora9i@cs_dc02:/ora9i > sqlplus pubuser/pubuser SQL*Plus: Release 9.2.0.4.0 - Production on Mon Jan 10 10:11:06 2005 Copyright (c) 1982, 2002, Oracle Corporation. 

oracle数据库library cache lock引发的一个问题解决办法

美女同事说某个客户有个问题,系统出现了大量的library cache lock. 导致业务严重受阻,具体表现是所有访问某个表的SQL语句都会挂起. 首先我们来看hanganalyze 的结果: PORADEBUG END ORIGINATING INST:1 SERIAL:0 PID:38076802 ******************************************************************** Found 341 objects waiting fo

[20161216]关于library cache lock.txt

[20161216]关于library cache lock.txt --这几天一直在关注这个链接,http://www.itpub.net/thread-2073170-1-1.html --就是library cache lock导致挂死业务,一般引起这个问题编译包,而应用正好在使用执行这个包,以及11g口令大小写导致无法登录的问题, --我自己很久以前也遇到过一些,那时的系统是10g,http://www.itpub.net/thread-1842463-1-1.html,但是只要分析某个

0324resumable_timeout library cache lock

[20160324]参数resumable_timeout和library cache lock.txt --今天测试环境遇到library cache lock的情况,主要测试磁盘空间很紧张,但是设置了参数resumable_timeout. --开发通过ctas建立表时,空间不够挂起,估计他程序挂起异常关闭,ctas依旧在后台运行.但是访问到这个表的程序全部挂起. --通过例子来说明: 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING            

library cache lock 的解决案例

cache|解决  下午,业务人员报告,执行任何和zzss03201281cs_no表有关的操作都会hang住,包括desc zzss03201281cs_no,也会hang在那里 第一感觉是锁了,于是,我看看锁 SQL> select * from v$lock where block=1; no rows selected SQL> SQL> select * from gv$lock where block=1; no rows selected SQL>   再看看等待事件

故障分析:一则library cache lock问题处理

编辑手记:library cache lock 大家都并不陌生,在MOS上对该阻塞的一般成因描述为:一般可以理解的是alter table或者alter package/procedure会以X模式持有library cache lock,造成阻塞(444560.1).但针对具体问题仍要具体分析,今天分享一则因SQL绑定变量出现空值,导致大量子游标产生并引发library cache lock 的故障,供大家参考借鉴. 请故障现象及影响某数据库为Oracle 11.2.0.3.9 RAC Lin

密码错误频繁登录引发的“library cache lock”或“row cache lock”等待

密码错误频繁登录引发的"library cache lock"或"row cache lock"等待 对于正常的系统,由于密码的更改,可能存在某些被遗漏的客户端,不断重复尝试使用错误密码登录数据库,从而引起数据库内部长时间的"library cache lock"或"row cache lock"的等待,这种情形非常常见.这种现象在Oracle 10.2和11.1中体现的等待事件为:"row cache lock&q

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@ by