Popis serveru SQL Server blokování způsobené uzamčení kompilace

Překlady článku Překlady článku
ID článku: 263889 - Produkty, které se vztahují k tomuto článku.
Rozbalit všechny záložky | Minimalizovat všechny záložky

Na této stránce

Souhrn

Na serveru Microsoft SQL Server pouze jednu kopii uloženou proceduru plánu je obecně v mezipaměti najednou. Vynucení to vyžaduje serializace některých částí proces kompilace a tato synchronizace je částečně provedeno pomocí zámků kompilace. Počet připojení pracují současně stejné uložené procedury a kompilace lock musí být získány pro tuto uloženou proceduru pokaždé, když je spuštěn, systémový proces ID (SPIDs) může začít blokovat vzájemně tak, jak se jednotlivé pokusí získat výhradní kompilace lock objektu.

Další informace

Uložená procedura recompilation je jeden vysvětlení kompilace zámků na uložené procedury a aktivační procedury. Řešení v tomto případě je snížit nebo odstranit překompilování. Vysvětlení nejčastější příčiny, které uložená procedura může být recompiled a některé užitečné informace týkající se snížení frekvence překompilování naleznete v následujícím článku znalostní báze Microsoft Knowledge Base:
243586Poradce při potížích s uloženou procedurou recompilation
Jiný scénář, ve kterém dojde k uzamčení kompilace je v případě, že jsou splněny následující podmínky:
  • Uživatel, který spustí uloženou proceduru není vlastníkem tohoto postupu.
  • Název uložené procedury není plně kvalifikovaného názvu vlastníka objektu.
Jestliže uživatel "dbo" vlastníkem objektudbo.mystoredproca jiný uživatel "Harry Sverdlove", spustí tuto uloženou proceduru pomocí příkaz „exec mystoredproc,"počáteční mezipaměti vyhledávání pomocí názvu objektu se nezdaří, protože není objekt určen vlastníkem. (Není dosud známo zda existuje jiný uloženou proceduru s názvem Harry.mystoredproc. Proto serveru SQL Server nemůže se, zda plán uložený v mezipaměti pro dbo.mystoredproc správná provést.) SQL Server pak získá výhradní kompilace lock postup a provede kompilaci postup přípravy. Jedná se o přeložit název objektu na identifikátor objektu. Dříve, než SQL Server kompiluje plánu, SQL Server používá daný Identifikátor objektu pro hledání přesnější řízení mezipaměti a nalezení dříve sestavený plán i bez vlastníka kvalifikace.

Pokud je nalezeno existující plán, serveru SQL Server znovu použije plán uložený v mezipaměti a není ve skutečnosti kompilovat uložené procedury. Nedostatek vlastníka kvalifikace však vynutí serveru SQL Server a druhý mezipaměti vyhledávání a získat kompilace výhradní zámek dříve, než program určí, zda lze znovu použít existující plán provedení uložené v mezipaměti. Získání zámku a provádí vyhledávání a jiné práce potřebné k dosažení tohoto bodu může způsobovat zpoždění pro kompilaci zámek vede k zablokování. Je to především v případě, že je mnoho uživatelů, kteří nejsou uložené procedury vlastníka procedury souběžně spustit bez zadání názvu vlastníka. Be aware that even if you do not see SPIDs waiting for compile locks, lack of owner-qualification can introduce delays in stored procedure execution and cause unnecessarily high CPU utilization.

The following sequence of events will be recorded in a SQL Server Profiler trace when this problem occurs. (To trace cache-related events, you must enable advanced events. To do this, clickOptionson theNástrojemenu, and then selectAll event classes.)

Zmenšit tuto tabulkuRozšířit tuto tabulku
Event classText
RPC:Startingmystoredproc
SP:CacheMissmystoredproc
SP:ExecContextHitmystoredproc
SP:Startingmystoredproc
......

SP:CacheMissoccurs when the cache lookup by name fails. The followingSP:ExecContextHitindicates that a matching cached plan was ultimately found in cache after the ambiguous object name was resolved to an object ID. Depending on the circumstances,SP:CacheHitmay appear instead ofSP:ExecContextHit.

The solution to this problem of compile locking is to make sure that references to stored procedures are owner-qualified. (Instead ofexec mystoredproc, use execdbo.mystoredproc.) While owner-qualification is important for performance reasons, you do not have to qualify the stored proc with the database name to prevent the additional cache lookup.

Blocking that is caused by compile locks can be detected by using blocking scripts such as those that are defined in the following Microsoft Knowledge Base articles:
251004INF: How to monitor SQL Server 7.0 blocking
271509INF: How to monitor SQL Server 2000 blocking
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]]
V seznamuwaitresourcecolumn ("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).

POZNÁMKY
  • 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. Další informace naleznete následujícím článku znalostní báze Microsoft Knowledge Base::
    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

Vlastnosti

ID článku: 263889 - Poslední aktualizace: 24. listopadu 2010 - Revize: 1.0
Informace v tomto článku jsou určeny pro produkt:
  • 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 Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
Klíčová slova: 
kbinfo kbmt KB263889 KbMtcs
Strojově přeložený článek
Důležité: Tento článek byl přeložen pomocí software společnosti Microsoft na strojový překlad, ne profesionálním překladatelem. Společnost Microsoft nabízí jak články přeložené překladatelem, tak články přeložené pomocí software na strojový překlad, takže všechny články ve Znalostní databázi (Knowledge Base) jsou dostupné v češtině. Překlad pomocí software na strojový překlad ale není bohužel vždy dokonalý. Obsahuje chyby ve skloňování slov, skladbě vět, nebo gramatice, podobně jako když cizinci dělají chyby při mluvení v češtině. Společnost Microsoft není právně zodpovědná za nepřesnosti, chyby nebo škody vzniklé chybami v překladu, nebo při použití nepřesně přeložených instrukcí v článku zákazníkem. Společnost Microsoft aktualizuje software na strojový překlad, aby byl počet chyb omezen na minimum.
Projděte si také anglickou verzi článku:263889

Dejte nám zpětnou vazbu

 

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