Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Bu makalede, derleme kilitlerinin neden olduğu engelleme sorunlarını giderme ve çözme işlemleri açıklanmaktadır.
Özgün ürün sürümü: SQL Server
Özgün KB numarası: 263889
Özet
Microsoft SQL Server'da, bir saklı yordam planının yalnızca bir kopyası genellikle bir kerede önbellektedir. Bunun zorunlu hale getirilmesi için derleme işleminin bazı bölümlerinin seri hale getirilmesi gerekir ve bu eşitleme kısmen derleme kilitleri kullanılarak gerçekleştirilir. Birçok bağlantı aynı saklı yordamı eşzamanlı olarak çalıştırıyorsa ve her çalıştığında bu saklı yordam için bir derleme kilidi alınması gerekiyorsa, her biri nesne üzerinde özel bir derleme kilidi elde etmeye çalışırken oturum kimlikleri (SPID) birbirini engellemeye başlayabilir.
Derleme engellemenin engelleme çıkışında gözlemlenebilir bazı tipik özellikleri aşağıda verilmiştir:
waittypeengellenen ve (genellikle) engelleyen oturum IÇIN SPID'lerLCK_M_X(özel) vewaitresourcebiçimindedirOBJECT: dbid: object_id [[COMPILE]]; buradaobject_idsaklı yordamın nesne kimliğidir.Engelleyiciler
waittypeNULL, durum çalıştırılabilir. Engellenen oturumlardawaittypeLCK_M_X(özel kilit), uyku durumu bulunur.Engelleme olayının genel süresi uzun olsa da, diğer SPID'leri uzun süre engelleyen tek bir oturum (SPID) yoktur. Sıralı engelleme var; bir derleme tamamlanır tamamlanmaz, başka bir SPID birkaç saniye veya daha kısa bir süre boyunca baş engelleyici rolünü devralır, vb.
Aşağıdaki bilgiler, bu tür bir engelleme sırasında anlık sys.dm_exec_requests görüntüsünden alınıyor:
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]]
Sütunda waitresource (6:834102), 6 veritabanı kimliği ve 834102 nesne kimliğidir. Bu nesne kimliği tabloya değil saklı yordama aittir.
Derleme kilitlerine yol açan senaryolar
Aşağıdaki senaryolarda saklı yordamlarda veya tetikleyicilerde özel derleme kilitlerinin nedenleri açıklanmaktadır.
Saklı Yordam Tam Ad olmadan yürütülür
- Saklı yordamı çalıştıran kullanıcı, yordamın sahibi değildir.
- Saklı yordam adı, nesne sahibinin adıyla tam olarak nitelenmemiştir.
Örneğin, dbo kullanıcısı nesneye dbo.mystoredproc ve başka bir kullanıcıya sahipse, Harrykomutunu kullanarak exec mystoredprocbu saklı yordamı çalıştırır; nesnenin sahip nitelikli olmadığı için nesne adına göre ilk önbellek araması başarısız olur. (Adlı Harry.mystoredproc başka bir saklı yordamın mevcut olup olmadığı henüz bilinmiyor. Bu nedenle, SQL Server için önbelleğe alınmış planın yürütülecek doğru plan dbo.mystoredproc 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ı bir nesne kimliğine çözümlemeyi 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.
Mevcut bir plan bulunursa, SQL Server önbelleğe alınmış planı yeniden kullanır ve saklı yordamı derlemez. Ancak sahip yeterlik eksikliği, program mevcut önbelleğe alınmış yürütme planının yeniden kullanılabilmesini saptamadan önce SQL Server'ı ikinci bir önbellek araması yapmaya ve özel derleme kilidi elde etmeye zorlar. Kilidin alınması ve bu noktaya ulaşmak için gereken aramaların ve diğer çalışmaların gerçekleştirilmesi, derleme kilitleri için engellemeye yol açan bir gecikmeye neden olabilir. Saklı yordamın sahibi olmayan birçok kullanıcı, sahibin adını vermeden yordamı eşzamanlı olarak çalıştırıyorsa bu durum özellikle geçerlidir. Derleme kilitlerini bekleyen SPID'ler görmeseniz bile sahip yeterliliği olmaması saklı yordam yürütmede gecikmelere neden olabilir ve yüksek CPU kullanımına neden olabilir.
Bu sorun oluştuğunda aşağıdaki olay dizisi SQL Server Genişletilmiş Olay oturumuna kaydedilir.
| Olay Adı | Metin |
|---|---|
| rpc_starting | mystoredproc |
| sp_cache_miss | mystoredproc |
| sql_batch_starting | mystoredproc |
| sp_cache_hit | mystoredproc |
| ... | ... |
sp_cache_miss , ada göre önbellek araması başarısız olduğunda gerçekleşir, ancak belirsiz nesne adı bir nesne kimliğine çözümlendikten ve bir olay olduğunda önbellekte eşleşen bir sp_cache_hit önbelleğe alınmış plan bulunur.
Bu derleme kilitleme sorununun çözümü, saklı yordamlara yapılan başvuruların sahip nitelikli olduğundan emin olmaktır. (exec yerine exec mystoredprocdbo.mystoredprockullanın.) Sahip yeterliliği performans nedenleriyle önemli olsa da, ek önbellek aramasını önlemek için depolanan proc'a veritabanı adıyla nitelemeniz gerekmez.
Derleme kilitlerinden kaynaklanan engelleme, standart engelleme sorun giderme yöntemleri kullanılarak algılanabilir.
Saklı yordam sık sık yeniden derleniyor
Yeniden derleme, saklı yordam veya tetikleyicideki derleme kilitlerinin bir açıklamasıdır. Bir saklı yordamın yeniden derlenesine neden olmanın yolları arasında EXECUTE... WITH RECOMPILE, CREATE PROCEDURE ...WITH RECOMPILEveya kullanma sp_recompilebulunur. Daha fazla bilgi için bkz . Saklı Yordamı Yeniden Derleme. Bu durumda çözüm, yeniden derlemeyi azaltmak veya ortadan kaldırmaktır.
Saklı yordama sp_** ön eklenmiştir
Saklı yordam adınız ön ek ile sp_ başlıyorsa ve ana veritabanında değilse, saklı yordamı sahip olarak niteleseniz bile her yürütme için önbellek isabet etmeden önce sp_cache_miss görürsünüz. Bunun nedeni, ön ekin sp_ SQL Server'a saklı yordamın bir sistem saklı yordamı olduğunu ve sistem saklı yordamlarının farklı ad çözümleme kurallarına sahip olduğunu belirtmesidir. (Tercih edilen konum ana veritabanındadır.) Kullanıcı tarafından oluşturulan saklı yordamların adları ile sp_başlamamalıdır.
Saklı yordam farklı bir büyük/küçük harf kullanılarak çağrılır (üst /alt)
Sahip nitelikli yordam, oluşturmak için kullanılan büyük/küçük harften farklı bir harf durumu (üst veya alt) kullanılarak çalıştırılırsa, yordam bir CacheMiss olayını tetikleyebilir veya COMPILE kilidi isteyebilir. Bunu göstermek için içinde kullanılan CREATE PROCEDURE dbo.SalesData ... harf örneğinin yerine EXEC dbo.salesdatakullanıldığına dikkat edin. Sonunda, yordam önbelleğe alınmış planı kullanır ve yeniden derlenmez. Ancak DERLEME kilidi isteği bazen daha önce açıklanan bir engelleme zinciri durumuna neden olabilir. Engelleme zinciri, oluşturmak için kullanılan durumdan farklı bir servis talebi kullanarak aynı yordamı yürütmeye çalışan çok sayıda oturum (SPID) varsa oluşabilir. Bu, sunucuda veya veritabanında kullanılan sıralama düzeninden veya harmanlamadan bağımsız olarak geçerlidir. Bu davranışın nedeni, önbellekteki yordamı bulmak için kullanılan algoritmanın karma değerlere (performans için) dayalı olması ve büyük/küçük harf farklıysa karma değerlerin değişebileceğidir.
Çözüm, uygulama yordamı yürütürken kullanılan harf örneğini kullanarak yordamı bırakmak ve oluşturmaktır. Ayrıca, doğru büyük/küçük harf (üst veya alt) kullanarak yordamın tüm uygulamalardan yürütülmesini de sağlayabilirsiniz.
Saklı yordam Bir Dil olayı olarak çağrılır
Bir saklı yordamı RPC yerine Dil Olayı olarak yürütmeyi denerseniz, SQL Server'ın dil olayı sorgusunu ayrıştırıp derlemesi, sorgunun belirli bir yordamı yürütmeye çalıştığını belirlemesi ve ardından bu yordam için önbellekte bir plan bulmaya çalışması gerekir. SQL Server'ın dil olayını ayrıştırması ve derlemesi gereken bu durumdan kaçınmak için sorgunun SQL Server'a RPC olarak gönderildiğinden emin olun. Örneğin, .NET kodunda bir RPC olayından emin olmak için kullanabilirsiniz SqlCommand.CommandType.StoredProcedure .
Saklı yordam veya sp_executesql 8 KB'tan büyük bir dize parametresi kullanır
Saklı yordamı veya sp_executesql çağırır ve 8 KB'tan büyük bir dize parametresi geçirirseniz, SQL Server parametreyi depolamak için ikili büyük nesne (BLOB) veri türünü kullanır. Sonuç olarak, bu yürütme için sorgu planı plan önbelleğinde kalıcı olmaz. Bu nedenle, saklı yordamın her yürütmesi veya sp_executesql yeni bir plan derlemek için bir derleme kilidi alması gerekir. Yürütme tamamlandığında bu plan atılır. Daha fazla bilgi için Yürütme planı önbelleğe alma ve 8 KB'tan büyük dize değişmez değerleriyle ilgili yeniden kullanma başlığındaki nota bakın. Bu senaryoda derleme kilidini önlemek için parametrenin boyutunu 8 KB'ın altına düşürün.
Başvurular
OPEN SYMMETRIC KEY komutu sorgu planı önbelleğe almayı engeller