今天回想這中間的過程：

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

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

相關文章