Soubor INF: Optimalizace výkonu Microsoft SQL Server

Důležité: Tento článek byl přeložen pomocí software společnosti Microsoft na strojový překlad, ne profesionálním překladatelem. Společnost Microsoft nabízí jak články přeložené překladatelem, tak články přeložené pomocí software na strojový překlad, takže všechny články ve Znalostní databázi (Knowledge Base) jsou dostupné v češtině. Překlad pomocí software na strojový překlad ale není bohužel vždy dokonalý. Obsahuje chyby ve skloňování slov, skladbě vět, nebo gramatice, podobně jako když cizinci dělají chyby při mluvení v češtině. Společnost Microsoft není právně zodpovědná za nepřesnosti, chyby nebo škody vzniklé chybami v překladu, nebo při použití nepřesně přeložených instrukcí v článku zákazníkem. Společnost Microsoft aktualizuje software na strojový překlad, aby byl počet chyb omezen na minimum.

Projděte si také anglickou verzi článku:110352
Tento článek byl archivován. Je nabízen v takovém stavu, v jakém je, a nebude již nadále aktualizován.
Souhrn
Chcete-li co nejefektivněji optimalizovat výkon Microsoft SQL Server, musíteidentifikovat oblasti vytvářející největší zvýšení výkonu nadširokou škálu situací a fokus analýzy v těchto oblastech.V opačném případě může výdajů významné času a úsilí o tématech, které mohounepřinese lze upravovat velikost vylepšení.

Z větší části neřeší následující informaceproblémy s výkonem, vyplývající z víceuživatelském souběžnosti. Jedná sesamostatné, složité téma, které jsou obsaženy v dokumentu "maximalizaciKonzistence a souběžnosti, databáze", které najdete v serveru SQL Serververze 4.2 x "Programmer's Reference C" Dodatek E a také v ostatníchČlánky znalostní báze Knowledge Base. Není v dokumentaci verze 6.0, alese nachází na disku CD-ROM MSDN (Microsoft Developer Network) na základě tétonadpis.

Místo teoretických diskusí soustředí se především naoblasti, které má let zkušeností týmem pro podporu Microsoft SQL ServerZobrazí se praktické hodnoty v reálném světě situacích.

Zkušenosti ukazují, že může být největší výhody ve výkonu serveru SQL Serverzískané z obecných oblastech návrh logické databáze, návrh rejstříkunávrh dotazu a návrhu aplikace. Naopak největší výkonproblémy jsou často způsobeny nedostatky v těchto oblastech stejná. Pokud jstedotyčné s výkonem, se mělo soustředit na tyto oblasti nejprveprotože se často dosáhnout zlepšení výkonu velmi velkérelativně malé časové investice.

Při výkonu jiné úrovni systému problémy, například paměti, mezipaměť, vyrovnávací pamětihardware atd., jsou jistě kandidáty studie, zkušenostiZobrazuje výkon zisk z těchto oblastí je často přírůstkové. SQLServer automaticky spravuje dostupné hardwarové prostředky pro nejčastějičást, snižuje potřebu (a tedy ve prospěch) z rozsáhléOptimalizace ručička na úrovni systému.

Microsoft SQL Server 6.0 obsahuje nové příležitosti pro platformu vrstvyzlepšení výkonu s velkým množstvím paměti, symetrickévíce procesy a data paralelní prohledávání, vylepšení optimalizace diskuprokládání. Stejně velká jako tato vylepšení jsou, jsou však omezené vrozsah. Nejrychlejší počítač lze bogged s neefektivní dotazy nebonevhodně navržená aplikace. Proto i další výkonzvýšíte, že SQL Server 6.0 umožňuje, je velice důležité, optimalizacedatabáze, index, dotaz a navrhování aplikací.

Většina problémy s výkonem, nemůže být úspěšně vyřešen s pouzezaměření na straně serveru. Server je v podstatě "puppet" klienta,Ovládací prvky, které jsou odesílány dotazy, co a jaké zámky jsou získanéa vydané. Přestože některé optimalizace je možné na straně serveruobvykle závisí úspěšné řešení potíží s výkonemna UZNÁVAJÍCE rozhodující roli klienta hraje problém aanalýza chování klientské aplikace.
Další informace
Následují některé návrhy, které na základě koncového uživatele, předánívýrazný nárůst výkonu:

Normalizovat logický návrh databáze

Přiměřené normalizace návrhu logické databáze dává nejlepšívýkon. Větší počet úzký tabulek je charakteristikanormalizované databáze. Nižší počet široké tabulky je charakteristikaNenormalizovaná databáze. Rutinně souvisí vysoce normalizované databázepomocí komplexní relační spojení, které se můžete zranit výkonu. Však SQLOptimalizátor serveru je velmi efektivní při výběru rychlé a efektivní spojení, jakodlouhý jako účinné indexy jsou k dispozici.

Výhody normalizace patří:
  • Vytváření třídění a indexu zrychlí, protože tabulky jsou užší.
  • Umožňuje více seskupených indexů, protože existuje více tabulek.
  • Indexy mají tendenci být užší a kompaktnější.
  • Méně indexů pro tabulku, pomáhá aktualizace výkonu.
  • Méně hodnoty Null a méně redundantních dat, zvýšení Hutnost databáze.
  • Zmenšuje souběžnosti dopadu DBCC diagnostiky, protože nezbytné Tabulka zámky ovlivní méně dat.
Se serverem SQL Server často přiměřené normalizace pomáhá spíše než škodí jakvýkon. Jako normalizace zvyšuje, ovlivníte počet a složitostspojení je nutný k načtení dat. Jako surové pravidlem, Microsoftnabídne provozující proces normalizace, pokud to způsobí, že mnohodotazy, které mají větší nebo Čtyřsměrná spojení.

Pokud je návrh logické databáze již pevné a celkový vzhled neníTo je proveditelné, je možné selektivně normalizuje velké tabulce, pokudanalýza ukazuje problémové místo na této tabulce. Pokud je přístup k databázivedeny prostřednictvím uložených procedur, tato změna schématu nelze uskutečnitbez dopadu aplikací. Pokud není, je možné skrýtZměňte vytvořením zobrazení, který vypadá jako jediné tabulky.

Použít návrh účinného rejstříku

Na rozdíl od mnoha systémů-relační nejsou považovány za relační indexyčást návrhu logické databáze. Možné ztrátě indexů, přidali, azměnit bez ovlivnění návrhu databáze schématu nebo aplikace v libovolnémzpůsob jiných než výkon. Návrh účinného rejstříku je prvořadá vdosažení dobrý výkon serveru SQL Server. Z těchto důvodů byste měli neníváhání experimentovat s různými indexy.

Optimalizátor spolehlivě vybere nejúčinnější index ve většiněpřípady. Celkové strategie návrhu indexu by mělo být poskytování zbožíVýběr indexů pro optimalizaci a důvěřujete mu, aby právorozhodnutí. Tím se sníží čas analýzy a poskytuje dobrý výkon přes širokéřadě situací.

Index návrhu doporučení jsou následující:
  • Přezkoumá klauzuli WHERE dotazů SQL, protože se primární zaměření optimalizaci.

    Každý sloupec uvedený v klauzuli WHERE je možné kandidáta pro index. Máte-li příliš mnoho dotazů zkoumat, vyberte zástupce nastavení, nebo pouze ty pomalé. Pokud vývoj nástroj transparentně generuje kód SQL, je obtížnější. Mnoho těchto nástrojů Povolit protokolování generované syntaxe SQL do souboru nebo na obrazovce účely ladění. Chcete-li zjistit od dodavatele na nástroj Tato funkce je k dispozici.
  • Použití úzká indexy.

    Úzký indexy jsou často efektivní než sloučenina multicolumn, indexy. Úzký indexy mít více řádků na stránce a méně index úrovně, zvýšení výkonu.

    Optimalizátor můžete rychle a efektivně analyzovat stovky nebo dokonce tisíce, index a spojení možností. S větším počtem úzký indexů poskytuje optimalizace s více možností výběru které obvykle pomůže výkonu. S méně široký, multicolumn indexy poskytuje optimalizace s méně možností na výběr, výkon, který může zranit.

    Je často vhodné strategie zdůraznění plně kryté nepřijmout dotaz. Je PRAVDA, pokud se týká všech sloupců v klauzuli SELECT seskupeného indexu optimalizátor může rozpoznat to a poskytují velmi dobrý výkon. Však často výsledkem je příliš široký. indexy a využívá příliš možnost, že bude Optimalizátor Pomocí této strategie. Obvykle byste měli použít více četné úzký indexy přes širší rozsah dotazů, které často poskytují lepší výkon.

    Není nutné další indexy, než je nezbytné pro dosažení přiměřené čtení výkonu z důvodu potřebného v těch aktualizace indexy. I většina operací orientované na aktualizaci vyžadovat mnohem více čtení než psaní. Proto není váhání vyzkoušet nový index, pokud domníváte, že vám pomůže; můžete vždy přetáhnout ji později.
  • Použití seskupených indexů.

    Vhodné použití seskupených indexů může dramaticky zvýšit. výkon. Operace i UPDATE a DELETE zrychlit indexy clusteru, protože tyto operace vyžadují mnohem čtení. A je povolen jeden seskupený index za tabulku, tak použijte tento index s rozvahou. Dotazy, které vracejí mnoho řádků nebo dotazy týkající se oblasti hodnoty, jsou vhodnými kandidáty pro akceleraci podle seskupený index.

    Příklady:
          SELECT * FROM PHONEBOOK      WHERE LASTNAME='SMITH'      -or-      SELECT * FROM MEMBERTABLE      WHERE  MEMBER_NO > 5000       AND MEMBER_NO < 6000						
    Naopak jsou výše uvedené sloupce Příjmení nebo MEMBER_NO pravděpodobně nejsou vhodní kandidáti na-seskupeného indexu je-li tento typ dotaz je běžné. Zkuste použít neseskupené indexy na sloupcích kde několik řádky jsou vráceny.
  • Zkontrolujte jedinečnost sloupce.

    Pomůže vám rozhodnout, jaké sloupce je kandidát pro seskupeného indexu seskupeného indexu nebo žádný index.

    Dotaz například zkontrolovat jedinečnost sloupce je následující:
          SELECT COUNT (DISTINCT COLNAME)      FROM TABLENAME						
    Tento příkaz vrátí počet jedinečných hodnot ve sloupci. Toto porovnání Celkový počet řádků v tabulce. Na 10 000 řádků tabulky, 5000 Jedinečné hodnoty by vytvořit sloupec vhodná pro neseskupené index. V téže tabulce 20 jedinečných by lépe vyhovovala clusteru index. Nemá být indexován na všech tří jedinečných hodnot. Jedná se pouze Příklady, není pevný a rychlé pravidla. Nezapomeňte umístit indexy jednotlivé sloupce uvedené v klauzulích WHERE dotazů.
  • Prozkoumejte distribuci dat v indexovaných sloupců.

    Dlouho běžící dotaz často dochází, protože sloupec s málo jedinečný indexované hodnoty nebo je provedena spojení na sloupce. Jedná se Základní problém s daty a v samotném dotazu a obvykle nelze bez identifikující tuto situaci vyřešit. Například fyzického Telefonní adresář řazen abecedně podle příjmení není urychlení. Vyhledání osoby v případě, že všechny osoby ve městě jsou pojmenovány stejně "Novák" nebo "Novák. Vedle výše uvedených dotazu, který dává jeden údaj pro jedinečnost sloupce, můžete dotaz Group zobrazit data rozdělení indexované hodnoty klíče. To poskytuje vyšší Obrázek s rozlišením údajů a lepší perspektivy pro jak na Optimalizace zobrazení data.

    Následující dotaz například prozkoumat distribuci dat je indexované hodnoty klíče, za předpokladu, že ve sloupci Sloupec1, Sloupec2 dvěma sloupci klíče:
          SELECT COL1, COL2, COUNT(*)      FROM TABLENAME      GROUP BY COL1, COL2						
    Tento postup vrátí jeden řádek pro každou hodnotu klíče, s počtem Chcete-li zobrazit instance každé hodnoty. Chcete-li omezit počet vrácených řádků, může být vhodné vyloučit některé s klauzule HAVING. Například klauzule
          HAVING COUNT(*) > 1						
    vyloučí všechny řádky, které mají jedinečný klíč.

    Počet řádků vrácených dotazem je také důležitým faktorem Výběr indexu. Optimalizátor domnívá-seskupeného indexu na náklady nejméně jedna stránka I/O na vrácených řádků. Při této rychlosti se rychle stane efektivnější prohledávat celou tabulku. Toto je dalším důvodem pro omezit velikost sady výsledků nebo vyhledejte velký výsledek se Seskupený index.
Není vždy vyrovnat použití indexu s dobrý výkon a naopak.Pokud použití indexu vždy nejlepší výkon, optimalizátor 'sÚloha bude velmi jednoduché - vždy používat libovolný dostupný index. Ve skutečnosti,Velmi špatný výkon může způsobit nesprávné volbě indexovaných načítání.Proto optimalizace je úkol vyberte indexovaných načítání kde budouvýkon i vyhnout indexovaných načítání, kde bude zranitvýkon.

Návrh účinného dotazu použít

Některé typy dotazů jsou ze své podstaty náročný. To souvisí sZákladní databáze a index problémy společné pro většinu relační databázesystémy správy (RDBMSs), konkrétně k serveru SQL Server. Nejsouneefektivní, protože provede Optimalizátor dotazů v nejvícemožné účinným způsobem. Jsou však náročná apovaha orientované na sadu SQL může provádět zobrazit neefektivní. Žádný stupeňOptimalizace logiky můžete vyloučit tyto náklady vlastní zdrojekonstrukce. Jsou vnitřně nákladné, ve srovnání s další jednoduchédotaz. Ačkoli SQL Server budete používat nejčastěji optimální plán přístup, jeCo je podstatně omezeno.

Například:
  • Velké výsledné sady
  • DO NOT IN a či dotazy
  • Vysoce nejedinečný klauzulí WHERE
  • ! = operátory porovnání (nerovná se)
  • Některé sloupce funkce, například SUMA
  • Převody výrazy nebo dat v klauzuli WHERE
  • Lokální proměnné v klauzuli WHERE
  • Komplexní zobrazení s Group
Různé faktory mohou vyžadovat použití některé z těchto informací v dotazu.Dopad těchto bude trh, pokud optimalizátor může omezitvýsledek nastavení před použitím prostředku intenzivní část dotazu. NaNásleduje několik příkladů.

Prostředky:
   SELECT SUM(SALARY) FROM TABLE				

Méně náročná:
   SELECT SUM(SALARY) FROM TABLE WHERE   ZIP='98052'				

Prostředky:
   SELECT * FROM TABLE WHERE   LNAME=@VAR				

Méně náročná:
   SELECT * FROM TABLE   WHERE LNAME=@VAR AND ZIP='98052'				

V prvním příkladu, nemůže být operace SOUČTU accelerated sindex. Každý řádek musí přečíst a sečteny. Za předpokladu, že je v indexusloupec ZIP Optimalizátor pravděpodobně použije to zpočátku omezit.Před použitím SOUČTU sady výsledků. To může být mnohem rychlejší.

V druhém příkladu lokální proměnná není přeložen do běhu.Však nelze Optimalizátor odložit volba přístup plán až do spuštěníčas; je nutné zvolit v čase kompilace. Ještě v době kompilace při přístupuplán je sestaven, hodnota @ VAR není známa a proto nemůže býtpoužívá jako vstup pro výběr indexu.

Ilustrované techniku pro zlepšení zahrnuje omezení výsledeknastavit s klauzulí AND. Alternativní techniky pomocí uložené procedury,a předá hodnotu pro @ VAR jako parametr uloženou proceduru.

V některých případech je vhodné použít skupinu jednoduchých dotazů pomocí dočasné tabulkyukládat průběžné výsledky než jediného dotazu velmi složité.

Velké výsledné sady jsou náročné na většině RDBMSs. Doporučujeme nevrátívelké výsledné nastavení klienta pro výběr konečného data procházení. Jehoje mnohem efektivnější omezit velikost výsledek nastavení, coždatabázový systém funkci, pro kterou byl určen. Totaké snižuje síťové vstupně výstupní operace a další pak způsobí, že aplikacenasazení přes propojení pomalé vzdálené komunikace. Vylepšuje takésouvisející souběžný výkon jako aplikace změní směrem nahoru k víceuživatelé.

Použít efektivní navrhování aplikací

Roli, kterou hraje návrhu aplikace ve výkonu serveru SQL nelze.nadsadila. Místo obrázku v dominantní roli serveru je dalšís přesností na obrázku jako řídící subjekt a server jako klientapuppet klienta. Je zcela pod příkazem klienta SQL ServerPokud jde o typ dotazů, pokud jsou doručeny a jak jsou výsledkyzpracování. To zase má významný vliv na typ a trvánízámky, velikost I/O a CPU zatížení serveru a tedy zdavýkon je dobré nebo špatné.

Z tohoto důvodu je důležité pro správné rozhodování běhemfáze návrhu aplikace. Avšak i, když budete čelit problému výkonupomocí kompletních aplikací, kde zdánlivě změny klientské aplikacenemožné, nezmění základní faktory, které ovlivňujívýkon - totiž, že klient hraje rozhodující roli a mnohobez změn klienta nelze vyřešit potíže s výkonem.

S dobře navržených aplikací je podporující SQL Servertisíce uživatelů současně. S nevhodně navržená aplikace,Můžete dokonce nejvýkonnější server platforma bog s pouze několika málouživatelé.

Pomocí následující návrhy pro návrh aplikace klient poskytnedobrý výkon serveru SQL Server:
  • Pomocí sady výsledků malé. Načítání zbytečně velké výsledné sady (například tisíce řádků) pro procházení v klientském počítači přidá procesoru a I/O zatížení sítě, způsobí, že aplikace méně schopné vzdálené použití, a škálovatelnost s více uživateli, můžete omezit. Je lepší návrh aplikace na výzvu pro dostatečné vstup tak, že dotazy jsou předloženy, které generují sady výsledků mírné.

    Techniky návrhu aplikace, které usnadní to zahrnovat omezení použití zástupných znaků při vytváření dotazů, akreditivů určitých vstup pole a zákazem amatérsky dotazy.
  • Dbcancel() správně použijte v aplikacích knihovny DB-Library. Všechny aplikace v průběhu by mělo umožnit zrušení dotazu. Žádná aplikace by měla. přinutíte uživatele k restartování klientského počítače Zrušit dotaz. Není podle této zásady mohou vést k problémům s výkonem, které nelze vyřešit. Při použití dbcancel() by měla být vykonávána řádné péče Pokud jde o úroveň transakcí. Další informace naleznete následující článek znalostní báze Microsoft Knowledge Base:
    117143: Soubor INF: kdy a jak používat dbcancel() nebo sqlcancel()
    Nevzniká aplikací ODBC, pokud ODBC sqlcancel() slouží k volání.
  • Vždy zpracovat všechny výsledky na dokončení. Není návrh aplikace nebo použijte kompletních aplikací, který zastaví zpracovávání výsledné řádky bez zrušení dotazu. Tím bude obvykle vést k zablokování a pomalý výkon.
  • Vždy provádět časový limit dotazu. Nepovolit spuštění dotazů po neomezenou dobu. Proveďte příslušné knihovny DB-Library nebo ODBC vyžaduje nastavení časový limit dotazu. Do knihovny DB-Library to se provádí pomocí volání dbsettime() a ODBC s SQLSetStmtOption().
  • Nepoužívejte nástroj pro vývoj aplikace, který neumožňuje explicitní řídit příkazy SQL, které jsou odeslány na server. Ne použijte nástroj, který generuje transparentně příkazů SQL, které jsou založeny na vyšší úroveň objekty, pokud poskytuje klíčové funkce, jako je například dotaz zrušení časový limit dotazu a úplnou kontrolu transakční. Je často není možné udržovat dobrý výkon nebo řešení výkon problému generuje aplikace všechny sama o sobě "průhlednou SQL", protože to neumožňuje explicitní ovládání přes transakční a uzamčení problémy, které jsou kritické pro výkon Obrázek.
  • Nelze kombinovat, podporu rozhodování a online zpracování transakcí Dotazy (OLTP).
  • Navrhování aplikace ani kompletních aplikací, který vynutí použití uživatel restartování klientského počítače Zrušit dotaz. To může způsobit různé problémy s výkonem, které je obtížné vyřešit, protože možné osamocené připojení. Další informace naleznete následující článek znalostní báze Microsoft Knowledge Base:
    137983: Řešení potíží s připojením osamocené serveru SQL Server

Techniky analyzovat výkon

Může být tempting řešit problémy s výkonem výhradně v úrovni systémuOptimalizace výkonu serveru. Například kolik paměti typu souborusystém, počet a typ procesorů a tak dále. ZkušenostiMicrosoft SQL Server podpora ukázaly, že většina problémy s výkonemnelze vyřešit tímto způsobem. Musí být adresována analýzouaplikace, dotazy, aplikace odesílá do databáze, aTyto dotazy interakci s schématu databáze.

Nejprve izolujte, dotaz nebo dotazy, které jsou pomalé. Často zdá, žecelou aplikaci je pomalý, když jen několik dotazů SQL jsou pomalé.Obvykle není možné vyřešit problémy s výkonem bezrozdělení problém a izolace pomalé dotazy. Pokud máteVývojový nástroj, který transparentně generuje SQL použít všechny dostupnédiagnostické nebo režim ladění tohoto nástroje k zachycení generované SQL. V mnohafunkce trasování případech jsou k dispozici, ale které mohou být dokumentovány otevřeně.Obraťte se na technickou podporu pro aplikaci a zjistěte, zda trasováníexistuje funkce pro sledování příkazů SQL, které jsou generoványaplikace.

Pro nástroje pro vývoj aplikací používajících SQL vložený je to mnohemSQL je snazší - otevřeně viditelné.

Pokud vývoj nástroje nebo koncovým uživatelem aplikace neposkytuje trasovánífunkce, existuje několik alternativ:
  • Použít příznak trasování 4032 podle návodu v SQL Server 4.2 x "Průvodce odstraňováním potíží" a SQL Server 6.0 "Reference jazyka transact-SQL." To vám umožní sběr příkazů jazyka SQL Odeslat na server SQL došlo k chybě protokolu.
  • Sledování dotazů pomocí síťového analyzátoru, jako je například Microsoft Network Monitor, který je součástí serveru Systems Management Server.
  • U aplikací ODBC vyberte pomocí programu Správce ODBC trasování volání ODBC. Další informace v dokumentaci ODBC.
  • Klienta nástroj třetí strany, která zachycuje SQL na Knihovny DB-Library nebo ODBC vrstev. Příklad je inspektor SQL z modré Software zátok.
  • Použijte nástroj analysis SQLEye jako příklad Microsoft TechNet CD. Poznámka: SQLEye není podporována společnosti Microsoft Podpora.
Po pomalé dotazu je izolován, postupujte takto:
  • Podezřelé pomalé dotaz spustit v izolaci, například pomocí nástroje pro dotaz ISQL a ověřte, zda je pomalé. Často je vhodné spustit dotaz počítači serveru pomocí nástroje ISQL a místní potrubí a přesměrovat výstup do souboru. To pomáhá eliminovat komplikujícím faktory, jako například sítě a obrazovky I/O a výsledek ukládání do vyrovnávací paměti aplikace.
  • Pomocí nastavení vstupně-výstupní statistiky na zkoumat I/O, spotřebované v dotazu. Všimněte si počet logickou stránku vstupně-výstupních. Cílem optimalizace Minimalizujte počet I/O. Nastavit záznam logické I/O Count. Tím se vytvoří Směrný plán proti na zlepšení měření. Je často účinného soustředění výhradně na výstupu IO statistiky a Experimentujte s různými typy dotazů a index než nastavení SHOWPLAN ON. Interpretace a efektivní použití výstupu SHOWPLAN mohou vyžadují některé studie a mohou spotřebovat čas, který může být efektivnější stráví empirické zkoušky. Pokud problém výkonu nejsou opraveny. Tyto jednoduché doporučení a pak můžete SHOWPLAN více Optimalizace chování důkladně prozkoumejte.
  • Pokud dotaz zahrnuje zobrazení nebo uloženou proceduru, extrahujte z dotazu zobrazení nebo uloženou proceduru a spustit samostatně. Díky tomu přístup k plánu změnit při experimentování s různými indexy. Je také pomáhá lokalizovat problém do dotazu, a jak optimalizace zpracovává, zobrazení nebo uložené procedury. Jestliže problém není v dotazu samotným, ale pouze při dotaz je spuštěn jako součást zobrazení nebo uložené Postup spuštění dotazu sám vám pomohou určit, to.
  • Být vědomi možných aktivační události související tabulky, které lze jako aktivační událost spustí, transparentně generovat I/O. Je třeba odebrat všechny aktivační události účastní pomalejší dotaz. To pomáhá zjistit, zda problém je v dotazu samotném nebo aktivační události nebo zobrazení a proto pomáhá přímé fokus.
  • Zkontrolujte indexy tabulek použitých v dotazu pomalé. Použít dříve uvedené techniky k určení, pokud se jedná o kvalitní indexy a v případě, že je nezbytné změny. Jako první úsilí zkuste indexování sloupce v klauzuli WHERE. Často problémy s výkonem způsobené jednoduše není s sloupec v klauzuli WHERE indexovaných nebo bez nutnosti užitečná index sloupce.
  • Použití dotazů, bylo zmíněno dříve, zkontrolovat jedinečnost dat a rozdělení pro každý sloupec uvedený v klauzuli WHERE a zvláště pro každý indexovaný sloupec. V mnoha případech jednoduché inspekce dotaz, tabulky, indexy a data okamžitě zobrazí problém Příčina. Například problémy s výkonem jsou často způsobena Index klíče pouze tři nebo čtyři jedinečné hodnoty nebo provádění SPOJENÍ na sloupce nebo vrácením nadměrný počet řádků klient.
  • Na základě této studie, na žádost, provést potřebné změny dotazu nebo indexy. Spustit dotaz znovu po provedení změn a dodržovat jakákoli změna v počtu I/O.
  • Po zaznamenání zlepšení, spusťte hlavní aplikace v případě celkové je lepší výkon.
Zkontrolujte, zda program I/O nebo svázané procesoru chování. Je často užitečnéZjistěte, zda je dotaz I/O nebo procesoru vázán. To pomáhá zaměřit své zlepšeníúsilí na true problémové místo. Například pokud dotaz procesoru vázán,přidáním paměti serveru SQL Server se pravděpodobně zvýší výkon,protože více paměti pouze zlepšuje poměr přístupů do mezipaměti, což v tomto případějiž je vysoká.

Jak zkoumat chování I/O vs. vazbou procesoru dotazu:
  • Pomocí nástroje Sledování výkonu systému Windows NT do hodinek I/O versus aktivity procesoru. Sledovat všechny instance čítače z logický disk % času disku" objekt. Také sledovat "% celkem času procesoru" čítač systému objekt. Chcete-li zobrazit informace o výkonu platný disk, musíte mít nastavení systému Windows NT DISKPERF vydáním zapnuta dříve "diskperf -Y" z příkazového řádku a následným restartováním systému. Další informace v dokumentaci systému Windows NT.
  • Při spuštění dotazu, je-li graf procesoru je neustále vysoké (pro například vyšší než 70 %), a hodnota "% čas disku" stále nízká, označuje stav procesoru vazbou.
  • Při spuštění dotazu, je-li graf procesoru je důsledně nízké (pro například méně než 50 procent), a "% času disku je důsledně Vysoká, znamená to že vázán I/O státu.
  • Porovnejte grafu CPU IO statistické informace.

Závěr

Je schopen velmi vysoký výkon v rozsáhlých databází serveru SQL Server. To jezejména v případě SQL Server 6.0. K dosažení tohoto výkonupotenciál, je nutné použít efektivní databáze, index, dotaz a aplikacenávrh. Tyto oblasti jsou nejlepší kandidáty pro získání významnézlepšení výkonu. Zkuste provést každý dotaz jako co nejúčinnější,tak, aby při škálování aplikace více uživatelům, kolektivníVíceuživatelská zatížení je supportable. Studie chování aplikace klienta,dotazy, předložené žádosti a experimenty s indexyPokyny v tomto dokumentu jsou důrazně doporučujeme. Metodickýv analýze potíží s výkonem přístup povede často významnézlepšování investování relativně málo času.
sqlfaqtop optimalizace systému Windows NT 4.20 sql6

Upozornění: Tento článek je přeložený automaticky

Vlastnosti

ID článku: 110352 - Poslední kontrola: 12/04/2015 09:57:27 - Revize: 5.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 KbMtcs
Váš názor