Riešenie problémov s výkon Ad Hoc dotazy SQL Server

Charakteristiky problémy s výkonom

Problém výkonu má nasledujúce charakteristiky:

• Krátke ad hoc dotazy, ktoré majú zvyčajne veľmi krátke trvanie za následok pomalé celkový výkon systému pri vysoký počet súbežných používateľov spustiť dotazy.

• Veľmi vysoké alebo 100 percent využitie Procesora.

• Žiadne súvisiace blokovanie počas období pomalé.
  
  Môžete rýchlo vyhľadať na blokovanie kontrolou BLK stĺpec výstup sp_who systém uložená procedúra. Ak BLK stĺpec nie je nulový počet systém proces ID (SPIDs), tam blokuje.

• V niektorých situáciách pamäť servera upozorniť a sa môže zobraziť chyby podobné nasledujúcej chyby:

  Chyba: 701, závažnosť: 17, štát: 1
  Nie je dostatok systémovej pamäte na spustenie tohto dotazu.

  - alebo -

  MSG 8645, úroveň 17, štát 1, postup, riadok 1
  Uplynul časový limit čakania na pamäťové prostriedky na vykonanie dotazu. Znova spustite dotaz.

Zlepšenie kompilácie dotazov

Z dôvodu zlepšenia architektúry systému začína v SQL Server 7.0, osobitne Optimalizácia dotazu, môžete si všimnúť rozdiel v používaní systémových prostriedkov aplikácie v porovnaní so staršími verziami programu SQL Server. Konkrétne, SQL Server 7.0 môže ukazujú nárast buď CPU alebo využitie pamäte, ale staršie verzie programu SQL Server sú zvyčajne disk IO viazané. Tieto zmeny môžu zistiť dve skutočnosti:

• Hodnota hash a korešpondencie spojenia

• Dotaz zostavovanie krát

Staršie verzie programu SQL Server úplne spoliehať na vnorené slučky iterácie vykonať spojenia. Vnorené slučky spojenia vo svojej podstate použiť disk IO. Počnúc SQL Server 7.0, boli zavedené hash a korešpondencie spojenia. Hodnota hash a korešpondencie spojenia urobiť oveľa viac v pamäti spracovanie ako vnorené slučky spojenia. Logický výsledok Toto je že CPU a využitie pamäte je vyšší, keď sú tieto spojenia techniky použiť. Ďalšie informácie o hash a korešpondencie spojenia, pozri "Understanding Hash pripojí" a "Pochopenie zlúčiť pripojí" témy v SQL Server 7.0 Books Online.

Dotaz zostavovanie časy sú ovplyvnené, pretože dotaz optimalizácia má viac možností a informácie dostupné ako v starších verziách programu SQL Server, vrátane nových hash a korešpondencie pripojiť techniky, zlepšené vyhľadávanie algoritmov a štatistiky stĺpca. Doplňujúce informácie umožňuje ukazovateľa vyberte najúčinnejším spôsobom získať údaje. Však analýzy a týchto nových techník a informácie vyžaduje čas spracovania. Tento zvýšené využitie Procesora môže mať za následok dotaz zostavovanie krát dlhšie ako v starších verziách programu SQL Server.

Väčšina dotazov je pozícia zvýšenie kompilácia poklesom výkonu čas. Celkový efekt je spustenia dotazu rýchlejšie ako v starších verziách programu SQL Server. Jedna výnimka však dochádza s veľmi malé a jednoduché, OLTP-typ otázky, ktoré majú veľmi nízky výkon krát. Pre tieto dotazy procesu generovania plán dotazu môžu mať rovnaké alebo väčšie náklady ako vykonávanie dotazu. V dôsledku toho môže vykonať dotaz niečo pomalšie ako v starších verziách programu SQL Server. Pretože rozdiel je zvyčajne v milisekundách, tieto účinky sú všimli ku konkrétnemu dotazu, ak je vykonaný jednotlivo. Však môžete si všimnúť, že celkový systém využitie Procesora je vyššia ako v starších verziách programu SQL Server Ak veľké čísla ad hoc dotazov vykonávajú súbežne vysoký počet používateľov.

Vytvoriť parametrizovaná dotazy

SQL Server 7.0 používa niekoľko nových techník, ako je ukladanie do vyrovnávacej pamäte ad hoc dotazy a automatické parametrizáciou. Avšak dotazy SQL Server 7.0 automaticky parameterizes sú obmedzené. Uistite sa, že dotaz plány sú parametrizovaná a môžu opätovne efektívnejšie, použite nasledujúce postupy:

• Parameter značky OLE DB a ODBC API umožňujú parametre uvedené otáznik, keď používatelia odosielať dotazy. Môže to byť užitočné v všetky aplikácie najmä strednej vrstvy aplikácie, ktoré majú dotaz generácie moduly kde pomocou uložené procedúry nie je k dispozícii. Plánu dotazu, ktorý je generované pre dotazy, ktoré majú parametra značky môžu opätovne akékoľvek klientov to vykonať rovnaký dotaz, aj v prípade, že sú uvedené hodnoty rôznych parametrov. Ďalšie informácie nájdete v téme "Parameter značky" SQL Server 7.0 Books Online.

• sp_executesql Sp_executesql uložená procedúra sa nazýva poskytovateľa OLE DB alebo ovládač ODBC Ak parameter značky sa používajú v aplikácii. Však môže tiež byť nazýva priamo v aplikácii alebo v inom uloženej procedúry na výslovne parameterize ad hoc dotazov. Môže to byť užitočné v aplikáciách alebo dávkové súbory ak vykonať vyhlásenie sa používa na spracovanie dynamické SQL. Na rozdiel od sp_executesql, vykonať vyhlásenie nepovoľuje parametrizáciou. Toto limity šancu na dotaz plán opätovné použitie. Ďalšie informácie nájdete v téme "sp_executesql (T-SQL)" a "Using sp_executesql" témy v SQL Server 7.0 Books Online.

• Uložené procedúry Uložené procedúry majú mnoho výhod, vrátane schopnosti parameterize dotazy a opätovné použitie vykonávania plánov. Ďalšie informácie nájdete v témach "Uložené postupy" a "Programovanie uložené postupy" SQL Server 7.0 Books Online.

Zobraziť údaje, sledovanie výkonu

Použite sledovanie výkonu denníka určiť, ktorý systém zdroje spôsobujú kritické miesto. Sledovanie výkonu denníka môže vám celkový obraz systému a pomôcť zamerať svoju pozornosť pri zobrazení SQL Profiler údaje. Skontrolujte sledovanie výkonu údaje od času, keď výkon bol dobrý cez čas, ktorý zníži výkon. Určite počítadlo, ktoré bolo prvýkrát a potom určiť, ktorá z týchto problémov pre vašu situáciu:

• Objekt: proces
  Počítadlo: procesor
  Inštancie: SQL Server

• Objekt: procesor
  Počítadlo: % času procesora
  Inštancia: Skontrolujte každú inštanciu procesor

• Objekt: SQL Server: medzipamäť Manager
  Počítadlo: Voľný medzipamätí

• Objekt: SQL Server: medzipamäť Manager
  Počítadlo: Ukradnuté počtu strán

• Objekt: SQL Server: Memory Manager
  Počítadlo: Grantov pamäte až

• Objekt: SQL Server: SQL štatistiky
  Počítadlo: SQL kompilácie za sekundu

Ak využitie CPU, SQL kompilácie za sekundu a voľný medzipamätí počítadlá sú vysoké a pamäť príspevky spracováva a ukradnuté počtu strán sú nízke, Toto označuje Procesor zúženie. Zamerať ako účinne parameterize a opätovné použitie plánuje dotaz vyhnúť náklady na dotaz plán generovanie a v časti "Skupina SQL Profiler sledovania udalosť triedy" tohto článku. Ak voľný medzipamätí a SQL kompilácie za sekundu počítadiel sú nízke, a ukradnuté počtu strán a pamäte granty čakajúce počítadiel sú vysoké, SQL Server je limitovaná pamäte. Zameria na nájdenie dotazy, kde hodnota hash spojenia používajú a slučky spojenia a vidieť "Skupina SQL Profiler sledovania doba" v tomto článku sa môže zmeniť. Ďalšie informácie o týchto počítadlá, použite názov počítadla na hľadanie SQL Server 7.0 Books Online.

Zobrazenie údajov SQL Profiler

Keď sú vyriešiť problémy s výkonom, je mimoriadne SQL Profiler údaje. Nemáte všetky údaje, ktoré vzniká; byť selektívne. SQL Profiler umožňuje účinne Zobraziť zaznamenanom údaje. Na karte Vlastnosti (na
Súbor v ponuke kliknite na položku Vlastnosti), SQL Profiler umožňuje obmedziť údaje zobrazené odstránením stĺpce údajov alebo udalostí, zoskupenie alebo zoradenie podľa údajov stĺpcov a používanie filtrov. Môžete vyhľadávať celý stopa alebo len určitý stĺpec špecifické hodnoty (na
Upraviť ponuky, kliknite na položku vyhľadávanie ). Môžete tiež uložiť SQL Profiler údajov do tabuľky SQL Server (v ponuke súbor ukážte na položku Uložiť akoa kliknite na tlačidlo Tabuľky sledovania), a potom spustite SQL dotazov proti.

Poznámka: Uistite sa, že ste iba filter súbor uložený sledovania. Ak vykonávate tieto kroky na aktívne stopy, riziko straty údajov, ktorý bol zachytený od spustenia sledovania. Uložiť aktívne sledovať do súboru alebo tabuľka najprv (na
Ponuku súbor , kliknite na tlačidlo Uložiť ako ), a znovu otvoriť (v ponuke súbor kliknite na tlačidlo otvorené) pred pokračovaním. Keď pracujete s súbor uložený sledovania, filtrovanie natrvalo neodstraňuje údaje; len je skryté údaje neodstránia. Môžete pridať a odstrániť udalosti a stĺpce údajov na zameriavanie vyhľadávania.

Takisto sa zamerať na oblasti, kde dostanete výhod. Nasledujúce faktory môžu zvýšiť výkon aplikácií, ale nemusí rovnako. Pred implementáciou zmeny, Zistite, ako efektívne zmeny môžu byť v závislosti na nasledujúce faktory:

• Ako často sa spúšťa dotaz

• Koľko zlepšenie dotaz je možné zlepšiť

Napríklad skrátenie času realizácie jedného dotazu z 1,5 sekundy 1,2 sekundy možno užitočné, ak dotaz sa nevykoná často po celý deň. Ak dotaz je vykonaný veľmi často vysoký počet súbežných používateľov, zlepšenie výkonu môže byť veľmi efektívna. Naopak, zlepšenie jediného dotazu z 6 minút na 3 sekúnd nemusí priniesť výrazné zvýšenie celkovej výkonnosti Ak je to zriedka. Použiť zoskupovanie a filtrovanie techník v SQL Profiler a vaše vedomosti o žiadosti na konkrétny dotaz alebo postup pred zavedením akýchkoľvek zmien. Zameria na čo najefektívnejšie zmeny prvý a potom pokračujte iterácie prostredníctvom iných dotazy a postupov kým nedosiahnete úroveň kde dostatočne zlepšila výkonnosť.

Po uložení SQL Profiler stopy do súboru alebo tabuľka, znovu otvorte stopy v SQL Profiler a skontrolovať obsah. Do skupiny SQL Profiler sledovania, postupujte nasledovne:

• Skupina SQL Profiler sledovania doba:

  1. V ponuke súbor kliknite na položku
     Vlastnosti.

  2. Kliknite na kartu Stĺpce s údajmi a podľa skupiny, kliknite na tlačidlo nahor presunúť
     Trvanie. Kliknite na tlačidlo dole odstrániť všetky ostatné stĺpce.

  3. Kliknite na kartu udalosti , a potom odstráňte všetky udalosti s výnimkou TSQL SQL: StmtCompleted a TSQL RPC: dokončené. Umožňuje zamerať na otázky, ktoré boli vykonané.

  4. Kliknite na tlačidlo OK.

  Zoskupenia podľa trvania umožňuje ľahko vidieť SQL výkazy dávok a postupy, ktoré používate najnižšou. Skontrolujte sledovania výskytu problému a vytvoriť základný dobrý výkon. Môžete filtrovať podľa Štart čas prerušiť sledovania do sekcií, keď výkon je dobré a samostatných sekcií, keď je slabý výkon. Pozrite sa na dotazy s najdlhšie trvanie, keď výkon je dobré. Sú s najväčšou pravdepodobnosťou koreň problému. Keď znižuje výkon systému, aj dobré dotazy môžete zobraziť dlhé trvanie, pretože čakajú na systémové prostriedky.
  
  Preskúmanie vykonávania plánov pre dotazy, že väčšina často majú dlhú dobu. Ak sa používa hash pripojiť, zvážte použitie slučky pripojiť dotaz pomôcku vynútiť vnorené slučky spojenie pre dotaz. Ak čas dotaz použitím slučky spojenie je menej ako rovná, alebo dokonca mierne vyšší ako doba vykonávania s hash pripojiť, spojenie slučky možno vhodnejšie počítač s pamäť a CPU. Zníženie zaťaženia na zúženie prostriedkov (CPU a pamäte), môžete zvýšiť výkon systému. Ďalšie informácie o pomôcku slučky pripojiť dotazu, nájdete v téme "Vybrať (T-SQL)" v SQL Server 7.0 Books Online.

• Skupina sledovania SQL Profiler udalosť triedy:

  1. V ponuke súbor kliknite na položku
     Vlastnosti.

  2. Kliknite na kartu Stĺpce údajov a pod položkou skupiny , kliknite na tlačidlo nahor presunúť
     Trieda udalostí a Text s Udalosť trieda na začiatok. Kliknite na tlačidlo dole odstrániť všetky ostatné stĺpce podľa Groups položka.

  3. Kliknite na kartu udalosti a uistite sa, že všetky udalosti sú zahrnuté.

  4. Kliknite na tlačidlo OK.

Typy udalostí

Zistiť, aké typy udalostí dochádza v počítači so systémom SQL Server a ako často udalosti nastanú, zoskupiť podľa Udalosť trieda stĺpec. Hľadať v tomto stĺpci pre nasledujúce udalosti:

• MISC: Pripravte SQL a Exec pripravené SQL; KURZOROV: Cursorprepare Pripravte SQL udalosti indikuje, že príkaz SQL bol pripravený na použitie s predvolené množiny (kurzor na strane klienta) pomocou SQLPrepare/SQLExecute (ODBC) alebo ICommandText::Prepare/ICommandText::Execute (pre OLE DB) s predvolenými kurzor možnosti: dopredu len iba na čítanie, veľkosť skupiny riadkov = 1. Cursorprepare udalosť označuje, že kurzor na strane servera bol pripravený na SQL vyhlásenie pomocou SQLPrepare/SQLExecute (ODBC) alebo ICommandText::Prepare/ICommandText::Execute (pre OLE DB) s jednou z predchádzajúci možnosti kurzor nastaviť nie je predvolená hodnota. Exec pripravené SQL udalosti indikuje, že niektorý z predchádzajúcich typy existujúcich pripravené príkazy vykonal. Ak vidíte časté výskyty týchto udalosti, aplikácia používa pripraviť a spustenie model pri otvorení množiny výsledkov. V takom prípade je potrebné určiť, či používate pripraviť a spustenie vzor správne.
  
  Ideálne žiadosť pripravuje príkaz SQL a spustí ho niekoľkokrát tak, že optimalizácia nemá zostaviť nový plán zakaždým príkaz je vykonaný. Vždy, keď spustíte pripravené vyhlásenie, môžete ušetriť náklady na zostavenie dotazu. Ak chcete vykonať dotaz raz, spoločnosť Microsoft odporúča, aby sa pripraviť. Príprava a potom vykonáva príkaz SQL vyžaduje tri siete roundtrips: jeden pripraviť vyhlásenie, jeden vykonať vyhlásenie a jeden k unprepare výkazu. Príprava na strane servera kurzorov vyžaduje aspoň päť spiatočných: jeden na prípravu kurzora, jeden spustiť alebo otvoriť, jedného alebo viacerých z, zatvoriť a jeden na unprepare to. Vykonanie dotazu vyžaduje iba jeden spiatočný.
  
  O tom, ako efektívne vaša aplikácia používa pripraviť a spustenie modelu, porovnať koľkokrát tieto dve udalosti (pripraviť a spustiť) vyskytujú. Počet Exec pripravené SQL udalosti by mali byť väčšie ako súčet Pripravte SQL a CursorPrepare udalosti (najmenej tri až päťkrát väčší je dobrý odhad). Znamená to, že pripravené príkazy sú opätovne často prekonať zvýšené náklady na ich vytvorenie. Ak počet Pripravte SQL a CursorPrepare udalosti sa približne rovná počtu Exec pripravené SQL udalosti, môže to znamenať, že aplikácie nie je účinne pomocou modelu pripraviť a spustenie. Skúste potvrdenie raz a znova použiť čo najviac. Môžete tiež zmeniť vašu žiadosť na prípravu výkazy jeden čas a opätovné použitie týchto vyhlásení.
  
  Aplikácia musí byť napísaný špeciálne použitie modelu pripraviť a spustenie efektívne. Životnosť rukoväť na pripravené vyhlásenie riadi ako dlho nechať HSTMT otvoriť v ODBC alebo ICommandText objekt OLE DB. Jeden spoločný postup je získanie príkazu HSTMT, pripravte príkaz SQL, spustiť príkaz pripravený a potom bez príkazu HSTMT, tým stráca rukoväť pripravený plán. Ak to nedostanete žiadnu výhodu z pripraviť a spustenie modelu. V skutočnosti môžete vidieť výkon degradácia z dôvodu dodatočných použitia roundtrips siete. Žiadosť musí mať metódu cache príkazu HSTMT alebo objektu s popisovačom pripravené vyhlásenie a prístupu k nim pre opätovné použitie. Ovládač alebo poskytovateľ neurobí automaticky; Aplikácia je zodpovedný za implementáciu, udržiavanie a pomocou týchto informácií. Ak aplikácia tak urobiť, zvážte použitie parametra značky namiesto pripraviť a spustenie metódy.

• Použitím parametra značky Aplikácie môžete optimalizovať využitie rovnaký príkaz Transact-SQL niekoľkokrát s rôzne vstupné a výstupné hodnoty parametra značky. Pri prvom spustení dotazu je pripravený ako parametrický dotaz a SQL Server vytvára a cache plán parametrický dotaz. Pre následné hovory na rovnaký dotaz použitím buď rovnakého alebo rôznych parametrov, server SQL Server nemá generovať nový dotaz plánu; SQL Server môžete opätovné použitie existujúcich dotaz plán nahradí aktuálne parametre.
  
  Ak aplikácia používa parameter značky hovory SQLExecDirect (ODBC) alebo ICommandText::Execute (pre OLE DB), ovládač alebo poskytovateľ automaticky balíky príkazu SQL a spustí ho ako sp_executesql hovor. Príkaz nie je potrebné pripraviť a vykonať samostatne. Keď SQL Server prijíma hovor sp_executesql, automaticky kontroluje vyrovnávacej pamäti procedúry pre zodpovedajúce plán a opätovné použitie tohto plánu alebo vytvára nový plán.
  
  Určiť, ak aplikácia v súčasnosti používa parameter značky,
  Textový stĺpec v SQL Profiler sledovania pre "sp_executesql." Pretože sp_executesql sa nazýva priamo, nie všetky inštancie naznačujú použitie parameter značky.
  
  Ďalšie informácie o pripraviť a spustenie model, nájdete v téme "Vykonanie plánu Caching a opätovné použitie" SQL Server 7.0 Books Online. Ďalšie informácie o parameter značky, nájdete v téme "Parameter značky" SQL Server 7.0 Books Online.

• SP: dokončiť Dynamické príkazy SQL vykonaný pomocou príkazu Spustiť Zobraziť ako SP: dokončiť udalosť s textom "Dynamické SQL." Rozbaľte SP: dokončiť udalostí a vyhľadajte všetky udalosti, ktoré majú "Dynamic SQL" ako text. Ak existujú mnohé z týchto udalostí, je možné zlepšiť výkon aplikácie pomocou sp_executesql namiesto výkazu vykonať. Sp_executesql uložené postupom povolení servera SQL Server na opätovné použitie vykonávania plánov, ak istého dotazu sa opäť pomocou rôznych parametrov. Použijete vykonať vyhlásenie, plán nie je parametrizovaná a nie je opätovne, ak dotaz je vykonaný znova pomocou rovnaké parametre.
  
  Na určenie dotazy alebo postupov, ktoré používajú dynamické SQL udalosti s spustiť vyhlásenie, Poznámka identifikáciu pripojenia a spustenie času pre každú udalosť. Oddeliť stopa (odstrániť Trieda udalostí a Text z Groups položka). Po oddelení stopa je zoradený chronologicky. Môžete filtrovať sledovania identifikáciou pripojenie (na filtre karta) a potom odstráňte všetky triedy udalostí s výnimkou SP: od a SP: kompletný udalosti zvýšenie názornosti. Môžete potom hľadať Štart čas udalosti (na Upraviť ponuky, kliknite na tlačidlo
  ( Hľadať). Výsledky ukazujú, keď začal dynamické SQL udalosť. Ak nastala udalosť v uloženej procedúry, udalosti sa zobrazuje medzi SP: od a SP: dokončiť udalosti tohto postupu. Ak udalosť nestala uloženú procedúru, bola vykonaná ako ad hoc dotazy a môžete použiť iné stĺpce údajov (Názov NT používateľaa iné) zistiť, kde sa príkaz vykonal. Zistiť príkaz a kontext, kde bola vykonaná pridáte udalosť triedy, napríklad SQL:BatchCompleted a SQL:RPCCompleted.
  
  Keď určíte, kde vykonať vyhlásenie je používaný, zvážte nahradenie hovor sp_executesql. Predstavte si napríklad nasledujúci scenár kde spustiť príkaz sa používa s dynamickým SQL. Postup trvá názov tabuľky, ID, a idValue, ako vstupné parametre a potom spustí príkaz SELECT z tabuľka na základe ID hodnoty. Výkazu vykonať postup vyzerá podobne ako nasledujúci 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 predpokladu, že dotaz je nie automaticky parametrizovaná, ak ste vykonanie tohto postupu proti tituly tabuľka v krčmy Ukážková databáza dva krát s rôzne hodnoty parametra @idValue , musíte vytvoriť SQL Server samostatné dotaz plán každý výkon. Napríklad:

  exec dynamicUsingEXECUTE
    'titles', 'title_id', 'MC2222' go exec dynamicUsingEXECUTE 'titles',
    'title_id', 'BU7832'

  Poznámka: V tomto príklade je jednoduchý, že SQL Server môže automaticky parameterize a skutočne opätovné použitie vykonávania plánu dotazu. Ak to komplexný dotaz, ktorý server SQL Server môže automaticky parameterize, SQL Server nie opätovné použitie plán druhý realizácie @idValue parameter sa zmenil. Tieto limity jednoduchý dotaz zložitosť príklad.
  
  Môžete prepísať tento postup použiť sp_executesql namiesto výkazu vykonať. Podpora nahradení parametra robí sp_executesql efektívnejšie, pretože to vytvára vykonávania plánov, ktoré sú viac pravdepodobne opätovne SQL Server. Naprí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 príklade pri prvom spustení príkazu sp_executesql SQL Server generuje parametrický plán na príkaze SELECT z tituly s title_id ako parameter. Na druhom vykonanie, opätovné SQL Server plán novou hodnotou parametra. Ďalšie informácie o sp_executesql, pozri "sp_executesql (T-SQL)" a "Using sp_executesql" témy v SQL Server 7.0 Books Online.

• SP: recompiles Táto udalosť naznačuje, že uložená procedúra prekompilovali počas spustenia. Mnoho udalosti recompile označuje, či SQL Server je pomocou zdrojov pre zostavovanie dotazu namiesto vykonávanie dotazu.
  

Ak sa niektorý z týchto udalostí, aplikácia vykonáva len ad hoc dotazy proti SQL Server. Ak SQL Server určuje, či sa automaticky parameterize určitých dotazoch alebo ak rovnaké parametre sa používajú opakovane, každý dotaz, ktorý sa vyžaduje SQL Server generovať nové vykonávania plánu. Sledovanie výkonu SQL Server by mala ukázať mnoho SQL kompilácie za sekundu. To môže byť náročné na Procesor pre mnoho súbežných používateľov. Tento problém obísť, nájsť najviac často vykonávajú dotazy a vytvorte uloženej procedúry pre tieto dotazy pomocou parametra značky alebo pomocou sp_executesql.