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>

 

再看看等待事件：

SQL> col event for a30
SQL> l
  1* select event,p1,p2,sid from v$session_wait where event='library cache lock'
SQL> /

EVENT                                  P1         P2        SID
------------------------------ ---------- ---------- ----------
library cache lock             1.3835E+19 1.3835E+19         32

SQL> /

EVENT                                  P1         P2        SID
------------------------------ ---------- ---------- ----------
library cache lock             1.3835E+19 1.3835E+19         32

SQL> /

EVENT                                  P1         P2        SID
------------------------------ ---------- ---------- ----------
library cache lock             1.3835E+19 1.3835E+19         32

。。。

 

奇怪，怎么这么多 library cache lock  ？

SQL> show user
USER is "SYS"
SQL> exec dbms_system.set_ev(32,27506,10046,12,'');

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.10
SQL> l
  1  SELECT    d.VALUE
  2         || '/'
  3         || LOWER (RTRIM (i.INSTANCE, CHR (0)))
  4         || '_ora_'
  5         || p.spid
  6         || '.trc' trace_file_name
  7    FROM (SELECT p.spid
  8            FROM v$mystat m, v$session s, v$process p
  9           WHERE m.statistic# = 1 AND s.SID = m.SID AND p.addr = s.paddr) p,
 10         (SELECT t.INSTANCE
 11            FROM v$thread t, v$parameter v
 12           WHERE v.NAME = 'thread'
 13             AND (v.VALUE = 0 OR t.thread# = TO_NUMBER (v.VALUE))) i,
 14         (SELECT VALUE
 15            FROM v$parameter
 16*          WHERE NAME = 'user_dump_dest') d
SQL> /

TRACE_FILE_NAME
--------------------------------------------------------------------------------
/ora9i/app/oracle/admin/csmisc/udump/csmisc2_ora_2708.trc

Elapsed: 00:00:00.10
SQL>

 

SQL> select xidusn, object_id, session_id, locked_mode from v$locked_object;

    XIDUSN  OBJECT_ID SESSION_ID LOCKED_MODE
---------- ---------- ---------- -----------
        14      35202         31           3
        15         18         30           3

SQL> col object_name format a30
SQL> select owner,object_name,status from dba_objects where object_id=35202;

OWNER
------------------------------
OBJECT_NAME
--------------------------------------------------------------------------------
STATUS
-------
SYS
PLAN_TABLE
VALID

SQL>

这个对象显然不是我们关注的。

SQL> l
/  1* select owner,object_name,status from dba_objects where object_id=18
SQL>

OWNER                          OBJECT_NAME                    STATUS
------------------------------ ------------------------------ -------
SYS                            OBJ$                           VALID

就是这个对象搞得，估计是开发人员异常退出一些进程

SQL> c/18/30
  1* select serial#,username,command,lockwait,status,schemaname,osuser,machine,terminal,program,module from v$session where sid=30
SQL> /

   SERIAL# USERNAME                          COMMAND LOCKWAIT         STATUS
---------- ------------------------------ ---------- ---------------- --------
SCHEMANAME                     OSUSER
------------------------------ ------------------------------
MACHINE
----------------------------------------------------------------
TERMINAL                       PROGRAM
------------------------------ ------------------------------------------------
MODULE
------------------------------------------------
     17921 PUBUSER                                 0                  ACTIVE
PUBUSER                        report16
cs_dc02

   SERIAL# USERNAME                          COMMAND LOCKWAIT         STATUS
---------- ------------------------------ ---------- ---------------- --------
SCHEMANAME                     OSUSER
------------------------------ ------------------------------
MACHINE
----------------------------------------------------------------
TERMINAL                       PROGRAM
------------------------------ ------------------------------------------------
MODULE
------------------------------------------------
                               sqlplus@cs_dc02 (TNS V1-V3)
SQL*Plus

SQL> select b.username username, b.terminal terminal,b.program program,b.spid
  2  from v$session a, v$process b
where a.PADDR=b.ADDR and a.sid ='&sid';
  3  Enter value for sid: 30
old   3: where a.PADDR=b.ADDR and a.sid ='&sid'
new   3: where a.PADDR=b.ADDR and a.sid ='30'

USERNAME        TERMINAL
--------------- ------------------------------
PROGRAM                                          SPID
------------------------------------------------ ------------
ora9i           UNKNOWN
oracle@cs_dc02 (TNS V1-V3)                       835

很显然，是由于report16用户执行了某些DDL操作，然后，异常退出，造成系统的锁（估计和bug有关，有待考证）
SQL> host
ora9i@cs_dc02:/ora9i/app/oracle/product/920/rdbms/admin > ps -ef | grep 835
   ora9i  4619  4617  1 14:48:18 pts/te    0:00 grep 835
   ora9i   835     1  0  Jan  5  ?         0:01 oraclecsmisc2 (LOCAL=NO)
ora9i@cs_dc02:/ora9i/app/oracle/product/920/rdbms/admin > kill 835
ora9i@cs_dc02:/ora9i/app/oracle/product/920/rdbms/admin > exit

SQL> select xidusn, object_id, session_id, locked_mode from v$locked_object;

    XIDUSN  OBJECT_ID SESSION_ID LOCKED_MODE
---------- ---------- ---------- -----------
        14      35202         31           3

SQL>

kill掉这个进程后，问题解决了。（遗憾的是，忘了看看这个家伙执行的sql了，呵呵）
SQL> desc zzss03201281cs_no
ERROR:
ORA-04043: object zzss03201281cs_no does not exist

SQL> desc zzss03201281cs_no
ERROR:
ORA-04043: object zzss03201281cs_no does not exist

SQL>

SQL> exec dbms_system.set_ev(32,27506,0,0,'');

PL/SQL procedure successfully completed.

SQL>

查看trace文件，：

果然大量的wait：

WAIT #1: nam='library cache lock' ela= 316 p1=-4611686013647472824 p2=-4611686013691747544 p3=1301
WAIT #1: nam='library cache lock' ela= 326 p1=-4611686013647472824 p2=-4611686013691747544 p3=1301
WAIT #1: nam='library cache lock' ela= 398 p1=-4611686013647483736 p2=-4611686013691747816 p3=1301
WAIT #1: nam='library cache lock' ela= 552 p1=-4611686013647483736 p2=-4611686013691747816 p3=1301
WAIT #1: nam='library cache lock' ela= 330 p1=-4611686013649700264 p2=-4611686013691715248 p3=1301
WAIT #1: nam='library cache lock' ela= 141 p1=-4611686013649700264 p2=-4611686013691715248 p3=1301
WAIT #1: nam='library cache lock' ela= 223 p1=-4611686013647485472 p2=-4611686013691762016 p3=1301
WAIT #1: nam='library cache lock' ela= 93 p1=-4611686013647485472 p2=-4611686013691762016 p3=1301
WAIT #1: nam='library cache lock' ela= 223 p1=-4611686013595934816 p2=-4611686013642107320 p3=1301

 

 

时间： 2024-08-22 14:16:02

library cache lock 的解决案例的相关文章

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

故障分析：一则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

[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”或“row cache lock”等待

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

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的信息访问h

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