學習動態效能表(11)--v$latch$v$latch_children

學習動態效能表第十一篇-(1)-V$LATCH

　　Oracle Rdbms應用了各種不同型別的鎖定機制，latch即是其中的一種。Latch是用於保護SGA區中共享資料結構的一種序列化鎖定機制。Latch的實現是與作業系統相關的，尤其和一個程式是否需要等待一個latch、需要等待多長時間有關。Latch是一種能夠極快地被獲取和釋放的鎖，它通常用於保護描述buffer cache中block的資料結構。與每個latch相聯絡的還有一個清除過程，當持有latch的程式成為死程式時，該清除過程就會被呼叫。Latch還具有相關級別，用於防止死鎖，一旦一個程式在某個級別上得到一個latch，它就不可能再獲得等同或低於該級別的latch。

　　本檢視儲存自例項啟動各類栓鎖的統計資訊。常用於當v$session_wait中發現栓鎖競爭時鑑別SGA區中問題所在區域。

　　v$latch表的每一行包括了對不同型別latch的統計，每一列反映了不同型別的latch請求的活動情況。不同型別的latch請求之間的區別在於，當latch不可立即獲得時，請求程式是否繼續進行。按此分類，latch請求的型別可分為兩類：willing-to-wait和immediate。

　　Willing-to-wait：是指如果所請求的latch不能立即得到，請求程式將等待一很短的時間後再次發出請求。程式一直重複此過程直到得到latch。
　　Immediate：是指如果所請求的latch不能立即得到，請求程式就不再等待，而是繼續執行下去。

V$LATCH中的常用列：
NAME：latch名稱
IMMEDIATE_GETS：以Immediate模式latch請求數
IMMEDIATE_MISSES：請求失敗數
GETS：以Willing to wait請求模式latch的請求數
MISSES：初次嘗試請求不成功次數
SPIN_GETS：第一次嘗試失敗，但在以後的輪次中成功
SLEEP[x]：成功獲取前sleeping次數
WAIT_TIME：花費在等待latch的時間

V$LATCH中的連線列
Column View Joined Column(s)
--------------------- ------------------------------ ------------------------
NAME/LATCH# V$LATCH_CHILDREN NAME/LATCH#
NAME V$LATCHHOLDER NAME
NAME/LATCH# V$LATCHNAME NAME/LATCH#
NAME V$LATCH_MISSES PARENT_NAME

示例：下列的示例中，建立一個表儲存查詢自v$latch的資料：
CREATE TABLE snap_latch as SELECT 0 snap_id, sysdate snap_date, a.* FROM V$LATCH a;
ALTER TABLE snap_latch add (constraint snap_filestat primary key (snap_id, name));

最初，snap_id被置為0，稍後，snap_latch表的snap_id列被更新為1：
INSERT INTO snap_latch SELECT 1, sysdate, a.* FROM V$LATCH a;
注意你透過sql語句插入記錄時必須增加snap_id的值。

在你連續插入記錄之後，使用下列的select語句列出統計。注意0不能成為被除數。

SELECT SUBSTR(a.name,1,20) NAME, (a.gets-b.gets)/1000 "Gets(K)",
(a.gets-b.gets)/(86400*(a.snap_date-b.snap_date)) "Get/s",
DECODE ((a.gets-b.gets), 0, 0, (100*(a.misses-b.misses)/(a.gets-b.gets))) MISS,
DECODE ((a.misses-b.misses), 0, 0,
(100*(a.spin_gets-b.spin_gets)/(a.misses-b.misses))) SPIN,
(a.immediate_gets-b.immediate_gets)/1000 "Iget(K)",
(a.immediate_gets-b.immediate_gets)/ (86400*(a.snap_date-b.snap_date)) "IGet/s",
DECODE ((a.immediate_gets-b.immediate_gets), 0, 0,
(100*(a.immediate_misses-b.immediate_misses)/ (a.immediate_gets-b.immediate_gets)))

IMISS
FROM snap_latch a, snap_latch b
WHERE a.name = b.name
AND a.snap_id = b.snap_id + 1
AND ( (a.misses-b.misses) > 0.001*(a.gets-b.gets)
or (a.immediate_misses-b.immediate_misses) >
0.001*(a.immediate_gets-b.immediate_gets))
ORDER BY 2 DESC;

下例列出latch統計項，miss列小於0.1%的記錄已經被過濾。
NAME Gets(K) Get/s MISS SPIN IGets(K) IGet/s IMISS
------------------ -------- ------- ----- ------ -------- ------- -----
cache buffers chai 255,272 69,938 0.4 99.9 3,902 1,069 0.0
library cache 229,405 62,851 9.1 96.9 51,653 14,151 3.7
shared pool 24,206 6,632 14.1 72.1 0 0 0.0
latch wait list 1,828 501 0.4 99.9 1,836 503 0.5
row cache objects 1,703 467 0.7 98.9 1,509 413 0.2
redo allocation 984 270 0.2 99.7 0 0 0.0
messages 116 32 0.2 100.0 0 0 0.0
cache buffers lru 91 25 0.3 99.0 7,214 1,976 0.3
modify parameter v 2 0 0.1 100.0 0 0 0.0
redo copy 0 0 92.3 99.3 1,460 400 0.0

什麼時候需要檢查latch統計呢？看下列項：

misses/gets的比率是多少
獲自spinning的misses的百分比是多少
latch請求了多少次
latch休眠了多少次

　　Redo copy latch看起來有很高的的失誤率，高達92.3%。不過，我們再仔細看的話，Redo copy latches是獲自immediate模式。immediate模式的數值看起來還不錯，並且immediate模式只有個別數大於willing to wait模式。所以Redo copy latch其實並不存在競爭。不過，看起來shared pool和library cache latches可能存在競爭。考慮執行一條查詢檢查latches的sleeps以確認是否確實存在問題。

latch有40餘種，但作為DBA關心的主要應有以下幾種：
Cache buffers chains latch：當使用者程式搜尋SGA尋找database cache buffers時需要使用此latch。
Cache buffers LRU chain latch：當使用者程式要搜尋buffer cache中包括所有 dirty blocks的LRU (least recently used) 鏈時使用該種latch。
Redo log buffer latch：這種latch控制redo log buffer中每條redo entries的空間分配。
Row cache objects latch：當使用者程式訪問快取的資料字典數值時，將使用Row cache objects latch。

Latches調優

不要調整latches。如果你發現latch存在競爭，它可能是部分SGA資源使用反常的徵兆。要修正問題所在，你更多的是去檢查那部分SGA資源使用的競爭情況。僅僅從v$latch是無法定位問題所在的。

關於latches的更多資訊可以瀏覽Oracle Database Concepts。

第十一篇-(2)-V$LATCH_CHILDREN

　　資料庫中有些類別的latches擁有多個。V$LATCH中提供了每個類別的總計資訊。如果想看到單個latch，你可以透過查詢本檢視。

例如：
select name,count(*) ct from v$Latch_children group by name order by ct desc;

與v$latch相比，除多child#列外，其餘列與之同，不詳述~~