Kilit İçeriğini En Aza İndirgeme

 

  Kaynaklardan birinde kilit isteğinden kaçınarak kilitlenme çözülebilir. Kaynağa yanlızca veri okumak için erişilir. Bir kaynak üzerinde değişiklik yapmak her zaman özel bir kilit kazanacaktır. Kaynağın tutarlılığını korumak için kilitlenme durumunda kaynak erişimlerini tanımlanması gerekir. Salt okunur, kirli okuma özelliklerini kullanarak karşılıklı gelen kilit isteklerinden kaçınmaya çalışın.

Kaynak kilitlerinden kaçınmak için aşağıdaki tetikler kullanılır.

* Satır versiyonlama Uygulamak

* İzolasyon seviyesini arttırmak

* Kilitlenme ipuçlarının kullanılması.

Satır versiyonlama Uygulamak

Katı kilitlenme şeması kullanarak kaynaklara erişim engelleye çalışmak yerine READ_COMMITTED_SNAPSHOT izlosayon seviyesi veya SNAPSHOT izolasyon seviyesi ile satır versiyonlama. Satır versiyonlama izolasyon seviyelerini engellemeyi azaltmak için kullanılıyor. 

ALTER DATABASE AdventureWorks2012

SET READ_COMMITTED_SNAPSHOT ON;

Yukarıdaki T-SQL ile tempdb de bulunan satırların bir sürümüne sahip olabilirsiniz potansiyel olarak önceki kilitlenme senaryosundaki kilitlenmenin neden olduğu detayı görebilirsiniz. Bu okumalar farklı bir sürümde olduğu için kilit çekişmesine neden olmadan gerekli tüm okumalara izin verecektir. Satır sürümleme ek yük getirecektir. Özellikle tempdb de sorguda kullanılan tablo, dizinler. Artan değiş tokuş azaltılmış kilitlenmeler ve artan eşzamanlılık avantajına karşı ek yük ve maliyet değerlendirilebilir.

İzolasyon seviyesini arttırmak

Bazen bir SELECT ifadesi  tarafından istenen (S) kilidi dairesel engellemenin oluşumuna katkıda bulunacaktır.  SELECT deyimi içeren işlemin yalıtım düzeyini azaltarak bu tür döngüsel engellemelerden kaçınılabilir. SELECT ifadesindeki (s) kilidi istenmeden verilerin okunmasına ve böylece dairesel engellemelerden kaçınmasına yarar sağlayacaktır.  Ancak öngörülmeyen verilerin okunması kötü verileri döndürerek ciddi sorunlara sebep verecektir. 

Ayrıca bağlantıların kendilerini SERİLEŞTİRİLEBİLiR olarak ayarlayıp ayarlamadığını kontrol etmeniz gerekir. Bazen çevrimiçi bağlantı dizisi oluşturucuları bu seçeneği içerecek ve geliştiricilerinde bunu kullanması sonucunda istenmeyen sonuçlara yol açabilecektir. MSDTC varsayılan olarak serileştirilebilir kullanılır ancak bu değiştirilebilir.

Kilitlenme ipuçlarının kullanılması.

READ UNCOMMITTED izolasyon seviyesi gibi NOLOCK veya READUNCOMMITTED kilitlenme ipucu (s) kilitlerini önleyecektir. Belirli bir oturum tarafından istenir, böylece dairesel blokaj oluşumunu engeller.

Kilitleme ipucu etkisi sorgu düzeyindedir. Uygulandığı tablo ve dizinlerle sınırlıdır. NOLOCK ve  READUNCOMMITTED kilitlenme ipuçları yanlızca SELECT deyimlerinden ve veri seçim bölümlerinde izin verilir.

INSERT, DELETE, UPDATE

Kirli okuma sayfa bölümleri nedeniyle eksik veya fazla satırları içerebilir. Bu teknik sadece düşük kaliteli verilerin olduğu durumlarda kullanılabilir.

DeadLock Analiz #2

Öncelikle kilitlenme bayrağı 1222 ve xml_deadlock_report olaylarının kullanıma açıldığından emin olmamız gerekiyor.

Tek bir bağlantıda aşağıdaki komut çalıştırılabilir;

BEGIN TRAN

UPDATE Purchasing.PurchaseOrderHeader

SET Freight = Freight * 0.9 -- 10% discount on shipping

WHERE PurchaseOrderID = 1255;

ikinci bağlantıda aşağıdaki komut çalıştırılabilir.

BEGIN TRANSACTION

UPDATE Purchasing.PurchaseOrderDetail

SET OrderQty = 4

WHERE ProductID = 448

AND PurchaseOrderID = 1255;

Yukarıdaki komutlar çalıştırıldığında her biri bir işlem açar ve verileri işlemeye başlar. Ancak ne kadar zamanda işlemi yapacağını ve geri alacağını bilemiyoruz.

Birinci komuta gidip aşağıdaki işlemi çalıştırılalım;

UPDATE Purchasing.PurchaseOrderDetail

SET OrderQty = 2

WHERE ProductID = 448

AND PurchaseOrderID = 1255;

İlk bağlantı büyük ihtimalle bir kaç saniye sonra bir kilitlenme oluşacaktır. 

Msg 1205, Level 13, State 51, Line 1

Transaction (Process ID 52) was deadlocked on lock resources with another process and has been

chosen as the deadlock victim. Rerun the transaction.

Önce izleme olayı aracılıyla toplanan kilitlenme grafiğini incelememiz ardından xml_deadlock_report olay için bu pencerede verilen grafiği incelememiz gerekir. 

Ancak daha detaya inerek kilitlenme olayının tam olarak nerede olduğu hangi süreçlerin buna neden olduğu hangi nesnelerin dahil edildi bilgileri XML dosyasını doğrudan genişletilmiş olay grafiğini değerlerinden bulabiliriz.

Örnek tabloda uPurchaseOrderDetail adlı bir tetikleyici bulunuyor. Tüm bu bilgiler hangi kod parçalarının kilitlenmeye yol açtığını belirlememizde yardımcı olacaktır. Ayrıca SQL Handle  gibi bilgileri almak, DMO lar ile birlikte ifadeleri almak kilitlenme ile ilgili bilgilerde bize yardımcı olacaktır.

İzleme bayrağı 1222 tarafından toplanan veriler ile XML içerisindeki bilgiler hemen hemen aynıdır.  Ana farklılıkları biçimlendirme ve konumudur. İzleme bayrağı 1204 tarafından toplanan veriler ise tamamen farklıdır.  Kullanabiliyorsanız Genişletilmiş olayları kullanmaya devam etmeniz işinizin kolaylaşması açısında daha iyidir. 1222 takip edilmesi genellikle önerilir. system_health içinde oluşan bilgilerde size yardımcı olacaktır. 

Yukarıdaki örnekde kilitlenme Purchasing.PurchaseOrderDetail  tablosundaki bir tetikleyiciden kaynaklanmaktadır. Miktar güncellendiğinde Purchasing.PurchaseOrderDetail tablosunda Purchasing.PurchaseOrderHeader tablosu güncellemeye çalışır. İlk iki sorgu çalıştığında her biri açık bir işlem üzerinde bir engelleme durumu söz konusu olur. İkinci sorgu ilk sorgunun temizlenmesini bekler böylece Purchasing.PurchaseOrderHeader tablosunu güncelleyebilir. Sorunu çözebilmek için süreçlerden birini öldürmektir.