Blog ' da Ara

Loading

14 Mart 2012

Latch Nedir Ve Latch Contention Sebepleri

      

Latch Nedir?
Latch SGA içerisindeki shared data yapısını korumak amacıyla ile geliştirilmiş düşük seviyeli seri data erişim mekanizmasıdır.Yani prosesiın SGA içerisinde memory parçasının tutmmasıdır.Proses bittiğinde ise ilgili latch başka bir prosese verilir. Latch İşletim sisteminden bağımsız değildir. Çünkü bir prosesin ne zaman biteceği ve ne kadar süreceği işletim sistemine bağlıdır.
                Latch bir çeşit lock dır.Şöyleki bir den çok kod betiklerinin aynı memory birimini kullanmaya çalışması ile meydana gelir. Çünkü latch tutan proses eğer sonlandırılırsa ilgili latch temizlenmiş olacaktır.
                Latch ve Enqueue arasındaki farklar Nelerdir?
                Enqueue bir oracle lock mekaizması olmasına karşın , birkaç prosesion aynı zmaanlı olarak bir kaynağı kullanımına izin verebilir.Tablo lock ları burada en iyi örnektir.Çünkü iki proses bir tabloyu share modda yada share update modda  lock edebilir.
                Latch ve enqueue arasındaki en belirgin fark burada Enqueue İşletim sistemi lock mekanizması tarafından oluşturulabilir ve .Latch ise işletim sistemi lock larından bağımsız olarak meydana gelir.Enqueue  kullanıcının lock içerisinde veri girişine izin verir. Eğer bir proses bir kaynağı lock edebilecek yapıya sahip değilse işletim sistemi tarafında enqueu mekanizmasında FIFO yasasına göre bekelmeye girer.
                Diğer bir önemli fark ise latchler enqueu ler gibi kaynağı sürekli tutamazlar.Çünkü belli zamanlama ile proses tekrarlanır ve eğer multi prosessor varsa spin yapabilir. Dolayısıyla beleten tüm prosesler aynı anda işlem yapmayı denerler.


                Latch ve Mutex Arasındaki Farklar Nelerdir?
                Mutex ler library cache içerisindeki belli prosesler olarak tanımlanmıştır.Mutexler latch lere göre daha granuler bir yapıdadır.Örneğin eğer seri çalışma prensibi yoksa ve memory içerisindeki bir data parçası belli bir prosess tarafından değiştirilmişse ve başka birprosesde benzer bir değişiklik yapacaksa , sonraki proses değişikliği yapmadan önce mutex elde etmiş olur beklemeye girer. Böylece seri çalışma prensibinin olmadığı durumlarda data corruption bu şekilde engellenmiş olur.
                Unutmamak gerekirki latch seri mekanizmanın olduğu yerde vardır. Mutex ise serilerştirmenin olmadığı yerde ortaya çıkar.
                Latch Request Moda ları nelerdir?
                Willing-to-wait:Willing-to-wait mode, bekle ve dene bekle ve dene… şeklinde bir loop oluşturur ve en sonunda latch elde edilir. Örneğin shared pool ve library cache latch.
                No wait:No wait modda eğer bir proses latch elde edememişse diğer bir proses elde etmeye çalışır ve bu şekilde eğer bütün prosesler fail olursa server proses wait konumuna geçer.Örneğin redo copy latch.
                Latch Contention Oluşma Sebebi Nedir?
                Eğer elde edilmeye çalışılan latch meşgulse loop içerisinde tekrar tekrar bu latch elde edimek için spin maydana gelir._SPIN_COUNT adındaki initialization parametre ise latch beletme üsresi kontrol altına alınmıştır.Eğer bu süre aşılırsa ilgili proses statusu CPU tarafından sleep olarak tanımlanır.Bu durum CPU da fazla kullanım miktarı ortaya çıkarır.Bu durum latch contention olarak tanımlanır ve latch kullanılabilir oluncaya kadar performans kaybına sebep olur._SPIN_COUNT parametresinin default değerinin değiştirilmesi ise oracle tarafından tavsiye edilen bir durum değildir.

                Latch contention;
V$LATCH,V$LATCH_PARENT ve V$LATCH_CHILDREN viewlarından belirlenebilir.Aşağıdaki değerler ise dikkat edilmeye değerdir.
                GETS: başaraılı willing-towait latch isteklerinin sayısı.
                MISSES:başarısız willing-towait latch isteklerinin sayısı.
                SLEEP:bir prosesin latch istekerlinden sonraya beklemeye girme sayısı
                IMMEDIATE_GETS: Her bir latch için anlık başarılı latch istekleri
                IMMEDIATE_MISSES:Her bir latch için anlık başarısız latch istekleri.

                V$LATCH_NAME ise yukarıdaki viewlar daki latchler hakkında bilgi içerir.
                                select latch#, name from v$latchname;

V$LATCH_HOLDER: Anlık Latch holder hakkında bilgi verir.

                Aşağıdaki sql ile latch hit ratio hesaplanabilir. Latch hit ratio 1 yada 1 e yakın olmalıdır.Aksi takdirde ilgili latch için tuning çalışması başlatılmalıdır.
               
                SELECT L.INST_ID,
       L.ADDR,
       L.LATCH#,
       L.NAME,
       (GETS - MISSES) / GETS "willing-to-wait Hit Ratio",
       (IMMEDIATE_GETS - IMMEDIATE_MISSES) / IMMEDIATE_GETS
          "no wait Hit Ratio"
  FROM gv$latch l
 WHERE L.GETS <> 0 AND L.IMMEDIATE_GETS <> 0
 order by 5 , 6
               
                System bazında latch istatistikleri;
                  SELECT a.inst_id,
        a.name,
         a.addr,
         a.latch#,
         a.wait_time,
         a.gets,
         a.misses,
         a.sleeps,
         a.immediate_gets,
         a.immediate_misses,
         b.sid,
         b.pid
    FROM gv$latch a, gv$latchholder b
   WHERE a.addr = b.laddr(+)
ORDER BY a.sleeps DESC, a.misses DESC;


Bir DBA’nın En Fazla Karşılaştığı Latch Tipleri

Buffer Catch Lathes:

Bu Tip Latchler genelde çok yüksek miktarda I/O yapıldığında ortaya çıkar. Aşağıda  buffer catch latch tiplerini ve bunların nasıl azaltılacağı yada tüne edileceğine dair tavsiyerl bulabilirsiniz.

Cache Buffer Chain Latch: Bu tipler Latch durumunda genelde buffer cache deki bloğa erişim sağlandığında (pinned) ortaya çıkar.Cache Buffer Chain Latch leri azaltmak için sql’lerdeki logical I/O miktarının azaltılması gerekir. Üzerinde yüksek miktrada I/O trafiği bulunan bir bloğa “hot block ” denir. Hot block üzerindeki wait miktarıda hızlıca artar.

Hot Block Nasıl Belirlenir?
Aşağıdaki sql birkaç kez çalıştırılarak yüksek miktarda  SLEEP count ‘a sahip Latch ‘in addresi belirlenir.

SELECT CHILD# "cCHILD",
ADDR "sADDR",
GETS "sGETS",
MISSES "sMISSES",
SLEEPS "sSLEEPS"
FROM v$latch_children
WHERE name = 'cache buffers chains'
ORDER BY 5,1,2,3;
                       
Daha sonra elde edilen addr aşağıdaki sql de  yerine yazılarak TCH (Sql tarafından bloğun hit edilme sayısı) kolonuna göre hot block elde edilir.

  SELECT     /*+ RULE */
        e.owner || '.' || e.segment_name segment_name,
         e.segment_type,
         e.extent_id extent#,
         x.dbablk - e.block_id + 1 block#,
         x.tch,
         l.child#
    FROM sys.v$latch_children l, sys.x$bh x, sys.dba_extents e
   WHERE x.hladdr = '00000003E08E3C20'
     AND e.file_id = x.file#
     AND x.hladdr = l.addr
     AND x.dbablk BETWEEN e.block_id AND e.block_id + e.blocks - 1
ORDER BY x.tch DESC;

Bu objeler üzerindeki Contention azaltılması için ;
1-Uygulama incelenmeli ve bu objeler üzerindeki DML ve SELECt cümlelerinin Contention oluşturmayacak şekilde yeniden düzenlenmesi gerekebilir.
2-Buffer Cache ‘i azaltmak küçük bir ihtimal faydalı olabilir.
3-DBWR sayısını artırmak faydalı olabilir.
4-Tabloya ait PCTFREE değerini artırmak faydalı olabilir.
5-Index Range scan genel olarak kullanılmıyorsa reverse ket index kullanmak faydalı olabilir.
Cache Buffer LRU (Least Recent Used) Chain:Cache Buffer LRU Chain Buffer cache de yeni bir block tanımlanırken yada buffer diske tekrar yazarken meydana gelir.
Cache Buffer LRU chain azaltmak için Buffer cache artırılabilir.Bunun için DB_CACHE_SIZE parametresi artırılmalıdır. Ancak burada yapılan temel hatayada düşmemek gerekir. Eğer buffer hit ratio %99 -98 civarında ise ve buffer yetmemesinin sebebi full table scan işlemleri yada buffer tüketen operasyonlarsa bu durumda buffer cache artırmanın bir anlamı kalmaz. Sql Tuning Yapılması gerekir. Ayrıca DB_BLOCK_LRU_LATCHES parametresi set edilerekde Cache Buffer LRU Chain azaltılabilir. Bilgi için eğer Metalink Supportunun varsa aşağıdaki dökümanı inceleyebilirsiniz.

Library Cache Latches:

Library Cache Latches: Aslında Library Cache Latch ler ,library cache içerisinde bulunan sql cümlelerinin ve pl/sql objelerin tanımlarını korur. Bir sql çalıştırıldığında oracle bunu pars ederken library cache içerisinde latch arar ve bulamazsa yeni bir latch elde ederek parse eder.Bu durumda bize sorun çıkaran tarafı nedir? Şöyleki eğer yeni latch elde etme işlemi aşırı tekrarlanırsa library cache latch contention  ortaya çıkar. Bunu engellemek için sql ler de bind variable ler kullanılarak mümkün olduğunca her seferinde tekrar parse edilmesini önlemektir. Eğer Uygulama Tuning yapıldı ise ve sqllerin harde parse oranları (v$sql,v$sqlarea viewlarından monitör edilebilir) düşükse  bu duurmda SHARED_POOL_SIZE parametresinin değeri artırılabilir. Eğer yine de Contention çözülmedi ise _KGL_LATCH_COUNT (library cache latch sayısı) parametresi artırılabilir. Default değer aslında yeterlidir.
               
Library Cache Pin Latch: Library Cache Pin Latch bir sql cümlesi library cachede tekrar çalışırsa oluşur. Aynı sql çok yüksek miktarda tekrar tekrar çalışırsa library cachede tuttuğu latch üzerinde beklemeler (misses) oluşur.  Public Yerine Private synonym ler kulanmak yada owner.object_name gibi sql içerisinde direk objeyi belirtmek library cache pin latch sayısını azaltabilir. Library Cache Pin Latch daha detaylı bahsetmek gerekirse;

P1           à           Handle Adres (sessionın beklediği library cache objesi)
P2           à           Pin Adres ( pin ‘e ait adres)
P3           à           Encode Mode & Nampesace…
               
Mode is the mode in which the pin is wanted. This is a number thus:
·         2 - Share mode
·         3 - Exclusive mode

Namespace is just the namespace number of the namespace in the library cache in which the required object lives:
·         0 SQL Area
·         1 Table / Procedure / Function / Package Header
·         2 Package Body
·         3 Trigger
·         4 Index
·         5 Cluster
·         6 Object
·         7 Pipe
·         13 Java Source
·         14 Java Resource
·         32 Java Data


Library Cache Pin Latch Gördüğünüz sessiona ait parametrelerin anlamlarını yukarıda belirtmeye çalıştık.Bu parametreler kulanılarak daha detaylı problem analizi yapılabilir.

Aşağıdaki sql de kglhdadr değerine p1 row yada p2 row yazılarak handle yada pin objesi bulunabilir.

SELECT kglnaown "Owner", kglnaobj "Object"
  FROM x$kglob
 WHERE kglhdadr = '&P1RAW';

Aşağıdaki sql ile library cache de latch handle edip bloke eden session bulunabilir.
SELECT s.sid,s.serial#, kglpnmod "Mode", kglpnreq "Req"
    FROM x$kglpn p, v$session s
   WHERE p.kglpnuse=s.saddr
     AND kglpnhdl='&P1RAW';
Sonrasında isterseniz sid ve serial# bilgisini bulduğunuz sesionu kill ederek obje üzerindeki lock’ı kaldırmış olursunuz. Ancak eğer bu durum sık sık başınıza geliyor ve support almak istiyorsanız aşağııdaki gibi hang analiz yapabilir ve bu bilgileri Oracle ile paylaşarak kalıcı bir çözüme gitmiş olabilirsiniz.
                ALTER SESSION SET max_dump_file_size = UNLIMITED;
ALTER SYSTEM SET EVENTS 'immediate trace name systemstate level 266';
                Yukarıdaki parametreleri set ettikten sonra USER_DUMP_DEST altında yada shared server kullanıyorsanız BACKGROUND_DUMP_DEST altında ilgili trace file lerini bulabilirsiniz.
                Library Cache Latch Pin lockları çok fazla ise ve bu eventten kaynaklanan bekleme olayları oluşuyorsa bu udurumda dinamik sql kullanımı genel bir problemdir ve dinamik sql leri sisteminizden mümkün olduğunca azaltmanız gerekir.

Shared Pool Latches:
                Shared Pool Latches :Library Cache latch , library cachedeki operasyonları koruduğunu belirtmiştik.Shared pool latch de , shared pool içindeki operasyonlar Shared pool memory alanı alırken, bu operasyonları bozulmamasını ve sağlıklı bitmesini temin eder. Aslında shared pool latchlerin genel sebebi literal (bind içermeyen , her çalıştığında tekrar pars edilen sql) SQL kullanımıdır. Aşağıda shared pool latch lerin iyileştirilmesine yönelik tavsiyeler bulunmaktadır.
                1-Hard Parse mümkün olduğunca az yapılacak şekilde sql tuning yapılmaktadır.
                2-Literal Sql kullnımından kaçınılmalıdır.
                3-Reload ların azalması için shareed_pool miktarını uygulamaya göre yeteri kadar büyütün.
                4-Shared Server (MTS) kullanımı shared pool latch tuningde çok iyi bir etki yapacaktır.

                Aşağıdaki sqller yardımı ile shared pool latch analiz yapılabilir.
                -- literal SQL leri bulma
  SELECT SUBSTR (sql_text, 1, 40) "SQL", COUNT (*),
SUM (executions) "TotExecs"
    FROM v$sqlarea
   WHERE executions < 5
GROUP BY SUBSTR (sql_text, 1, 40)
  HAVING COUNT (*) > 30
ORDER BY 2;

--10g ve sonrası için aşağıdaki sqlde kullanılabilir
WITH c
     AS (  SELECT FORCE_MATCHING_SIGNATURE, COUNT (*) cnt
             FROM v$sqlarea
            WHERE FORCE_MATCHING_SIGNATURE != 0
         GROUP BY FORCE_MATCHING_SIGNATURE
           HAVING COUNT (*) > 20),
     sq
     AS (SELECT sql_text,
                FORCE_MATCHING_SIGNATURE,
                ROW_NUMBER ()
                OVER (PARTITION BY FORCE_MATCHING_SIGNATURE
                      ORDER BY sql_id DESC)
                   p
           FROM v$sqlarea s
          WHERE FORCE_MATCHING_SIGNATURE IN
                   (SELECT FORCE_MATCHING_SIGNATURE FROM c))
  SELECT sq.sql_text, sq.FORCE_MATCHING_SIGNATURE,
c.cnt "unshared count"
    FROM c, sq
   WHERE sq.FORCE_MATCHING_SIGNATURE = c.FORCE_MATCHING_SIGNATURE AND sq.p = 1
ORDER BY c.cnt DESC

--Shared pool memory Fazla kullanan sqller

    SELECT SUBSTR (sql_text, 1, 40) "Stmt",
         COUNT (*),
         SUM (sharable_mem) "Mem",
         SUM (users_opening) "Open",
         SUM (executions) "Exec"
    FROM v$sql
GROUP BY SUBSTR (sql_text, 1, 40)
  HAVING SUM (sharable_mem) > 14778368;
 
-- 
--shareable_mem değeri byte cinsinden olmalıdır. Show parameter sga ifadesi ile sqlplusda bulunabilir.

--Invalidasyon yapan sqller, ki bunların mümkün olduğunca azaltılması gerekir.
 
SELECT   SUBSTR(sql_text, 1, 40) "SQL",
         invalidations
FROM     v$sqlarea
ORDER BY invalidations DESC;

                Row Cache Object Latch: Row cache Obje latchleri SGA da cache edilen data dictionary objelerine erişirken yaşanabilir. Bu tip latch Contentionlar genel yaşanan bir latch değildir.Engellemenin tek yolu SHARED_POOL_SIZE değerini artırmaktır.
Redo Log Buffer Latches:
                Bir data blok değiştiğinde , bu kayıt dan daha yeni bir SCN olmadığı kontroledilir. Sonrasında redolog bufferda uygun yer aranır ve yer bulunamazsa data LGWR tarafından diske yazılmak zorunda kalır. Eğer yer varsa redo bufferda, kopyalama için yer alınır ve recovery proceses için link oluşturulur.
                Bu prosesleri gerçekleştirmek için veritabanında üç adet latch vardır.
                Redo Copy Latch: Yukarıdaki  parasesin tamamında bu latch vardır.Log file switch sonuna kadar da devam eder.LOG_SIMULTANEOUS_COPIES redo latch kopya sayısını belirtir.
                Redo Allocation Latch: Redo allocation latch log buffer memory alanında yer alma sırasında oluşur.
                Redo Writing Latch: Bu tip redo latchlar LGWR prosesisne log switch için aynı anda birden fazla proses gönderilmesini engeller. Bu durumda LGWR ye iletilecek prosesler beklenmeli yada log switch yapılmalıdır.
                Aşağıdaki sql de redolog buffer latchlerinin istatistikleri görüntülenebilir.Bu istatistiklerdeb yola çıkarak eğer  misses/gets oranı %1 denbüyükse  yada  immediate_misses / (immeidate_gets+ immediate_misses) oranı %1 en büyükse redo log contention var denebilir.
SELECT SUBSTR (LN.name, 1, 20),
       gets,
       misses,
       immediate_gets,
       immediate_misses
  FROM v$latch l, v$latchname LN
 WHERE LN.name IN ('redo allocation', 'redo copy')
 AND LN.latch# = l.latch#;

Latch Contention çıkması durumunda oracle öncelikle redo allocation latch tune edilmesini tavisye etmektedir. Latch Contentionu engellemek için ise aşağıdaki tavsiyeler denenebilir.
            Oracle 10.2 versiyonunda redo buffer allocation retries istatistiği, bir prosesin redo buffer yer alması için beklediği süreyi belirtir.Ideal olan bu değerin 0 a yakın olmasıdır. Eğer bu değer artmaya başlamışsa bekleme olayı başlar. Bekleme olayının sebebi log buffer daki boş alanın daralması yada checkpointlerin sıklaşmasıdır. LOG_BUFFER (byte) parametresi artırılarak fayda sağlanabilir. Oracle 11.2 verisyonunda ise konu ile ilgili bir bug vardır inceleyebilirsiniz Bug 13520743.
                Request for Space Contention: Aşağıdaki sqlde “redo log space request ”  istatistiğinin değerini bulabilirsiniz.Bu değerin 0 dan farklı olması user proseslerinin redo log file lerde yer beklediğini belirtir.Eğer değer 0 dan buyukse checkpoint sayısını artırmak yada archive proses sayısını artırmak faydalı olacaktır.
SELECT name, VALUE
  FROM v$sysstat
 WHERE name = 'redo log space requests';


                                                                                              Özcan YILDIRIM

1 yorum:

"Sorularınız ve Eleştirileriniz Değerlidir"