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

3：代表exclusive mode

namespace仅仅是一个在library cache的namespace的数值，其中每个数值含义如下:

0 sql area

1 table/procedure/function/package header

2 package body

3 trigger

4 index

5 cluster

6 object

7 pipe

13 java source

14 java resource

32 java data

3、诊断方式

常见的情况有如下两项：往往对于这种诊断可以更加准确的确定问题。

1）当我在一个对象上执行dml语句的时候，其他会话正在视图改变该表的定义，如alter table xxxx modify等，这个时候dml就会被hang住，需要等待的时间根据这个表的大小不同而不同。

这个时候我在v$lock视图上会看到LMODE=6, TYPE=TM 并且id1也指向了操作的object_id,并且还有其他session的等待获取锁的信息。

2）当我们在编译一个procedure或是packet的时候，会获得library cache lock以及library cache pin，其他会话去使用它们，那么这个时候也是会产生等待。

第一种去诊断的方式是通过oradebug进行查看信息或是通过alter system set events 'immediate trace name systemstat level 10';来进行查看内部信息：

注意：

As systemstate dumps are instance specific, they tend to be

inconclusive with hanging problems involving Oracle Parallel Server

(OPS) unless you get them from each node. You will need 3 system state

dumps from each node for OPS.

eg：

SQL> oradebug setmypid

Statement processed.

SQL> oradebug unlimit

Statement processed.

SQL> oradebug dump systemstate 266;

Statement processed.

SQL>