Bu kilitlenme türü için olası neden ne olabilir? (genel olarak çıkmaz)
İletişim arabelleği kaynaklarını kilitle
Belirtilen sistem hafızada düşük mü ve tamponların sayısı sınırsız mı?
Ayrıntılı Hata:
İşlem (İşlem Kimliği 59), başka bir işlemle kilit iletişim arabellek kaynakları üzerinde kilitlendi ve kilitlenme kurbanı olarak seçildi. İşlemi yeniden başlat
Yanıtlar:
Yaygın olarak görülen tam mesaj:
İşlem (İşlem Kimliği 53) kilitlendiğinde kilitlendi | başka bir işlem ile iletişim tampon kaynakları ve kilitlenme kurbanı olarak seçildi. İşlemi yeniden çalıştırın.
Bu kilit türü, genellikle "sorgu içi paralel kilitlenme" olarak da adlandırılan, SQL Server'ın paralel olarak yürüttüğü kilitlenme sorgularıyla birlikte görülür. Bunun, sistem kaynaklarının düşük olduğunu ve bunun da küçük bir dereceye kadar dahil olabileceğini belirttiğine dair birkaç ifade gördüm.
Paralel kilitlenme olup olmadığını belirlediğim için genel bir kılavuz, XML kilitlenme grafiğini (2008 ve üstü sistem_health oturumu ile yapılabilen) çizdiğiniz zamandır; yürütme yığını
Ayrıca, kilitlenme grafiğinin kaynak listesine bakarken ve garson olayı türünü not ederek. Genellikle "e_xxxxxx" veya bunun gibi bir şey gösterirler:
<waiter-list>
<waiter event="e_waitPipeGetRow" type="consumer" id="process821d828" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process8209198" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process3827c18" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process3809eb8" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process8226b08" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process9acb6d8" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process6188d7828" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process381cef8" />
</waiter-list>Sorunu denemek ve çözmek için çevrimiçi ve kitaplarda atılması gereken çeşitli yollar sunulur. Genelde sorgu / prosedürün yürütme planına bakarak başlar ve paralel yürütmeyi gösteren alanlara odaklanırım. Daha sonra oradan önce sorguyu ayarlamaya çalışmaktan sonra son çare olarak sorgu ipuçlarını kullanmaya başlayabilir.
Bu kilitlenmeleri gidermek için bahsettiğin en yaygın sorgu ipucu uygulamaktır MAXDOP 1. Bununla birlikte, bunu yapmadan önce, sunucu seviyesi MAXDOP ve Maliyet Eşiği değerlerinin ne şekilde ayarlandığını kontrol edebilirsiniz. Maliyet Eşiği genellikle varsayılan olarak 5 olarak ayarlanır ve söz konusu sorgunun kod bölümü için düşük bir maliyeti varsa, paralel olarak çalıştırılması gerekmeyebilirse, başlamak için bunu 35 veya 40'a çıkarmak isterim. MAXDOP sorgulama ipuçlarını kullanmaktan hoşlanmayan biri değilim ama bu onların yeri ve amacı olmadığı anlamına gelmiyor. sadece benim düşüncem.