Oracle Latches

Latches  nedir??
Mandallar(latches), Oracle paylaşımlı bellek alanlarını(SGA) koruyan serileştirme mekanizmalarıdır. Basit anlamda mandallar iki prosesin aynı SGA alanını eşzamanlı güncellemelerinden ve muhtemelen bu olaya bağlı bozulmalardan korur. Mandallar, birden fazla kullanıcı prosesinin belirli bir zamanda aynı kod parçasını çalıştırmasını önlemek için kullanılmaktadır.

Oracle oturumları neredeyse tüm veritabanı işlemleri için SGA’dan okumak veya SGA’yı güncellemek ihtiyacı duyar.  Örneğin;

• Bir oturum diskten bloğu okurken, bu oturum önbellek tamponunda serbest bloğu değiştirir ve önbellek tampon LRU(en son kullanılan) zincirini düzeltir.
• Bir oturum SGA’dan bir blok okuduğunda, LRU zinciride değiştirilir. Yeni bir SQL komutu ayrıştırıldığında(parsed) SGA deki library cache’e eklenir.
• Bloklarda değişiklikler yapıldığı gibi, girişlerde redo tamponuna yerleştirilir. Veritabanı yazıcısı periyodik olarak kirli tamponları önbellekten diske yazar ve statülerini “kirli” den “temiz” e değiştirmek zorundadır.
• Redo log yazıcısı, girişleri redo tampondan redo log dosyalarına yazar.

Mandallara karşılık kuyruğa alma(enqueues)
Kuyruğa almalarda(enqueues), Oracle içindeki diğer bir kilitleme mekanizmasıdır. Kuyruğa alma  daha gelişmiş bir mekanizmadır ve birçok eşzamanlı prosesi, bilinen kaynakların değişik derecelerde paylaşımına olanak verir. Eşzamanlı kullanılabilen herhangi bir nesne kuyruğa almalarla korunabilir. Tablolarda değişik seviyelerde paylaşımlara izin verilir, örneğin iki proses paylaşımlı modda veya paylaşımlı güncelleme modunda bir tabloyu kilitleyebilir.Kuyruğa almanın bir farklılığı, işletim sistemi kilitleme mekanizması kullanılarak elde edilmesidir. Kuyruğa alma ile bir değerin kilit içinde saklamansına izin verilir. İşletim sistemi kilit yöneticisi, kilitlenmiş kaynakların izini tutar. Eğer bir proses, talep edilen modun uyumsuzluğu sebebiyle ve bir bekleme için kilit talep edildiğinde bu kilidi kabul edemezse, işletim sistemi bekleyen prosesi FIFO içinde servis edilen bekleme kuyruğuna koyar. Mandallar ve kuyruğa almaların arasındaki diğer bir fark ise, mandallarda kuyruğa almalardaki gibi sıralanmış kuyruk bekleyicileri yoktur. Mandal bekleyicileri uyanmak ve yeniden denemek için ya zamanlayıcıları yada  sadece çoklu işlemcilerde kullanılmak üzere devirleri kullanır.  Tüm bekleyicilerin zamanlayıcıya bağlı eşzamanlı yeniden denemesinden itibaren herhangi biri mandalı alabilir ve makul olarak en son alan olur.


Mandallar nasıl çalışır?
Belleğe karşı yapılan işlemlerin süresi çok kısa olduğundan (tipik olarak nanosaniyeler arasında) ve mandal talep sıklığı çok yüksek olduğundan, mandal mekanizması çok hafif yükte olma ihtiyacı duyar.

Eğer mandal zaten kullanımdaysa, Oracle bunun daha fazla kullanımda olmamasını üstlenir, böylece pasif beklemeye gitmekten ziyade, vazgeçmeden önce Oracle operasyonu birkaç sefer daha dener. Bu algoritma, “spin lock” elde etmek olarak adlandırılır ve uykudan önce bu spinlerin sayısı “_spin_count” başlangıç parametresince kontrol edilir.

Oturum spin yoluyla mandalı elde ederken, ilk defa başarısız olduğu anda 10 milisaniye sonra uyanmak için tekrar deneme yapar. Daha sonraki beklemeler süre içinde artar ve aşırı durumlarda ise bir saniyeyi bile aşabilir. Mandallar için yoğun çekişmelerden dertli sistemlerde bu beklemelerin cevap sürelerinde ve çıktılarında şiddetli bir etkisi olacaktır.

Aşağıdaki örnek raporda mandal bekleme olayları süreleri ile yer almaktadır.

Spesifik mandalların çekişme nedenleri
Eğer gerekli mandal meşgulsa, bunu talep eden proses spin çeker, tekrar dener ve eğer hala uygun değilse tekrar spin çeker. Bu döngü, _SPIN_COUNT başlangıç parametresince belirlenen maksimum sayıda tekrarlanır ve bu esnada CPU tüketir. Eğer bütün bu döngülerden sonra mandal hala uygun değilse, proses CPU’ya karşı koymaz ve uykuya geçer. Başlangıçta uykular bir sentisaniyedir. Süre her sonraki uykularda ikiye katlanır.  Bu yavaşlamaya sebep olur ve bir mandal uygun olana kadar ilave CPU kullamı ile sonuçlanır. Bu CPU kullanımı prosesin spin çekmesinin eseridir. “Spin çekme” prosesin uykuda kaldığı süre içinde belirli zaman aralıklarıyla mandalın uygunluğunu kontrol etmesidir.

Performansı en sık etkileyen mandallar önbellek tamponunu,paylaşımlı havuz alanlarını ve redo tamponunu koruyan mandallardır.  

·        Library cache ve paylaşımlı havuz mandalları:  Bu mandallar paylaşımlı SQL komutlarının tutulduğu library cache’i korur. İyi hazırlanmış uygulamalarda bu mandallar için çok az veya hiç çekişme olmaz, ancak bind değişkenleri yerine tam isim kullanan uygulamaların SQL komutlarında library cache çekişmesi yaygın olmaktadır(mesela “WHERE surname=:surname“ yerine “WHERE surname=’INAL’” kullanılırsa)

Library cache ve paylaşımlı havuz mandallarında yaygın bekleme sebepleri;

1.      Komutlarda tekrar kullanım eksikliği

2.      Bind değişkenlerinin kullanılmamasıü

3.      Uygulama imleç önbellek büyüklüğünün yetersiz olması

4.      Her çalıştırma sonrasında imleçlerin açık seçik kapatılması

5.      Çok sık oturum açma ve kapama işlemleri

6.      Temel nesne yapısının değiştirilmesi(mesela TRUNCATE işlemleri)

7.      Paylaşımlı havuzun küçük kalması

·        Redo kopya/redo tahsis mandalları: Bu mandallar, redo log tamponunu korur.

·        Ön bellek tamponları zincir mandalları: Bu mandallar oturumlar önbellek tamponundaki tamponlara yazma veya okuma işlemi yapıldığında tutulmaktadır. Avuç dolusu blokları koruyan pek çok sayıda bu mandallardan bulunur. Bu mandallardaki çekişmeler genellikle “sıcak” bloklara eşzamanlı erişimden kaynaklanır ve en yaygın “sıcak” blok index kökü veya kol bloktur(herhangi bir indeks kök bloğa erişmek zorunda olana kadar)

Önbellek tamponları zincir mandallarındaki yaygın bekleme sebepleri;

1.      Yanlış indekslere tekrar tekrar erişen veya çok sık “full table scan” çeken verimsiz SQL komutları

2.      DBWR prosesinin kirli tamponlarla devam edememesi, bundan dolayı arkaplan prosesinin boş tampon bakarken mandal tutmak için çok fazla zaman harcaması.

3.      Önbellek yetersiz büyüklükte olabilir.

4.      Aynı bloklara çok ağır şekilde erişim olabilir.

5.      Çok uzun tampon zincirleri olabilir veya bir bloğa tekrarlı erişim olabilir. Bu durumda DB_BLOCK_LRU_LATCHES parametresinin değerinin arttırılması tavsiye edilir.

Bununla beraber sıcak blokların varlığını ve sayısını bulmak için aşağıdaki sorgu çalıştırılabilir.

SELECT OBJ data_object_id, FILE#, DBABLK,CLASS, STATE, TCH
FROM X$BH
WHERE HLADDR = 'address of latch'
ORDER BY TCH;

TCH kolonu sıcak blokların dokulma sayısını tutar. Yüksek değerdeyse o durumda “sıcak blok” mevcuttur.