由最长SQL想到的Latch Free( Library Cache Pin/Lock)整理~~草稿

今天回想这中间的过程：

这句SQL 导致Parse，execute占用大量资源，Parse的过程需要一直持有Library Cache，而Library Cache Latch的个数是有限的，这点引起了Library Cache的竞争。而Library Cache Pin的Contention有点疑惑，这可能也是一个我概念比较模糊的地方，今天又上Metalink和PUB上找了很多。

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

[@more@]

Library Cache Pin/Lock 和 Library Cache Pin Latch是什么？

这是我经常感到疑惑的，很多人讲了很多，看完却也觉得说不清。上午看到PUB上今年6月份的关于Latch的帖子，其中BITI_RAINY的说法给我很大启发。

最主要集中在Library Cache Pin/Lock 是不是Latch? 似乎常看到Latch Free的等待是Library Cache Pin的wait event。

我现在理出来的思路是：Library Cache Pin/Lock是一种锁定机制，而Library Cache Pin/Lock Latch责是实施这种机制之前的闩。

也就是说，想在 Library Cache 中干 Pin 和 Lock 这 2 件事，该 Process 必须先获得对应的 Latch ，只有拿到了 Latch ，才能接下去做 Pin/Lock 。从这个角度说，可以把 Library Cache Pin/Lock 和 Obtain Library Cache Pin/Lock Latch 等同起来。

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...

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10856805/viewspace-1012872/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10856805/viewspace-1012872/