sql >> Databáze >  >> RDS >> Sqlserver

Zlepšete ladění výkonu SQL Server pomocí těchto 3 tipů

Jak každý, kdo spravuje databáze, moc dobře ví, ladění výkonu SQL Serveru je klíčovou funkcí pro zajištění optimálního výkonu. Vzhledem k tomu, že výkon závisí na různých faktorech, jako je paměť, konfigurace, návrh dotazů a využití zdrojů, není izolování hlavní příčiny snížení výkonu žádný malý úkol.

Namísto čekání na problémy s výkonem, proaktivní ladění SQL Serveru zajistí, že vaše příkazy SQL budou fungovat co nejefektivněji tím, že SQL pomůže najít nejrychlejší cestu dovnitř a ven, aby poskytl výsledky vašeho dotazu.

Pokud se potýkáte s pomalým výkonem – nebo nejste z těch, kteří jen čekají, až se vyskytnou problémy – zde jsou tři klíčové oblasti, na které byste měli zaměřit ladění výkonu SQL Serveru, abyste dosáhli optimálního výkonu a zdravějších systémů.

Tip #1:Optimalizujte svou TempDB

Nesprávně nakonfigurovaná TempDB je běžným viníkem při pohledu na snížení výkonu. Pokud často plníte TempDB, je čas podívat se, co je potřeba změnit.

Nejprve se podívejte na velikost TempDB. Neexistuje žádné pevné pravidlo o tom, jak velká by měla být, ale dobrým pravidlem je udržovat TempDB na 25 procentech vaší největší databáze nebo na stejné velikosti jako váš největší index. To zabraňuje nutnosti zvyšovat TempDB během přestaveb.

U TempDB platí, že čím rychlejší disk, tím lepší. Když je TempDB umístěn na pomalý disk nebo stejný disk jako operační systém, určitě zaznamenáte problémy s výkonem databáze. Pokud je to možné, ponechejte TempDB na vyhrazeném místním SSD. Pokud to není možné, další nejlepší možností je ponechat jej na vlastním vyhrazeném svazku s dostatečným předem přiděleným místem na disku.

Je také důležité uchovávat data a soubory protokolů odděleně a nastavit velkou pevnou hodnotu pro automatický růst TempDB. V opačném případě budete mít zbytečnou režii pokaždé, když se TempDB zaplní.

Řízení počtu datových souborů TempDB přispívá k optimalizaci TempDB. Ale velkou otázkou je, kolik datových souborů TempDB potřebujete? V ideálním případě budete mít jeden datový soubor TempDB pro každý logický CPU, ale ne více než osm celkem (až na některé výjimky). Pokud máte například čtyři logické CPU, potřebujete čtyři datové soubory TempDB. Pokud máte 12 logických CPU, můžete mít osm datových souborů TempDB.

Tip č. 2:Předcházejte překážkám výkonu

Existují tři hlavní typy omezení výkonu serveru SQL Server, které přispívají ke slabému výkonu:CPU, paměť a I/O. Příčiny, příznaky a diagnostika se liší podle typu úzkého hrdla, takže zde je stručný návod, na co si dát pozor:

Úzká místa CPU

Příčina: Nedostatečné hardwarové zdroje

Příznaky: Trvale vysoké využití procesoru

Metriky ke sledování:  % času procesoru, dávkové požadavky/s, kompilace SQL/s a rekompilace SQL/s

Úzká místa paměti

Příčina:  Omezení dostupné paměti a tlaku paměti způsobené SQL Serverem, systémem nebo jinou aktivitou aplikace

Příznaky:  Pomalá odezva aplikací, celkové zpomalení systému a pády aplikací

Metriky ke sledování:  Dostupná paměť (KB), Celková paměť serveru (KB), Cílová paměť serveru (KB), Stránky/s, Stránky kontrolního bodu/s, Líné zápisy/s a Poměr přístupů k vyrovnávací paměti

Úzká místa I/O

Příčina:  Nadměrné čtení a zápis databázových stránek z a na disk

Příznaky: Dlouhé doby odezvy, zpomalení aplikací a časové limity úloh

Metriky ke sledování:  Průměrná délka diskové fronty, průměrná disková sec/čtení, průměrná disková sec/zápis, % času na disk, průměrná čtení z disku/s a průměrný zápis na disk/s

Tip #3:Ujistěte se, že jsou indexy správně navrženy

Indexy jsou skvělým způsobem, jak urychlit určité operace serveru SQL Server, ale pouze v případě, že jsou dobře navrženy. Špatně navržené indexy mají opačný efekt a představují jistý způsob, jak snížit výkon vašeho SQL Serveru.

Správné nastavení těchto čtyř oblastí může pomoci zajistit, že indexy jsou správně navrženy a pomáhají spíše než zhoršovat výkon SQL Serveru.

Velikost tabulky

Ne každá tabulka je vhodným kandidátem na indexování. Ve skutečnosti, pokud je tabulka příliš malá, je pro SQL Server mnohem efektivnější prohledávat celou tabulku než prohledávat indexy. U velkých tabulek je tomu samozřejmě naopak, takže při rozhodování, které tabulky by indexy prospěly, musíte zvážit potenciální režii.

Typy indexů

Technicky vzato může mít každá databázová tabulka jeden seskupený index a nekonečný počet neshlukovaných indexů, ale víte, co se říká o „Jen proto, že něco dokážeš“…

Příliš mnoho neseskupených indexů může výrazně zpomalit operace vkládání a aktualizace, takže držet se jednoho seskupeného indexu a minimálního počtu absolutně nezbytných neshlukovaných indexů je mnohem lepší návrhová volba.

Indexové úložiště

Během fáze návrhu je výběr správných kritérií úložiště pro indexy zásadní pro výkon I/O. Dělené seskupené indexy a indexy bez klastrů mohou být uloženy ve stejné skupině souborů jako hlavní tabulka nebo mohou být uloženy v jiné skupině souborů. Uložení neklastrovaného indexu do skupiny souborů umístěné na jiné diskové jednotce může zlepšit výkon dotazů, které jej používají, protože není ovlivněno souběžným čtením dat a stránek indexu SQL, ke kterému dochází na různých diskových jednotkách.

FILLFACTOR

FILLFACTOR určuje procento místa, které bude vyplněno na každé datové stránce při vytváření indexu. Hodnoty FILLFACTOR se mohou pohybovat od 0 procent (není vyplněna žádná datová stránka) do 100 procent (datová stránka je zcela vyplněna). Při navrhování indexu vyberte hodnotu FILLFACTOR, která optimalizuje využití stránky a zároveň minimalizuje riziko nadměrné fragmentace indexu.

Začlenění ladění výkonu SQL Server do vaší standardní rutiny je skvělý způsob, jak zajistit, aby vaše databáze běžely na maximální výkon. Začleněním těchto tří jednoduchých kroků do vašich pravidelných plánů údržby SQL Serveru se výrazně zvýší rychlost a výkon vašich uživatelů.


  1. Soulad s PCI pro MySQL a MariaDB s ClusterControl

  2. Zadanému názvu a typu argumentu neodpovídá žádný operátor. Možná budete muset přidat explicitní přetypování. -- Netbeans, Postgresql 8.4 a Glassfish

  3. Jak EXTRACT() funguje v MariaDB

  4. Oracle Floats vs Number