关于library cache lock和pin的模式

生产系统(10203 10G  RAC)出现了一个这样的问题，4号的晚上19点有同事对一个表执行了modify column的ddl，完后忘记手工编译无效对象了，这样系统中依赖此表的pkg就处于失效状态。5号早上来发现系统中有大量session的等待事件是library cache lock，还有一个session等待事件是library cache pin，因为情况紧急同事就将相关应用停机，将这些sesssion全部kill掉，手工编译了下失效PKG，问题得到解决。
      按理来说不会出现这样的情况，夜里系统活动会话很少，如果有session访问此PKG会重新编译成有效状态的，而且OLTP系统不会有长时间运行的会话去PIN住PKG，失效包为何一夜都没能编译过去呢，因为同事没有记录当时的library cache信息，我只好从ASH和杀会话之前的会话信息着手进行调查，发现了两个可疑会话事件kksfbc child completion，从ASH中看4号凌晨就开始是这个状态，持续占用CPU，对应的sql语句正好是访问导致library cache事件的pkg，这样看来正是这两个死进程以share模式pin住了pkg对象，导致之后的第一个访问此pkg的session发现PKG失效后去重新编译(申请Exclusive的lock和Exclusive pin)，因为获取不到Exclusive pin而产生library cache pin等待，再往后访问此pkg的session会申请(share or Exclusive 那个模式? )的lock，由于lock被第一个sesion以Exclusive模式得到，所以后面的session因为获取不到lock会产生library cache lock等待。事件过程大概就是这样的
       4号凌晨2点:有两个会话在调用pkg的时候出现bug(Bug 6795880)，未能释放对象上的cache pin
        4号晚7点:同事对对象进行ddl，PKG失效
       4号晚7点-5号早5点:系统中大量libary cache pin事件
       5号早5点-7点:系统中大量library cache pin 和 library cache lock
        5号早7点-8点:系统中大量library cache lock，一个libary cache pin
        5号早8点:杀会话，重编译，解决
但是还有一些疑问，针对同一PKG对象，5号早上的大量lock一个pin的现象同我的推测相符。但是4号晚上和5号凌晨为何会出现多个library cache pin事件而没有lock事件呢，第一个访问此失效PKG的session会去编译此session，获得exclusive模式lock和等待exclusive模式的pin，这样的话后续访问此PKG的session就不可能获取share模式的lock了，又如何去获取pin呢（即产生library cache pin等待事件）。请各位大侠指点一下，多谢了。

       我们都知道Oracle使用两种数据结构来进行shared pool的并发控制:lock 和 pin.Lock在handle上获得,在pin一个对象之前,必须首先获得该handle的锁定.LOCK和PIN 锁定主要有这几种模式: None,Null,share,Exclusive.
       那么LOCK和PIN有几种组合方式呢，分别对应着什么操作，哪位朋友能指教下

访问类型	LOCK MODE	PIN  MODE
PKG对象执行/访问	Share	Share
TABLE对象的访问	Share	Share
对象的DDL	Exclusive	Exclusive
有木有?	Share	Exclusive
有木有?	Exclusive	Share

[ 本帖最后由 deepshrift 于 2011-9-6 13:47 编辑 ]

library cache lock/pin有none模式木？

有none模式

NONE就是不需要持有句柄吧，呵呵

各位朋友指教指教啊