遇到Library cache load lock 等待事件

遇到Library cache load lock 等待事件:

在Troubleshooting Library Cache: Lock, Pin and Load Lock (Doc ID 444560.1)这篇文章中,详细解释了该等待事件:

If an object is not in memory, then a library cache lock cannot be acquired on it.
 The object has to be loaded into the memory to acquire the lock.
 The session tries to find the load lock for the database object so that it can load the object.
 In order to prevent multiple processes requesting the load of the same object simultaneously, the other requesting sessions have to wait for the library cache load lock as the lock is busy with loading the object into the memory.

 The waits on the library cache load lock is due to the objects not being available in memory.
 The unavailability of the library cache object in the library cache is due to the undersized shared pool causing frequent reloads or too many hard parse as a result of unshared sqls.

有如下几种方法避免该等待事件的发生:

?Increase the shared pool ( to avoid high reloads)
?Increase the session cached cursors (to avoid the cursors flushing out of shared pool)
?Set cursor_sharing to force (to reduce hard parsing)--again this may change the plan and performance of query. This will change literals to use binds; so plan may change: 

后来总结了一下:

该db上之所以发生Library cache load lock等待事件,是因为将shared_pool_size的大小减小了。看来,貌似简单的操作,可能会引起很多问题。于是后来找时间加大了shared_pool_size

DBA在生产库上的一举一动都可能引起各种问题。慎重!

时间: 2024-11-04 17:06:34

遇到Library cache load lock 等待事件的相关文章

Oracle 11g下重现library cache lock等待事件

从下面的例子中可以看到,在生产数据库中对象的重新编译会导致library cache lock,所以应该尽量避免在业务高峰期编译对象.如果是package或过程中存在复杂的依赖关系就极易导致library cache lock的出现,所以在应用开发的过程中,也应该注意这方面的问题. session1: SQL> select * from v$version; BANNER -------------------------------------------------------------

共享池之六: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的数量:[email prote

oracle9i statspack 报告 分析 direct path read 等待事件

DB Name         DB Id    Instance     Inst Num Release     Cluster Host ------------ ----------- ------------ -------- ----------- ------- ------------ LIXORA          1409317108 LIXORA                1 9.2.0.1.0   NO      lixora-DATA Snap Id     Sna

Oracle Library Cache深入解析

Oracle Library Cache深入解析 每一个进入库缓存的对象,在库缓存中都被按照本身内容分割成多块进行存贮.Oracle这样做的目的是为了更灵活的内存管理,因为在内存寻找大块连续的内存,总比寻找小块连续内存更慢一些.如果一个库缓存对象(如一条SQL语句的执行计划),它所占的内存被切割成4个小块,它们分别被存放在库缓存的各处,并且互不相连.为了将这4个小块组合起来,Oracle另外这个库缓存对象分配一小块内存,这块内存中存有其他4个小块内存的地址,并且,还有一些有关此库缓存对象的基本信

等待事件监测性能瓶颈

1. 会话等待事件性能视图:v$system_event, v$session_event, v$session_wait v$system_event: 查看整个系统级或者说最高级别的整体系统性能情况,这里面没有每个会话的相关信息,而是对每个事件总计了从系统启动以来在所有会话中发生过的情况.这个视图有5个字段: event: 列出所有发生的事件的名称. total_waits: 从数据库启动到现在这个等待事件总的等待次数. total_timeouts:总的等待超时次数. time_waite

db file sequential read等待事件 --转载

db file sequential read db file sequential read等待事件有3个参数:file#,first block#,和block数量.在10g中,这等待事件受到用户I/O等待级别的影响.当处理db file sequential read等待事件的时候,牢记以下关键想法. l         Oracle进程需要一个当前不在SGA中的块,等待数据库块从磁盘读入到SGA中 l         要看的两个重要的数字是单独会话的TIME_WAITED和AVERAGE

oracle等待事件以及解决方案

我们可以通过视图v$session_wait来查看系统当前的等待事件,以及与等待事件相对应的资源的相关信息,从而可确定出产生瓶颈的类型及其对象. v$session_wait的p1.p2.p3告诉我们等待事件的具体含义,根据事件不同其内容也不相同,下面就一些常见的等待事件如何处理以及如何定位热点对象和阻塞会话作一些介绍. <1> db file scattered read DB 文件分散读取 (太多索引读,全表扫描-----调整代码,将小表放入内存)这种情况通常显示与全表扫描相关的等待.当全

ORACLE 常见等待事件

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

Oracle Study之--Oracle等待事件(8)

Oracle Study之--Oracle等待事件(8)      库缓存中的对象在库缓存中被切割成多个内存块,另有一个对象句柄记录了各个内存块的地址和其他的一些信息.当你要修改句柄中的信息时,需要在句柄上加独占锁,而如果另一个进程恰好在这时要求读.写句柄中的信息,它就必须等待.此时的等待就被Oracle记入Library cache lock事件.而读.写对象内存块也是无法同时进行的,有人如果正在写,你的读操作就必须等待,读写内存块的等待事件就是Library cache pin.如果这两个等