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

4 klíčové aktivity monitorování databáze, které by měl znát každý správce databáze

DBA hrají v organizaci zásadní roli. Jako správci dat jsou zodpovědní za správu všech aspektů výkonu databáze, včetně vysoké dostupnosti, rychlého zpracování dotazů, zmírňování rizik a obnovy po havárii. Kromě toho jsou správci databází odpovědní za obchodní cíl údržby databází organizace s ohledem na návratnost investic a úspory nákladů.

Se všemi různými klobouky, které nosí, musí DBA pracovat efektivně a efektivní řízení času je jejich nejlepším přítelem. Nejlepším způsobem, jak dosáhnout efektivity, je zaměřit se nejprve na klíčové činnosti, které pomohou udržet optimální výkon databází.

Zde jsou čtyři aktivity monitorování databází, které by měly být na prvním místě seznamu „musí vědět“ každého DBA.

Jak (a proč) upravit výchozí nastavení v SQL Server

Mnoho správců databází provozuje SQL Server tak, jak je, přímo po vybalení. Výchozí konfigurace však nejsou vždy tou nejlepší volbou z hlediska zabezpečení nebo výkonu. Databáze každé organizace se liší a splňují různé obchodní potřeby, takže je logické, že ne každá databáze je nakonfigurována stejným způsobem.

V závislosti na vašich konkrétních databázových potřebách a preferencích existuje několik výchozích nastavení SQL Serveru, která můžete chtít změnit:

  • Faktor vyplnění:Pokud vytvoříte index bez určení hodnoty faktoru vyplnění, výchozí hodnota je 0. To znamená, že se stránka zaplní do posledního místa a jakékoli vložení, odstranění nebo aktualizace mohou způsobit nadměrné rozdělení a fragmentaci stránky.

    Neexistuje žádná univerzálně „správná“ hodnota faktoru plnění, ale 80-90 je normálně bezpečná volba. Tento rozsah hodnot umožňuje zaplnění 80–90 procent stránky, přičemž 10–20 procent zůstává volných.
  • Práh nákladů pro paralelismus:Prahová hodnota nákladů pro paralelismus je hodnota, při které stroj SQL Server spustí paralelní plány pro vaše dotazy. Výchozí hodnota je pět sekund, ale tato hodnota je poměrně nízká a mohla by vytvořit spoustu zbytečně složitých dotazů, což negativně ovlivní výkon.

    Začněte s nastavením 20 sekund a upravte podle potřeby na základě čekání CXPACKET a využití procesoru.
  • Automatický růst databázového souboru:Autogrowth je proces, ke kterému dochází, když stroj SQL Server zvětší velikost databázového souboru, když je nedostatek místa. Jak moc soubor roste, je standardně nastaveno na 1 MB pro datové soubory a 10 procent pro soubory protokolu transakcí.

    Každá databáze poroste různým tempem, takže odhadněte, jak moc si myslíte, že databáze poroste, a podle toho nastavte hodnotu.
  • Model obnovy databáze:Výchozí model obnovy je FULL po vybalení, ale není účinný pro všechny databáze.

    Změňte nastavení na SIMPLE pro databáze, které nejsou kritické, a ponechte nastavení na FULL pouze pro vysoce rizikové produkční databáze.
  • Max. paměť serveru:Výchozí hodnota je 2 TB, což znamená, že SQL Server přiděluje veškerou paměť z operačního systému. Operačnímu systému tak nezůstane žádná paměť k použití.

    Upravte nastavení tak, abyste maximalizovali množství paměti dostupné pro proces SQL Server, ale v případě potřeby ponechte trochu na operační systém.
  • Maximální stupeň paralelismu (MAXDOP):MAXDOP řídí, kolik procesorů se použije pro provedení dotazu v paralelním plánu. Výchozí hodnota je 0, což znamená, že SQL Server určí, kolik procesorů může použít. Pokud necháte prahovou hodnotu pro paralelismus na výchozí hodnotě 5, můžete skončit s využitím všech CPU pro každý dotaz.

    Ideální nastavení MAXDOP se bude lišit v závislosti na vašem konkrétním systému, ale Microsoft zde nabízí několik návrhů.
  • Komprese zálohy:Výchozí nastavení této funkce je VYPNUTO. Komprese záloh však urychluje operace zálohování databáze a vytváří menší soubory zálohy, takže ji možná budete chtít zapnout.

Jeden tip na závěr pro úpravu nastavení SQL Serveru z výchozích hodnot:Po změně jakýchkoli nastavení vždy důkladně otestujte systém, abyste se ujistili, že nedošlo k neúmyslnému zavedení problémů.

Jak odstranit překážky serveru SQL Server

Úzká místa SQL Serveru jsou běžným zdrojem problémů s výkonem, včetně zatěžování procesoru SQL Serverem, dlouhých časů provádění dotazů, nadměrného I/O a extrémní aktivity na discích.

Existuje mnoho jiných než úzkých míst, proč se u vaší databáze mohou vyskytnout tyto problémy s výkonem, ale pokud problém pramení z úzkých míst SQL Serveru, pravděpodobně budou ovlivněny tři hlavní oblasti:paměť, I/O a CPU.

Úzká místa paměti jsou způsobena nedostatečnými paměťovými prostředky nebo aktivitami serveru SQL Server využívající příliš mnoho dostupné paměti. Dávejte pozor na delší doby provádění dotazů, nadměrné I/O, zprávy o nedostatku paměti v protokolu aplikace a časté pády systému.

K I/O úzkým místům dochází, když není k dispozici dostatek úložiště pro podporu běžných databázových operací, jako je tempDB. Dávejte pozor na dlouhé doby odezvy, zpomalení aplikací a časté vypršení časového limitu úkolů.

Problémová místa CPU jsou způsobena nedostatečnými hardwarovými prostředky. V monitorování databáze vyhledejte data protokolu, která ukazují, že SQL Server využívá nadměrné množství CPU.

Jak zabránit růstu tempDB

TempDB je dočasný pracovní prostor v instancích SQL Server používaný k vytváření a udržování přechodných a dočasných objektů. TempDB je jedním z nejaktivnějších zdrojů v prostředí SQL Server, takže je důležité sledovat a kontrolovat nadměrný růst tempDB.

TempDB se v rámci instance používá často, protože se používá k ukládání uživatelských objektů, interních objektů a úložišť verzí. Nadměrný růst tempDB může způsobit problémy s výkonem, takže je důležité sledovat velké dotazy, dočasné tabulky a proměnné tabulky, které využívají velké množství místa na disku tempDB.

Chcete-li optimalizovat velikost a růst tempDB, společnost Microsoft doporučuje následující doporučené postupy:

  • Nastavte model obnovy tempDB na SIMPLE
  • Povolit automatický růst souborů tempDB podle potřeby
  • Nastavte přírůstek růstu souboru na přiměřenou velikost, abyste zabránili růstu souborů databáze tempDB o příliš malou hodnotu.
  • Předem přidělte prostor pro všechny soubory tempDB nastavením velikosti souboru na hodnotu dostatečně velkou, aby vyhovovala typické zátěži v prostředí
  • Nastavte každý datový soubor stejně velký

Velikost a parametry růstu datových souborů tempDB můžete upravit pomocí SQL Server Management Studio.

Jak vypočítat celkové náklady na vlastnictví

I když možná nestrávíte spoustu času přemýšlením o rozpočtu vaší společnosti, raději věřte, že finanční ředitel ano. Když je čas požádat o novou technologii sledování výkonu, je chytré přijít s pevnými daty pro zálohování vašeho požadavku.

Jedním z nejvlivnějších údajů, které můžete prezentovat, jsou potenciální celkové náklady na vlastnictví (TCO) nové technologie oproti vašemu současnému řešení. Kromě přímých nákladů nezapomeňte vzít v úvahu nepřímé náklady, jako je infrastruktura, a náklady na zdroje, jako je údržba.

Snížení celkových nákladů na vlastnictví je společným cílem správců databází, kteří chtějí nahradit svůj současný nástroj pro monitorování výkonu databáze, takže je třeba zvážit několik faktorů. Jak bylo zmíněno výše, je důležité dívat se nejen na přímé náklady, jako je nákupní cena, ale také na nepřímé náklady, jako jsou náklady na skladování a zdroje, jako je školení.

Chcete-li určit TCO pro nový nástroj, zapojte svá specifika do kalkulátoru TCO a zjistěte, jaké jsou úspory nákladů, pokud nějaké jsou.


  1. Jak Random() funguje v PostgreSQL

  2. Převeďte OracleParameter.Value na Int32

  3. tomcat7 - jdbc datasource - To velmi pravděpodobně způsobí únik paměti

  4. Upozornění:mysql_fetch_array():zadaný argument není platným výsledkem MySQL