Řešení potíží s výkon dotazů ad Hoc na serveru SQL Server

Překlady článku Překlady článku
ID článku: 243588 - 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

Tento článek popisuje řešení potíží s zpomalení mnoho souběžných ad-hoc dotazů v Microsoft SQL Server. Pokud jste zjistili není přesné zdroj problému, naleznete v následujícím článku znalostní báze Microsoft Knowledge Base před pokračovat:
224587Řešení potíží s výkon aplikací se serverem SQL Server

Tento článek předpokládá, že jste použili KB 224587 zúžit rozsah problému a že jste se zachycených protokolu nástroje Sledování výkonu pro systém Windows NT a SQL Profiler dané Podrobnosti trasování, sloupce specifické čítače, události a data.

Charakteristiky problémům s výkonem

Týkající se výkonu lze charakterizovat následujícími vlastnostmi:
  • Krátké ad-hoc dotazy, které mají obvykle velmi krátkou dobu trvání způsobit pomalé celkový výkon systému při vysoký počet souběžných uživatelů spuštění dotazů.
  • Velmi vysoké nebo 100 % využití PROCESORU.
  • Žádný přidružený blokování během období snížení výkonu.

    Můžete rychle vyhledávat blokování kontrolou sloupci Výstup systémovou uloženou proceduru sp_whoBLK. Ve sloupci BLK není-li nula pro počet systémový proces ID (SPIDs), existují blokuje.
  • V některých situacích je zdůraznila paměti serveru a může se zobrazit chyby, které jsou podobné následující chyby:
    Chyba: 701, stupeň závažnosti: 17, stát: 1
    Není dostatek paměti ke spuštění tohoto dotazu.
    - nebo -
    Msg 8645, úroveň 17, stavu 1, procedura, řádek 1
    Došlo k časového limitu při čekání na paměťové prostředky k provedení dotazu. Spusťte dotaz znovu.

Vylepšení v dotazu kompilace

Z důvodu zlepšení v architektuře systému spuštění na serveru SQL Server verze 7.0, konkrétně Optimalizátor dotazů můžete zaznamenat rozdíl ve využití systémových prostředků aplikacemi ve srovnání s předchozí verze serveru SQL Server. Konkrétně serveru SQL Server 7.0 může zobrazit zvýšení využití PROCESORU nebo paměti, ale starší verze serveru SQL Server jsou obvykle disku vstupně-výstupní vázán. Tyto změny lze vysledovat k dva faktory:
  • Algoritmus hash a sloučení spojení
  • Čas kompilace dotazu
Starší verze serveru SQL Server spolehlivé zcela iterací smyčky vnořené k provedení spojení. Vnořené smyčky spojení ze své podstaty použít disketu vstupně-výstupních operací. SQL Server 7.0 počínaje, byly zavedeny algoritmu hash a sloučení spojení. Algoritmus hash a sloučení spojení provést mnohem více paměti než spojení vnořené smyčky zpracování. Logický výsledek to je tohoto PROCESORU a využití paměti je vyšší, pokud se používají tyto techniky spojení. Další informace o spojeních algoritmu hash a korespondence naleznete v tématech "Porozumění hash spojení" a "Porozumění korespondence spojení" v SQL Server 7.0 Books Online.

Čas kompilace dotazu jsou ovlivněny vzhledem k tomu, že Optimalizátor dotazů má více možností a které jsou k dispozici než v předchozích verzích serveru SQL Server, včetně nových technik spojení algoritmu hash a korespondence, Vylepšené hledání algoritmy a statistiky sloupce. Tyto doplňkové informace umožňuje Optimalizátor dotazu Vybrat nejúčinnější způsob načtení dat dotazu. Analýzy a posouzení těchto nových technik a informace však vyžaduje čas zpracování. Toto zvýšení využití PROCESORU může mít za následek dotazu kompilace časy, které jsou delší než v předchozích verzích serveru SQL Server.

U většiny dotazů tento nárůst v čase kompilace posunu snížení v době spuštění. Celkový efekt je rychlejší než ve spuštění dotazu starší verze serveru SQL Server. Jedinou výjimkou však dochází s velmi malé, jednoduché, OLTP typu dotazy, které mají velmi nízké časy spuštění. Pro tyto dotazy proces generování plánu dotazu pravděpodobně výdajů stejné nebo větší než spuštění dotazu. V důsledku toho může provést dotaz mírně pomalejší než v předchozích verzích serveru SQL Server. Protože rozdíl je obvykle v milisekundách, tyto efekty není zaznamenali pro konkrétní dotaz, pokud je spuštěn samostatně. Však můžete všimnout, že využití PROCESORU pro celý systém vyšší než v předchozích verzích serveru SQL Server pokud velkého počtu dotazy ad hoc jsou provedeny souběžně vysoké počtem uživatelů.

Rozvíjet parametrizované dotazy

SQL Server 7.0 používá několik nových technik, jako je například ukládání do mezipaměti dotazů ad hoc a automatické Parametrizace. Však dotazy tohoto serveru SQL Server 7.0 se automaticky parameterizes jsou omezeny. Přesvědčte se, zda plány dotazů jsou rozděleny do parametrů a může být znovu účinněji použito použít následující metody:
  • Parametr značky OLE DB i rozhraní ODBC API povolit parametry, které mají být specifikovány s otazníkem, když uživatelé odesílají dotazy. To může být velmi užitečné v libovolné aplikaci, zejména pro střední vrstvy aplikace, které moduly generování dotazu kde není k dispozici pomocí uložené procedury. Plán dotazů, který je generován pro dotazy, které mají značek parametrů může být znovu použito ve všech klientů, kteří spuštění téhož dotazu, i když nejsou určeny hodnoty různých parametrů. Další informace naleznete tématu "Parametr značky" v SQL Server 7.0 Books Online.
  • sp_executesqlSp_executesql uložený postup je volána ovladač ODBC nebo zprostředkovatele OLE DB značek parametrů se používají v aplikaci. Však ji může také být volána přímo aplikaci nebo v jiné uložené procedury k explicitně parametrizaci dotazů ad hoc. To může být velmi užitečné v aplikacích nebo dávkové soubory, kde příkazu EXECUTE používá k provádění dynamických příkazů SQL. Na rozdíl od sp_executesql příkazu EXECUTE Parametrizace nepovoluje. Takto se omezí možnost opětovného použití plánu dotazu. Další informace naleznete v tématu "sp_executesql (T-SQL)" a "Použití sp_executesql" témat, v SQL Server 7.0 Books Online.
  • Uložených procedur Uložené procedury mají mnoho výhod, včetně schopnosti parametrizaci dotazů a opakované využití provádění plánů. Další informace naleznete v tématech "Uložené procedury" a "Programming uložené procedury" v SQL Server 7.0 Books Online.

Zobrazení dat nástroje Sledování výkonu

Sledování výkonu protokolu použít k určení, které systémové prostředky způsobují kritické místo. Sledování výkonu protokolu můžete umožňují celkový obrázek systému a pomáhají při zobrazení dat SQL Profiler zaměřuje pozornost uživatelů. Zkontrolujte data sledování výkonu od okamžiku, kdy byl výkon dobrý prostřednictvím čas, který ke snížení výkonu. Určit čítače, která byla ovlivněna nejprve a pak určit, které z následujících problémů je nejdůležitějších pro vaši situaci:
  • Objekt: proces
    Čítač: procesor
    Instance: SQL Server
  • Objekt: procesor
    Čítač: % času procesoru
    Instance: Kontrola každou instanci procesoru
  • Objekt: SQL Server: vyrovnávací paměť Manager
    Čítač: Libovolná vyrovnávací paměti
  • Objekt: SQL Server: vyrovnávací paměť Manager
    Čítače: Počet stránek odcizených
  • Objektu: Správce SQL Server: paměti
    Čítače: Paměť uděluje čeká na vyřízení
  • Objekt: SQL Server: SQL Statistika
    Čítač: SQL kompilace za sekundu
Pokud využití PROCESORU, SQL kompilace za sekundu a volné vyrovnávacích pamětí čítače jsou vysoké, čekání na granty paměti a odcizení počet stránek jsou čítače nízká, to znamená, že procesor kritické místo. Zaměřit se na postup účinně parametrizaci a opakované použití plánů dotazů, aby se zabránilo náklady generování plánu dotazu a v části "Skupina trasování SQL Profiler třídou událostí" v tomto článku. Pokud libovolná vyrovnávací paměti a čítače SQL kompilace za sekundu jsou nízké a čítače odcizení počet stránek a čekání na granty paměti jsou vysoké, je SQL Server omezen paměti. Soustředí na vyhledávání dotazy, kde spojení hash jsou používány a mohou být změněny k vytvoření smyčky spojení a v tématu "Skupina SQL Profiler trasování podle doby trvání" části tohoto článku. Další informace o těchto čítačů pomocí názvu čítače hledání SQL Server 7.0 Books Online.

Zobrazení dat SQL Profiler

Při řešení potíží s výkonem je velmi cenné pro zobrazení dat SQL Profiler. Je nebudete muset zkontrolujte data můžete zachytit; být selektivní. SQL Profiler umožňuje účinně Zobrazit sebraná data. Na kartě Vlastnosti (v nabídce soubor klepněte na příkaz Vlastnosti), SQL Profiler umožňuje omezit data zobrazená odebrání sloupce dat nebo události, seskupení nebo řazení podle sloupce dat a používání filtrů. Můžete vyhledávat trasování celý nebo pouze konkrétního sloupce pro specifické hodnoty (v nabídce Úpravy klepněte na příkaz Najít). Můžete také uložit SQL Profiler dat tabulky serveru SQL Server (v nabídce soubor přejděte na příkaz Uložit jako a poté klepněte na příkaz Najít tabulku), a spusťte dotazy SQL proti němu.

Poznámka: Ujistěte se, že filtrovat pouze uložené trasovacího souboru. Provedením těchto kroků na trasování aktivní, riskujete ztráty dat, která byla zachycena vzhledem k tomu, že trasování bylo spuštěno. Uložit aktivní trasování do souboru nebo tabulky nejprve (v nabídce soubor klepněte na příkaz Uložit jako) a poté jej znovu otevřete (v nabídce soubor klepněte na příkaz Otevřít) dříve, než budete pokračovat. Při práci s uloženou trasovacího souboru filtrování trvale neodeberete data, jsou data pouze skryta, nebudou odstraněny. Můžete přidat a odebrat události a data sloupce pomoci fokus hledání.

Možné by měl také zaměřit se na oblasti, kde většina výhodu obdržet. Tyto faktory mohou pomoci zvýšit výkon aplikace, ale ne nezbytně stejnou měrou. Před implementací jakékoli změny, zjistěte, jak účinné změny mohou být podle následující faktory:
  • Jak často se spustí dotaz
  • Kolik zlepšení dotazu může být zlepšen
Například zkrácení doby spuštění jeden dotaz z 1,5 sekund na 1,2 sekund nemusí být užitečné, pokud často v průběhu dne není spuštěn dotaz. Však pokud dotaz je spuštěn často velmi vysoký počet souběžných uživatelů, zlepšení výkonu může být velmi efektivní. Naopak zlepšení jediném dotazu z 6 minut 3 sekundy může není výnosu k znatelné zvýšení celkového výkonu když je použito jen zřídka. Před implementací jakékoli změny odhadnout účinky konkrétní dotaz nebo procedura pomocí seskupení a filtrování technik v SQL Profiler a vaše znalosti aplikace. Zaměřit na změny nejefektivnější nejprve a potom pokračujte iterací prostřednictvím další dotazy a postupy, dokud se nedostanete na úroveň, kde má dostatečně vyšší výkon.

Po uložení SQL Profiler trasování do souboru nebo tabulky, otevřete znovu trasování v SQL Profiler a prohlédněte si obsah. Chcete-li seskupit trasování SQL Profiler, postupujte takto:
  • Trasování SQL Profiler Seskupit podle doby trvání:
    1. V nabídce soubor klepněte na příkaz Vlastnosti.
    2. Klepněte na kartu Datové sloupce a potom ve skupinovém rámečku skupiny klepněte na tlačítko nahoru přesunete Doba trvání. Klepněte na dolů k odebrání všech sloupců.
    3. Klepněte na kartu události a pak odeberte všechny události, kromě TSQL SQL:StmtCompleted a TSQL vzdáleného volání PROCEDUR: dokončení. Tento postup vám umožní soustředit se pouze dotazů, které jsou právě prováděny.
    4. Klepněte na tlačítko OK.
    Seskupování podle doby trvání umožňuje snadno zobrazit SQL příkazů, listy a postupy, které jsou spuštěny slowest. Zkontrolujte trasování, pokud dochází k problému a vytvořit účaří dobrý výkon. Můžete filtrovat podle počátečního času Ukončit trasování do oddílů, v případě výkonu je vhodné a samostatné oddíly v případě, že výkon je nízký. Dotazy s nejdelší dobou trvání, kdy výkon je dobré Hledat. Jedná se pravděpodobně kořen problém. Při snižuje celkový výkon systému, i dobré dotazy můžete zobrazit dlouhé doby trvání, protože čekání systémových prostředků.

    Zkontrolujte provádění plánů pro dotazy, většina má často dlouhé doby trvání. Pokud zjistíte, že je používán hash spojení, zvažte použití dotazu nápovědy LOOP JOIN vynutit spojení vnořené smyčky pro dotaz. Je-li spuštění doba pro dotaz pomocí smyčky spojení nižší než rovna nebo dokonce mírně vyšší než čas spuštění s hash spojení, smyčky spojení mohou být lepší možnost, pokud v počítači dochází k vysoké paměti a využití PROCESORU. Snižováním napětí na problémová místa prostředků (PROCESORU a paměti), můžete zlepšit celkový výkon systému. Pro dotaz na Další informace o LOOP JOIN nápovědy, naleznete v tématu "SELECT (T-SQL)" v SQL Server 7.0 Books Online.
  • Seskupit SQL Profiler trasování událostí třídy:
    1. V nabídce soubor klepněte na příkaz Vlastnosti.
    2. Klepněte na kartu Datové sloupce a pod nadpisem skupiny klepněte nahoru k přesunutí Třídy událostí a text s Událostí třídy na horní. Klepněte na dolů k odebrání všech sloupců pod nadpisem skupiny.
    3. Klepněte na kartu události a pak se přesvědčte, zda se zahrnou všechny události.
    4. Klepněte na tlačítko OK.

Typy událostí

Chcete-li zobrazit typy události dochází v počítači se systémem SQL Server a jak často událostem, Seskupit podle sloupce Třídy událostí. Hledat v tomto sloupci pro následující události:
  • MISC: Příprava SQL a připraveny SQL; exec kurzory: CursorpreparePříprava SQL události označuje, že příkaz SQL byl připraven pro použití s výchozí sadu výsledků (kurzor na straně klienta) SQLPrepare/SQLExecute (pro ODBC) nebo ICommandText::Prepare/ICommandText::Execute (pro OLE DB) pomocí výchozích možností kurzoru: dopředu, pouze jen pro čtení, velikost řádků = 1. Události Cursorprepare označuje, že kurzor straně serveru byl připraven na SQL příkazu pomocí jedné z předchozí možnosti kurzoru SQLPrepare/SQLExecute (pro ODBC) nebo ICommandText::Prepare/ICommandText::Execute (pro OLE DB) nastavena na hodnotu jinou než výchozí. Událost Exec připraveny SQL označuje, že byl proveden jeden z předchozích typů existující připravených příkazů. Pokud časté výskytů těchto událostí, aplikace používá model přípravy/spuštění otevře výsledek sad. Pokud ano, je nutné určit používáte model/spuštění přípravy správně.

    V ideálním případě by aplikace připraví jednou příkaz SQL a provede jeho mnohokrát tak, aby Optimalizátor není měly ke kompilaci nový plán pokaždé, když je tento příkaz proveden. Při každém spuštění připravený příkaz Uložit náklady na sestavování dotazu. Pokud plánujete spuštění dotazu jednou, společnost Microsoft doporučuje, že není připravíte jej. Přípravu a potom spuštěním příkazu SQL vyžaduje tři sítě roundtrips: jeden k přípravě příkazu, jeden pro spuštění příkazu a jeden k unprepare příkazu. Příprava kurzory na straně serveru vyžaduje nejméně pět round cest: jeden pro přípravu kurzor, ke spuštění nebo ho otevřete, jeden jeden nebo více vyvolání z něj, zavřete jej a jeden k unprepare jej. Provádění dotazu vyžaduje pouze jednu zpáteční.

    Chcete-li se podívat, jak efektivně aplikace používá model/spuštění přípravy, porovnejte počet tyto dvě události (připravit a spouštění) dojít. Počet událostí Exec připraveny SQL by měl být mnohem větší než součet Příprava SQL a události CursorPrepare (alespoň tři pro pětkrát větší je dobré odhadu). To znamená, že připravených příkazů jsou nebránili opětovnému použití dostatečně často k překonání zvýšené nároky na jejich vytváření. Pokud je počet událostí Příprava SQL a CursorPrepare zhruba odpovídající počet událostí SQL připraveny exec, může to znamenat, zda aplikace nepoužívá účinně modelu přípravy/spuštění. Pokuste se připraví výpis jednou a znovu použít co nejvíce. Aplikace pro přípravu výkazů jednou a opakovaně používat tyto příkazy můžete také změnit.

    Aplikace musí být napsány specificky efektivně používat model přípravy/spuštění. Platnosti popisovače do připraveného příkazu je řízena jak dlouho ponechat HSTMT otevřené v ODBC nebo ICommandText objektu v rozhraní OLE DB. Jednu běžnou praxí je získat HSTMT připravit příkaz SQL, připravený příkaz Spustit a potom uvolněte HSTMT, a tím došlo ke ztrátě popisovač připraveného plánu. Pokud tak učiníte, neobdržíte žádnou výhodu z přípravy a provedení modelu. Ve skutečnosti vidět snížení výkonu z důvodu další zatížení sítě roundtrips. Aplikace musí mít metodu mezipaměti HSTMT nebo objektu s popisovačem připraveného příkazu a k nim získat přístup pro opakované použití. Ovladače nebo zprostředkovatele neprovádí to automaticky, aplikace odpovídá za provádění, správu a pomocí těchto informací. Pokud aplikace nemůže provést, zvažte použití značek parametrů namísto metody přípravy/spuštění.
  • Pomocí značek parametrů Aplikace mohou optimalizovat využívání příkazu Transact-SQL stejné několikrát s různými vstupní a výstupní hodnoty pomocí značek parametrů. Při prvním spuštění dotazu je připraveno jako parametry dotazu a SQL Server generuje a ukládá do mezipaměti parametrizované plán pro dotaz. Pro další volání stejný dotaz pomocí buď stejné nebo různé parametry SQL Server neobsahuje generovat nový plán dotazů; SQL Server můžete znovu použít existující plán dotazů nahrazením aktuální parametry.

    Pokud aplikace používá značek parametrů s volání funkce SQLExecDirect (pro ODBC) nebo ICommandText::Execute (pro OLE DB), ovladače nebo zprostředkovatele automaticky sbalí příkazu SQL a zpracuje ji jako voláním sp_executesql. Příkaz nemá připraven a provedeny samostatně. SQL Server obdrží volání sp_executesql, jej automaticky kontroluje mezipaměť postup pro odpovídající plán a znovu použije plán nebo generuje nový plán.

    Chcete-li zjistit, pokud aplikace používá aktuálně značek parametrů, můžete hledat textové sloupce SQL Profiler trasování pro "sp_executesql" Protože sp_executesql může být volána přímo, uveďte všechny instance použití značek parametrů.

    Další informace o modelu přípravy/spuštění naleznete v tématu "znovu spuštění plánu ukládání do mezipaměti a použít" v SQL Server 7.0 Books Online. Další informace o značek parametrů naleznete v tématu "Parametr značky" v SQL Server 7.0 Books Online.
  • SP: dokončení Dynamických příkazů SQL spuštěn pomocí příkazu EXECUTE zobrazí jako SP: dokončení události s textem "Dynamic SQL." Rozbalte SP: dokončení události a následným vyhledáním všech výskytů, jejichž "Dynamické SQL" jako text. Pokud existuje mnoho z těchto událostí, bude pravděpodobně možné zvýšit výkon aplikací pomocí sp_executesql namísto příkazu EXECUTE. Sp_executesql uložený postup umožňuje serveru SQL Server znovu použít k provádění plánů, pokud stejný dotaz se spustí znovu pomocí různých parametrů. Při použití příkazu EXECUTE, v plánu není parametrické a nebyla používána Pokud dotaz se spustí znovu pomocí stejných parametrů.

    K určení dotazy nebo postupy, které pomocí dynamické události SQL spuštění příkazu, Poznámka ID připojení a začátek o každé události. Oddělit trasování (odebrání Třídy událostí a text ze záhlaví skupiny). Po oddělíte trasování, je řazen v chronologickém pořadí. Můžete filtrovat trasování podle ID připojení (na záložce filtry) a pak odeberte všechny třídy událostí, s výjimkou SP: počáteční a SP: dokončeno události pro lepší čitelnost. Potom můžete vyhledat začátek události (v nabídce Úpravy klepněte na příkaz Najít). Výsledky zobrazit při spuštění události dynamické SQL. Pokud došlo k události v uložené proceduře, se zobrazí události mezi SP: počáteční a SP: dokončení události pro tento postup. Pokud událost nedošlo v uložené proceduře, byl-li proveden jako dotaz ad hoc a můžete použít jiné datové sloupce (Název aplikace, NT uživatelské jméno a další) k určení, kdy byl proveden příkaz. Chcete-li určit text příkazu a kontext, kde byl proveden, můžete také přidat třídy událostí, jako například SQL:BatchCompleted a SQL:RPCCompleted.

    Po určení, kde je používána příkazu EXECUTE, zvažte nahrazení volání sp_executesql. Například zvažte následující scénář kde spuštění příkazu se používá s dynamického příkazu SQL. Postup trvá název tabulky, ID a idValue jako vstupní parametry a potom spustí příkaz SELECT z tabulky na základě hodnoty ID. Příkazu EXECUTE postup vypadá podobně jako následující kód:
    drop proc dynamicUsingEXECUTE
    		  go create proc dynamicUsingEXECUTE @table sysname, @idName varchar(10),
    		  @idValue varchar(10) as declare @query nvarchar(4000) -- Build query string
    		  with parameter. -- Notice the use of escape quotes. select @query = 'select *
    		  from ' + @table + ' where ' + @idName + ' = ''' + @idValue + '''' exec (@query)
    		  go
    za předpokladu, že rozděleny do dotazu je automaticky parametrů, je-li provést tento postup v tabulce tituly z ukázkové databáze pubs dvakrát s různými hodnotami pro a @ idValue parametr serveru SQL Server musí generovat plán samostatného dotazu pro každé spuštění. Například:
    exec dynamicUsingEXECUTE
    		  'titles', 'title_id', 'MC2222' go exec dynamicUsingEXECUTE 'titles',
    		  'title_id', 'BU7832'
    Poznámka: V tomto příkladu, dotaz je jednoduché dostatečně SQL Server může automaticky parametrizaci a skutečně znovu použít plán provádění. Znovu však jedná-li složitý dotaz, který SQL Server pravděpodobně není automaticky parametrizaci, SQL Server může nelze použít plán pro provedení druhého, pokud a @ idValue parametr byl změněn. Následující jednoduchý dotaz omezuje složitost v příkladu.

    Tento postup použijte místo příkazu EXECUTE sp_executesql můžete přepsat. Podpora pro nahrazení parametru umožňuje sp_executesql zefektivnit protože generuje provádění plánů, které je pravděpodobnější být opětovně použity serverem SQL. Například:
    drop proc dynamicUsingSP_EXECUTESQL go create proc
    		  dynamicUsingSP_EXECUTESQL @table sysname, @idName varchar(10), @idValue
    		  varchar(10) as declare @query nvarchar(4000) -- Build query string with
    		  parameter select @query = 'select * from ' + @table + ' where ' + @idName + ' =
    		  @idValue' -- Now execute with parameter exec sp_executesql @query, N'@idValue
    		  varchar(10)', @idValue go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',
    		  'MC2222' go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',
    		  'BU7832'
    v tomto příkladu při prvním spuštění příkazu sp_executesql serveru SQL Server generuje parametrizované plán z názvů s title_id jako parametr příkazu SELECT. Pro provedení druhého SQL Server znovu použije plán s novou hodnotu parametru. Další informace o sp_executesql naleznete v "sp_executesql (T-SQL)" a "Použití sp_executesql" témata v SQL Server 7.0 Books Online.
  • SP:RECOMPILES Tato událost označuje, že byl uložené procedury recompiled během spuštění. Mnoho událostí překompilujte označuje, že SQL Server využívá prostředky pro sestavování dotazu místo spuštění dotazu.
Pokud není některá z těchto událostí, aplikace provádí pouze ad-hoc dotazy vůči serveru SQL Server. Pokud SQL Server určuje ji lze automaticky parametrizaci některých dotazů nebo pokud se opakovaně používá stejné parametry, vyžaduje každý dotaz, který je spuštěn SQL Server ke generování nového spuštění plánu. Sledování výkonu serveru SQL Server by měl zobrazit mnoho SQL kompilace sekundu. To může být náročné na procesor pro mnoho souběžných uživatelů. Chcete-li tento problém vyřešit, vyhledejte nejvíce často provedeny dotazy a zvažte vytvoření uložené procedury pro tyto dotazy pomocí značek parametrů nebo pomocí sp_executesql.

Odkazy

Další informace o sledování a řešení problémů výkonu na serveru SQL Server získáte v následujících článcích v databázi Microsoft Knowledge Base:
224587Řešení potíží s výkon aplikací se serverem SQL Server
224453INF: Vysvětlení a řešení serveru SQL Server verze 7.0 nebo 2000 blokující problémy
243586Poradce při potížích s uloženou proceduru recompilation
243589Poradce při potížích s dotazy zpomalit běžící na serveru SQL Server 7.0 nebo novější
251004INF: Sledování serveru SQL Server 7.0 blokování jak

Vlastnosti

ID článku: 243588 - Poslední aktualizace: 8. prosince 2005 - Revize: 5.4
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 2000 64-bit Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard Edition
Klíčová slova: 
kbmt kbhowtomaster kbhowto kbinfo KB243588 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:243588

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