INF: Optimalizácia Microsoft SQL Server výkonnosti

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

Na tejto stránke

SUHRN

Najúčinnejšie optimalizovať Microsoft SQL Server, musíte určiť oblasti, ktoré budú prinášajú najväčší výkonnosť sa zvyšuje počas najširšej rôzne situácie, a zameranie analýzy v týchto oblastiach. V opačnom prípade môže spotrebovať významné čas a úsilie na témy, ktoré môžu nie je výnos značné zlepšenie.

Z veľkej časti sa tieto informácie nezaoberá problémy s výkonom vyplývajúce z viacerých používateľov súbežnosti. To je samostatné, zložité tému, ktoré je obsiahnuté v dokumente "maximalizovať Databázy konzistentnosť a súbežnosti,"ktoré možno nájsť v SQL Server verzia 4.2 x "Programmer's Reference c," dodatok E, a tiež v iných Články databázy Knowledge Base. Nie je v dokumentácii verzia 6.0, ale možno nájsť na MSDN (Microsoft Developer Network) CD podľa tohto titul.

Skôr ako teoretické diskusiu, tento článok je zameraný predovšetkým na oblastí, ktorý má rokov skúseností tím technickej podpory spoločnosti Microsoft SQL Server preukáže praktickú hodnotu v reálnom svete situáciách.

Skúsenosti ukazujú, že najväčší prínos v SQL Server výkonnosti môže byť získané z všeobecných oblastiach logické databáza dizajnu, index design, návrh dotazu a dizajnom aplikácie. Naopak, najväčší výkon problémy sú často spôsobené nedostatkami v týchto istých oblastiach. Ak ste zaoberajú sa výkon, ste mali sústrediť na týchto oblastiach po prvé, preto často dá dosiahnuť veľký výkon zlepšenia relatívne malá čas investície.

Zatiaľ čo ostatné systéme-úroveň výkonnosti problémov, napríklad pamäť cache tlmivých roztokov, hardvér, a tak ďalej, sú určite kandidátmi na štúdiu, skúsenosti ukazuje, že výkon zisk z týchto oblastí je často prírastkové. SQL Server spravuje dostupné hardvérové prostriedky automaticky, pre väčšinu časť znížiť potrebu (a preto v prospech) rozsiahlej úroveň systému Ručné ladenie.

Microsoft SQL Server 6.0 poskytuje nové možnosti pre platformu vrstva vylepšenia výkonu s veľkým množstvom pamäte, symetrické viacprocesové, paralelné údajov skenovanie, optimalizácia vylepšenia a disku prekladanie. Tak veľká, ako sú tieto zlepšenia, sú však výlučné v rozsah. Najrýchlejší počítača môžete zabředly s neefektívne dotazy alebo zle navrhnuté aplikácie. Teda aj s dodatočné výkon zvýšiť, že SQL Server 6.0 umožňuje, je nesmierne dôležité, aby optimalizovali databáza, index, dotaz a dizajnom aplikácie.

Väčšina problémov s výkonom nemožno úspešne vyriešiť len server-bočné zameranie. Server je v podstate "bábkové" klienta, ktoré kontroly otázky, čo sa odosielajú, a tým sú získané čo zámky a uvoľní. Hoci niektoré ladenie je možné na strane servera úspešné riešenia problémov s výkonom bude zvyčajne závisieť na UZNÁVAJÚC dominantnú úlohu zohráva v problém klienta a analýza chovanie aplikácie klienta.

DALSIE INFORMACIE

Nižšie sú uvedené niektoré návrhy, že na základe skúseností, priniesli zvýšenie významné výkonu:

Normalizovať logické návrhu databázy

Primerané normalizácia návrhu logické databázy výnosy najlepšie výkon. Väčší počet úzky tabuliek je charakteristická pre normalizovanú databáza. Menší počet širokej tabuľky je charakteristická pre Nenormalizované databáza. Vysoko normalizovanom databázy je bežne spojené s zložité relačnej spojenia, ktoré môže bolieť výkon. Avšak, SQL Server optimizer je veľmi efektívne pri výbere rýchle, efektívne spojenia, ako dlho ako účinné indexy sú k dispozícii.

Výhody normalizácia zahŕňajú:
  • Urýchľuje triedenie a index vytvorenie, pretože tabuliek sú užšie.
  • Umožňuje viac skupinový indexov, pretože existuje viac tabuliek.
  • Indexy majú tendenciu byť užší a kompaktnejšia.
  • Menej indexy na tabuľku, pomáha aktualizácia výkon.
  • Menej NULL a menej nadbytočných údajov, zvýšenie databázy kompaktnosť.
  • Znižuje súbežnosť vplyv DBCC diagnostiky, pretože potrebné Tabuľka zámky ovplyvní menej údajov.
S SQL Server, často rozumné normalizácia pomáha než bolí výkon. Normalizácia zvyšuje, tak počet a komplexnosť spojenia na získanie údajov. Ako neopracované pravidlo palca, Microsoft navrhuje vykonávajúce procesu štandardizácie, pokiaľ to spôsobuje veľa dotazy na štyroch-pásmový alebo väčšie spojenia.

Ak návrh logické databázy je už pevné a celkové redesign nie je uskutočniteľné, je možné na selektívne normalizovať veľkej tabuľky, ak analýza ukazuje prekážkou v tejto tabuľke. Ak je prístup k databáze vykonávané prostredníctvom uložené procedúry, táto zmena schémy mohla uskutočniť bez ovplyvňujúcich aplikácie. Ak nie je možné skryť zmeniť vytvorením názor, že vyzerá ako jednu tabuľku.

Použiť účinné indexom dizajn

Na rozdiel od mnohých-relačný systémov, relačnej indexy sa nepovažujú za časť návrhu logické databázy. Indexy môžete spadol, pridali, a zmenil bez ovplyvnenia schémy alebo uplatňovanie návrhu databázy v ktoromkoľvek spôsob iné ako výkon. Účinné indexom dizajn je rozhodujúci v dosiahnutie dobrý výkon servera SQL Server. Z týchto dôvodov by ste sa nemali Neváhajte a experimentovať s rôznymi indexmi.

Optimalizácia spoľahlivo rozhodne najviac účinné indexom vo väčšine prípadoch. Celková stratégia dizajn indexu by malo byť poskytovať dobrý výber indexov na optimalizáciu, a dôvera ho tak, aby právo rozhodnutie. To znižuje čas analýzy a dáva dobrý výkon nad širokú rôznorodosť situácií.

Index návrhu odporúčania sú:
  • Preskúmať klauzule WHERE dotazov SQL, pretože to je primárnym zameraním optimalizácia.

    Každý stĺpec uvedený v klauzule WHERE je možné kandidátom pre register. Ak máte príliš veľa otázok preskúmať, vyskladnenie zástupca súbor, alebo len tie pomalý. Ak váš rozvoj nástroj transparentne generuje kód SQL, je to ťažšie. Mnohé z týchto nástrojov Povoliť zapisovanie do denníka vytvorené syntaxe SQL súboru alebo obrazovka pre účely ladenia. Možno budete chcieť zistiť od dodávateľa sa nástroj, ak takáto funkcia je k dispozícii.
  • Úzky indexy použiť.

    Úzky indexy sú často účinnejšie ako multicolumn, kŕmnych indexy. Úzky indexy majú viac riadkov na stranu a menej indexu úrovní, zvyšovanie výkonnosti.

    Optimalizácia môže rýchlo a účinne analyzovať stovky alebo dokonca tisíce možností index a pripojiť. Majú väčší počet úzky indexy poskytuje optimalizácia viac možností na výber ktoré zvyčajne pomáha výkon. Majú menej široká, multicolumn indexy poskytuje optimalizácia s menšími možnosťami vyberať, ktoré môže bolieť výkon.

    Často je najlepšie prijať stratégiu zdôrazňujúc plne hradené dotaz. Je pravda, že ak sú zahrnuté všetky stĺpce vo vašom klauzula SELECT klastrované indexom, optimalizácia rozpoznať to a poskytnúť veľmi dobrý výkon. Avšak toto často vedie k príliš široké indexuje a opiera príliš na možnosť, že bude pre optimalizáciu využívanie tejto stratégie. Zvyčajne by ste mali používať početnejšie úzky indexy ktoré často poskytujú lepší výkon nad širší rozsah dotazov.

    Nemali by ste mať viac indexy ako sú potrebné na dosiahnutie primeranej výkon pri čítaní z dôvodu zapojených do aktualizácie tými režijné náklady indexy. Však dokonca aj väčšina aktualizácia-orientované operácie vyžadujú oveľa viac čítanie ako písať. Preto neváhajte skúsiť nový index, ak myslíte, že to pomôže; môžete vždy presúvať ho neskôr.
  • Použiť skupinový indexy.

    Primerané použitie skupinový indexy nesmierne zvýšiť výkon. Dokonca UPDATE a odstrániť operácie sú často urýchliť Skupinový indexov, pretože tieto operácie vyžadujú oveľa čítanie. A jeden klastrovaný index na jeden stôl je povolené, takže používať tento index s rozvahou. Dotazy, ktoré vrátia početné riadky alebo dotazy zahŕňajúci rozsah hodnoty sú kandidátmi na zrýchlenie skupinový indexom.

    Príklady:
          SELECT * FROM PHONEBOOK
          WHERE LASTNAME='SMITH'
    
          -or-
    
          SELECT * FROM MEMBERTABLE
          WHERE  MEMBER_NO > 5000
           AND MEMBER_NO < 6000
    
    						
    Naopak, priezvisko alebo MEMBER_NO stĺpce uvedené vyššie sú pravdepodobne nie kandidátmi na-klastrované index, ak je to typ dotaz je spoločná. Skúste použiť-klastrované indexy na stĺpcoch kde niekoľko riadky sa vrátia.
  • Preskúmať stĺpec jedinečnosť.

    Pomôže vám to rozhodnúť, aké stĺpec je kandidátom klastrovaný index klastrované index alebo ne index.

    Toto je príklad dotazu preskúmať jedinečnosť stĺpec:
          SELECT COUNT (DISTINCT COLNAME)
          FROM TABLENAME
    
    						
    To vráti počet jedinečných hodnôt v stĺpci. Porovnať túto celkový počet riadkov v tabuľke. V tabuľke Riadok 10.000, 5000 jedinečné hodnoty by sa stĺpec dobrým kandidátom na non-klastrované register. V tej istej tabuľke 20 jedinečné hodnoty by lepšie vyhovoval skupinový register. Tri jedinečné hodnoty by nemal byť indexovaný vôbec. Sú to len Príklady, tvrdá a rýchla pravidlá. Nezabudnite uviesť indexy na Jednotlivé stĺpce uvedené v kde klauzuly dotazov.
  • Preskúmať distribúciu údajov v indexované stĺpce.

    Často sa vyskytuje dlho-bežiaci dotazu, pretože stĺpec s málo jedinečný indexované hodnoty alebo spojenie na takúto kolónu sa vykonáva. To je základný problém s údajmi a dotaz, samotného a obvykle nemožno vyriešiť bez identifikácie túto situáciu. Napríklad fyzické telefónny zoznam Abecedne zoradené podľa priezviska bude nie urýchliť vzhlédl osobou, ak všetkých ľudí v meste sú pomenované len "Smith" alebo "Jones." Popri vyššie dotaz, ktorý dáva jednociferné číslo pre stĺpec jedinečnosť, môžete použiť dotaz ZOSKUPIŤ podľa vidieť údaje distribúcia indexované hodnoty kľúča. Tento balík poskytuje vyššiu rozlíšenie obrázka údajov a lepší výhľad pre ako Optimalizácia zobrazení údajov.

    Toto je príklad dotazu preskúmať distribúciu údajov indexované hodnoty kľúča, za predpokladu, že dvojstĺpcovú kľúč v stĺpci 1, COL2:
          SELECT COL1, COL2, COUNT(*)
          FROM TABLENAME
          GROUP BY COL1, COL2
    
    						
    Toto návrat jeden riadok pre každú hodnotu kľúča s počítadlom prípady každej hodnoty. Znížiť počet vrátených riadkov, môže byť užitočné vylúčiť niektoré s klauzulu HAVING. Napríklad klauzula
          HAVING COUNT(*) > 1
    
    						
    vylúči všetky riadky, ktoré majú jedinečný kľúč.

    Počet riadkov vrátené v dotaze je tiež dôležitým faktorom pri Výber indexu. Optimalizácia považuje index klastrované náklady aspoň jednu stranu I/O vrátených riadkov. Pri tomto tempe, sa rýchlo stáva efektívnejšie skenovanie celú tabuľku. To je ďalší dôvod obmedziť veľkosť množiny alebo vyhľadajte veľké výsledok s klastrovaný index.
Nemusí vždy byť ekvivalentom používanie indexu s dobrý výkon a naopak. Ak použitie indexu vždy vyrába najlepší výkon, optimalizácia je úlohou by bolo veľmi jednoduchý - vždy použiť všetky dostupné index. Skutočne, nesprávny výber indexované vyhľadávania môžu mať za následok veľmi zlé výkonnosti. Preto pre optimalizáciu úlohou je vyberte indexované vyhľadávania tam, kde to bude pomôcť výkon, a vyhnúť sa indexované vyhľadávania, kde bude bolieť výkon.

Použiť účinné návrh dotazu

Niektoré typy dotazov sú vo svojej podstate náročný. To súvisí s základné databázu a indexu problémov spoločný pre väčšinu relačnej databázy riadiace systémy (RDBMSs), nie je osobitne na server SQL Server. Nie sú neefektívne, pretože optimalizácia bude vykonávať dotazy vo väčšine účinným spôsobom možné. Sú však náročný, a súbor orientovanú povahu SQL môžu ich zobraziť neefektívne vykonať. Žiadny stupeň Optimalizácia inteligencia vylúčiť náklady inherentné zdroj týchto konštrukcie. Sú vnútorne nákladné, keď v porovnaní s viac jednoduchý dotaz. Hoci SQL Server bude používať plánu optimálne prístup, je to obmedzená čo je zásadne možné.

Napríklad:
  • Veľké výsledok sady
  • V, nie v a alebo dotazy
  • Vysoko Nejedinečná klauzuly WHERE
  • ! = operátory porovnávania (nerovná sa)
  • Určité stĺpec funkcie, napríklad funkciu SUM
  • Výrazy alebo údaje prepočty v klauzula WHERE
  • Lokálne premenné v klauzula WHERE
  • Komplexné názorov s ZOSKUPIŤ podľa
Rôzne faktory môžu vyžadovať používanie niektorých z týchto dotaz konštrukcií. Vplyv týchto bude potlačená, ak môžete obmedziť optimalizácia výsledok nastaviť pred použitím prostriedku intenzívne časť dotaz. V nižšie sú uvedené niektoré príklady.

Náročných na zdroje:
   SELECT SUM(SALARY) FROM TABLE
				

Menej náročných na zdroje:
   SELECT SUM(SALARY) FROM TABLE WHERE
   ZIP='98052'
				

Náročných na zdroje:
   SELECT * FROM TABLE WHERE
   LNAME=@VAR
				

Menej náročných na zdroje:
   SELECT * FROM TABLE
   WHERE LNAME=@VAR AND ZIP='98052'
				

V prvom príklade súčet operácia nemôže zrýchlil s register. Každý riadok musí prečítať a sčítajú. Za predpokladu, že je index na stĺpci ZIP optimalizácia budú pravdepodobne používať to spočiatku obmedziť výsledok nastaviť pred použitím súčet. To môže byť oveľa rýchlejšie.

V druhom príklade lokálnej premennej nie je vyriešený až doba spracovania. Však optimalizácia nedá odložiť výber prístup plán kým spustiť čas; musia vybrať pri kompilácii. Ešte pri kompilácii, keď prístup plán je postavený, hodnota @ VAR nie je známe, a teda nemôžu byť použiť ako vstup pre výber indexu.

Ilustrovaná technika na zlepšenie zahŕňa obmedzenie výsledok množina s a doložka. Ako alternatívne techniky, použite uloženej procedúry, a prejsť hodnotu pre @ VAR ako parameter uloženej procedúry.

V niektorých prípadoch je najlepšie použiť skupinu jednoduché dotazy pomocou temp tabuliek na uloženie priebežné výsledky než použite jeden veľmi zložitý dotaz.

Veľké výsledok sú nákladné na väčšine RDBMSs. Mali by ste skúsiť nevráti veľké výsledok nastaviť klienta pre konečné údaje výber prehliadania. To je oveľa účinnejšie obmedziť veľkosť výsledok nastaviť, ktoré umožnia databázový systém vykonávať funkciu, na ktoré bolo určené. Toto tiež znižuje siete I/O a podáva žiadosť viac podrobiť nasadenie cez pomalé vzdialenej komunikácie odkazy. Zlepšuje tiež výkonnosti súvisiace s súbežnosť ako uplatňovanie stupníc smerom nahor na viac používatelia.

Použiť účinné uplatňovanie dizajn

Nemôže byť úlohu, ktorú zohráva dizajnom aplikácie SQL Server výkonnosti nadhodnotené. Skôr ako obrázok server v dominantnú úlohu, je to viac presný obraz klienta ako kontrolný subjekt a server ako bábka klienta. SQL Server je úplne pod velením klienta pokiaľ ide o typ dotazov, ak sú predložené a ako sú výsledky spracované. To zasa má významný vplyv na typ a trvanie zámky, množstvo I/O a CPU načítať na serveri, a teda či výkon je dobré alebo zlé.

Z tohto dôvodu je dôležité urobiť správne rozhodnutia počas uplatňovanie projektovej fáze. Avšak aj keď budete čeliť problému s výkonom pomocou kľúč aplikácie, kde zmeny klientska aplikácia zdať nemožné, a to nemení základné faktory, ktoré ovplyvňujú výkon - menovite že klient zohráva dominantnú úlohu a mnohé výkon problémy nemôžu byť vyriešené bez zmien klienta.

Dobre navrhnuté aplikáciou SQL Server dokáže podporných tisíce súbežných používateľov. S aplikáciou zle určený dokonca aj najmocnejšou server platforma môže zapadnúť s len pár používatelia.

Pomocou tieto návrhy pre klienta dizajnom aplikácie bude poskytovať dobrý výkon servera SQL Server:
  • Používať malé výsledok sady. Množín zbytočne veľké výsledkov Retrieving (napríklad tisíc riadkov) na prehľadávanie klienta pridá CPU a sieťové vstupno-výstupného zaťaženia, podáva žiadosť menej schopný vzdialenej používania, a môžete obmedziť viacerými používateľmi škálovateľnosť. Je to lepší dizajn uplatňovanie na vyzve používateľa želali, tak že dotazy sú predložené, ktoré vytvárajú skromný výsledok sady.

    Uplatňovanie dizajnu techniky, ktoré uľahčia to zahŕňajú obmedzenie používanie zástupných znakov pri budovaní dotazov, Nariaďovanie určitý vstup polia, a zakazujú improvizované dotazov.
  • Správne používanie dbcancel() v knižnici databázy aplikácie. Všetky žiadosti by mali umožniť zrušenie dotazu v pokroku. Žiadna žiadosť by platnosť používateľa na reštartovanie klientsky počítač zrušiť dotaz. Nie podľa tejto zásady môžu viesť k problémy s výkonom, ktorý nie je vyriešené. Keď sa použije dbcancel(), sa vykonávajú v riadnej starostlivosti pokiaľ ide o transakcie úrovni. Ďalšie informácie nájdete nasledujúci článok v databáze Microsoft Knowledge Base:
    117143: INF: kedy a ako používať dbcancel() alebo sqlcancel()
    Rovnaké otázky uplatňovať ODBC aplikácií, ak ODBC sqlcancel() hovor sa používa.
  • Vždy spracovať všetky výsledky na dokončenie. Robiť dizajnu žiadosť alebo použite kľúč aplikácia, ktorá zastaví spracovávanie výsledok riadkov bez zrušenie dotaz. Pritom bude zvyčajne viesť k zablokovaniu a pomaly výkon.
  • Vždy vykonávať časový limit dotazu. Neumožňujú dotazov na spustenie neurčito. Značka vhodné DB knižnice alebo ODBC vyzýva nastaviť časový limit dotazu. V DB-knižnici, to sa vykonáva s dbsettime() hovor, a v ODBC s SQLSetStmtOption().
  • Nepoužívajte aplikácie rozvoj nástroj, ktorý neumožňuje explicitné kontrolu nad SQL výkazoch zaslaných na server. ne- použiť nástroj, ktorý transparentne generuje príkazy SQL založené na vyššie úroveň objektov, ak ju poskytuje dôležité funkcie, ako napríklad dotaz zrušenie, dotaz timeout a úplnú transakčné kontrolu. Je to často nie je možné zachovať dobrý výkon alebo vyriešiť výkon problém Ak uplatňovanie všetkých sama o sebe generuje "transparentné SQL," pretože to neumožňuje explicitné kontrolu nad transakčné a zabezpečovacích otázkam, ktoré sú kritické pre výkon obrázok.
  • Nie intermix podporu rozhodovania a OLTP (Databázy OLTP) dotazov.
  • Nie konštrukčné aplikácia alebo aplikácia kľúč, že sily používateľa na reštartovanie klientsky počítač zrušiť dotaz. To môže spôsobiť rôzne problémy s výkonom, ktoré sú ťažké vyriešiť pretože možné osamotená pripojenia. Ďalšie informácie nájdete v téme nasledujúci článok v databáze Microsoft Knowledge Base:
    137983: Riešenie problémov s osamotená pripojenia servera SQL Server

Techník analyzovať pomalá výkonnosť

To môže byť lákavá na riešenie problému s výkonom výhradne ich úroveň systému Server výkon tuning. Napríklad, koľko pamäte, typ súboru systém, počet a typ procesory a podobne. Skúsenosti Microsoft SQL Server Support ukázali, že väčšina problémov s výkonom nie je možné vyriešiť týmto spôsobom. Musia byť adresované analyzovaním uplatňovanie, dotazy žiadosť predkladá databázy, a ako tieto dotazy v interakcii s schéme databázy.

Po prvé, izolujte dotazu alebo dotazy, ktoré sú pomalé. Často sa javí, že celej aplikácie je pomalé, keď len pár SQL dotazov sú pomalé. Zvyčajne nie je možné vyriešiť problém výkonu bez rozepisovat problém a izolovanie pomalé dotazov. Ak máte nástroj rozvoja, ktorý transparentne generuje SQL, použitie všetkých dostupných diagnostické alebo debug režime tohto nástroja zachytiť generované SQL. V mnohých prípadoch stopových funkcie sú k dispozícii, ale ich možno nie otvorene zdokumentovať. Kontaktovať technickú podporu pre vašu aplikáciu chcete zistiť, či stopy funkcia existuje pre monitorovanie príkazy SQL generované aplikácia.

Pre vývojové nástroje aplikácií, ktoré používajú vložený SQL je to moc jednoduchšie - SQL je otvorene viditeľný.

Ak rozvoj nástroj alebo koncového používateľa žiadosť neposkytuje stopy funkciu, existuje niekoľko alternatív:
  • Použiť príznak stopových 4032 podľa pokynov v SQL Server 4.2 x "Troubleshooting Guide" a SQL Server 6.0 "Transact-SQL odkaz." To vám umožní zachytiť príkazy SQL odošle na server v denníku chýb SQL.
  • Monitorovať dotazy prostredníctvom analyzátora siete, ako sú Microsoft Network Monitor, ktorý je súčasťou Systems Management Server.
  • ODBC aplikácií pomocou programu Správca ODBC vyberte sledovania ODBC hovorov. Nájdete v dokumentácii ODBC pre viac informácií.
  • Použite pomôcku klientske tretej strany, ktoré zachytáva SQL na DB knižnice alebo ODBC vrstiev. Príkladom toho je SQL inšpektor z modrej Lagúny softvér.
  • Použite nástroj pre SQLEye analýzu uvedené ako príklad v Microsoft TechNet CD. Poznámka: SQLEye, nie je podporovaný spoločnosťou Microsoft technické Podpora.
Po pomalom dotaz je izolovaný, vykonajte nasledovné:
  • Podozrivých pomalé dotaz spustiť izolovane, pomocou dotaz nástroja ako napríklad ISQL, a overí, že je pomalý. Často je najlepšie spustiť dotaz na samotný počítač servera pomocou ISQL a miestne potrubia a presmerovanie výstup do súboru. To pomáha eliminovať komplikujúci faktory, ako napríklad siete a obrazovky I/O a uplatňovanie výsledok do medzipamäte.
  • Pomocou SET IO štatistiky na preskúmať I/O spotrebovanej dotaz. Oznámenie sa počet logickú stránku generovaných. Optimalizácia cieľ je minimalizovať I/O počítať. Vyhotoviť záznam z logických I/O počítať. To vytvára Základná línia proti ktorému na meranie zlepšenia. Je to často efektívne zamerať výlučne na základe štatistiky IO produkcie a Vyskúšajte rôzne typy dotazu a index ako použite SET SHOWPLAN ON. Tlmočenie a efektívne uplatňovanie výstup SHOWPLAN môžete vyžadujú niektoré štúdie a môže spotrebovávať čas, ktorý môže byť efektívnejšie strávené empirické testy. Ak váš výkon problém nie je fixovaný tieto jednoduché odporúčania, potom ju môžete použiť SHOWPLAN viac dôkladne preskúmať optimalizácia správanie.
  • Ak dotaz obsahuje zobrazenia alebo uloženej procedúry, extrahovať dotaz z zobrazenia alebo uloženej procedúry a spustite ho samostatne. To umožňuje prístup plán zmeniť as experimentovať s rôznymi indexmi. To tiež pomáha lokalizovať problém samotný, dotaz verzus ako optimalizácia kľučky názory alebo uložené procedúry. Ak problém nie je v dotaze samotnú, ale len keď dotaz spustiť ako časť Zobrazenie alebo uložené postup spustený dotaz sama pomôže zistiť to.
  • Byť informovaný o možných spúšťače o zapojení tabuliek, ktoré môžete transparentne generovať I/O ako spúšťač spustí. By ste mali odstrániť ktorýkoľvek Spúšťače zapojené do pomalého dotazu. Toto pomáha zistiť, či problém je v dotaze sama alebo spúšťacej alebo zobrazenie, a preto pomáha priame váš sústrediť.
  • Preskúmať indexy tabuliek použitých pomalé dotazom. Použitie predtým uvedených techník určiť, ak tieto sú dobré indexov, a ich zmeniť, ak je to potrebné. Ako prvý úsilie, skúste indexovanie každý stĺpec vaše klauzula WHERE. Často výkon problémy sú spôsobené jednoducho nie má stĺpca v klauzule WHERE indexované, alebo ktoré nemajú užitočné indexu na takúto kolónu.
  • Pomocou dotazov spomenuli, preskúmať údaje jedinečnosť a distribúcie pre každý stĺpec uvedený v klauzule WHERE a najmä pre každý indexované stĺpec. V mnohých prípadoch jednoduché prehliadka dotaz, tabuľky, registre a údaje sa okamžite zobrazí problém spôsobiť. Napríklad, problémy s výkonom sú často spôsobené so indexovať na kľúč s iba tri alebo štyri jedinečné hodnoty, alebo ak vykonávate PRIPOJTE sa na takúto kolónu alebo vykazujúcich nadmerný počet riadkov na klient.
  • Na základe tejto štúdie, vykonajte požadované zmeny na uplatňovanie dotaz, alebo indexy. Spustite dotaz znova po vykonaní zmeny a pozorujte Každá zmena v I/O počítať.
  • Po konštatovaní zlepšenie spustenie hlavné aplikácie či celkový výkon je lepší.
Skontrolujte, či program pre vstupno-výstupný alebo viazané na Procesor správanie. Často je užitočné určiť, či dotaz je vstupno-výstupný alebo CPU viazané. To pomáha sústrediť vaše zlepšenie úsilie o skutočný prekážkou. Napríklad ak dotaz CPU viazaný, pridanie pamäte na server SQL Server bude pravdepodobne nie zlepšiť výkon, pretože viac pamäte iba zvyšuje postihnutých pomer vyrovnávacej pamäte, ktoré v tomto prípade je už vysoké.

Ako sa preskúmať I/O vs viazané na Procesor dotaz správanie:
  • Použite sledovanie výkonu systému Windows NT na hodinky I/O verzus CPU činnosti. Sledujte všetky inštancie počítadla "čas disku v %" logický disk objekt. Tiež sledovať „% celkového času procesora "počítadla systému objekt. Ak chcete zobraziť informácie o výkone platné disku, musíte mať predtým zapnuté nastavenie Windows NT pomôcky DISKPERF vydávaním "pomôcky diskperf -Y" z príkazového riadka a reštartovaním systému. Nájdete v dokumentácii k systému Windows NT ďalšie podrobnosti.
  • Pri spustení dotazu ak CPU graf je neustále vysoké (pre napríklad väčší ako 70 percent), a hodnota "čas disku v %" je dôsledne nízka, označuje viazané na Procesor štátu.
  • Pri spustení dotazu ak CPU graf je dôsledne nízka (pre napríklad menej ako 50 percent), a "čas disku v %" je dôsledne vysoká, označuje, I/O viazané štátu.
  • Porovnajte CPU graf s štatistiky IO informácie.

Záver

SQL Server je schopný veľmi vysokej výkonnosti na veľkých databáz. To je najmä v prípade SQL Server 6.0. Aby sa dosiahol tento výkon potenciál, musíte použiť účinné databázy, index, dotaz a uplatňovanie dizajn. Tieto oblasti sú najlepších kandidátov na získanie významné zlepšenie výkonu. Skúste to, aby každý dotaz čo najúčinnejšie, Takže keď vaša žiadosť váhy pre viacerých používateľov, kolektívnej viacerými používateľmi zaťaženie je preukázateľných. Štúdiu o uplatňovaní správanie klienta dotazy predložilo žiadosť a experimentovanie s indexy pomocou usmernenia v tomto dokumente sa dôrazne odporúča. Úrka prístup v analýze problémov s výkonom prinesie často významné Zlepšovanie investovania relatívne málo času.

Vlastnosti

ID článku: 110352 - Posledná kontrola: 10. októbra 2011 - Revízia: 2.0
Informácie v tomto článku sa týkajú nasledujúcich produktov:
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
Kľúčové slová: 
kbinfo kbother kbmt KB110352 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:110352
Upozornenie na neaktuálny obsah článku databázy KB
Tento článok obsahuje informácie o produktoch, pre ktoré spoločnosť Microsoft už neposkytuje technickú podporu. Z tohto dôvodu je tento článok publikovaný ako nezmenený a už nebude aktualizovaný.

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