http://www.yazgelistir.com/makale/lock-blocking-deadlock-sorunlari-ve-giderilmesi Veritabanı Isolation işini gerçekleştirebilmek için Locking i kullanır. Transaction ımız ne kadar uzun zaman alırsa, veritabanının Lock lı tuttuğu kaynağı (table, row, index vb.) bırakmasıda o oranda gecikir. Bundan dolayı, diğer transaction ların, mevcut işin bitmesini beklemelerine Blocking denir. Yukarıda da belirtildiği gibi Blocking, Locking den dolayı oluşan bir sonuçtur. --Aşağıdaki sorguları ayrı ayrı sessionlarda çalıştırınız. use [AdventureWorks2012] g0 begin tran -- 1.step -- 3. step update HumanResources.Employe set JobTitle= JobTitle + ' UPDATE where BusinessEntityI -- 5. s rollback tran use [AdventureWorks2012] go use [AdventureWorks2012] go begin tran -- 2.step -- 4. step select * from HumanResources.Employee where BusinessEntityID<=15 -- BLOK OLUŞMUŞTUR BEKLEMEYE GEÇER -- 5. STEP BİTENE KADAR ASKIDA KALIR -- 6.STEP ROLLBACK TRAN /* AdventureWork sample database imize baglanıp 2 adet query penceresi açalım. Ardından yukardaki resimde belirtildiği gibi STEP leri sırasına göre çalıştıralım. 4.STEP i çalıştırdıktan sonra işlemimiz, 3.STEP te oluşan Lock yüzünden bekleme durumuna geçer. Sonuçta, bloklayan (blocking) sol penceredeki query, bloklanan (blocked by) da sağ penceredeki query dir. Sistemde her an blocking olması muhtemeldir. Asıl kritik problem, Blocking süresinin makul sürelerin çok çok üstüne çıkmasıdır. Long running query ler işte bu sebepten ötürü oluşurlar. Veritabanında Blocking ve Long Running Query ler, izlenmesi ve çözümlenmesi karmaşık durumlardır. Cevap bulunması gereken sorular şunlardır: - Hangi process, hangi process i yada process leri bloklar - Blocking esnasında aktif process lerin çalıştırmak istediği query nedir, (hangi query yüzünden Blocking oluşmuştur) - Belli bir zaman limitini aşan query lerin tespiti, - Bu zaman limitinin sebebinin anlaşılması, (Blocking den ötürümü yoksa gerçekten zaman alıcak bir iş mi) - Cevaplarımızı bir analiz tool u olan SQL Profiler ile alacağız. Sql Profiler üzerindeki Trace Template lerinden faydalanacağız. - SQL Profiler dan yeni bir Trace oluştururuz. Ardından Trace özelliklerini belirlemek için diğer tab a geçeriz. “Blocked Process Report” isimli event e bağlanırız. Böylece Blocked Process lerimiz XML rapor halinde log lanabilir hale gelir. - Blocking Log süresini belirlemek için (kaç saniye bloklu kalırsa Profiler tarafından Log a yazılsın) sp_configure procedure ünden faydalanılır. sp_configure ‘blocked process threshold’, ‘10000’ go reconfigure go Komutunu çalıştırırsak 10 saniyeyi geçen Blocking leri Log lamasını sağlarız. Aşağıdaki Log 10 sn boyunca kendisini engelleyen işin bitmesini bekleyen diğer bir iş tarafından Trace e yazılmıştır. RecordBy
