oracle library cache pin、library cache lock原理分析

oracle  library cache pin、library cache lock原理分析

 

前段时间一直在研究oracle中复杂的component之shared pool，今天也不例外，对library cache lock、library cache pin进行一下深入的研究，

另外呢，在后边一篇文章也会通过案例来介绍相应的cursor：pin s on wait x等待的原理以及处理办法。

在研究本章内容之前啊，建议懂得一些shared pool的相关知识，我之前写过相关的blog日志，虽然谈不上什么经典，但是也可以帮我提提意见。

 

第一：原理知识：

  1、什么是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, no other client can change the object)

This lock is also obtained to locate an object in the library cache.

Wait Time: 3 seconds (1 second for PMON)

Parameter Description

object address Address of the object being loaded

lock address Address of load lock being used

mask Indicates which data pieces of the object that needs to be loaded

翻译一下：在这个library cache lock控制library cache的并发管理，以便。

   1）一个客户端可以阻止其他的客户端访问同一个对象

   2）这个客户端可以长时间的维护一个依赖对象（例如，没有其他用户可以修改该对象）

这种锁在用户试图在library cache中查询定位对象的时候也会获得。对于该锁有三种模式分别是null、share、exclusive，对于该锁的获得等待三秒，一秒用于pmon进程如果超过3秒那么就

会产生等待。

那对于上面说的1和2怎么理解呢？

在我们解析sql或是编译pl/sql语句期间，我们需要获得被应用的数据库对象（表，视图，过程，函数，包，包体，触发器，索引，聚簇，同义词）的library cache lock；这个锁在解析与编

译结束时会被释放。注意：cursor（sql与pl/sql区），管道（pipes）和其他瞬时（transient）对象不适用该锁，library cache lock上的死锁不会被自动检测到，对其的操作是瞎子进行的

。

  2、为什么需要library cache lock

library cache lock是在对象和他们的sql语句之间维持了一种依赖对象机制，假如对象的定义（如字段）被重新定义了或是这个解析锁被“损坏”了，那么依赖对象肯定也失效了，这种维持就

是通过library cache lock实现的。举个例子来说，如果一个表的字段被删除了，那么所有依赖该表的sql将都会变的失效了，必须在下一次访问该 对象的时候重新进行解析，那么library

cache lock就是实现这种机制。而这也是需要有一个队列的，library cache lock是在library cache handle上获得，如果存在不兼容的模式，那么其他的会话必须这时候进行等待。

  3、什么是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.

Wait Time: 3 seconds (1 second for PMON)

Parameter Description

handle address Address of the object being loaded

pin address Address of the load lock being used. This is not the same thing as a latch or an enqueue, it is basically a State Object.

mode Indicates which data pieces of the object that needs to be loaded

namespace

翻译一下：

这个library cache pin是维护管理library cache的并发性。在pin一个对象的时候将会把heap载入到内存中，如果一个会话视图编辑或是检查这个对象的时候在获得lock之后必须获得pin。

对于heap怎么理解？它是内存堆，里面包含了很多信息，可以看一下下图就明白了。

 

 

 

同样library cache pin也有三种模式分别是null，share、exclusive，当需要访问被缓存到library cache中的数据对象的时候（如，表，索引，聚簇，同义词，视图，过程，包，包体，触

发器、）必须要先pin，当出现library cache pin等待的时候那么这个对象正在被其他会话进行不兼容的模式持有。对于以上的参数，下边会有介绍，就不在这个小命题说了。

 4、我为什么需要library cache pin？

library cache pin是为了处理当前执行依赖对象的，例如，当一个会话在执行访问（sql）这个加载的对象的时候不应该被修改。也就是说，当一个解析锁在没有释放之前，其他会话必须获

得library cache pin 的exclusive模式才能将该对象进行修改。同时，可以想象一个长的sql可能会导致library cache pin的等待。

到了这里我发现，对于library cache 有两种锁，一种为lock另一种是pin，lock是存在于library cache object handle上的，而pin是为了在内存堆维持object的一致性。oracle在sql解析

或是编译对象的时候需要获得library cache lock和library cache pin，防止其他会话对执行的sql对象进行修改。另外在sql的硬解析的时候会获得library cache lock，阻止其他会话对对

象的修改，那么其他会话就会发生等待。

5、什么是library cache load lock？

官方解释：

The session tries to find the load lock for the database object so that it can load the object. The load lock is always obtained in Exclusive mode, so that no other

process can load the same object. If the load lock is busy the session will wait on this event until the lock becomes available.

Wait Time: 3 seconds (1 second for PMON)

Parameter Description

object address Address of the object being loaded

lock address Address of load lock being used

mask Indicates which data pieces of the object that needs to be loaded

这种锁一般发生在编译和重新编译对象的时候出现，如果我试图重新编译一个失效的对象，而这个对象正好也被其他会话给pin住了，那么会产生错误。

第二、参数分析以及咋去查？

1、x$kgllk, x$kglpn and x$kglob 

x$kgllk:kernal general library lock

x$kglpn ：kernel general library pin

x$kglob:kernel general library object

查看相关结构

x$kgllk is externalizing all locking structures on an object. Entries in x$kglob acts as a resource structure. x$kglpn is externalizing all library cache pins.

对于该类视图字段，我就是猜，如x$kgllk 中的inst_id代表实例号，kgllkadr代表锁的地址，kgllkuse代表持有该锁的用户，kgllkses代表会话sid，kgllksnm代表这个锁的命名空间，

kgllkhdl代表锁定的handle地址也就是library cache object handle地址，kgllkmod代表锁的模式，kgllkreq代表需要请求的锁的类型，kgllksqlid代表该锁被sql持有的sqlid，user_name

代表用户名等。对于x$kglob和x$kglpn每个字段也是同样的方法，他们的默写字段都是可以和其他会话进行关联的，之后会发现。

2、参数分析

对于library cache pin有如下参数：

Parameter Description

handle address Address of the object being loaded

pin address Address of the load lock being used. This is not the same thing as a latch or an enqueue, it is basically a State Object.

mode Indicates which data pieces of the object that needs to be loaded

namespace  namespace&&encoded mode

这三个参数其实以前我就见过就是对应的v$session中字段p1、p2、p3而p1raw代表是p1的十六进制形式p2raw和p3raw都是一样的，需要说明的是v$session中的这三个字段对于不同的情况有不

同的含义，而现在我们在研究library cache pin那么这三个字段表示内容如下：

p1=handle address

p2=pin address

p3=namespace&&encoded mode

对于p1raw可以对应于x$kglob中的KGLHDADR字段x$kglpn中的KGLPNHDL字段，x$kgllk中的KGLLKHDL字段，后边有sql关联。

对于p2raw代表pin它自己的地址

对于namespace&&encoded mode有如下内容：

In Oracle 7.0 - 8.1.7 inclusive the value is 10 * Mode + Namespace. 

In Oracle 9.0 - 11.1 inclusive the value is 100 * Mode + Namespace. 

mode 代表这个pin需要获得什么样的锁。

2：代表shared mode