library cache pin大部分都是因为编译存储过程造成的 查找造成问题的数据库对象(一般为存储过程) SELECT * FROM v$session_wait WHERE event = 'library cache pin' ORDER BY p1raw; SELECT kglnaown "Owner", kglnaobj "Object" FROM x$kglob WHERE kglhdadr = 'p1raw'; 一般是因为在编译的过程中,有大量的程

内容如下: 今天接到同事的电话,说他的一个存储过程已经run了一个多小时了,还在继续run,他觉得极不正常,按道理说不应该run这么长时间. 我说那我去看一下吧. 这个库是一个AIX上的10.2.0.4,我采集了一下问题时间段的AWR报告: 从AWR报告结果里我们可以看出在出问题的时间段,系统在经历严重的library cache pin以及library cache lock等待. 根据Load Profile的信息,看出导致上述library cache pin和library cache

关于library cache相关的LATCH非常多,名称差不多,我相信一些人对这些概念还是有些晕,我之前也有些晕,希望此文可以对这些概念有个更为清晰的理解,本文主要学习library cache pin 前期相关文章 http://blog.itpub.net/9240380/ 结论 1,library cache pin是用于并发的一种特殊锁,它不是LATCH2,library cache pin适用于正在执行存储过程时,不能同时去编译存储过程,后者则会产生此等待事件,目的即防止并发修改存储

Oracle Library Cache 的 lock 与 pin 说明 一. 相关的基本概念 之前整理了一篇blog,讲了Library Cache 的机制,参考: Oracle Library cache 内部机制 说明 http://blog.csdn.net/tianlesoftware/article/details/6629869 在这个机制中,没有详细讲library 上的lock 和pin.这2个概念对DB 的理解非常重要. 所以单独拿出来,进行说明. 根据hellodba 和

外键约束列并没有导致大量建筑指数library cache pin/library cache lock 清除一个100大数据表超过一百万线,发现已经运行了几个小时: delete B001.T_B11; 由下面的SQL跟踪,发现经常发生library cache pin和library cache lock的等待,怀疑有大量的recursive sql在运行.于是对这个session做了10046: 发现有大量的例如以下SQL运行,每删除1行T_B11,都会运行以下2条SQL一次, PARSI

Doc ID 1476663.1) To Bottom In this Document   Purpose   Troubleshooting Steps   Brief Definition:   Problem Confirmation:   Library Cache Pin   Cursor Pin S wait on X   Improving Performance of Library cache pin or Pin S wait on X   Measuring Succes

怎么发现RAC环境中的'library cache pin'等待事件的堵塞者(Blocker) 參考自 How to Find the Blocker of the 'library cache pin' in a RAC environment? (文档 ID 780514.1) 本文不做翻译.全文转载: Applies to: Oracle Database - Enterprise Edition - Version 9.2.0.1 to 11.1.0.7 [Release 9.2 to

select sid,event,p1raw from v$session_wait where event like 'library cache pin%'; select sql_text from v$sqlarea where hash_value=(select sql_hash_value from v$session where sid=164); 通过以下SQL可以从 x$kglob得到正在pin的对象:select kglnaown,kglnaobj,kglnadlk fro

Oracle单实例情况下的library cache pin的问题模拟与问题分析 參考自: WAITEVENT: "library cache pin" Reference Note (文档 ID 34579.1) How to Find the Blocker of the 'library cache pin' in a RAC environment? (文档 ID 780514.1) 本机环境:Oracle 10.2.0.5 x86-64bit for RHEL5.8 x86-

What is "Library cache lock" ? This event controls the concurrency between clients of the library cache. It acquires a lock on the object handle so that either: One client can prevent other clients from accessing the same object. The client can

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>se

1.现象: 客户10.2.0.4 RAC环境,出现大量的library cache lock和cursor: pin S wait on X等待,经分析是由于统计信息收集僵死导致的.数据库在8点到9点期间,数据库两个节点都存在明显的cursor: pin S wait on X和library cache lock的等待: TOP 5 EVENT: Event Waits Time(s) Avg   Wait(ms) %   Total Call Time Wait   Class cursor

Library cache lock/pin 一.概述 ---本文是网络资料加metalink 等整理得来一个实例中的library cache包括了不同类型对象的描述,如:游标,索引,表,视图,过程,等等. 这些对象不能在他们被使用的时候改变,他们在被使用的时候会被一种library locks and pins的机制锁住. 一个会话中,需要使用一个对象,会在该对象上先得到一个library lock(null, shared or exclusive模式的)这是为了,防止其他会话也访问这个对

原文链接: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

产生library cache latch原因The library cache latches protect the cached SQL statements and objects' definitions held in the library cache within the shared pool. The library cache latch must be acquired in order to add a new statement to the library cach

先来张大图: 结合上图来说明一下解析的各个步骤涉及的锁. 软解析.硬解析.软软解析区别的简单说明: 为了将用户写的sql文本转化为oracle认识的且可执行的语句,这个过程就叫做解析过程. 解析分为硬解析和软解析,SQL语句第一次解析时必须进行硬解析 一句话说明硬解析与软解析的区别是: 硬解析=需要生成执行计划   软解析=不需要生成执行计划 在Oracle中存在两种类型的SQL语句,一类为DDL语句,不共享使用,也就是每次执行都需要进行硬解析.还有一类就是DML语句,会进行硬解析或软解析. 硬

前面介绍的 shared pool,library cache结构,都是为了说明一条SQL是如何被解析的.先看下面的图: 图中涉及的各结构简单介绍 父HANDLE,里面有父游标堆0的地址.. 父游标堆0:有指向一个或多个子游标的HANDLE的句柄地址 父游标在第一次打开时被锁定,直到其他所有的session都关闭该游标后才被解锁.当父游标被锁定的时候是不能被交换出librarycache的,只有在解锁以后才能被交换出library cache.父游标被交换出内存时父游标对应的所有子游标也被交换出

今天收到同事电话,说是数据库中一张名为acct_balance进行操作是奇慢,第一反映是不是扫行计划有问题,结果我错了,现将过程记录下来. 用pl/sql连上数据库情况:1.对acct_balance表的查询很慢,正常少于0.1s完成,现在要60s完成:2.使用explain plan对语句进行分析,过析比正常情况下慢很多. 下面为处理过程:1.从v$session_wait中查找有问题的waitSql>select event,count(*) from v$session_wait grou

本文了解下等待事件library cache lock,进一步理解library cache,之前的文章请见:  深入理解shared pool共享池之library cache的library cache pin系列三 相关图例 为了真观理解library cache pin及library cache lock的联系,有个图: 结论 1,道理同library cache pin一样,诊断library cache lock也要使用v$session及dba_kgllock2, library

SESSION 34 执行存储过程: SESSION 43 编译存储过程: SESSION 25 删除存储过程: 1.查询查看library cache lock等待事件的相关会话 SQL> select sid, P1RAW,P1TEXT ,event from v$session_wait where event not like '%message%'; SID P1RAW P1TEXT EVENT ---------- ---------------- -----------------