今天回想这中间的过程:
这句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/