Library Cache: Lock, Pin and Load 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 maintain a dependency for a long time (for example, so that no other client can change the object).

This lock is also obtained to locate an object in the library cache.
Library cache lock will be obtained on database objects referenced during parsing or compiling of SQL or PL/SQL statements (table, view, procedure, function, package, package body, trigger, index, cluster, synonym). The lock will be released at the end of the parse or compilation.

Cursors (SQL and PL/SQL areas), pipes and any other transient objects do not use this lock.
Library cache lock is not deadlock sensitive and the operation is synchronous.

Parameters:
 

  • handle address
    Address of the object being loaded.
  • lock address
    Address of the load lock being used. This is not the same thing as a latch or an enqueue, it is a State Object.
  • Mode
    Indicates the data pieces of the object which need to be loaded.
  • Namespace
    The name of the object namespace as it is displayed in V$DB_OBJECT_CACHE view

What is "Library cache pin"?

This event manages library cache concurrency. Pinning an object causes the heaps to be loaded into memory. If a client wants to modify or examine the object, the client must acquire a pin after the lock. Pin can be acquired in NULL, SHARE or EXCLUSIVE modes and can be considered as a special form of lock. A wait for a "library cache pin" implies some other session holds that PIN in an incompatible mode.

Library cache pin will be obtained on a database object that is currently cached in the library cache (table, view, procedure, function, package, package body, trigger, index, cluster, synonym). In the library cache, a database object is cached in 2 parts: "handle" and "object". Library cache pin is only held when the "object" part is cached.

It is not deadlock sensitive and the operation is synchronous

时间: 2024-10-16 00:51:35

Library Cache: Lock, Pin and Load Lock的相关文章

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

Library cache lock/pin详解

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

怎么发现RAC环境中'library cache pin'等待事件的阻塞者(Blocker)?

怎么发现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

共享池之八:软解析、硬解析、软软解析 详解一条SQL在library cache中解析涉及的锁

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

外键约束列没建索引导致大量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一次, PARSING IN CURSOR #3 len=93 dep=2 uid=0 oct=3 lid=0 tim=14

共享池之六: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

library cache lock和cursor: pin S wait on X等待

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

【翻译自mos文章】找到持有library cache lock session的方法

找到持有library cache lock session的方法 参考自: How to Find which Session is Holding a Particular Library Cache Lock (文档 ID 122793.1) 其实就是两种方法: 一.Systemstate Analysis 此处不做翻译,原文转载 Systemstate event will create a tracefile containing detailed information on eve

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

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