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

Preklady článku Preklady článku
ID článku: 243588 - Zobraziť produkty, ktorých sa tento článok týka.
Rozbaliť všetko | Zbaliť všetko

Na tejto stránke

SUHRN

Tento článok popisuje riešenie problémov s pomalým výkonu mnohých súbežné ad hoc dotazov v Microsoft SQL Server. Ak ste neurčili presný zdroj vášho problému, pozri nasledujúci článok Microsoft Knowledge Base skôr ako budete pokračovať:
224587 Riešenie problémov s uplatňovanie výkonu s SQL Server

Tento článok predpokladá, že ste použili KB 224587 zúžiť rozsah problému a že ste zachytili Sledovanie výkonu systému Windows NT denníka a SQL Profiler stopového detail, že špecifické počítadlá, udalosti a údaje stĺpce.

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é užívatelia spustiť dotazy.
  • Veľmi vysoké alebo 100 percent vyu?itie CPU.
  • Žiadne súvisiace blokovanie počas období pomalé výkon.

    Môžete rýchlo vyhľadať na blokovanie kontrolou BLK stĺpec do produkcie sp_who systém uložená procedúra. Ak BLK stĺpec nie je nulový počet systém proces ID (SPIDs), tam je blokovanie.
  • V niektorých situáciách pamäť servera je potrebné zdôrazniť, a môžete dostávať chyby, ktoré sú podobné ako nasledovné chyby:
    Chyba: 701, závažnosť: 17, štát: 1
    Existuje nedostatočná systémovej pamäte chcete tento dotaz spustiť.
    -alebo-
    Msg 8645, Úroveň 17, štát 1, postup, riadok 1
    Time out vyskytla počas čakania pre pamäťové prostriedky spustíte dotaz. Znovu spustite dotaz.

Zlepšenia v dotaze kompilácie

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 vystopovať až k dva faktory:
  • Haš a zlúčiť spojenia
  • Dotaz zostavovanie krát
Staršie verzie programu SQL Server úplne spoliehať na vnorené slučky iterácií vykonávať spojeniach. Vnorené slučky spojenia vo svojej podstate použiť disk IO. Začína s SQL Server 7.0, boli zavedené hash a korešpondencie spojenia. Haš a zlúčiť 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 kníh Online.

Dotaz zostavovanie časy sú ovplyvnené, pretože dotaz Optimalizácia má viac možností a informácie dostupné ako v predchádzajúcich verziách SQL Server, vrátane nových hash a korešpondencie pripojiť techniky, zlepšené vyhľadávanie algoritmy a štatistiky stĺpca. Toto dodatočné informácie o povoleniach Optimalizácia dotazu vyberte Najúčinnejšou metódou na načítanie údajov dotazu. Avšak, analýzu a posúdenie týchto nových techník a informácie vyžaduje čas spracovania. Táto zvýšená vyu?itie CPU 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 kompenzovaná toto zvýšenie kompilácii pokles výkonu čas. Celkový účinok je rýchlejšie spusteného dotazu ako v predchádzajúcich verziách servera SQL Server. Jedna výnimka však dochádza s dotazov na databázy OLTP-typ veľmi malé a jednoduché, 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šia ako v starších verziách programu SQL Server. Pretože rozdiel je zvyčajne v milisekundách, tieto účinky sú všimli za určitú dotaz, ak je vykonaný jednotlivo. Avšak, môžete si všimnúť, že celkovo systém vyu?itie CPU 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 užívateľov.

Rozvíjať Parametrizované dotazy

SQL Server 7.0 používa niekoľko nových techník, ako napríklad použitie vyrovnávacej pamäte ad hoc dotazy a automatické parametrizáciou. Avšak dotazy SQL Server 7.0 automaticky parameterizes sú obmedzené. Použitie týchto metód, aby istí, že dotaz plány sú parametrizovaná a môžu opätovne efektívnejšie:
  • Parameter značky OLE DB a ODBC API umožňujú parametre upresniť s otáznikom keď používatelia odošlú dotazov. To môže byť veľmi užitočné v ktoromkoľvek aplikácie najmä strednej vrstvy aplikácie, ktoré majú dotaz generácie moduly kde pomocou uložené procedúry nie je k dispozícii. Dotaz plán, ktorý je generované pre dotazy, ktoré majú parametra značky môžu opätovne akékoľvek klientov to vykonať rovnakým dotazem, dokonca aj vtedy, ak sú uvedené hodnoty rôznych parametrov. Ďalšie informácie nájdete v téme "Parameter Značkovače" v SQL Server 7.0 Books Online.
  • sp_executesql V 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. Avšak, môže tiež byť nazýva priamo žiadosť alebo v inom uloženej procedúry na výslovne parameterize ad hoc dotazov. To môže byť veľmi 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éme "Riaden? postupy" a "Programovanie uložené postupy" témy v 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, že výkon poklesol. Určenie počítadlo, ktoré bola ovplyvnená prvý a potom určiť, ktoré z nasledujúcich otázky je najdôležitejšie pre vašu situáciu:
  • Objekt: proces
    Počítadlo: procesor
    Stupňa: SQL Server
  • Objekt: procesor
    Počítadlo: % času procesora
    Stupňa: Skontrolujte každý procesor stupňa
  • Objekt: SQL Server: medzipamäte Manager
    Počítadlo: voľný Medzipamäte
  • Objekt: SQL Server: medzipamäte Manager
    Počítadla: Odcudzených stránku Count
  • Objekt: SQL Server: Memory Manager
    Počítadlo: pamäte Granty až do
  • 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 počítadlá pamäte granty Čakajúce a odcudzených počtu strán sú nízke, naznačuje, že Procesor je prekážkou. Zamerať sa na tom, ako účinne parameterize a opätovné použitie plánuje dotaz zamedziť nákladom na dotaz plán generovanie a pozri oddiel "Kolektívne SQL Profiler stopových udalosť triedy" tohto článku. Ak voľný buffery 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 obmedzovaný pamäte. Zameria na nájdenie dotazy, kde hodnota hash spojenia sú používa a slučky spojenia a vidieť "skupina SQL Profiler je možné zmeniť Trace duráciou"časti tohto článku. Pre viac informácií o týchto počítadlá, použite názov počítadla na hľadanie SQL Server 7.0 kníh Online.

Zobrazenie údajov SQL Profiler

Keď sú vyriešiť problémy s výkonom, je to veľmi cenná pre zobrazenie SQL Profiler údajov. Nemáte na preskúmanie všetkých údajov, ste zajatý; byť selektívne. SQL Profiler umožňuje efektívne zobrazenie zachytené údaje. Na Vlastnosti kartu (na Súbor ponuky, kliknite na tlačidlo Vlastnosti), SQL Profiler umožňuje obmedziť údaje, ktoré sa zobrazí odstránením stĺpcov údajov alebo udalosti, zoskupovania alebo zoraďovaní podľa stĺpcov údajov a uplatňovaní filtre. Môžete Prehľadať celý stopových alebo len určitý stĺpec špecifické hodnoty (na Upraviť ponuky, kliknite na tlačidlo Nájsť ). Môžete tiež uložiť SQL Profiler údajov do tabuľky servera SQL Server (na Súbor v ponuke ukážte na Uložiť ako, a potom kliknite na tlačidlo Stopový Tabuľka), a potom spustite SQL dotazov proti nemu.

Poznámka: Uistite sa, že ste iba filter súbor uložený sledovania. Ak postupujete podľa tieto kroky na aktívne stopových riskujete stratu údajov, ktorý bol zajatý od stopa sa spustila. Uložiť aktívny stopových súboru alebo tabuľka najprv (na Súbor ponuky, kliknite na tlačidlo Uložiť ako ), a potom znova otvorte to (na Súbor ponuky, kliknite na tlačidlo Otvorené) pred vami pokračovať. Keď pracujete s súbor uložený sledovania, filtrovanie nemá natrvalo odstrániť údaje; len je skryté údaje neodstránia. Môžete pridať a odstránenie udalosti a stĺpce údajov, ktoré pomôžu zameranie vyhľadávania.

Ste tiež by sa mali zamerať na oblasti, kde dostanete maximálne využiť. V nasledujúcich faktorov môže pomôcť zvýšiť uplatňovanie výkonu, ale nie nevyhnutne v rovnakej miere. Predtým, ako budete vykonávať akékoľvek zmeny, určiť, 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 jednotného dotazu z 1,5 sekundy 1,2 sekundy nesmie byť užitočné, ak dotaz sa nevykoná často po celý deň. Avšak, ak dotaz je vykonaný veľmi často o vysoký počet súbežných používateľov, zlepšenie výkonu môže byť veľmi účinná. Naopak, zlepšenie jediného dotazu z 6 minút na 3 sekúnd nie priniesť výrazné zvýšenie celkovej výkonnosti ak je zriedkavo používané. Použiť zoskupovanie a filtrovanie techník v SQL Profiler a vaše vedomosti o žiadosti na odhadnutie účinkov najmä dotaz alebo postup pred zavedením akýchkoľvek zmien. Zameria na čo najefektívnejšie zmeny prvý, a potom pokračujte iterácií 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 preskúmajú obsah. Do skupiny SQL Profiler Mikroprvky, postupujte nasledovne:
  • Skupiny stopových SQL Profiler duráciou:
    1. Na Súbor ponuky, kliknite na tlačidlo Vlastnosti.
    2. Kliknite na Stĺpce údajov kartu, a potom podľa Groups, kliknite na tlačidlo NAHOR presunúť Trvanie. Kliknite na položku NADOL Ak chcete odstrániť všetky ostatné stĺpce.
    3. Kliknite na Udalosti kartu, a potom odstráňte všetky udalosti s výnimkou TSQL SQL:StmtCompleted a TSQL RPC: dokončené. To umožňuje sústrediť len dotazy, ktoré sú predmetom popravený.
    4. Kliknite na položku ok.
    Zoskupenia podľa trvania umožňuje ľahko vidieť SQL výkazy, dávok a postupy, ktoré sú spustené slowest. Preskúmanie stopové keď problém sa vyskytuje a vytvoriť základný dobrý výkon. Môžete filtrovať podľa Štart čas na prestávku stopy sekcií, keď výkon je dobré a samostatných sekcií, keď výkon je slabá. Pozrite sa na dotazy s najdlhšie trvanie, keď výkon je dobrý. Tieto sú s najväčšou pravdepodobnosťou koreň problému. Keď znižuje výkon celkového systému, dokonca aj dobré dotazy môžete zobraziť dlhé durácií, pretože čakajú na systémové prostriedky.

    Preskúmanie vykonávania plánov pre dotazy, že väčšina často majú dlho durácií. Ak vidíte, že spojenie Haš používa, zvážte použitie SLUČKY JOIN dotaz nádychom prinútiť vnorené slučky spojenie pre dotaz. Ak čas uskutočnenia dotaz použitím slučky spojenie je menej ako rovná, alebo dokonca mierne vyšší ako doba vykonávania s hash pripojiť, môže byť spojenie slučky lepšia voľba, ak počítač zažíva vysokej pamäte a CPU. Autor: znížiť stres na zdroj prekážkou (CPU a pamäť), môžete zlepšiť celkový výkon systému. Ďalšie informácie o SLUČKY, pripojte sa k dotaz nádychom, pozrite si tému "Vybrať (T-SQL)" v SQL Server 7.0 Books Online.
  • Skupiny stopových SQL Profiler udalosť triedy:
    1. Na Súbor ponuky, kliknite na tlačidlo Vlastnosti.
    2. Kliknite na Stĺpce údajov kartu, a potom podľa Groups položky, kliknite na tlačidlo NAHOR presunúť Trieda udalostí a Text s Udalosť Trieda na vrchole. Kliknite na položku NADOL Ak chcete odstrániť všetky ostatné stĺpce podľa Groups položka.
    3. Kliknite na Udalosti kartu, a potom vykonaním ste si istí, že všetky udalosti sú zahrnuté.
    4. Kliknite na položku ok.

Typy udalostí

Vidieť, aké typy udalostí dochádza na počítači so systémom Server 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; KURZORY: Cursorprepare A 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, len na čítanie, veľkosť skupiny riadkov = 1. A 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ť na hodnotu ako predvolený. An Exec pripravené SQL udalosť naznačuje, že buď predošlého typy existujúcich pripravené závierky bol popravený. Ak vidíte časté výskyty týchto udalosti, vaša aplikácia je vzoru pripraviť a vykonať pri otvorení množiny výsledkov. Ak áno, musíte určiť Ak používate, pripraviť a spustenie vzor správne.

    V ideálnom prípade žiadosť pripravuje príkaz SQL Akonáhle a spustí ho niekoľkokrát, tak, že optimalizácia nemá zostaviť nový plán zakaždým, keď vyhlásenie je popravený. Keď spustíte pripravené vyhlásenie, môžete uložiť náklady na zostavenie dotazu. Ak si len chcete Spustenie dotazu jeden čas, Microsoft odporúča, aby ste sa nedoporučuje pripravovať. Prípravu a potom vykonávajúci príkaz SQL vyžaduje tri siete roundtrips: jeden pripraviť vyhlásenie, jeden vykonať vyhlásenie a jeden k unprepare výkazu. Príprava server-bočné kurzory vyžaduje aspoň päť spiatočných letov: jeden na prípravu kurzora, jeden spustiť alebo ho, otvoriť jedným alebo viac sehnat z ju, jeden zavrite ho a jeden na unprepare to. Vykonávajúci dotaz vyžaduje iba jeden spiatočný.

    Vidieť, 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 musia byť oveľa väčšie ako súčet Pripravte SQL a CursorPrepare udalosti (najmenej tri až päťkrát väčší je dobrý odhad). To naznačuje, že pripravené závierky sú často dosť na opätovnému prekonať zvýšené režijné náklady na ich vytvorenie. Ak počet Pripravte SQL a CursorPrepare udalosti sa zhruba rovná počtu Exec pripravené SQL udalosti, môže to naznačovať, že žiadosť nie je účinne pomocou modelu pripraviť a spustiť. Snažiť vypracovať výkaz jeden čas a opätovné použitie to č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í.

    Žiadosť musí byť napísaný špeciálne použitie modelu pripraviť a vykonávať efektívne. V životnosť rukoväť na pripravené vyhlásenie je riadený ako dlho budete držať príkazu HSTMT otvoriť v ODBC alebo ICommandText objekt OLE DB. Jeden spoločný prax je získanie príkazu HSTMT, pripravte príkaz SQL, spustenie pripravených vyhlásenie, a potom bez príkazu HSTMT, tým stráca rukoväť na pripravenej plán. Ak urobíte, nedostanete žiadnu výhodu z pripraviť a spustenie vzor. V skutočnosti, môžete vidieť výkon degradácia z dôvodu extra réžia 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ľ nemá robiť to automaticky; uplatňovanie je zodpovedný za realizáciu, udržiavanie a pomocou týchto informácií. Ak žiadosť nemôže tak urobiť, zvážte použitie parametra značky namiesto pripraviť a spustenie metódy.
  • Použitím parametra značky Aplikácie môžu používať Parameter markerov optimalizovať využitie tohto vyhlásenia Transact-SQL niekoľkokrát s rôzne vstupné a výstupné hodnoty. Prvýkrát, dotaz je popravený, 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 nahradením súčasné parametre.

    Ak uplatňovanie používa parameter markerov 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. Vyhlásenie nemusí byť pripravené a popravený oddelene. 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.

    Zistiť, či vaša aplikácia v súčasnosti používa parameter značky, môžete vyhľadávaťText stĺpec v SQL Profiler stopových pre „sp_executesql. ” Avšak, pretože sp_executesql môže 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 "opätovné vykonanie plánu Caching a použitie" v SQL Server 7.0 Books Online. Ďalšie informácie o parameter značky, pozri "Parameter Značkovače"tému v SQL Server 7.0 Books Online.
  • PS: dokončené Dynamické príkazy SQL vykonaný pomocou príkazu Spustiť Zobraziť ako PS: dokončené udalosť s textom "Dynamické SQL." Rozbaľte PS: dokončené udalosť a potom vyhľadajte akékoľvek udalosti, ktoré majú "Dynamic SQL"ako text. Ak existujú mnohé z týchto udalostí, je možné zlepšiť uplatňovanie výkonu pomocou sp_executesql namiesto výkazu vykonať. V sp_executesql uložené postupom povolení servera SQL Server na opätovné použitie vykonávania plánov, ak istého dotazu je popravený, opäť pomocou rôznych parametrov. Keď použijete VYKONAŤ vyhlásenie, plán nie je parametrizovaná a nesmú opätovne použiť, ak dotaz je popravený, znova s použitím rovnakých parametrov.

    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ý v chronologické poradie. Môžete filtrovať stopových identifikáciou pripojenie (na Filtre karta), a potom odstráňte všetky triedy udalostí s výnimkou PS: spustenie a PS: úplná udalosti pre zvýšené čitateľnosť. Môžete potom hľadať Štart čas udalosti (na Upraviť ponuky, kliknite na tlačidloNájsť). Výsledky ukazujú, keď začal dynamické SQL udalosť. Ak nastala udalosť v uloženej procedúre, udalosti sa zobrazuje medzi PS: spustenie a PS: dokončené udalosti pre takéto konanie. Ak udalosť sa nevyskytovali v uložené postup, bol popravený ako dotaz ad hoc a môžete použiť iné údaje stĺpce)Názov aplikácie, NT Meno používateľaa i.) určiť, kde bol vykonaný príkaz. Vykonaná akcia určenie textu, príkaz a v kontexte, kde bol popravený, môžete môžete tiež pridať triedy udalostí, ako sú SQL:BatchCompleted a SQL:RPCCompleted.

    Keď určíte, kde vykonať vyhlásenie je používaný, zvážte nahradenie hovor sp_executesql. Napríklad Uvažujme o nasledovnom scenári 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á podobné 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
    Predpokladáme, ž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ôznymi hodnotami pre @ idValue parameter, SQL Server musí vygenerovať 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 dostatočne jednoduché, že server SQL Server môže dotaz automaticky parameterize a skutočne opätovné použitie vykonávania plánu. Avšak, Ak to bolo sa komplexný dotaz SQL Server môže automaticky parameterize, SQL Server, sa musí nie opätovné použitie plán druhý realizácie, ak @ idValue parameter bol zmenený. Tieto limity jednoduchý dotaz zložitosť príklad.

    Môžete prepísať tento postup použiť sp_executesql namiesto výkazu vykonať. Podpora pre parameter substitučná 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 prvýkrát, sp_executesql výkaz je popravený, SQL Server generuje parametrický plán na príkaze SELECT z tituly s title_id ako parameter. Na druhom vykonanie, opätovné použitie servera 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čujú, že bola uložená procedúra prekompilovali počas realizácie. Mnoho udalosti recompile označuje, že SQL Server je pomocou zdrojov pre zostavovanie dotazu namiesto vykonávanie dotazu.
Ak nevidíte ktorejkoľvek z týchto udalostí, žiadosť je vykonávajúci len ad hoc dotazy proti SQL Server. Pokiaľ nestanoví SQL Server že môžete automaticky parameterize určitých dotazoch alebo ak rovnaké parametre sa používajú opakovane, každý dotaz, ktorý je popravený vyžaduje SQL Server generovať nové vykonávania plánu. Sledovanie výkonu SQL Server by mala ukázať mnoho SQL kompilácie/SEK. Toto môže byť náročné na Procesor pre mnoho súbežných užívateľov. Tento problém obísť, nájsť najčastejšie popravený dotazy, a zvážte vytvorenie uložené procedúry pre tieto dotazy pomocou parametra markéry; alebo pomocou sp_executesql.

ODKAZY

Ďalšie informácie o monitorovanie a riešenie problémov výkon v SQL Server nájdete po kliknutí na nasledovné číslo článku databázy Microsoft Knowledge Base:
224587Riešenie problémov s uplatňovanie výkonu s SQL Server
224453 INF: Pochopenie a riešenie SQL Server 7.0 alebo 2000 blokovanie problémy
243586 Riešenie problémov s uloženej procedúry recompilation
243589 Riešenie problémov s pomalý chod dotazy na SQL Server 7.0 alebo novší
251004 INF: Ako sledovať, SQL Server 7.0 blokovanie

Vlastnosti

ID článku: 243588 - Posledná kontrola: 23. októbra 2011 - Revízia: 3.0
Informácie v tomto článku sa týkajú nasledujúcich produktov:
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-bit Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL Server 2005 Standard Edition
Kľúčové slová: 
kbhowtomaster kbhowto kbinfo kbmt KB243588 KbMtsk
Strojovo preložené
DÔLEŽITÉ: Tento článok bol preložený pomocou softvéru na strojový preklad od spoločnosti Microsoft, nie prekladateľom. Spoločnosť Microsoft ponúka články preložené prekladateľmi aj strojovo preložené články, vďaka čomu máte možnosť prístupu ku všetkým článkom databázy Knowledge Base vo svojom jazyku. Strojovo preložený článok však nie je vždy perfektný. Môže obsahovať chyby týkajúce sa slovnej zásoby, syntaxe alebo gramatiky, podobne ako cudzinec môže robiť chyby, keď rozpráva vašim jazykom. Spoločnosť Microsoft nenesie zodpovednosť za akékoľvek nepresnosti, chyby alebo škody spôsobené akýmkoľvek nepresným prekladom obsahu alebo jeho použitím zo strany zákazníkov. Spoločnosť Microsoft softvér na strojový preklad pravidelne aktualizuje.
Pokiaľ chcete vidieť anglickú verziu článku, kliknite sem:243588

Odošlite odozvu

 

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