library cache lock/pin等待事件

一般情况下情况下，Library cachelock都是由DDL导致的

1、存储过程执行中进行修改OR重编译

2、存储过程执行中,删除重建依赖对象

3、密码延迟验证

4、SQL编译过程中

概念描述

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模式获得后，创建执行计划。

参数解析

COL NAME FORMAT A20    
COL PARAMETER1 FORMAT A15   
COL PARAMETER2 FORMAT A15   
COL PARAMETER3 FORMAT A20 
select NAME,PARAMETER1,PARAMETER2,PARAMETER3 from v$event_name where name like 'library cache lock';

NAME		     PARAMETER1      PARAMETER2      PARAMETER3
-------------------- --------------- --------------- --------------------
library cache lock   handle address  lock address    100*mode+namespace

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

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

案例介绍

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

select p3raw,count(*) from gv$session where event = 'library cache lock' group by p3raw;

p3raw                count(*)
-------------------- --------------- 
0000000007F0002           30

select to_number('7F','xxxxxxxxxxxxxx') from dual;

TO_NUMBER('7F','XXXXXXXXXXXXXX')
--------------------------------
			     127

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

select distinct KGLHDNSP,KGLHDNSD from x$kglob where KGLHDNSP = 127;

KGLHDNSP              KGLHDNSD
-------------------- --------------- 
127                 Last_Successful_Logon_Time

使用x$kglob获得了namespace名。

Last_Successful_Logon_Time是12c新特性，用于在用户登陆时打印上次成功登陆的时间，可禁用。

但是此次故障本人并没有选择禁用该特性。因为lock模式全部为2，也就是说阻塞者另有他人。

经过分析，是由于2个节点CPU个数不一致导致的lck进程被enq:IV contention阻塞，lck进程又导致了其他enqueue事件的等待。

后将CPU个数多的节点减少到与少的节点个数一致并重启实例后数据库正常。

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

SQL> select distinct KGLHDNSP,KGLHDNSD from x$kglob;

  KGLHDNSP KGLHDNSD
---------- --------------------------------------------------------------------------------------------------------------------------------
	 0 SQL AREA
	 4 INDEX
	 1 TABLE/PROCEDURE
	 3 TRIGGER
	52 SCHEDULER EARLIEST START TIME
	64 EDITION
	48 MULTI-VERSION OBJECT FOR INDEX
	69 DBLINK
	45 MULTI-VERSION OBJECT FOR TABLE
	 2 BODY
	10 QUEUE
	23 RULESET
	24 RESOURCE MANAGER
	73 SCHEMA
	51 SCHEDULER GLOBAL ATTRIBUTE
	38 RULE EVALUATION CONTEXT
	74 DBINSTANCE
	82 SQL AREA BUILD
	75 SQL AREA STATS
	 5 CLUSTER
	18 PUB SUB INTERNAL INFORMATION

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

案例介绍

存储过程语法出现错误，数据库无法进行正确的SQL解析导致

现象
     客户数据库在每周五出现大量的“library cache lock”等待事件，数据库业务办理失败。

问题分析
     从ASH视图我们可以发现，数据库从9:01分开始出现“library cache lock”等待事件。

    如上图，等待事件中P3TEXT 对应的是100*mode+namespace，对于的P3RAW十六进制值为52002。namespace 52转为相应的十进制为82，mode为2。

• 通过查询82对应的具体library cache操作类型为“SQL AREA BUILD”

• library cache lock中“SQL AREA BUILD”对应的原因大部分都是SQL解析失败的原因导致。通过在测试数据库对该问题进行测试重现，在v$sysstat视图可以看到数据库有明显的SQL解析错误的情况。

• 通过设置10035 event将解析错误的SQL打印到alert日志，找出具体的解析错误SQL。
      ALTER SYSTEM SET EVENTS ‘10035 trace name context forever, level 1’;

我们可以看到，存在较多的解析错误的SQL，通过业务人员修复存储过程对应的错误后，再次在测试库进行相应的测试，数据库没有再出现“library cache lock”类等待事件。由此可以证明，数据库出现的大量“library cache lock”是由于存储过程语法出现错误，数据库无法进行正确的SQL解析导致。

另外数据库还存在较多的硬解析。每秒有640的硬解析次数，建议联系业务将未使用绑定变了的SQL进行绑定变量处理。