Özet

Microsoft SQL Server'da, depolanan yordam planının yalnızca bir kopyası genellikle önbellektedir. Bunu zorlamak derleme işleminin bazı bölümlerinin serileştirilmesini gerektirir ve bu eşitleme kısmen derleme kilitleri kullanılarak gerçekleştirilir. Birçok bağlantı aynı anda aynı anda depolanan yordamı çalıştırıyorsa ve bu depolanan yordam için her çalıştırılan işlem için bir derleme kilidi elde edilmesi gerekiyorsa, oturum iDiler (SpiD'ler) her biri özel bir derleyici kilidi elde etmeye çalışırken birbirlerini engellemeye başlayabilir Nesne.

Engelleme çıkışında gözlemlenebilen derleme engellemenin bazı tipik özellikleri şunlardır:

  • engellenen ve (genellikle) engelleme oturumu SPID'leri için bekleme tipi LCK_M_X (özel) ve bekleme kaynağı "OBJECT: dbid:object_id [[COMPILE]", burada "object_id" depolanan yordamın nesne kimliğidir.

  • Engelleyiciler bekleme tipi NULL, durum çalıştırılabilir var. Blockees bekleme tipi LCK_M_X (özel kilit), durum uyku var.

  • Engelleme olayının süresi uzun olsa da, diğer SPID'leri uzun süre engelleyen tek bir SPID yoktur. Yuvarlanma engellemesi var. En kısa sürede bir derleme tamamlandığında, başka bir SPID birkaç saniye veya daha az baş engelleyici rolünü devralır, ve benzeri.

Aşağıdaki bilgiler, bu tür engelleme sırasında sys.dm_exec_requests bir anlık görüntüsünden:

   session_id  blocking_session_id  wait_type  wait_time  waitresource
   ----------  -------------------  ---------  ---------  ----------------------------   
   221          29                  LCK_M_X    2141       OBJECT: 6:834102 [[COMPILE]]
   228          29                  LCK_M_X    2235       OBJECT: 6:834102 [[COMPILE]]
    29         214                  LCK_M_X    3937       OBJECT: 6:834102 [[COMPILE]]
    13         214                  LCK_M_X    1094       OBJECT: 6:834102 [[COMPILE]]
    68         214                  LCK_M_X    1968       OBJECT: 6:834102 [[COMPILE]]
   214           0                  LCK_M_X       0       OBJECT: 6:834102 [[COMPILE]] 

Bekleme kaynağı sütununda ("6:834102"), 6 veritabanı kimliği ve 834102 nesne kimliğidir. Bu nesne kimliğinin tabloya değil, depolanmış bir yordama ait olduğunu lütfen unutmayın.

Ek Bilgi

Depolanan yordam derlemesi, depolanan yordam veya tetikleyicideki kilitleri derlemek için yapılan bir açıklamadır. Bu durumda çözüm, yeniden derlemeleri azaltmak veya ortadan kaldırmaktır. Depolanan yordamın yeniden derlenmesi gerekebilecek en yaygın nedenlerle ve yeniden derleme sıklığını azaltmaya ilişkin bazı yararlı bilgiler için aşağıdaki Microsoft Bilgi Bankası makalesine bakın:

243586 Sorun giderme depolanan yordam derlemesi

Kilitleri Derlemeye Yol Açan Ek Senaryolar:

  1. Depolanan Yordam Tam Nitelikli Ad olmadan yürütülür

    • Depolanan yordamı çalıştıran kullanıcı yordamın sahibi değildir.

    • Depolanan yordam adı, nesne sahibinin adı ile tam olarak nitelikli değildir.

    Örneğin, kullanıcı "dbo" nesne dbo.mystoredproc ve başka bir kullanıcı, "Harry" sahibi ise, "exec mystoredproc" komutunu kullanarak bu depolanan yordamı çalıştırır, nesne adına göre ilk önbellek arama sıcağı başarısız olur, çünkü nesne sahibi nitelikli değildir. (Henüz Harry.mystoredproc adlı başka bir saklı yordam var olup olmadığı bilinmemektedir. Bu nedenle, SQL Server dbo.mystoredproc için önbelleğe alınmış planın yürütülmesi için doğru olan olduğundan emin olamaz.) SQL Server daha sonra yordamüzerinde özel bir derleme kilidi alır ve yordamı derlemek için hazırlıklar yapar. Bu, nesne adının nesne kimliğine çözülmesini içerir. SQL Server planı derlemeden önce, SQL Server yordam önbelleğinde daha hassas bir arama yapmak için bu nesne kimliğini kullanır ve sahip niteliği olmadan bile önceden derlenmiş bir planı bulabilir. Varolan bir plan bulunursa, SQL Server önbelleğe alınmış planı yeniden kullanır ve depolanan yordamı gerçekten derlemez. Ancak, sahip-yeterlilik eksikliği SQL Server'ı ikinci bir önbellek araması yapmaya ve program varolan önbelleğe alınmış yürütme planının yeniden kullanılabileceğini belirlemeden önce özel bir derleme kilidi almaya zorlar. Kilit ve bu noktaya ulaşmak için gerekli olan aramave diğer çalışma gerçekleştirmek elde engelleme yol açan derleme kilitleri için bir gecikme başlatabilir. Bu, özellikle, depolanan yordamın sahibi olmayan birçok kullanıcı yordamı sahibinin adını vermeden aynı anda çalıştırıyorsa geçerlidir. Kilitleri derlemek için bekleyen SPID'leri görmeseniz bile, sahip niteliği eksikliğinin saklanan yordam yürütmesinde gecikmelere neden olabileceğini ve gereksiz yere yüksek CPU kullanımına neden olabileceğini unutmayın. Bu sorun oluştuğunda, aşağıdaki olaylar dizisi bir SQL Server Extended Event oturumuna kaydedilir.

    Etkinlik Adı

    Metin

    rpc_starting

    mystoredproc

    sp_cache_miss

    mystoredproc

    sql_batch_starting

    mystoredproc

    sp_cache_hit

    mystoredproc

    ...

    ...

    sp_cache_miss, önbellek ada göre arama başarısız olduğunda oluşur, ancak belirsizlik nesne adı nesne kimliğine çözüldükten ve sp_cache_hit bir olay olduktan sonra önbellekte eşleşen bir önbelleğe alınmış plan bulunur. Derleme kilitleme bu sorunun çözümü, depolanan yordamlara yapılan başvuruların sahip nitelikli olduğundan emin olmaktır. (Exec mystoredprocyerine, exec dbo.mystoredprockullanın .) Performans nedenleriyle sahip niteliği önemli olsa da, ek önbellek aramasını önlemek için depolanan proc'u veritabanı adı ile nitelemeniz gerekmez. Derleme kilitleri neden olduğu engelleme standart engelleme sorun giderme yöntemleri kullanılarak algılanabilir.

  2. Depolanan yordam "sp_" ile önceden belirlenmiş

    Depolanan yordam adınız "sp_" önekiyle başlıyorsa ve ana veritabanında değilse, depolanan yordamı sahibi niteleseniz bile önbellek her yürütme için isabet etmeden önce sp_cache_miss görürsünüz. Bunun nedeni, sp_ önekinin SQL Server'a depolanan yordamın sistem depolanan bir yordam olduğunu ve sistem depolanan yordamların farklı ad çözümleme kurallarına sahip olduğunu söylemesidir. ("Tercih edilen" konum ana veritabanındadır.) Kullanıcı tarafından oluşturulan depolanan yordamların adları "sp_" ile başlamamalıdır.

  3. Depolanan yordam farklı bir servis talebi (üst /alt) kullanılarak çağrılır

    Sahip nitelikli yordam, oluşturmak için kullanılan servis talebinden farklı bir servis talebi (üst veya alt) kullanılarak yürütülürse, yordam bir CacheMiss olayını tetikleyebilir veya DERLeE kilidi isteyebilir. Sonunda, yordam önbelleğe alınmış planı kullanır ve yeniden derlenmez. Ancak DERLEME kilidi isteği, oluşturmak için kullanılan durumdan farklı bir servis talebi kullanarak aynı yordamı gerçekleştirmeye çalışan çok sayıda SPID varsa bazen "engelleme zinciri" durumuna neden olabilir. Bu, sunucuda veya veritabanında kullanılan sıralama sırası veya harmanlama ne olursa olsun doğrudur. Bu davranışın nedeni, önbellekte yordamı bulmak için kullanılan algoritmanın karma değerlere (performans için) dayanması ve servis talebi farklıysa karma değerlerinin değişebiliyor olmasıdır. Geçici çözüm, uygulama yordamı yürütürken kullanılan servis talebiyle aynı servis talebi kullanılarak yordamı bırakmak ve oluşturmaktır. Ayrıca, doğru servis talebi (üst veya alt) kullanarak tüm uygulamalardan yordamın yürütüldeceğinden de emin olabilirsiniz.

  4. Depolanan yordam Bir Dil olayı olarak çağrılır

    RPC yerine Dil Olayı olarak depolanan bir yordamı yürütmeye çalışırsanız, SQL Server dil olay sorgusunu ayrıştırmalı ve derlemeli, sorgunun belirli yordamı yürütmeye çalıştığını belirlemeli ve ardından bu yordam için önbellekte bir plan bulmaya çalışmalısınız. SQL Server'ın dil olayını ayrıştırması ve derlemesi gereken bu durumu önlemek için, sorgunun RPC olarak SQL'e gönderildiğinden emin olun.

    Daha fazla bilgi için, Books Online makalesi "Depolanmış Yordam Oluşturma" bölümündeki "Sistem Depolanan Yordamlar" bölümüne bakın.

Bilinen sorunlar

Plan önbelleğe almayı önleyebilen bilinen bazı sorunlar şunlardır:

  • BLOB değişkenlerini Depolanmış Yordam parametresi olarak kullanırsınız. Daha fazla bilgi için, Makaleyi Microsoft Bilgi Bankası'nda görüntülemek için aşağıdaki makale numarasını tıklatın:

    2380435 DÜZELTME: Saklanan yordam blob değişkeni kullanıyorsa ve değişken Microsoft SQL Server 2008'de bir dize işlevinde kullanılıyorsa, depolanan yordam için sorgu planı önbelleğe alınmaz

  • Depolanan Yordam/Sorgu Toplu İşleminde AÇIK SİMETRİk KEY'i kullanırsınız. Daha fazla bilgi için aşağıdaki MSDN blog girişine bakın:

    OPEN SymmetrIC KEY komutu sorgu planı önbelleğe alma önler

Daha fazla yardıma mı ihtiyacınız var?

Yeteneklerinizi geliştirin

Eğitimleri keşfedin >

Yeni özellikleri ilk olarak siz edinin

Microsoft Insider’a katılın >

Bu bilgi yararlı oldu mu?

Dil kalitesinden ne kadar memnunsunuz?
Deneyiminizi ne etkiledi?

Geri bildiriminiz için teşekkürler!

×