SQL Server tarafından derleme kilit nedeniyle engelleme açıklaması

Makale çevirileri Makale çevirileri
Makale numarası: 263889 - Bu makalenin geçerli olduğu ürünleri görün.
Hepsini aç | Hepsini kapa

Bu Sayfada

Özet

Microsoft SQL Server'da, tek bir saklı yordam planı genellikle önbellekte bir kopyasıdır. Bu zorlama seri hale getirme bazı bölümlerinin derleme işlemi gerektirir ve bu eşitleme, kısmen derleme kilit kullanılarak gerçekleştirilir. Çok sayıda bağlantısı saklı yordamı aynı anda çalışan ve bir derleme kilidi, saklı yordam için çalışan her zaman elde edilmesi, sistem işlem kimliği (SPID), her bir nesne üzerinde özel derleme kilit edinmeye gibi birbirine engellemek başlayabilir.

Daha fazla bilgi

Saklı yordam recompilation bir açıklama yapmak için bir saklı yordam veya tetikleyiciyi derleme kilitleri var. Bu durumda azaltmak veya recompiles ortadan kaldırmak için çözümdür. Derlenmiş çekirdekler için bir saklı yordam olabilecek en yaygın nedenleri hakkında bir açıklama ve bazı yararlı bilgi recompiles sıklığını azaltmak için aşağıdaki Microsoft Bilgi Bankası makalesine bakın:
243586Saklı yordam recompilation sorun giderme
Aşağıdaki koşullar geçerli olduğunda ortaya çıktığı derleme kilit başka bir senaryodur:
  • Depolanmış yordam çalıştıran kullanıcı yordamı sahibi değil.
  • Saklı yordam adı, nesne sahibinin adı ile tam değil.
Örneğin, kullanıcı "dbo" nesnenin sahibidbo.mystoredprocve nesnenin sahibi tam olmadığı için komut "exec mystoredproc," nesne adı başarısız olarak ilk önbellek araması kullanarak başka bir kullanıcı, "Harry," Bu saklı yordamı çalıştırır. (Bunu henüz Harry.mystoredproc adlı başka bir saklı yordamı var olup olmadığını bilinmiyor. Bu nedenle, SQL Server dbo.mystoredproc için önbelleğe alınan planını çalıştırmak için doğru olduğunu emin olamaz.) SQL Server bir özel derleme yordamı kilitlendiğinde alır ve yordamı oluşturmak için gerekli hazırlıkları yapar. Bu nesne kimliği için nesne adı çözümleme içerir. SQL Server plan derleme önce SQL Server yordam önbelleğindeki daha kesin bir arama gerçekleştirmek için bu nesnenin Kimliğini kullanır ve niteliğe sahip olmayan daha önceden derlenmiş bir plan bulabilirsiniz.

Varolan bir planı varsa, SQL Server önbelleğe alınan plan kullanır ve gerçekte saklı yordam derleme değil. Ancak, varolan önbelleğe alınmış yürütme planı yeniden kullanılabilir program belirlemeden önce bir özel derleme kilit almak ve ikinci bir önbellek araması gerçekleştirmek için SQL Server sahibi niteliği yetersiz zorlar. Kilit almak ve aramaları ve bu noktaya ulaşmak için gereken diğer işleri engellemek için müşteri adayları bir gecikme için derleme kilitleri neden olabilir. Sahibinin adı sağlama olmadan, aynı anda yordamı çalıştırmak saklı yordamın sahip olmayan kullanıcıların çoğu, özellikle de doğru olmasıdır. Derleme kilitlerine bekleyen SPID görmek bile sahip nitelikte olmaması, saklı yordam çalıştırmayı gecikmelere neden ve gereksiz yere yüksek CPU kullanımına neden unutmayın.

Bu sorun oluştuğunda, aşağıdaki olaylar dizisi bir SQL Server Profiler izlemesinde kaydedilir. (Önbellek ile ilgili olayları izlemek için Gelişmiş olayları etkinleştirmeniz gerekir. Bunu yapmak için tıklatınSeçeneklerüzerindeAraçlarımenü seçeneğini tıklatıp seçinTüm olay sınıflarını.)

Bu tabloyu kapaBu tabloyu aç
Olay sınıfıText
RPC: Başlangıçmystoredproc
SP:CacheMissmystoredproc
SP:ExecContextHitmystoredproc
SP: Başlangıçmystoredproc
......

SP:CacheMissada göre önbellek araması başarısız olduğunda oluşur. AşağıdakiSP:ExecContextHitsonra belirsiz bir nesne adını çözülmüş bir nesne kimliği için eşleşen bir önbellek planı önbellekte sonuçta bulunamadığını gösterir Koşullara göreSP:CacheHityerine görünebilirSP:ExecContextHit.

Derleme kilitleme bu sorunun çözümü, saklı yordamlar başvuru sahibi tam emin olmasını sağlamaktır. (Yerineexec mystoredproc, Yönet'i kullanmadbo.mystoredproc.) Sahibi niteliği performansı artırmak için önemli olsa da, saklı yordam ek önbellek araması önlemek için veritabanı adı ile ilgili gerek yoktur.

Engelleme, kilit aşağıdaki Microsoft Bilgi Bankası makalelerinde tanımlanan gibi engelleme komut dosyalarını kullanarak algılanabilir derleme nedeniyle oluşur:
251004BİLGİ: SQL Server 7.0 engelleme izlemek nasıl kullanılır
271509BİLGİ: SQL Server 2000 engelleme izlemek nasıl kullanılır
The following are some typical characteristics of compile blocking that can be observed in the blocking script output:
  • lastwaittypefor the blocked and (usually) blocking SPIDs is LCK_M_X (exclusive) andwaitresourceis of the form "TAB: dbid:object_id[[COMPILE]]," where "object_id" is the object ID of the stored procedure.
  • Blockers havewaittype0x0000, status runnable. Blockees havewaittype0x000e (exclusive lock), status sleeping.
  • Although the duration of the blocking incident may be long, there is no single SPID that is blocking the other SPIDs for a long time. There is rolling blocking. As soon as one compilation is complete, another SPID takes over the role of head blocker for a several seconds or less, and so on.
The following information is from a snapshot ofsysprocessesduring this kind of blocking:
   spid  blocked  waittype  waittime  lastwaittype  waitresource
   ----  -------  --------  --------  ------------  -------------------------
   
   221    29      0x000e    2141      LCK_M_X       TAB: 6:834102 [[COMPILE]]
   228    29      0x000e    2235      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    29   214      0x000e    3937      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    13   214      0x000e    1094      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    68   214      0x000e    1968      LCK_M_X       TAB: 6:834102 [[COMPILE]]
   214     0      0x0000       0      LCK_M_X       TAB: 6:834102 [[COMPILE]]
İçindewaitresourcecolumn ("6:834102"), 6 is the database ID and 834102 is the object ID. Be aware that this object ID belongs to a stored procedure, not to a table (despite the "TAB" lock type).

NOTLAR
  • If you are using SQL Server 2005, many of the system tables from SQL Server 2000 are now implemented as a set of views. These views are known as compatibility views, and they are meant for backward compatibility only. The compatibility views expose the same metadata that was available in SQL Server 2000. For more information about mapping between the SQL Server 2000 system tables and the SQL Server 2005 system views, see the "Mapping SQL Server 2000 System Tables to SQL Server 2005 System Views" topic in SQL Server 2005 Books Online.
  • If your stored procedure name starts with the "sp_" prefix and is not in the master database, you seeSP:CacheMissbefore the cache hit for each execution even if you owner-qualify the stored procedure. This is because the sp_ prefix tells SQL Server that the stored procedure is a system stored procedure, and system stored procedures have different name resolution rules. (The "preferred" location is in the master database.) The names of user-created stored procedures should not start with "sp_".
  • If an owner-qualified procedure is executed with a different case than the owner-qualified procedure was created as, the owner-qualified procedure can obtain aCacheMissor request a COMPILE lock but eventually use the cached plan. Therefore, this would not actually recompile the procedure and should not cause much of an overhead. But in certain situations, the request for a COMPILE lock can cause a "blocking chain" situation if there are many SPIDs trying to execute the same procedure with a different case than the procedure was created as. This is true regardless of the sort order or collation that is being used on the server or on the database. The reason for this behavior is that the algorithm that is being used to find the procedure in cache is based on hash values (for performance reasons), which can change if the case is different.

    The workaround is to drop and create the procedure with the same case as the procedure is executed by the application. You can also make sure that the procedure is executed from all applications that use the same case.
  • If you try to execute a stored procedure as a Language Event instead of as an RPC, SQL Server must parse and compile the language event query, determine that the query is trying to execute the particular procedure, and then try to find a plan in cache for that procedure. To avoid this situation in which SQL Server must parse and compile the language event, make sure that the query is sent to SQL as an RPC.

    For more information, see the "System Stored Procedures" section in the Books Online article "Creating a Stored Procedure."


Known issues

Here are some known issues that can prevent plan caching:
  • You use BLOB variables as a Stored Procedure parameter. Daha fazla bilgi için, Microsoft Bilgi Bankası'ndaki makaleyi görüntülemek üzere aşağıdaki makale numarasını tıklatın::
    2380435FIX: The query plan for a stored procedure is not cached if the stored procedure uses a BLOB variable and the variable is used in a string function in Microsoft SQL Server 2008
  • You use OPEN SYMMETRIC KEY in a Stored Procedure/Query Batch. For more information, see the following MSDN blog entry:
    http://blogs.msdn.com/b/sqlserverfaq/Archive/2010/09/08/Open-Symmetric-Key-Command-prevents-Query-Plan-Caching.aspx

Özellikler

Makale numarası: 263889 - Last Review: 24 Kasım 2010 Çarşamba - Gözden geçirme: 1.0
Bu makaledeki bilginin uygulandığı durum:
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL 2005 Server Workgroup
Anahtar Kelimeler: 
kbinfo kbmt KB263889 KbMttr
Machine-translated Article
ÖNEMLİ: Bu makale, bir kişi tarafından çevrilmek yerine, Microsoft makine-çevirisi yazılımı ile çevrilmiştir. Microsoft size hem kişiler tarafından çevrilmiş, hem de makine-çevrisi ile çevrilmiş makaleler sunar. Böylelikle, bilgi bankamızdaki tüm makalelere, kendi dilinizde ulaşmış olursunuz. Bununla birlikte, makine tarafından çevrilmiş makaleler mükemmel değildir. Bir yabancının sizin dilinizde konuşurken yapabileceği hatalar gibi, makale; kelime dağarcığı, söz dizim kuralları veya dil bilgisi açısından yanlışlar içerebilir. Microsoft, içeriğin yanlış çevrimi veya onun müşteri tarafından kullanımından doğan; kusur, hata veya zarardan sorumlu değildir. Microsoft ayrıca makine çevirisi yazılımını sıkça güncellemektedir.
Makalenin İngilizcesi aşağıdaki gibidir:263889

Geri Bildirim Ver

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com