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

學習動態性能表

第十一篇-(1)-V$LATCH  2007.6.7

 

　　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 poo         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  2007.6.6

 

　　數據庫中有些類別的latches擁有多個。V$LATCH中提供了每一個類別的總計信息。若是想看到單個latch，你能夠經過查詢本視圖。

 

例如：

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

 

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