library cache lock/pin等待事件

概念描述

Library cache lock控制对于Library Cache Object的并发访问，通过获取Object Handle上的锁定持有。通常在定位Library Cache对象时，就需要持有library cache lock。

对包，存储过程，函数，视图进行编译的时候，Oracle就会在这些对象的handle上面首先获得一个Library Cache Lock；然后在这些对象的Heap上获得Pin，这样就能保证在编译的时候其它进程不会来更改这些对象的定义，或者将对象删除。

Lock管理并发，Pin管理一致性。lock flag位于handle，是LCO对象的metadata之一。而pin针对LCO heap，确保在读取、修改LCO的过程中，不会被flush出library cache。故而，有先library cache lock，后有library cache pin.但是有lock未必有Pin。

此外，除了用户进程对lco的读取、删除需要lbl外，由于空间需求等原因，要将lco handle老化出lc，也需要持有Lock.

硬解析过程中，若找到了适当的chunk，对SQL相应的HANDLE以EXCLUSIVE模式获得library cache lock，并创建LCO信息。创建LCO后，library cache lock变为null模式，将library cache pin以exclusive模式获得后，创建执行计划。

参数解析

p3可以用于获取锁的模式以及所在的namespace，便于定位问题所在lco。

LOCK的持有模式：1-NULL 2-共享 3-独占

案例介绍

1.某天客户反馈某数据库非常慢，top1等待事件为library cache lock。通过p3 raw 转换得到了该等待的锁模式以及namespace。

得到namespace id 为127，锁模式为2.

使用x$kglob获得了namespace名。 last successful logon time是12c新特性，用于在用户登陆时打印上次成功登陆的时间，可禁用。但是此次故障本人并没有选择禁用该特性。因为lock模式全部为2，也就是说阻塞者另有他人。经过分析，是由于2个节点CPU个数不一致导致的lck进程被enq:IV contention阻塞，lck进程又导致了其他enqueue事件的等待。后将CPU个数多的节点减少到与少的节点个数一致并重启实例后数据库正常。

2.11g的密码延迟验证也是lbl的重灾区，namespace为 ACCOUNT_STATUS

3.某次巡检发现某个时间段lbl非常高，由于ash无p3raw，不能通过拆解该参数来分析。通过对blocking session的分析，为创建表的同时，对表进行了查询导致的等待。

总结

lbl的等待情况比较复杂，需要具体情况具体分析。