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.

Deadlock Analiz #1

 

Oluşan sorunların nedenlerini analiz ederken sonradan oluşabilecek sorunları önleyebiliriz.

* Deadlock oturumları

* Deadlock oluşturan kaynaklar

* Sessionlar tarafından yürütülen sorgular.

Kilitlenme Bilgilerinin Toplanması 

Bu bilgileri toplamanın 4 yolu vardır.

1-1222 flag izlemesinin ayarlanması

2-1204 flag izlemesinin ayarlanması

3-İzleme olaylarının kullanılması

4-Genişletilmiş olayların kullanılması

İzleme bayrakları kilitlenme durumlarının oluşmasında belirli SQL Server davranışlarının özelleştirmesi için kullanılır. Ancak bu bilgi edinme eski bir yöntem olmuştur. SQL Server 2008 den beri kullanılan örnekte; system_health adın bir genişletilmiş olay oturumu vardır. Oturum otomatik olarak çalışır ve olaylarından birini varsayılan olarak toplar. Bu kilitlenme bilgilerine anında erişmek için en kolay yoldur.

System_health sadece anlık olayları için kullanılabiliyor. Verileri yakalamak için ring_buffer kullanıldığı için bir kilitlenme yaşandıktan hemen sonra bu parametreye bakıyorsanız bilgilerin eksik olduğunu görebileceksiniz. Daha uzun süreli bilgi toplamak gerekli olursa mümkün olduğunda çok olay toplamamız gerekiyor.  Genişletilmiş olaylar kilitlenme bilgilerini toplamak için birkaç yol sağlamaktadır. Bu en iyi yollardan biridir. 

1- Lock_deadlock: Bir kilitlenme olayı hakkkında temel bilgileri görüntülenmesini sağlar.

2-Lock_deadlock_chain: bir kilitlenmedeki her oturumda bilgi alır.

3-Xml_deadlock_report : Kilitlenme nedeniyle beraber XML şeklinde grafik sağlar.

Temel kilitlenme bilgileri için en kolay yol xml_deadlock_report görünüyor. Aynı zamanda Lock_deadlock_chain kullanmak yardımcı olacaktır.

Kilitlenme grafiğini Management Studioda açabiliriz. XMLde de arama yapabiliriz.  XML kilitlenme için neredeyse bir yürütme planı gibi çalışır.

Kilitlenme bilgisini oluşturan iki izleme bayrağı farklı veriler oluşturmak için tek tek veya birlikte kullanılabilir.

Genellikle biri kullanılır bunu sebebi ise çok fazla veri olmasındandır.  SQL Server hata günlüğünü, izleme bayraklarını, toplanan verileri, kilitlenme olaylarını bir günlük dosyasına yazar. İzleme bayrağı 1222 kilitlenme olayları ile ilgili olarak ayrıntılı bilgiler çıkarır. Bilgileri kaynağa göre sıralar ve süreçler hakkında daha fazla bilgi sağlar.

İzleme bayrağı1204 ise; kilitlenme nedenini analiz etmemize yardımcı olarak ayrıntılı kilitlenme bilgileri sağlar. Kilitlenmeye dahil olan tüm düğümleri ayrıntılı olarak çıkarır.

DBCC TRACEON izleme bayraklarını açmak ve etkileştirmek için kullanılır. Açılan izleme bayrakları DBCC TRACEOFF  deyimi kullanılana kadar devrede kalır. Eğer sunucu yeniden başlatılırsa bu izleme bayrakları silinecektir. 

DBCC TRACESTATUS deyimini kullanarak izleme bayraklarının durumunu belirleyebiliriz.

DBCC TRACEON (1222, -1);

DBCC TRACEON (1204, -1);

SQL Server Management Studio üzerinden izleme bayraklarının ayarlanması başlangıçta yapılabilir. 

SQL Server Deadlock #1

 

Deadlock birincil nedenlerinden biri performans düşüklüğü gelir. iki veya daha fazla işlem arasında bir kilitlenme meydana geldiğinde SQL Server sadece bir işleme izin verir. Daha sonra diğer işlem(ler) için tamamlamak , sonlandırmak yada geri almak için bir hata döndürür. Kullanıcıya bu konuda yeniden denemesini sağlatmak yada işlemi sonlandırmak.

Kilitlenme, iki işlemin birbiri tarafından engellendiği özel bir engelleme senaryosudur. Her süreç kendi kaynaklarını elinde tutarak diğer işlem tarafında kilitlenen bir kaynağa erişmeye çalışır.

SQL Server işlemin geri alınması maliyetini değerlendirerek oturumu kilitleme kurbanı olarak belirler. Oturumdaki en düşük olanı seçer.  Bu alanda bir kontrol uygulanabilir. Bağlantı düşük olarak seçilerek bu işlemi yönetebiliriz.

SET DEADLOCK_PRIORITY LOW;

SET komutu yürüterek bağlantının kilitlenme önceliğini normal değere atayabiliriz.

SET DEADLOCK_PRIORITY NORMAL;

Deadlock tespiti için Error Handling Kullanmak 

SQL Server kurban olarak bir oturumu seçtiğinde hata numarası ile bir hata oluşturur. Bu hata numarasını ve hatayı bulabilmek için TRY - CATCH yapısını kullanabiliriz.

Hata işleyicisinde kilitlenme durumda hatayı uygulamaya döndürmeden önce T-SQL içerisinde birkaç kez yeniden başlatmayı deneyelim. 

DECLARE @retry AS TINYINT = 1,

      @retrymax AS TINYINT = 2,

      @retrycount AS TINYINT = 0;

WHILE @retry = 1

      AND @retrycount <= @retrymax

      BEGIN

            SET @retry = 0;

                   

            BEGIN TRY

                  UPDATE HumanResources.Employee

                  SET LoginID = '54321'

                  WHERE BusinessEntityID = 100;

            END TRY

            BEGIN CATCH

                  IF (ERROR_NUMBER() = 1205)

                        BEGIN

                              SET @retrycount = @retrycount + 1;

                              SET @retry = 1;

                        END

            END CATCH

END

Try, Catch blogu içerisinde hata numrasını bulabiliriz. Kilitlenme olup olmadığını kontrol edebilmek içinse, ERROR_NUMBER()  fonksiyonunu kullanabiliriz Kilitlenme ile karşılaşıldığında belirli bir sayıda işlemi yeniden başlatırız. Arasıra ortaya çıkan kilitlenmelerde kısa çözüm sağlayacaktır.  En iyi yaklaşım ise kilitlenmenin ana nedenini bulmaktır.