[20130228]等待事件library cache pin的快速定位与解决.txt

[20130228]等待事件library cache pin的快速定位与解决.txt

前几天管理的服务器出现library cache pin,当时解决有点乱了阵脚,正好下午空闲做一个例子来定位library cache pin事件以及解决方法,另外我也看许多blog,感觉定位太复杂,不合适快速解决问题:

1.环境以及问题再现:

SQL> select * from v$version where rownumBANNER--------------------------------------------------------------------------------Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

CREATE OR REPLACE PROCEDURE proc1ISBEGIN   DBMS_LOCK.sleep (1000);END;/

--在windows下执行如下命令,按ctrl+c中断它[注在linux下不行!]SQL> exec proc1;

--再打开一个回话,重新建立过程proc1,执行如下:CREATE OR REPLACE PROCEDURE proc1ISBEGIN   DBMS_LOCK.sleep (1000);END;/

--出现挂起.  
SQL> select sid,event,p1,p2,p3 from v$session_wait where wait_time=0 and event like 'library cache pin%';
       SID EVENT                                            P1         P2                      P3
---------- ---------------------------------------- ---------- ---------- -----------------------
       191 library cache pin                        3001221336 3000130456         416409964314627

参考文档:
http://docs.oracle.com/cd/B16240_01/doc/doc.102/e16282/oracle_database_help/oracle_database_wait_bottlenecks_library_cache_pin_pct.html

column h_wait format A20
SELECT s.sid,
    waiter.p1raw w_p1r,
    holder.event h_wait,
    holder.p1raw h_p1r,
    holder.p2raw h_p2r,
    holder.p3raw h_p2r,
    count(s.sid) users_blocked,
    sql.hash_value
FROM
    v$sql sql,
    v$session s,
    x$kglpn p,
    v$session_wait waiter,
    v$session_wait holder
WHERE
    s.sql_hash_value = sql.hash_value and
    p.kglpnhdl=waiter.p1raw and
    s.saddr=p.kglpnuse and
    waiter.event like 'library cache pin' and
    holder.sid=s.sid
GROUP BY
    s.sid,
    waiter.p1raw ,
    holder.event ,
    holder.p1raw ,
    holder.p2raw ,
    holder.p3raw ,
    sql.hash_value
;
--我修改一点点加入sql_id,sql_text.
SELECT   s.SID, waiter.p1raw w_p1r, holder.event h_wait, holder.p1raw h_p1r, holder.p2raw h_p2r, holder.p3raw h_p2r,
         COUNT (s.SID) users_blocked, SQL.sql_id, SQL.hash_value, SQL.sql_text
    FROM v$sql SQL, v$session s, x$kglpn p, v$session_wait waiter, v$session_wait holder
   WHERE s.sql_hash_value = SQL.hash_value
     AND p.kglpnhdl = waiter.p1raw
     AND s.saddr = p.kglpnuse
     AND waiter.event LIKE 'library cache pin'
     AND holder.SID = s.SID
GROUP BY s.SID, waiter.p1raw, holder.event, holder.p1raw, holder.p2raw, holder.p3raw, SQL.sql_id, SQL.hash_value, SQL.sql_text
  SID W_P1R            H_WAIT             H_P1R            H_P2R            H_P2R            USERS_BLOCKED SQL_ID        HASH_VALUE SQL_TEXT
----- ---------------- ------------------ ---------------- ---------------- ---------------- ------------- ------------- ---------- -----------------
   68 00000000B2E300D8 PL/SQL lock timer  00000000000186A0 00               00                           1 7ap74x3urn7f7 4118420935 BEGIN proc1; END;

--找到sid=68,kill该进程OK.这个脚本对于快速定位很有用.

时间: 2024-09-21 03:58:22

[20130228]等待事件library cache pin的快速定位与解决.txt的相关文章

0106library cache pin的快速定位与解决

[20150106]library cache pin的快速定位与解决.txt --昨天别人的系统遇到library cache pin问题,导致前台业务停顿,出现问题后请求协助. --我以前也遇到,也是手忙脚乱.我自己写过一个定位的脚本: http://blog.itpub.net/267265/viewspace-754965/ $ cat lcp.sql column h_wait format A20 column sql_text format a30 SELECT   s.SID,s

Oracle中library cache pin与PROCEDURE的重建

前面提到,Oracle10g重建Procedure的处理有所增强,最初看到这个增强的时候,我想这个增强是否可以减少困扰已久的Library Cache的竞争呢? 我们看一下以下测试,首先在第一个session执行操作: SQL> create or replace PROCEDURE pining 2 IS 3 BEGIN 4 NULL; 5 END; 6 / Procedure created. SQL> SQL> alter session set nls_date_format='

等待模拟-library cache 软解析

create table test (it int); insert into test values(10); commit; create or replace procedure do_soft_parse(p_idx in number)  is      v_value number;     v_cursor sys_refcursor;  begin     execute immediate 'alter session set session_cached_cursor=0';

ORACLE等待事件latch: cache buffers chains

    今天上午,电渠生产库维护人员通知,ORACLE生产库中有比较多的latch: cache buffers chains引起的会话,造成堵塞,相关处理过程如下    环境:hp-unix    数据库版本:10.2.0.5    登录数据库查询等待事件:      根据等待事件latch: cache buffers chains查询相关的SQL_ID,引起争用的对象所在的文件号和块号 select * from (select      count(*),      sql_id,   

SQL*Net more data from dblink引起library cache pin

今天论坛中发现一个问题在进行编译或者删除存储过程的时候一直卡住, 当然这个很可能是LIBRARY CACHE PIN引起的.概念如下: An Oracle instance has a library cache that contains the description of  different types of objects e.g. cursors, indexes, tables, views, procedures,  ... Those objects cannot be cha

等待模拟-library cache shared pool 硬解析

drop table test1; create table test1 (it int); insert into test1 values(10); create table test2 as select * from test1; create table test3 as select * from test1; create table test4 as select * from test1; create table test5 as select * from test1; c

library cache pin与PROCEDURE的重建

前面提到,Oracle10g重建Procedure的处理有所增强,最初看到这个增强的时候,我想这个增强是否可以减少困扰已久的Library Cache的竞争呢? 我们看一下以下测试,首先在第一个session执行操作: SQL> create or replace PROCEDURE pining 2 IS 3 BEGIN 4 NULL; 5 END; 6 / Procedure created. SQL> SQL> alter session set nls_date_format='

【MOS】常见问题cursor library cache类型的等待事件

[MOS]常见问题:'cursor:mutex ..'/ 'cursor:pin ..'/ 'library cache:mutex ..'类型的等待事件 (文档 ID 1525791.1) 文档内容 用途 问题和答案   什么是 'cursor: ' 等待事件?   最常见的等待事件是什么?   等待事件最常见的原因是什么?   如何避免这些等待事件?   可以在什么位置找到原因诊断以及关于这些等待事件的更多信息?   有用参考 参考 适用于: Oracle Database - Enterp

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