这两个等待事件其实很少出现在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

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

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模式的)这是为了,防止其他会话也访问这个对

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

同事反映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

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 和

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

外键约束列并没有导致大量建筑指数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

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.

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

Bug 7715339 - Logon failures causes "row cache lock" waits - Allow disable of logon delay (文档 ID 7715339.8) 究竟部  改动时间:2012-7-26类型:PATCH  为此文档评级 通过电子邮件发送此文档的链接 在新窗体中打开文档 可打印页 Bug 7715339  Logon failures causes "row cache lock" waits - A

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. CPU time CPU time其实不是真正的等待事件.是衡量CPU是否瓶颈的一个重要指标.一般来讲,一个良好的系统,CPU TIME 应该排在TOP 5 TIME Event的最前面. 当然这也是相对的, 如果不存在显著的 latch wait 或过高的logical read 等,  CPU time 占的比例高才是令人放心的. 也就是说CPU在高效率干活是好事,但是是否因为低效的设置或SQL而消耗CPU时间就需要注意了. NUM_CPU_SOCKETS    物理CPU的数目 NU

在Oracle 10g中的等待事件有872个,11g中等待事件1116个. 我们可以通过v$event_name 视图来查看等待事件的相关信息     一． 等待事件的相关知识 1.1 等待事件主要可以分为两类,即空闲(IDLE)等待事件和非空闲(NON-IDLE)等待事件.1). 空闲等待事件指ORACLE正等待某种工作,在诊断和优化数据库的时候,不用过多注意这部分事件.2). 非空闲等待事件专门针对ORACLE的活动,指数据库任务或应用运行过程中发生的等待,这些等待事件 是在调整数据库的时候

1Buffer busy waits从本质上讲,这个等待事件的产生仅说明了一个会话在等待一个Buffer(数据块),但是导致这个现象的原因却有很多种.常见的两种是: 当一个会话视图修改一个数据块,但这个数据块正在被另一个会话修改时. 当一个会话需要读取一个数据块,但这个数据块正在被另一个会话读取到内存中时. 在新的版本中,第二种情况已经被独立出来,以read by other session取代~Buffer busy waits等待事件常见于数据库中存在的热快的时候,当多个用户频繁地读取或者修

一． 等待事件的相关知识 1.1 等待事件主要可以分为两类,即空闲(IDLE)等待事件和非空闲(NON-IDLE)等待事件.1). 空闲等待事件指ORACLE正等待某种工作,在诊断和优化数据库的时候,不用过多注意这部分事件.2). 非空闲等待事件专门针对ORACLE的活动,指数据库任务或应用运行过程中发生的等待,这些等待事件 是在调整数据库的时候需要关注与研究的. 在Oracle 10g中的等待事件有872个,11g中等待事件1116个. 我们可以通过v$event_name 视图来查看等待事件

转自 http://blog.itpub.net/29371470/viewspace-1063994/ 1. Buffer busy waits 从本质上讲,这个等待事件的产生仅说明了一个会话在等待一个Buffer(数据块),但是导致这个现象的原因却有很多种.常见的两种是:--当一个会话视图修改一个数据块,但这个数据块正在被另一个会话修改时.--当一个会话需要读取一个数据块,但这个数据块正在被另一个会话读取到内存中时.在新的版本中,第二种情况已经被独立出来,以read by other ses