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

Vytváření plánů údržby v SQL Server

Plány údržby v SQL Server nám poskytují snadný způsob, jak organizovat, konfigurovat a plánovat úlohy, které zajistí, že databázový stroj a databáze, které jsou v něm hostovány, budou udržovány ve formě.

Plány údržby nabízejí správci databáze příležitost konfigurovat klíčové úlohy, jako je indexování, aktualizace statistik, zálohování, čištění protokolů a další. V předchozím článku jsme již diskutovali o tom, jak vytvořit základní plán údržby pro provádění kontroly konzistence databáze. V tomto článku provedeme průvodce vytvořením plánu údržby pro instanci databáze, která hostí malé databáze. V průběhu tohoto návodu vysvětlím klíčové volby provedené v každém kroku v kontextu instance se středně velkým počtem malých databází. Cílem je nakonfigurovat údržbu těchto databází, aniž byste to museli dělat jednu po druhé. Zaměření na malé databáze má zabránit režii výkonu související s operacemi údržby.

Plán údržby pro týdenní úkoly

Obrázek 1:Spuštění průvodce plánem údržby

Průvodce plánem údržby spustíme z Průzkumník objektů>[Název instance]>Správa>Plány údržby (viz obrázek 1). První stránka průvodce nám poskytuje přehled úloh, které lze konfigurovat. I když existují jiné způsoby, jak provést tyto úkoly pomocí kódu a plánování úloh, Průvodce plánem údržby to docela usnadňuje při práci s velkým počtem databází hostovaných v jedné instanci.

Obrázek 2:Průvodce plánem údržby

Na obrázku 3 vidíme, že SQL Server odhaluje pole, která můžeme pojmenovat a popsat plán údržby. Zadání popisu plánu má smysl pro účely dokumentace. Představte si převzetí nové instance SQL Serveru v nové společnosti. Bylo by užitečné, kdybyste v objektech našli popisy objektů SQL Serveru. Totéž byste měli udělat pro ostatní. Vezměte prosím na vědomí, že popis, který jsem uvedl, má jednoduše ilustrovat tento bod. V produkčním prostředí bude žádoucí podrobnější popis.

Obrázek 3:Pojmenování plánu údržby

Všimněte si, že na obrázku 3 máme možnost zvolit, zda chceme použít jeden plán pro všechny úkoly nebo samostatný plán pro každý úkol. Rozhodl jsem se použít samostatné plány, abych měl flexibilitu rozložení úkolů. Nechtěli bychom, aby příliš mnoho operací údržby probíhalo souběžně nebo zády k sobě po dlouhou dobu, abychom se vyhnuli riziku zahlcení serverových zdrojů. Rozhodnutí, které v tomto okamžiku učiníte, může také záviset na kapacitě zdrojů, které máte k dispozici, a dostupném okně údržby. Někteří lidé mají dostatečnou kapacitu a chtěli by mít úkol rychle za sebou při každém běhu. Ve scénáři popsaném v tomto článku předpokládáme, že se daná instance během víkendu nepoužívá.

Na obrázku 4 si vybereme úkoly, které chceme provést. Jednou ze skvělých věcí na SQL Serveru je, že každá úloha je popsána ve spodní části okna. Při práci jako DBA se vyplatí rozumět tomu, co děláte, i když pracujete na „Windows“. Podle mých zkušeností má mnoho „administrátorů“ ve zvyku jednoduše kliknout na „DALŠÍ, DALŠÍ, DALŠÍ“, protože spěchají, aby funkce fungovaly. Ale věnovat čas pochopení dopadu příštího „DALŠÍHO“ vám pomůže zajistit, že děláte něco, co přinese přidanou hodnotu a nezpůsobí nové problémy.

Obrázek 4:Výběr úloh údržby

Úkoly, které jsme vybrali, jsou popsány následovně:

Kontrola integrity databáze task provádí kontrolu vnitřní konzistence dat a indexových stránek v databázi.

Reorganize Index úkol defragmentuje a komprimuje seskupené a neseskupené indexy v tabulkách a pohledech. To zlepší výkon indexového skenování.

Rebuild Index úloha reorganizuje data na datových a indexových stránkách přebudováním indexů. To zlepšuje výkon indexových prohledávání a vyhledávání. Tento úkol také optimalizuje distribuci dat a volného místa na stránkách indexu, což umožňuje rychlejší budoucí růst.

Aktualizace statistik úloha zajišťuje, že má optimalizátor dotazů aktuální informace o rozložení hodnot dat v tabulkách. To umožňuje optimalizátoru lépe posoudit strategie přístupu k datům.

Vyčištění historie úloha odstraní historická data o operacích zálohování a obnovy, SQL Server Agent a plánu údržby. Tento průvodce vám umožňuje určit typ a stáří dat, která mají být odstraněna.

Zálohování databáze (úplná) task vám umožňuje určit zdrojové databáze, cílové soubory nebo pásky a možnosti přepsání pro úplnou zálohu.

Čištění údržby úloha odstraní soubory, které zbyly z provádění plánu údržby.

Obrázek 5 ukazuje, kde vybíráme pořadí, ve kterém se tyto úlohy provádějí. To je důležité z několika důvodů. Například nemá smysl provádět aktualizaci statistiky indexu po opětovném sestavení indexu, protože nové sestavení indexu také provádí aktualizaci statistiky indexu na serveru SQL Server. Později v článku uvidíme, jak s tím naložíme vzhledem k pořadí, které jsme zvolili. Další možnou úvahou je, že se můžete rozhodnout, že je smysluplnější nejprve provést zálohu, než budete pokračovat s určitými druhy údržby.

Obrázek 5:Pořadí úkolů

Na obrázku 6 si vybereme, na které databáze chceme aplikovat první úlohu údržby. Musíme to udělat i pro každý z následujících úkolů. To je důležité v tom smyslu, že některé databáze bude možná nutné z takových operací vyjmout. Například tam, kde máte ve stejné instanci směs velmi velkých databází (VLDB) a velmi malých databází (samotný špatný nápad), možná budete muset vyloučit VLDB z úplně slepých přestaveb indexů. V takovém případě musíte identifikovat klíčové tabulky v dané VLDB a zaměřit přestavby a další operace intenzivní údržby na klíčové tabulky. V tomto příkladu jsem vyloučil systémové databáze, protože pro ně mohu pečlivě plánovat údržbu samostatně. Domnívám se, že je bezpečnější manipulovat se systémovými databázemi samostatně, protože jakékoli jejich poškození by mohlo mít dopad na celou instanci.

Obrázek 6:Určení rozsahu

Každá operace údržby má vlastní sadu možností. Obrázek 7 ukazuje možnosti, pro které se musíme rozhodnout pro DBCC CHECKDB. Mírně jsem se odchýlil od výchozího nastavení zvýšením MAXDOP na 2. Na obrázku 8 jsme zvolili spuštění této úlohy v 1:00 v sobotu a neděli večer.

Obrázek 7:Možnosti DBCC

Obrázek 8:Plán DBCC

Úloha Reorganize Index má také specifickou sadu možností. Za zmínku stojí soubor podmínek, které určují, zda by měl být index reorganizován či nikoli – 30% fragmentace, více než 1000 stránek a poslední použití maximálně 28 dní. Toto okno podtrhuje potřebu porozumět možnostem, které děláme. Abyste tyto možnosti provedli správně, musíte v rozumné míře rozumět indexům a indexování. Všimněte si, že podobné volby bude nutné provést v úloze Rebuild Index. Vezměte také na vědomí, že doporučený práh fragmentace pro reorganizaci indexu je ve skutečnosti 15 % a ne 30 %.

Obrázek 9:Možnosti reorganizace indexu

Úloha Rebuild Index nabízí několik dalších možností kromě těch pro reorganizaci indexu. (Viz obrázek 10). Všimněte si, že jsem zvolil řazení výsledků v TempDB. Aby byla tato volba účinná, je důležité vhodně vyladit TempDB, protože tato volba znamená, že řazení pro tuto operaci ve VŠECH databázích proběhne v TempDB. Kromě toho musíme nastavit plán pro opětovné sestavení indexu. Pro tento úkol jsem také nastavil MAXDOP na 2.

Obrázek 10:Možnosti opětovného sestavení indexu

Již dříve jsme zmínili, že když je na serveru SQL vyvoláno opětovné sestavení indexu, ve výchozím nastavení je také vyvolána aktualizace statistik o indexech. Když tedy nakonfigurujeme úlohu aktualizace statistiky, zvolíme aktualizaci pouze statistiky sloupců (Obrázek 11). Toto okno nám také dává možnost buď provést úplné skenování nebo vzorkování. Vzhledem k tomu, že jde o malé databáze, volíme možnost úplné kontroly. Opět to vyžaduje určité porozumění statistikám.

Obrázek 11:Úloha aktualizace statistik

Rozhodli jsme se nakonfigurovat úlohu čištění tak, aby smazala všechna data starší než 4 týdny, jak je znázorněno na obrázku 12.

Obrázek 12:Úloha vyčištění historie

Úloha zálohování nabízí na třech kartách celou řadu možností konfigurace! Obrázek 13 ukazuje, že jsme se rozhodli omezit tuto úlohu zálohování na uživatelské databáze. Naplánujeme to na neděli ve 3:00 a jdeme dále, abychom zvolili umístění zálohy jako E:\MSSQL\Backup (viz obrázek 14). Na třetí záložce (obrázek 15) provedeme výběr k ověření zálohy a také provedeme kontrolní součet, takže jsme blíže k jistotě, že záloha je spolehlivá.

Obrázek 13:Úloha zálohování databáze

Obrázek 14:Cíl zálohy

Obrázek 15:Možnosti zálohování

Nakonec nakonfigurujeme úlohu, která bude spravovat uchovávání našeho protokolu plánu údržby. (Obrázek 16). Opět volíme odstranění všech záznamů protokolu starších než 4 týdny. Obrázek 17 ukazuje možnosti, které vybíráme, abychom zajistili, že aktivity plánu údržby budou protokolovány a také odeslány e-mailem skupině Database Admin. Samozřejmě, aby tato poslední možnost fungovala, musíme mít nakonfigurovanou Database Mail a správně nastavit operátory.

Obrázek 16:Úloha čištění plánu údržby

Obrázek 17:Možnosti sestavy

Obrázky 18 a 19 ukazují souhrn úloh, které jsme nakonfigurovali, a zpětnou vazbu o úspěšném dokončení průvodce.

Obrázek 18:Přehled možností

Obrázek 19:Dokončení průvodce

Plán údržby pro každodenní úkoly

Můžeme také nastavit samostatné plány údržby pro jiné účely, jako je například organizace. Pro denní úkoly nemusíme nastavovat samostatný plán, protože rozvrhy můžeme konfigurovat samostatně pro každý úkol. Jedním z důvodů, proč můžeme chtít nastavit samostatný plán, může být výběr jiné sady úkolů zaměřených na jinou sadu databází (ve skutečnosti to stále můžeme být schopni udělat i ve stávajícím plánu).

V následujícím příkladu předpokládejme, že máme další sadu velkých databází ve stejné instanci s různými cíli bodů obnovy. Potom musíme použít jinou strategii zálohování – denní plán rozdílového zálohování a hodinový plán zálohování protokolu transakcí kromě týdenní plné zálohy, abychom zajistili RPO 1 hodinu. (Viz obrázky 21 a 22).

Obrázek 20:Denní plán údržby úkolů

Obrázek 21:Úlohy diferenciálního a Tlog zálohování

Obrázek 22:Pořadí úkolů plánu denní údržby

Pro rozdílové zálohování volíme denní plán, který se spouští denně ve 2:00. (Viz obrázek 23). A vyberte stejné možnosti zálohování, jaké jsme udělali pro úplné týdenní zálohování nakonfigurované dříve.

Obrázek 23:Plán denního plánu údržby

Obrázek 24:Umístění rozdílové zálohy

Obrázek 25:Možnosti rozdílového zálohování

Na druhou stranu jsme se rozhodli naplánovat rozdílové zálohování tak, aby probíhalo každou hodinu každého dne. Zajišťujeme také, aby byla každá sada zálohování databáze uložena v adresáři s vlastním názvem. Zbytek průvodce je téměř stejný jako v předchozím návodu.

Obrázek 26:Plán zálohování protokolu transakcí

Obrázek 27:Umístění zálohy protokolu transakcí

Obrázek 28:Možnosti zálohování protokolu transakcí

Závěr

Po dokončení průvodce plánem údržby skončíme s plánem údržby a odpovídající sadou úloh agenta SQL (viz obrázek 29). Plán údržby je v podstatě soubor balíčků SSIS, a když prozkoumáte naplánované úlohy, zjistíte, že krok úlohy prováděný v každé úloze dílčího plánu je balíček SSIS (viz obrázek 30).

V následujícím příkladu si ukážeme, že úlohy dílčího plánu můžeme provádět ročně. Zkontrolujeme také výsledky provádění plánu údržby a odstraníme chyby související s prováděním pracovních kroků. Prozkoumáme také deník plánu údržby.

Obrázek 29:Výsledné úlohy SQL Agent

Obrázek 30:Krok úlohy balíčku SSIS


  1. Postgres – Převeďte seznam sousedství na vnořený objekt JSON

  2. Rozdíl mezi VARCHAR2(10 CHAR) a NVARCHAR2(10)

  3. PostgreSQL Meltdown Benchmarks

  4. Jak si přizpůsobit zálohy MySQL a MariaDB pomocí ClusterControl