INF: Optimalizácia Microsoft SQL Server výkonnosti

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
Tento článok bol archivovaný. Je publikovaný v aktuálnej podobe a už nebude aktualizovaný.
SUHRN
Najúčinnejšie optimalizovať Microsoft SQL Server, musíteurčiť oblasti, ktoré budú prinášajú najväčší výkonnosť sa zvyšuje počasnajš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ôžunie 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 jesamostatné, zložité tému, ktoré je obsiahnuté v dokumente "maximalizovaťDatabázy konzistentnosť a súbežnosti,"ktoré možno nájsť v SQL Serververzia 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, alemožno nájsť na MSDN (Microsoft Developer Network) CD podľa tohtotitul.

Skôr ako teoretické diskusiu, tento článok je zameraný predovšetkým naoblastí, ktorý má rokov skúseností tím technickej podpory spoločnosti Microsoft SQL Serverpreukáž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ýkonproblémy sú často spôsobené nedostatkami v týchto istých oblastiach. Ak stezaoberajú sa výkon, ste mali sústrediť na týchto oblastiach po prvé,preto často dá dosiahnuť veľký výkon zlepšeniarelatí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úsenostiukazuje, že výkon zisk z týchto oblastí je často prírastkové. SQLServer 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 vrstvavylepšenia výkonu s veľkým množstvom pamäte, symetrickéviacprocesové, paralelné údajov skenovanie, optimalizácia vylepšenia a diskuprekladanie. Tak veľká, ako sú tieto zlepšenia, sú však výlučné vrozsah. Najrýchlejší počítača môžete zabředly s neefektívne dotazy alebozle navrhnuté aplikácie. Teda aj s dodatočné výkonzvýšiť, že SQL Server 6.0 umožňuje, je nesmierne dôležité, aby optimalizovalidatabáza, index, dotaz a dizajnom aplikácie.

Väčšina problémov s výkonom nemožno úspešne vyriešiť lenserver-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ámkya 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 aanalýza chovanie aplikácie klienta.
DALSIE INFORMACIE
Nižšie sú uvedené niektoré návrhy, že na základe skúseností, prinieslizvýšenie významné výkonu:

Normalizovať logické návrhu databázy

Primerané normalizácia návrhu logické databázy výnosy najlepšievýkon. Väčší počet úzky tabuliek je charakteristická prenormalizovanú databáza. Menší počet širokej tabuľky je charakteristická preNenormalizované databáza. Vysoko normalizovanom databázy je bežne spojenés zložité relačnej spojenia, ktoré môže bolieť výkon. Avšak, SQLServer optimizer je veľmi efektívne pri výbere rýchle, efektívne spojenia, akodlho 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, Microsoftnavrhuje vykonávajúce procesu štandardizácie, pokiaľ to spôsobuje veľadotazy na štyroch-pásmový alebo väčšie spojenia.

Ak návrh logické databázy je už pevné a celkové redesign nie jeuskutočniteľné, je možné na selektívne normalizovať veľkej tabuľky, akanalýza ukazuje prekážkou v tejto tabuľke. Ak je prístup k databázevykoná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, azmenil bez ovplyvnenia schémy alebo uplatňovanie návrhu databázy v ktoromkoľvekspôsob iné ako výkon. Účinné indexom dizajn je rozhodujúci vdosiahnutie dobrý výkon servera SQL Server. Z týchto dôvodov by ste sa nemaliNeváhajte a experimentovať s rôznymi indexmi.

Optimalizácia spoľahlivo rozhodne najviac účinné indexom vo väčšineprípadoch. Celková stratégia dizajn indexu by malo byť poskytovať dobrývýber indexov na optimalizáciu, a dôvera ho tak, aby právorozhodnutie. 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 budepomô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í szákladné databázu a indexu problémov spoločný pre väčšinu relačnej databázyriadiace 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ý, asúbor orientovanú povahu SQL môžu ich zobraziť neefektívne vykonať. Žiadny stupeňOptimalizácia inteligencia vylúčiť náklady inherentné zdroj týchtokonš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 toobmedzená č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áciavýsledok nastaviť pred použitím prostriedku intenzívne časť dotaz. Vnižš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 sregister. Každý riadok musí prečítať a sčítajú. Za predpokladu, že je index nastĺ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ístupplá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ýsledokmnož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 tabuliekna 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átiveľké výsledok nastaviť klienta pre konečné údaje výber prehliadania. Toje oveľa účinnejšie obmedziť veľkosť výsledok nastaviť, ktoré umožniadatabázový systém vykonávať funkciu, na ktoré bolo určené. Tototiež 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 viacpoužívatelia.

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

Nemôže byť úlohu, ktorú zohráva dizajnom aplikácie SQL Server výkonnostinadhodnotené. Skôr ako obrázok server v dominantnú úlohu, je to viacpresný obraz klienta ako kontrolný subjekt a server akobábka klienta. SQL Server je úplne pod velením klientapokiaľ ide o typ dotazov, ak sú predložené a ako sú výsledkyspracované. To zasa má významný vplyv na typ a trvaniezámky, množstvo I/O a CPU načítať na serveri, a teda čivýkon je dobré alebo zlé.

Z tohto dôvodu je dôležité urobiť správne rozhodnutia počasuplatňovanie projektovej fáze. Avšak aj keď budete čeliť problému s výkonompomocou 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ýchtisí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árpouží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émuServer výkon tuning. Napríklad, koľko pamäte, typ súborusystém, počet a typ procesory a podobne. SkúsenostiMicrosoft SQL Server Support ukázali, že väčšina problémov s výkonomnie je možné vyriešiť týmto spôsobom. Musia byť adresované analyzovanímuplatňovanie, dotazy žiadosť predkladá databázy, aako tieto dotazy v interakcii s schéme databázy.

Po prvé, izolujte dotazu alebo dotazy, ktoré sú pomalé. Často sa javí, žecelej aplikácie je pomalé, keď len pár SQL dotazov sú pomalé.Zvyčajne nie je možné vyriešiť problém výkonu bezrozepisovat problém a izolovanie pomalé dotazov. Ak mátenástroj rozvoja, ktorý transparentne generuje SQL, použitie všetkých dostupnýchdiagnostické alebo debug režime tohto nástroja zachytiť generované SQL. V mnohýchprí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 stopyfunkcia existuje pre monitorovanie príkazy SQL generovanéaplikácia.

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

Ak rozvoj nástroj alebo koncového používateľa žiadosť neposkytuje stopyfunkciu, 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ípadeje 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 jenajmä v prípade SQL Server 6.0. Aby sa dosiahol tento výkonpotenciál, musíte použiť účinné databázy, index, dotaz a uplatňovaniedizajn. 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ívnejviacerými používateľmi zaťaženie je preukázateľných. Štúdiu o uplatňovaní správanie klientadotazy predložilo žiadosť a experimentovanie s indexypomocou usmernenia v tomto dokumente sa dôrazne odporúča. Úrkaprístup v analýze problémov s výkonom prinesie často významnéZlepšovanie investovania relatívne málo času.
4.20 sql6 Windows NT optimalizácia sqlfaqtop

Upozornenie: Tento článok bol preložený automaticky.

Vlastnosti

ID článku: 110352 – Posledná kontrola: 12/04/2015 09:57:34 – Revízia: 2.0

Microsoft SQL Server 4.21a Standard Edition, Microsoft SQL Server 6.0 Standard Edition, Microsoft SQL Server 6.5 Standard Edition

  • kbnosurvey kbarchive kbinfo kbother kbmt KB110352 KbMtsk
Pripomienky
ERROR: at System.Diagnostics.Process.Kill() at Microsoft.Support.SEOInfrastructureService.PhantomJS.PhantomJSRunner.WaitForExit(Process process, Int32 waitTime, StringBuilder dataBuilder, Boolean isTotalProcessTimeout)