借这次的现象整理了一下（顺便兼带Library Cache Lock）：

Wait event Library Cache Pin发生于，引用Metalink Doc.34579.1的原文：

A wait for “Library Cache Pin” implies some other session holds that PIN in an incompatible Mode.

Library Cache Mode 有3种 null, share, exclusive.

Incompatible mode 也就是在share和exclusive之间， 这2个模式是需要串行的 （当然exlusive和exclusive也是）。

这里又一个问题出来了：

从这段话能得出一个结论，就是Share 和 Share这种模式，Compatible，是可以同时被2个Session同时Pin的。--1

但我们在v$session_wait中发现的wait event Library Cache Pin 是属于Latch Free这个大类，也就说，waiting的是Library Cache Pin Latch，而Latch是一种串行化的机制，只有一个Process能获得。--2

结合1，2 有个推论，Process在获得Library Cache Pin Latch并且在可以Pin之后会释放这个Latch。

举一个High Activity 的Instance中Compile Procedure经常出现的问题，系统Hang住，很多Session的wait events 是Library Cache Pin。

Compile的时侯，所要获得的Library Cache Pin的mode是exclusive。由于很多Procedure的Dependence很复杂,而如果Library Cache中的一个object被PIN，那相关的objects都必须被PIN住。但相关object可能被other session Pined with incompatible Mode，此时进行Compile的Session就不得不花很多时间来Pin住其他的Objects，这样会长期持有Library Cache Pin 在exclusive Mode, 当其后第一个Session 获得了Library Cache Pin Latch的时侯，发现无法Pin住，按EYGLE的说法，取得PIN之前最多3秒，那这3秒中后续的Session则只能waiting for Libraray Cache Pin Latch.

在上周的案例中，并没有在进行Compile，有的只是Cost expensive Hard Parse。Hard Parse的过程中会用到下面的这些Latch

Library Cache

Shared Pool

Library Cache Lock

Library Cache Pin

Library Cache Pin Allocation

做个实验：

Alter system set “_kgl_latch_count”=1 scope=spfile;

Restart Instance.

发现个有个有趣的现象：Library Cache Latch的Children变为1，Library Cache Pin Latch，和Library Cache Pin Allocation Latch的children也变为1了。

看来_kgl_latch_count控制着所有关于Library Cache的Latch chilren的数目

另外9i里是没有Library Cache Lock这个Latch的，10g才有（还是说不是独立Latch？）

然后开起多个Session查询同一个Table，Where条件只有一个。

第一次测试是用了PL/SQL写的Procedure.测试的Bind Variable 情形：

观察到的Latch Contention是Cache Buffer Chains, 没有观察到Library Cache方面。

第二次是用Shell调用SQLPLUS 传Literal SQL，结果什么也没观察到，估计是这种方式execution频率还不算高，计划构造复杂SQL再测试下。

所以Soft Parse下Execute的时侯Pin是shared mode.

Wait event Library Cache Pin按前述只能发生于Library Cache Pin被exclusive占住的情形。所以当有Library Cache Pin发生的时侯，基本可以判断为有Hard Parse, Compile, DDL等。

另外在测试中发现一个现象，一句SQL执行后，Library Cache, Library Cache Pin, Library Cache Pin Allocation中增加的Gets计数都在同一编号的CHILD#上。

也就是说这三个Latch 是一组提供服务的，所以我想大概每组会负责Hash Bucket Array的一部分。

To be continued...