Sık Karşılaşılan Engelleme Senaryolarını Belirleme ve Giderme
Yukarıdaki bilgileri inceleyerek, birçok engelleme sorununun nedenini belirleyebilirsiniz. Bu makalenin bundan sonraki bölümlerinde bazı sık karşılaşılan engelleme senaryolarını belirlemek ve gidermek için bu bilgilerin nasıl kullanılacağı anlatılmaktadır. Bu konuda, engelleyen SPID'lerdeki bilgileri yakalamak için Q251004 numaralı makaledeki (yukarıda başvurulmuştur) engelleme komut dosyalarını kullandığınız ve yukarıda açıklanan olaylarla Profiler izlemesi yaptığınız varsayılmaktadır.
Engelleme Komut Dosyası Çıkışını Görüntüleme
• Her bir engelleme zincirinin başını belirlemek için sysprocesses çıkışını inceleyin.
Engelleme komut dosyaları için hızlı modu belirtmediyseniz, komut dosyası çıkışında diğerlerini engelleyen SPID'leri listeleyen "SPIDs at the head of blocking chains" (Engelleme zincirlerinin başındaki SPID'ler) başlıklı bir bölüm bulunur.

SPIDs at the head of blocking chains
spid
------
9
10

Hızlı seçeneği belirttiyseniz, sysprocesses çıkışına bakarak da engelleme başlangıçlarını belirleyebilirsiniz. Kısaltılmış sysprocesses çıkışı aşağıdadır:

spid status blocked
9 sleeping 0
10 sleeping 0
11 sleeping 13
12 sleeping 10
13 sleeping 9
14 sleeping 12

Bu durumda, hem SPID 9'un hem de 10'un blocked (engellenmiş) sütununda 0 değeri vardır ve bu da engellenmedikleri anlamına gelir, ancak her ikisi de diğer SPID'lerin blocked sütununda görünür. Bu, SPID 9 ve 10'un farklı engelleme zincirlerinin başında olduğunu gösterir.
• Engelleme zincirinin başındaki SPID'ler hakkında bilgi için sysprocesses çıkışını inceleyin.
Aşağıdaki sysprocesses alanlarının değerlendirilmesi önemlidir:

• Status
Bu sütun belirli bir SPID'nin durumuna hızlı bir bakış olanağı sağlar. Genellikle, sleeping durumu SPID'nin yürütmeyi tamamladığını ve uygulamanın başka bir sorgu veya toplu işlem göndermesini beklediğini gösterir. runnable durumu SPID'nin şu anda bir sorguyu işlediğini gösterir. Aşağıdaki tabloda çeşitli durum değerlerinin kısa açıklamaları verilmiştir.

Durum Anlamı
Background SPID arka plan görevi gerçekleştirmektedir.
Sleeping SPID şu anda yürütülmüyor. Bu genellikle SPID'nin uygulamadan komut beklediğini gösterir.
Runnable SPID şu anda yürütülüyor.
Dormant Sleeping ile aynıdır, ancak Dormant durumu ayrıca RPC olayı tamamlandıktan sonra SPID'nin sıfırlandığını gösterir. Sıfırlama RPC olayı sırasında kullanılan kaynakları temizler. Bu normal durumdur ve SPID diğer komutları yürütmek için kullanılabilir durumda beklemektedir.
Rollback SPID, bir hareketi geri alma hareketini gerçekleştirmektedir.
Defwakeup Bir SPID'nin serbest bırakılmakta olan bir kaynağı beklediğini gösterir. waitresource alanı ilgili kaynağı göstermelidir.
Spinloop İşlem, SMP sistemlerinde eşzamanlama denetimi için kullanılan sayaç kilidini alma denemesi sırasında beklemektedir.

• Open_tran
Bu alan SPID'nin iç içe geçmiş hareket düzeyini gösterir. Bu değer 0'dan büyükse, SPID açık bir hareket içindedir ve hareketin içindeki herhangi bir deyim tarafından alınan kilitleri tutabilir.
• Lastwaittype, waittype ve waittime
lastwaittype alanı SPID'nin son veya geçerli waittype değerini bildirir. Bu alan SQL Server 7.0'da yenidir ve waittype alanının (ayrılmış iç ikili sütundur) dize gösterimidir. waittype değeri 0x0000 ise, SPID şu anda beklemede değildir ve lastwaittype değeri SPID'nin son aldığı waittype değerini gösterir. waittype sıfırdan farklıysa, lastwaittype değeri SPID'nin geçerli waittype değerini gösterir.

Farklı lastwaittype ve waittype değerlerinin kısa açıklaması için, lütfen Microsoft Knowledge Base makalesine bakın:
244455 () BİLGİ: Sysprocesses Waittype ve Lastwaittype Alanlarının Açıklaması (Bu bağlantı, bir kısmı veya tamamı İngilizce olan içeriğe işaret edebilir.)
SPID'nin ilerleme kaydedip kaydetmediğini belirlemek için waittime değeri kullanışlı olabilir. sysprocesses tablosunda çalıştırılan bir sorgu waittime sütununda, önceki sysprocesses sorgusundaki waittime değerinden daha küçük bir değer döndürürse, bu, önceki kilidin alındığını ve serbest bırakıldığını ve şu anda yeni bir kilidin beklendiğini gösterir (sıfırdan farklı waittime değeri varsayılmaktadır). Bu, sysprocesses çıkışlarındaki waitresource değerleri karşılaştırılarak doğrulanabilir.
• Waitresource
Bu alan bir SPID'nin beklediği kaynağı gösterir. Aşağıdaki listede yaygın waitresource biçimleri ve anlamları listelenmiştir:

Kaynak Biçim Örnek
Tablo VeritabanıKimliği:NesneKimliği TAB: 5:261575970
Bu durumda, veritabanı kimliği 5 pubs örnek veritabanıdır ve nesne kimliği 261575970 titles tablosudur.
Sayfa VeritabanıKimliğiosyaKimliğiayfaKimliği PAG: 5:1:104
Bu durumda, veritabanı kimliği 5, pubs; dosya kimliği 1, birincil veri dosyası; ve sayfa 104, titles tablosuna ait bir sayfadır.
Anahtar VeritabanıKimliği:NesneKimliğiizinKimliği (Dizin anahtarı için karma değer) KEY: 5:261575970:1 (5d0164fb1eac)
Bu durumda, veritabanı kimliği 5, pubs; nesne kimliği 261575970, titles tablosu; dizin kimliği 1, kümelenmiş dizindir ve karma değeri ilgili satır için dizin anahtarı değerini gösterir.

• Diğer sütunlar
Diğer sysprocesses sütunları da sorunun kaynağına ışık tutabilir. Faydaları sorunun oluştuğu ortama göre değişir. Örneğin, sorunun yalnızca belirli istemcilerde (ana makine adı) veya belirli ağ kitaplıklarında (net_library) oluşup oluşmadığını, bir SPID tarafından gönderilen son toplu işlemin zamanını (last_batch) vs. belirleyebilirsiniz. Tüm sysprocesses sütunlarının kısa açıklaması için, lütfen SQL Server 7.0 Çevrimiçi Kitapları'ndaki "sysprocesses (T-SQL)" konusuna bakın.

NOTUID sütunu yalnızca geriye dönük uyumluluk için eklenen bir türetilen sütun olduğundan, engelleme komut dosyası çıkışına eklenmez. Bu sütun SQL Server tarafından iç işlemler için kullanılmaz ve bu sütunu sorgularsanız (türetilmiş olduğundan) performans azalmasına neden olabileceği için çıkışa eklenmez.

• DBCC INPUTBUFFER çıkışını inceleyin.

Engelleme komut dosyası, engelleme zincirinin başındaki veya sıfırdan farklı waittype değerine sahip bir SPID için, ilgili SPID'deki geçerli sorguyu belirlemek amacıyla DBCC INPUTBUFFER sorgusunu yürütür:

DBCC INPUTBUFFER FOR SPID 9
EventType Parameters EventInfo
-------------- ---------- --------------------------------------------
Language Event 0 update titles set title = title

Çoğu durumda, bu, diğer kullanıcıları engelleyen kilitli tutmalara neden olan sorgudur. Ancak, SPID bir hareket içindeyse, kilitler geçerli sorgu tarafından değil önceden yürütülmüş bir sorgu tarafından alınmış olabilir. Bu nedenle, yalnızca inputbuffer değerini değil SPID için Profiler çıkışını da görüntülemelisiniz.

NOT: Engelleme komut dosyaları birden çok adımdan oluştuğundan, bir SPID ilk bölümde engelleme zincirinin başlangıcı olarak görünebilir, ancak DBCC INPUTBUFFER sorgusu yürütüldüğünde bu SPID'nin artık engelleme yapmadığı ve INPUTBUFFER'ın yakalanmadığı görülür. Bu, ilgili SPID için engellemenin kendi kendine çözümlendiğini ve bunun sorun olup olmadığını gösterir. Bu noktada, temizlenmeden önce inputbuffer'ı yakaladığınızdan emin olmak için engelleme komut dosyasının hızlı sürümünü kullanabilir (yine de sonuç alamayabilirsiniz) veya SPID'nin yürüttüğü sorguları belirlemek için ilgili zaman aralığındaki Profiler verilerini görüntüleyebilirsiniz.

Row VeritabanıKimliğiosyaKimliğiayfaKimliği:yuva(s atır) RID: 5:1:104:3
Bu durumda, veritabanı kimliği 5, pubs; dosya kimliği 1, birincil veri dosyası; sayfa 104, titles tablosuna ait bir sayfadır ve yuva 3, satırın sayfadaki konumunu gösterir.
Compile VeritabanıKimliği:NesneKimliği TAB: 5:834102012 [[COMPILE]]

Bu durumda, veritabanı kimliği 5, pubs'dır; ancak nesne kimliği 834102012 bir saklı yordamdır. Bu, SPID'nin saklı yordam için bir plan derlemeyi beklediğini gösterir.
Profiler Verilerini Görüntüleme
Profiler verilerinin etkin bir şekilde görüntülenmesi, engelleme sorunlarını giderme açısından çok önemlidir. Dikkat edilmesi gereken en önemli nokta, yakaladığınız her şeye bakmanızın gerekli olmadığıdır; seçici davranın. Profiler yakalanan verileri etkin bir şekilde görüntülemenize yardımcı olacak olanaklar sunar. Profiler, Properties iletişim kutusunda (File menüsünde Properties'i tıklatın) veri sütunlarını veya olayları kaldırarak, veri sütunlarına göre gruplandırarak (sıralayarak) ve filtre uygulayarak görüntülenen verileri sınırlamanıza olanak tanır. Belirli değerleri, izlemenin tümünde veya belirli bir sütunda arayabilirsiniz (Edit [Düzen] menüsünde Find [Bul] öğesini tıklatın). Ayrıca, Profiler verilerini bir SQL Server tablosuna kaydedebilir (File menüsünde Save As öğesinin üzerine gelin ve sonra Table öğesini tıklatın) ve SQL sorgularını bu tabloyu kullanarak çalıştırın.

Yalnızca önceden kaydedilmiş izleme dosyasına filtre uyguladığınızdan emin olun. Bu adımları etkin izleme üzerinde gerçekleştirirseniz, izleme başlatıldıktan sonra yakalanan verileri kaybetme riski doğar. Etkin izlemeyi önce bir dosyaya veya tabloya kaydedin (File menüsünde Save As öğesini tıklatın) ve sonra devam etmeden önce yeniden açın (File menüsünde Open öğesini tıklatın). Kaydedilmiş bir izleme dosyasında çalışılırken, filtreleme işlemi filtre uygulanan verileri kalıcı olarak kaldırmaz; yalnızca bunların görüntülenmemesini sağlar. Aramalarınızın odaklanmasına yardımcı olmak için olaylar ve veri sütunları ekleyebilir ve kaldırabilirsiniz.

Aranacaklar:• Engelleme zincirinin başındaki SPID geçerli harekette hangi komutları yürütmüştür?
Engelleme zincirinin başındaki SPID'nin izleme verilerini filtreleyin (File (Dosya) menüsünde Properties (Özellikler) öğesini tıklatın ve sonra Filters (Filtreler) sekmesinde SPID değerini belirtin). Böylece, diğer SPID'leri engellemeden önce yürüttüğü komutları inceleyebilirsiniz. Hareket olaylarını eklerseniz, bunlar hareketin başlatıldığı zamanı kolaylıkla belirleyebilir. Aksi durumda, Text (Metin) sütununda BEGIN, SAVE, COMMIT veya ROLLBACK TRANSACTION işlemlerini arayabilirsiniz. Tüm hareket olaylarını yakaladığınızdan emin olmak için sysprocesses tablosundaki open_tran değerini kullanın. Yürütülen komutların ve hareket bağlamının bilinmesi SPID'nin kilitleri neden tuttuğunu belirlemenize olanak tanır.

Olayları ve veri sütunlarını kaldırabileceğinizi unutmayın. Hem başlatılan hem de tamamlanan olaylara bakmak yerine bunlardan birini seçin. Engelleyen SPID'ler saklı yordamlar değilse, SPtarting veya SP:Completed olaylarını kaldırın; SQLBatch ve RPC olayları yordam çağrısını gösterir. SP olaylarını yalnızca ilgili ayrıntı düzeyini görmeniz gerekiyorsa görüntüleyin.
• Engelleme zincirinin başındaki SPID'ler için sorgu süresi nedir?
Yukarıdaki tamamlanan olayları eklerseniz, Duration (Süre) sütunu sorgu yürütme süresini gösterir. Bu, engellemeye neden olan ve uzun süre çalışan sorguları belirlemenize yardımcı olabilir. Sorgunun yavaş çalışma nedenini belirlemek için Execution Plan olayının yanı sıra CPU, Read ve Writes sütunlarını görüntüleyin.

Sık Karşılaşılan Engelleme Senaryoları için Kategoriler Oluşturma
Aşağıdaki tabloda sık karşılaşılan belirtiler ve bunların olası nedenleri gösterilmektedir. Senaryo sütunundaki numara bu makalede aşağıda yer alan "Sık Karşılaşılan Engelleme Senaryoları ve Çözümleri" bölümündeki numaraya karşılık gelir. Waittype, Open_Tran ve Status sütunları sysprocesses bilgilerine başvurur. Giderilir? sütunu engellemenin kendi kendine çözümlenip çözümlenemeyeceğini gösterir.

Senaryo Waittype Open_Tran Durum Giderilir? Diğer Belirtiler
1 Sıfırdan farklı >= 0 runnable Evet, sorgu tamamlandığında. Physical_IO, CPU ve/veya Memusage sütunları zaman içinde artar. Tamamlandığında sorgu süresi yüksek olur.
2 0x0000 >0 sleeping Hayır, ancak SPID sonlandırılabilir. Bu SPID'nin Profiler izlemesinde sorgu zaman aşımı veya iptali oluştuğunu gösteren bir dikkat sinyali görülebilir.
3 0x0000 >= 0 runnable Hayır. İstemci tüm satırları alana veya bağlantıyı kapatana kadar giderilemez. SPID sonlandırılabilir, ancak bu işlem 30 saniye kadar sürebilir. open_tran = 0 ve hareket yalıtım düzeyi varsayılan (READ COMMMITTED) olduğunda SPID, kilitleri tutar; bu da olası nedendir.
4 Değişir >= 0 runnable Hayır. İstemci sorguları iptal edene veya bağlantıları kapatana kadar giderilemez. SPID'ler sonlandırılabilir, ancak bu işlem 30 saniye kadar sürebilir. Engelleme zincirinin başındaki SPID'nin sysprocesses çıkışındaki hostname sütunu, engellediği SPID'lerden biriyle aynı olur.
5 0x0000 >0 rollback Evet. Profiler izlemesinde bu SPID için sorgu zaman aşımı veya iptali oluştuğunu veya yalnızca geri alma deyimi yayınlandığını gösteren bir dikkat sinyali görülebilir.
6 0x0000 >0 sleeping Uygun bir zamanda. Windows NT, oturumun etkin olmadığını belirlediğinde, SQL Server bağlantısı kesilir. sysprocesses çıkışındaki last_batch değeri, geçerli zamandan çok öncedir.

Sık Karşılaşılan Engelleme Senaryoları ve Çözümleri
Aşağıda listelenen senaryolar, yukarıdaki tabloda listelenen özelliklere sahiptir. Bu bölümde, uygun olduğunda ek ayrıntıların yanı sıra çözüm yolları da sağlanmaktadır. 1. Uzun Yürütme Süresine Sahip Normal Çalışan Sorgunun Neden Olduğu Engelleme

Çözüm:
Bu tür engelleme sorununun çözümü, sorguyu eniyileştirme yollarını aramaktır. Aslında, bu engelleme sorunu sınıfı yalnızca performans sorunu olabilir ve bu şekilde izlenmesi gerekir. Yavaş çalışan özel bir sorguda sorun giderme hakkında bilgi için, Microsoft Knowledge Base'de aşağıdaki makaleye bakın:
243589 () BİLGİ: SQL Server 7.0'da Yavaş Çalışan Sorgularda Sorun Giderme (Bu bağlantı, bir kısmı veya tamamı İngilizce olan içeriğe işaret edebilir.)
Genel uygulama performansı sorunlarını gidermek için, Microsoft Knowledge Base'de aşağıdaki makaleye bakın:
224587 () NASIL YAPILIR: SQL Server'da Uygulama Performansı Sorunlarını Giderme (Bu bağlantı, bir kısmı veya tamamı İngilizce olan içeriğe işaret edebilir.)
Diğer kullanıcıları engelleyen, eniyileştirilemeyen ve uzun süre çalışan bir sorgunuz varsa, sorguyu OLTP ortamından karar destek sistemine taşımayı düşünün.
2. İç İçe Geçmiş Hareket Düzeyini Kaybetmiş bir Uyuyan SPID'nin Neden Olduğu Engelleme

Bu tür engelleme genellikle uyuyan veya komut bekleyen, ancak iç içe geçmiş hareket düzeyi (@@TRANCOUNT, sysprocesses'teki open_tran) sıfırdan büyük olan bir SPID ile belirlenebilir. Uygulama, sorgu zaman aşımıyla karşılaşırsa veya gerekli ROLLBACK ve/veya COMMIT deyimi sayısını yayınlamadan iptal yayınlarsa bu durum oluşabilir. SPID, sorgu zaman aşımı veya iptal aldığında geçerli sorguyu ve toplu işlemi sonlandırır, ancak hareketi otomatik olarak geri almaz veya tamamlamaya çalışmaz. SQL Server tek bir sorgunun iptal edilmesi nedeniyle hareketin tümüyle geri alınması gerektiğine karar veremeyeceği için bundan uygulama sorumludur. Sorgu zaman aşımı veya iptali Profiler izlemesinde SPID için ATTENTION sinyal olayı olarak görünür.

Bunu göstermek için Sorgu Çözümleyicisi'nden aşağıdaki basit sorguyu yayınlayın:

BEGIN TRAN
SELECT * FROM SYSOBJECTS S1, SYSOBJECTS S2

-- Sorguyu iptal ettikten sonra bunu yayınlayın
SELECT @@TRANCOUNT
ROLLBACK TRAN

Sorgu yürütülürken, kırmızı renkli Cancel düğmesini tıklatın. Sorgu iptal edildikten sonra, SELECT @@TRANCOUNT, iç içe geçmiş hareket düzeyinin bir olduğunu gösterir. Bu bir DELETE veya UPDATE sorgusu olsaydı veya SELECT deyiminde HOLDLOCK kullanılsaydı, alınan kilitlerin tümü hala tutuluyor olurdu. Yukarıdaki sorguda bile, harekette bulunan daha önceki bir sorgu kilitleri alıp tuttuysa, yukarıdaki SELECT sorgusu iptal edildiğinde kilitler tutulmaya devam eder.

Çözümler:

• Uygulamaların iç içe geçmiş hareket düzeylerini düzgün yönetmesi gerekir, aksi durumda sorgunun bu şekilde iptal edilmesinin ardından engelleme sorununa neden olabilirler. Bu, birkaç yoldan biriyle sağlanabilir: a. İstemci uygulamasının hata işleyicisinde, istemci uygulaması bir hareketin açık olduğunu göstermese de herhangi bir hatadan sonra IF @@TRANCOUNT > 0 ROLLBACK TRAN sorgusu gönderin. Toplu işlem sırasında çağrılan bir saklı yordam, istemci uygulamasının bilgisi dışında bir hareket başlatmış olabileceğinden, bu gereklidir. Sorguyu iptal etme gibi bazı durumların yordamı geçerli deyimin ilerisinde yürütmeyi önleyebileceğini ve böylece yordamda IF @@ERROR <> 0 deyimini denetleme mantığı varsa ve yordam hareketi iptal ederse, bu geri alma kodunun bu durumlarda yürütülemeyeceğine dikkat edin.
b. Bağlantı için veya hareket başlatan ve bir hatadan sonra temizleme yapmayan saklı yordamlarda SET XACT_ABORT ON deyimini kullanın. Çalışma zamanı hatası oluştuğunda, bu ayar açık hareketleri iptal eder ve denetimi istemciye döndürür. Hataya neden olan deyimden sonraki T-SQL deyimlerinin yürütülmeyeceğine dikkat edin.
c. Web tabanlı bir uygulama gibi bağlantıyı açan ve yeniden havuza bırakmadan önce birkaç sorgu çalıştıran bir uygulamada bağlantı havuzu kullanılıyorsa, istemci uygulaması hataları düzgün işleyecek şekilde değiştirilene kadar bağlantı havuzunun geçici olarak devre dışı bırakılması sorunu giderebilir. Bağlantı havuzu devre dışı bırakıldığında bağlantının serbest bırakılması, SQL Server bağlantısının fiziksel olarak oturumu kapatmasına neden olur ve bu da sunucunun açık hareketleri geri almasıyla sonuçlanır.
d. Bağlantı havuzu etkinleştirilmişse ve hedef sunucu SQL Server 2000 ise, istemci bilgisayarın MDAC 2.6 veya daha ileri bir sürüme yükseltilmesi faydalı olabilir. MDAC bileşenlerinin bu sürümü, bağlantının yeniden kullanılmadan önce "sıfırlanması" için ODBC sürücüsüne ve OLE DB sağlayıcısına kod ekler. Bu sp_reset_connection çağrısı sunucu tarafından başlatılan hareketleri iptal eder (istemci uygulaması tarafından başlatılan DTC hareketleri etkilenmez), varsayılan veritabanını sıfırlar, SET ile seçenekleri ayarlar ve benzeri işlemleri gerçekleştirir. Bağlantının, bağlantı havuzundan yeniden alınana kadar sıfırlanmayacağına dikkat edin; böylece kullanıcı hareketi açabilir ve sonra bağlantıyı bağlantı havuzuna bırakabilir, ancak bağlantı birkaç saniye boyunca yeniden kullanılamaz ve bu süre boyunca hareket de açık kalır. Bağlantı yeniden kullanılmazsa, bağlantı zaman aşımına uğradığında ve bağlantı havuzundan kaldırıldığında hareket iptal edilir. Bu nedenle en iyisi istemcinin, hareketleri kendi hata işleyicilerinde iptal etmesi veya olası gecikmeyi önlemek için SET XACT_ABORT ON deyimini kullanmasıdır.

• Aslında, bu sınıftaki bir engelleme sorunu, performans sorunu da olabilir ve bu şekilde izlenmesi gerekir. Sorgu yürütme süresi azaltılabilirse sorgu zaman aşımı veya iptali oluşmaz. Uygulamanın, zaman aşımı veya iptal senaryolarının oluşması durumunda bunları işleyebilmesi önemlidir; ancak sorgunun performansının incelenmeside de yararlı olabilir.

Yavaş çalışan sorguda sorun giderme hakkında bilgi için, Microsoft Knowledge Base'de aşağıdaki makaleye bakın:
243589 () BİLGİ: SQL Server 7.0'da Yavaş Çalışan Sorgularda Sorun Giderme (Bu bağlantı, bir kısmı veya tamamı İngilizce olan içeriğe işaret edebilir.)
Genel uygulama performansı sorunlarını gidermek için, Microsoft Knowledge Base'de aşağıdaki makaleye bakın:
224587 () NASIL YAPILIR: SQL Server'da Uygulama Performansı Sorunlarını Giderme (Bu bağlantı, bir kısmı veya tamamı İngilizce olan içeriğe işaret edebilir.)
Diğer kullanıcıları engelleyen, eniyileştirilemeyen ve uzun süre çalışan bir sorgunuz varsa, sorguyu OLTP ortamından karar destek sistemine taşımayı düşünün.

3. SPID'ye Karşılık Gelen Uygulamanın Tüm Sonuç Satırlarını Sonuna Kadar Almaması Nedeniyle Oluşan Engelleme

Sunucuya bir sorgu gönderdikten sonra, tüm uygulamaların tüm sonuç satırlarını sonuna kadar hemen alması gerekir. Uygulama tüm sonuç satırlarını almazsa, tablolar kilitli bırakılabilir ve bu da diğer kullanıcıları engeller. SQL deyimlerini sunucuya saydam bir şekilde gönderen bir uygulama kullanıyorsanız, uygulamanın tüm sonuç satırlarını alması gerekir. Bunu gerçekleştirmezse (ve gerçekleştirecek şekilde yapılandırılamazsa), engelleme sorununu gideremeyebilirsiniz. Sorunu önlemek için, uygun şekilde davranmayan uygulamaları raporlama veya karar destek veritabanıyla kısıtlayabilirsiniz.

Çözüm:

Uygulamanın, sonucun tüm satırlarını sonuna kadar alacak şekilde yeniden yazılması gerekir.
4. Dağıtılmış İstemci/Sunucu Kilitlenmesinin Neden Olduğu Engelleme

Sıradan kilitlenmeden farklı olarak, dağıtılmış kilitlenme RDBMS kilit yöneticisi kullanılarak algılanamaz. Bunun nedeni, kilitlenmeyle ilgili kaynaklardan yalnızca birinin SQL Server kilidi olmasıdır. Kilitlenmenin diğer tarafı, SQL Server'ın denetleyemediği istemci uygulaması düzeyindedir. Aşağıda bunun nasıl oluşabileceğine dair iki örnek ve uygulamanın bunu önlemek için kullanabileceği yollar verilmektedir.

a. Tek Bir İstemci İş Parçacığı ile İstemci/Sunucu Dağıtılmış Kilitlenmesi
İstemcinin birden çok açık bağlantısı ve tek bir yürütme iş parçacığı varsa, aşağıdaki dağıtılmış kilitlenme oluşabilir. Kısaltma amacıyla buradaki "dbproc" terimi, istemci bağlantı yapısı anlamında kullanılır.

SPID1-----kilitte engellenir----->SPID2
/\ (sonuçları istemciye yazmak
| için bekliyor)
| |
| | Sunucu tarafı
| ================================|================= =================
| <-- tek iş parçacığı --> | İstemci tarafı
| \/
dbproc1 <------------------- dbproc2
(sonraki satırı getirmek (dbproc1'de engellendi, tek iş parçacığının
için bekliyor) yürütülmesi bekleniyor)

Yukarıda gösterilen durumda, tek bir istemci uygulaması iş parçacığının iki açık bağlantısı bulunmaktadır. Zaman uyumsuz olarak dbproc1 üzerinde gerçekleştirilecek bir SQL işlemi gönderir. Bu, devam etmeden önce çağrının dönüşünü beklemediği anlamına gelir. Daha sonra uygulama dbproc2 üzerinde gerçekleştirilecek başka bir SQL işlemi gönderir ve döndürülen verileri işlemeye başlamak için sonuçları bekler. Veriler gelmeye başladığında (hangi dbproc önce yanıtlarsa; dbproc1 olduğunu varsayalım), ilgili dbproc ile döndürülen tüm veriler sonuna kadar işlenir. SPID1, SPID2 tarafından tutulan kilit ile engellenene kadar dbproc1'den sonuçlar alınır (bunun nedeni iki sorgunun, sunucu üzerinde zaman uyumsuz olarak çalışmasıdır). Bu noktada, dbproc1 daha fazla veri almak için süresiz olarak bekler. SPID2 kilitle engellenmez, ancak istemcisine (dbproc2) veri göndermeye çalışır. Ancak, uygulamanın yürütülen tek iş parçacığı dbproc1 tarafından kullanıldığından, dbproc2 de dbproc1 üzerinde engellenir. İlgili kaynaklardan yalnızca biri SQL Server kaynağı olduğundan, bu durum SQL Server'ın algılayamayacağı veya gideremeyeceği bir kilitlenmeyle sonuçlanır.
b. Bağlantı Başına İş Parçacığı ile İstemci/Sunucu Dağıtılmış Kilitlenmesi

İstemcide her bağlantı için ayrı bir iş parçacığı olsa da, bu dağıtılmış kilitlenmenin bir türevi aşağıda gösterilen şekilde oluşabilir.

SPID1-----kilitte engellenir------>SPID2
/\ (ağda yazmayı bekliyor) Sunucu tarafı
| |
| |
| INSERT |SELECT
| ================================|================= =================
| <- dbproc başına iş parçacığı ->| İstemci tarafı
| \/
dbproc1 <---veri satırı------ dbproc2
(ekleme (dbproc1 üzerinde engellendi, arabelleğinden
bekleniyor) satırı okuması bekleniyor)

Bu durum, dbproc2 ve SPID2'nin aynı anda bir satır işlemi gerçekleştirme niyetiyle bir SELECT deyimi çalıştırması ve aynı tablodaki INSERT, UPDATE veya DELETE deyimi için her satırı dbproc1'e bir arabellek üzerinden vermesinin dışında Örnek A'ya benzemektedir. Sonuç olarak, (INSERT, UPDATE veya DELETE deyimini gerçekleştiren) SPID1, (SELECT deyimini gerçekleştiren) SPID2 tarafından tutulan bir kilit nedeniyle engellenmiş olur. SPID2, istemci dbproc2'ye sonuç satırı yazar. Daha sonra Dbproc2 arabellekteki satırı dbproc1'e geçirmeye çalışır, ancak dbproc1'i meşgul durumda bulur (SPID1'de geçerli INSERT deyimini tamamlamayı beklemektedir, o da SPID2 üzerinde engellenmiştir). Bu noktada dbproc2, SPID'si (SPID1), SPID2 tarafından veritabanı katmanında engellenen dbproc1 tarafından uygulama katmanında engellenir. Yine, ilgili kaynaklardan yalnızca biri SQL Server kaynağı olduğundan, bu durum SQL Server'ın algılayamayacağı veya gideremeyeceği bir kilitlenmeyle sonuçlanır.
Örnek A ve B uygulama geliştiricilerin farkında olması gereken temel sorunlardır. Uygulamaları, bu durumları düzgün işleyebilecek şekilde kodlamaları gerekir.

Çözümler:

Sorgu zaman aşımı veya bağlı bağlantılar kullanma güvenilir iki çözümdür.

• Sorgu Zaman Aşımı
Bir sorgu zaman aşımı sağlandığında, dağıtılmış kilitlenme oluşmuşsa zaman aşımı olduğunda kilitlenme çözülür. Sorgu zaman aşımı kullanımı hakkında daha fazla bilgi için DB-Library veya ODBC belgelerine bakın.
• Bağlı Bağlantılar
Bu özellik birden fazla bağlantıya sahip bir istemcinin, bunları tek bir hareket alanına bağlamasına olanak tanır ve böylece birbirlerini engellemezler. Daha fazla bilgi için, SQL Server 7.0 Çevrimiçi Kitapları'ndaki "Using Bound Connections" (Bağlı Bağlantıları Kullanma) konusuna bakın.

5. "Golden" veya Geri Alma Durumundaki SPID'nin Neden Olduğu Engelleme

Sonlandırılan veya kullanıcı tarafından tanımlanan hareketin dışında iptal edilen veri değiştirme sorgusu, geri alınır. Bu durum, istemci bilgisayarın yeniden başlatılmasının ve ağ oturumunun bağlantısının kesilmesinin yan etkisi olarak da oluşabilir. Benzer şekilde, kilitlenme kurbanı olarak seçilen sorgu geri alınır. Veri değiştirme sorgusunun geri alınma hızı, genellikle başlangıçta değişikliklerin uygulanma hızından daha yüksek değildir. Örneğin, DELETE, INSERT veya UPDATE deyimi bir saattir çalışıyorsa, geri almak da en az bir saat sürer. Yapılan değişikliklerin tam olarak geri alınması gerektiğinden bu beklenen davranıştır, aksi durumda veritabanındaki harekete dayalı ve fiziksel bütünlük tehlikeye atılır. Bunun yapılması gerektiğinden, SQL Server SPID'yi "golden" veya geri alma durumuna sokar (bu da, sonlandırılamayacağı veya kilitlenme kurbanı olarak seçilemeyeceği anlamına gelir). Bu durum genellikle, ROLLBACK komutunu gösterebilen sp_who çıkışı izlenerek belirlenebilir. sysprocesses'in Status sütunu ROLLBACK durumunu gösterir; bu durum sp_who çıkışında veya SQL Enterprise Manager Current Activity (Geçerli Etkinlik) ekranlarında da görünür.
Çözüm:

SPID'nin yapılan değişiklikleri geri almasını beklemeniz gerekir.

Bu işlemin ortasında sunucu kapatılırsa, veritabanı yeniden başlatıldığında kurtarma modunda olur ve tüm açık hareketler işlenene kadar veritabanına erişilemez. Başlangıç kurtarma işlemi, hareket başına çalışma zamanı kurtarması kadar zaman alır ve bu süre boyunca veritabanı erişilemez olur. Bu nedenle, geri alma durumundaki bir SPID'yi düzeltmek için sunucuyu kapanmaya zorlamak genellikle ters etki yapar.

Bu durumu önlemek için, OLTP sistemlerinde yoğun saatlerde büyük INSERT, UPDATE veya DELETE toplu işlemleri gerçekleştirmeyin. Mümkünse, bu tür işlemleri etkinliğin düşük olduğu zaman aralıklarında gerçekleştirin.
6. Artık Bağlantının Neden Olduğu Engelleme

İstemci uygulaması tuzağa yakalanırsa veya istemci iş istasyonu yeniden başlatılırsa, sunucudaki ağ oturumu bazı durumlarda hemen iptal edilemeyebilir. Sunucu açısından, istemci var görünmeye ve alınmış olan kilitler korunmaya devam eder. Daha fazla bilgi için, SQL Server 7.0 Çevrimiçi Kitapları'nda "Orphaned Connections" (Artık Bağlantılar) konusuna bakın.

Çözüm:

İstemci uygulamasının bağlantısı, kaynaklarını uygun şekilde temizlemeden kesilirse, KILL komutunu kullanarak SPID'yi sonlandırabilirsiniz. KILL komutu girdi olarak SPID değerini alır. Örneğin, SPID 9'u sonlandırmak için aşağıdaki komutu yayınlayın:

KILL 9


NOT: KILL komutunun tamamlanması, KILL komutu denetimleri arasındaki aralıklar nedeniyle 30 saniye kadar sürebilir.



Engelleme Sorunlarında Uygulamanın Payı
Engelleme sorunuyla karşı karşıya kalındığında sunucu tarafında ayarlama ve platform sorunlarına odaklanma eğilimi olabilir. Ancak, bu yaklaşım bazen bir çözüme ***ürmez ve istemci uygulamasını ve bunun gönderdiği sorguları incelemeye harcanması daha iyi sonuç verecek olan zaman ve enerjiyi tüketebilir. Yapılan veritabanı çağrılarıyla ilgili olarak uygulamanın sunduğu görünebilirlik düzeyine bakılmaksızın, engelleme sorunu çoğu zaman hem uygulama tarafından gönderilen SQL deyimlerinin hem de sorgu iptali, bağlantı yönetimi, tüm sonuç satırlarını alma ve benzeri ile ilgili olarak uygulamanın davranışının tam olarak incelenmesini gerektirir. Geliştirme aracı bağlantı yönetimi, sorgu iptali, sorgu zaman aşımı, sonuç getirme ve benzeri üzerinde açık denetime olanak tanımıyorsa, engelleme sorunları çözülemeyebilir. Bu olasılığın özellikle iş açısından kritik OLTP ortamlarında SQL Server için uygulama geliştirme aracı seçmeden önce yakından incelenmesi gerekir.

Veritabanının ve uygulamanın tasarım ve oluşturma aşamasında çok dikkatli olunması önemlidir. Özellikle, her sorgu için kaynak tüketimi, yalıtım düzeyi ve hareket yolu uzunluğu değerlendirilmelidir. Her bir sorgunun ve hareketin olabildiğince sade olması gerekir. İyi bağlantı yönetimi prensipleri uygulanmalıdır. Bu yapılmazsa, uygulamanın az sayıda kullanıcıyla kabul edilebilir bir performansa sahip gibi görünmesi olasıdır, ancak kullanıcı sayısı arttıkça performans önemli ölçüde düşebilir.

Düzgün uygulama ve sorgu tasarımıyla, Microsoft SQL Server tek bir sunucu üzerinde binlerce eşzamanlı kullanıcıyı çok az engellemeyle destekleyebilir. Daha fazla bilgi için SQL Server 7.0 Çevrimiçi Kitapları'nda "Application Design" (Uygulama Tasarımı) ve "Understanding and Avoiding Blocking" (Engellemeyi Anlama ve Önleme) konularına bakın. Bu kullanıcı sayılarına ulaşan başarılı siteler genellikle bu konularda açıklanan teknikleri kullanır.