Soubor INF: Optimalizace výkonu Microsoft SQL Server

Překlady článku Překlady článku
ID článku: 110352 - Produkty, které se vztahují k tomuto článku.
Rozbalit všechny záložky | Minimalizovat všechny záložky

Na této stránce

Souhrn

Chcete-li co nejefektivněji optimalizovat výkon Microsoft SQL Server, musíte identifikovat 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é mohou nepřinese lze upravovat velikost vylepšení.

Z větší části neřeší následující informace problémy s výkonem, vyplývající z víceuživatelském souběžnosti. Jedná se samostatné, složité téma, které jsou obsaženy v dokumentu "maximalizaci Konzistence a souběžnosti, databáze", které najdete v serveru SQL Server verze 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, ale se nachází na disku CD-ROM MSDN (Microsoft Developer Network) na základě této nadpis.

Místo teoretických diskusí soustředí se především na oblasti, které má let zkušeností týmem pro podporu Microsoft SQL Server Zobrazí 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 Server získané z obecných oblastech návrh logické databáze, návrh rejstříku návrh dotazu a návrhu aplikace. Naopak největší výkon problémy jsou často způsobeny nedostatky v těchto oblastech stejná. Pokud jste dotyčné s výkonem, se mělo soustředit na tyto oblasti nejprve protož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ěti hardware atd., jsou jistě kandidáty studie, zkušenosti Zobrazuje výkon zisk z těchto oblastí je často přírůstkové. SQL Server 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 vrstvy zlepšení výkonu s velkým množstvím paměti, symetrické více procesy a data paralelní prohledávání, vylepšení optimalizace disku prokládání. Stejně velká jako tato vylepšení jsou, jsou však omezené v rozsah. Nejrychlejší počítač lze bogged s neefektivní dotazy nebo nevhodně navržená aplikace. Proto i další výkon zvýšíte, že SQL Server 6.0 umožňuje, je velice důležité, optimalizace databá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 pouze zaměř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ě serveru obvykle závisí úspěšné řešení potíží s výkonem na UZNÁVAJÍCE rozhodující roli klienta hraje problém a analý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 charakteristika normalizované databáze. Nižší počet široké tabulky je charakteristika Nenormalizovaná databáze. Rutinně souvisí vysoce normalizované databáze pomocí komplexní relační spojení, které se můžete zranit výkonu. Však SQL Optimalizátor serveru je velmi efektivní při výběru rychlé a efektivní spojení, jako dlouhý 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í jak výkon. Jako normalizace zvyšuje, ovlivníte počet a složitost spojení je nutný k načtení dat. Jako surové pravidlem, Microsoft nabídne provozující proces normalizace, pokud to způsobí, že mnoho dotazy, 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, pokud analýza ukazuje problémové místo na této tabulce. Pokud je přístup k databázi vedeny prostřednictvím uložených procedur, tato změna schématu nelze uskutečnit bez dopadu aplikací. Pokud není, je možné skrýt Změň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, a změnit bez ovlivnění návrhu databáze schématu nebo aplikace v libovolném způsob jiných než výkon. Návrh účinného rejstříku je prvořadá v dosaž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ávo rozhodnutí. 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 budou výkon i vyhnout indexovaných načítání, kde bude zranit výkon.

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

Některé typy dotazů jsou ze své podstaty náročný. To souvisí s Základní databáze a index problémy společné pro většinu relační databáze systémy správy (RDBMSs), konkrétně k serveru SQL Server. Nejsou neefektivní, protože provede Optimalizátor dotazů v nejvíce možné účinným způsobem. Jsou však náročná a povaha orientované na sadu SQL může provádět zobrazit neefektivní. Žádný stupeň Optimalizace logiky můžete vyloučit tyto náklady vlastní zdroje konstrukce. 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, je Co 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 omezit výsledek nastavení před použitím prostředku intenzivní část dotazu. Na Ná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 s index. Každý řádek musí přečíst a sečteny. Za předpokladu, že je v indexu sloupec 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řístupu plán je sestaven, hodnota @ VAR není známa a proto nemůže být používá jako vstup pro výběr indexu.

Ilustrované techniku pro zlepšení zahrnuje omezení výsledek nastavit 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é tabulky uklá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í. Jeho je mnohem efektivnější omezit velikost výsledek nastavení, což databázový systém funkci, pro kterou byl určen. To také snižuje síťové vstupně výstupní operace a další pak způsobí, že aplikace nasazení 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íce už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 klienta puppet klienta. Je zcela pod příkazem klienta SQL Server Pokud jde o typ dotazů, pokud jsou doručeny a jak jsou výsledky zpracování. To zase má významný vliv na typ a trvání zámky, velikost I/O a CPU zatížení serveru a tedy zda výkon je dobré nebo špatné.

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

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

Pomocí následující návrhy pro návrh aplikace klient poskytne dobrý 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ému Optimalizace výkonu serveru. Například kolik paměti typu souboru systém, počet a typ procesorů a tak dále. Zkušenosti Microsoft SQL Server podpora ukázaly, že většina problémy s výkonem nelze vyřešit tímto způsobem. Musí být adresována analýzou aplikace, dotazy, aplikace odesílá do databáze, a Tyto dotazy interakci s schématu databáze.

Nejprve izolujte, dotaz nebo dotazy, které jsou pomalé. Často zdá, že celou aplikaci je pomalý, když jen několik dotazů SQL jsou pomalé. Obvykle není možné vyřešit problémy s výkonem bez rozdělení problém a izolace pomalé dotazy. Pokud máte Vý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 mnoha funkce 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ány aplikace.

Pro nástroje pro vývoj aplikací používajících SQL vložený je to mnohem SQL 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 je zejména v případě SQL Server 6.0. K dosažení tohoto výkonu potenciál, je nutné použít efektivní databáze, index, dotaz a aplikace ná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 indexy Pokyny 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.

Vlastnosti

ID článku: 110352 - Poslední aktualizace: 23. dubna 2011 - Revize: 5.0
Informace v tomto článku jsou určeny pro produkt:
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
Klíčová slova: 
kbinfo kbother kbmt KB110352 KbMtcs
Strojově přeložený článek
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
Právní omezení pro obsah znalostní báze týkající se produktů, jejichž podpora byla ukončena
Tento článek byl napsán o produktech, pro které společnost Microsoft již neposkytuje nadále podporu. Článek je tedy nabízen v takovém stavu, v jakém je, a nebude již nadále aktualizován.

Dejte nám zpětnou vazbu

 

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