这两个等待事件其实很少出现在top5列表中,一般都没什么印象,在此整理记录以便以后查阅. 常见的library cache lock产生的原因在<高级OWI与Oracle性能调查>这本书和下面这个文档中有一般性的描述: Troubleshooting Library Cache: Lock, Pin and Load Lock (Doc ID 444560.1) 一般可以理解的是alter table或者alter package/procedure会以X模式持有library cache l

本文了解下等待事件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

在 Oracle 11g 中,为了提升安全性,Oracle 引入了『密码延迟验证』的新特性.这个特性的作用是,如果用户输入了错误的密码尝试登录,那么随着登录错误次数的增加,每次登录前验证的时间也会增加,以此减缓可能对于数据库重复的口令尝试攻击. 但是对于正常的系统,由于口令的更改,可能存在某些被遗漏的客户端,不断重复尝试,从而引起数据库内部长时间的 Library Cache Lock的等待,这种情形非常常见. 如果遇到这一类问题,可以通过Event 28401关闭这个特性,从而消除此类影响,以

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

今天收到同事电话,说是数据库中一张名为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

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 和

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

同事反映impdp时在SCHEMA_REPORT/TYPE/TYPE_SPEC步骤卡住,1个多小时后也没有响应, 查下v$session: select program,sid, event,blocking_session from gv$session  where program like '%DW%'; 结果为: DW01,98,library cache lock,213 DW03,13,library cache lock,213 DW02,36,library cache lock

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

My colleague suddenly encountered a problem today,a Database becomes very slow , and the a lot of session wait library cache lock event, Let me help him to look. DB env is 10.2.0.4 rac. at first ,to generate a AWR manually. exec dbms_workload_reposit

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

rac数据库默认sql tuning advisor,导致大量library cache lock 问题现象:客户反映周六周日固定十点钟,一个程序会特别慢(大概10分钟),平时1到2秒.查看当时的日志发现:DBMS_STATS: GATHER_STATS_JOB encountered errors.  Check the trace file.Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_j002_51847.

产生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

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

Oracle内存详解之 Library cache 库缓冲 2017年11月09日 11:38:39 阅读数:410更多 个人分类: 体系结构 Library cache是Shared pool的一部分,它几乎是Oracle内存结构中最复杂的一部分,主要存放shared curosr(SQL)和PLSQL对象(function,procedure,trigger)的信息,以及这些对象所依赖的table,index,view等对象的信息. Library cache需要解决三个问题: 1.快速定位

转自:http://blog.itpub.net/26736162/viewspace-2139754/   定位的办法: --查询row cache lock等待 select event,p1  from v$session where  event= 'row cache lock' and status='ACTIVE';   --查询rowcache 名称 select * from v$rowcache where cache# =p1; 名称 P1 P2 P3 原因 处理 row 

Library cache是Shared pool的一部分,它几乎是Oracle内存结构中最复杂的一部分,主要存放shared curosr(SQL)和PLSQL对象(function,procedure,trigger)的信息,以及这些对象所依赖的table,index,view等对象的信息. Library cache需要解决三个问题: 1.快速定位的问题:Library cache中对象众多,Oracle如何管理这些对象,以便服务进程可以迅速找到他们需要的信息.比如某个服务进程需要迅速定位

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

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