Úvod
Tento článek je krátkým přehledem hlavní plánované údržby s databází nepřetržitého informačního systému bez výpadků a přístupů k jejich provádění v MS SQL Server.
Jakékoli komentáře a aktualizace článku jsou velmi oceňovány.
Plánovaná údržba
Rád bych upozornil na následující plánovanou údržbu:
- Plánované zálohy s dalším ověřením bez obnovy
- Naplánované obnovení záloh za účelem ověření jejich výkonu
- Analýza zařízení pro ukládání dat, které obsahuje systém a všechny potřebné databáze
- Plánované testování požadovaných služeb
- Plánovaná optimalizace výkonu systému
- Plánovaná údržba integrity dat
- Plánovaná údržba ověřování dat
První tři body jsou nejdůležitější, protože poskytují obnovu systému po různých poruchách. Doporučil bych však provést také alespoň tři body, aby uživatelé mohli pracovat v klidu (všechny dotazy by tedy měly být prováděny rychle) a aby data byla validována ve všech systémech výkaznictví.
Pro automatizaci plánované údržby je možné uspořádat její části v Agentovi nebo Windows Scheduler.
Šestý bod je založen na příkazu CHECKDB.
Sedmý bod je implementován směrem k doménové oblasti používané v informačním systému.
Budu mluvit podrobně o prvních pěti bodech.
Plánované zálohy s dalším ověřením bez obnovy
Vzhledem k tomu, že na toto téma existuje mnoho článků, je třeba poznamenat, že tuto plánovanou údržbu je nutné pravidelně provádět na záložním serveru, nikoli na hlavním serveru. Tento záložní server by měl obsahovat aktuální data (například ta, která byla získána replikací). Kromě toho musíte zálohovat všechny systémové databáze (kromě tempdb) na každé instanci MS SQL Server.
Když se zálohování nezdaří nebo skenování zálohy identifikuje problém, je nutné tuto informaci nahlásit správcům. Můžete jim například poslat e-mail.
Je důležité určit strategii zálohování, která odpoví na následující otázky:
- Jak často a kdy bychom měli zálohovat data (úplná, rozdílová a protokol transakcí)?
- Jak dlouho a kdy máme smazat zálohy?
Naplánované obnovení záloh za účelem ověření jejich výkonu
Doporučuji provést tento postup na záložním serveru pomocí nástrojů třetích stran nebo RESTORE příkaz.
Pokud se obnovení zálohy nezdaří, je nutné tuto informaci nahlásit správcům. Můžete jim například poslat e-mail.
Kromě toho je nutné obnovit zálohy systémových databází. Chcete-li to provést, musíte je obnovit jako obvyklou uživatelskou databázi s názvem, který se liší od názvů systémových databází.
Analýza zařízení pro ukládání dat, která obsahují systém a všechny potřebné databáze
Musíte analyzovat, kolik místa zabírá každá databáze, jak se mění velikosti souborů a jak se mění velikosti volného místa v celém úložném zařízení. Tento úkol můžete částečně provést například automatickým sběrem dat o databázových souborech a logických jednotkách operačního systému na MS SQL Server.
Tuto kontrolu můžete provádět každý den a poté odeslat výsledky. Jako obvykle je můžete poslat na e-mail.
Je také nutné sledovat systémové databáze, abyste se ujistili, že vše funguje správně.
Kromě toho je důležité otestovat úložná zařízení a zkontrolovat, zda nedochází k odpisům nebo vadným sektorům.
Pamatujte, že během testování by zařízení mělo být mimo provoz a všechna data by měla být zkopírována do jiného zařízení, protože testování drasticky zatěžuje zařízení.
Tento úkol úzce souvisí s povinnostmi správce systému, takže jej ponecháme stranou. Chcete-li mít nad případem plnou kontrolu, musíte zautomatizovat doručování e-mailových zpráv.
Tento test bych doporučil provádět dvakrát ročně.
Plánované testování požadovaných služeb
Prostoje služby jsou špatnou praxí. V případě jakýchkoliv poruch se tedy spustí záložní server. Přesto je nutné protokoly čas od času zkontrolovat. Kromě toho můžete také uvažovat o automatickém sběru dat s dalším upozorněním administrátora zasláním e-mailu.
Je nutné kontrolovat úlohy SQL Server Agenta nebo Windows Scheduleru s automatickým sběrem dat o dokončených úlohách v MS SQL Serveru.
Plánovaná optimalizace výkonu systému
Zahrnuje následující aspekty:
- Automatizace defragmentace indexu v databázích MS SQL Server
- Automatizace sběru dat o změnách databázových schémat na MS SQL Server. Zálohu můžete obnovit a porovnat změny například pomocí dbForge
- Automatické čištění zaseknutých procesů na MS SQL Server
- Vyčištění mezipaměti procedur. Zde je třeba určit, kdy a co se má čistit
- Implementace ukazatele výkonu
- Vývoj a úprava seskupených indexů
Kromě toho doporučuji vypnout AUTO_CLOSE funkce.
Někdy z různých důvodů optimalizátor paralelizuje dotaz, což není vždy optimální.
Existuje tedy několik doporučení, která byste měli mít na paměti:
- Pokud získáváte hodně dat, ponechte paralelismus.
- Pokud získáte několik dat, nepoužívejte paralelismus.
V nastavení instance serveru SQL Server jsou dva parametry odpovědné za paralelismus:
- maximální stupeň paralelismu. Chcete-li paralelismus vypnout, nastavte hodnotu „1“, což znamená, že kód bude provádět pouze jeden procesor.
- práh nákladů pro paralelismus. Mělo by být nastaveno jako výchozí.
Existují dvě hlavní fronty:
- fronta pro čas CPU (fronta QCPU). Probíhá, když je dotaz povolen a čeká, až jej procesor provede.
- fronta na zdroje (QR fronta). Probíhá, když dotaz čeká na uvolnění prostředků, aby mohl proces spustit.
Následující vzorec popisuje provádění dotazu (T):
T=TP+TQR+TCPU+TQCPU, kde:
- TP sestavuje čas pro plán
- TQR je čas ve frontě na zdroje (QR fronta)
- TQCPU je doba čekání ve frontě na uvolnění prostředků (fronta QCPU)
- TCPU je čas na provedení dotazu
V systémovém zobrazení sys.dm_exec_query_stats:
- total_worket_time =TP+TCPU+TQCPU
- total_elapsed_time =TQR+TCPU
Vestavěné nástroje neumožňují přesné posouzení doby provádění dotazu.
Ve většině případů total_elapsed_time poskytuje čas, který se blíží času provedení dotazu.
Dobu provádění dotazu můžete určit přesněji pomocí trasování. Případně můžete zaznamenat čas začátku a konce dotazu. Buďte opatrní se stopami, protože výrazně zatěžují systém. Proto je lepší provádět to na záložním serveru a shromažďovat data z hlavního serveru. V tomto případě bude načtena pouze síť.
Při paralelizaci SQL Server přiděluje N procesů dotazu (v edici Standart n<=4). Každý proces vyžaduje čas CPU k provedení dotazu (ne vždy se má na každém jádru provést jeden proces).
Čím více procesů máte, tím větší je pravděpodobnost, že některé budou nahrazeny jinými, což vede ke zvýšení TQCPU.
Spuštění dotazu při paralelizaci může trvat mnohem déle v následujících případech:
- Nízká propustnost diskového subsystému. V tomto případě trvá rozklad dotazu mnohem déle.
- Pro tento proces mohou být data zablokována.
- Pro predikát neexistuje žádný index, což vede k prohledávání tabulky.
Poznámky:
Musíte zakázat paralelní dotazy na serverech, kde není potřeba provádět velký výběr (total_worket_time by se měl snížit kvůli možnému poklesu TCPU a TQCPU). Chcete-li to provést, musíte nastavit maximální stupeň paralelismu na '1', aby fungoval pouze jeden procesor.
Kromě toho můžete použít další rámce k sestavení systému, který určuje vysokorychlostní výkon databází . Je důležité pochopit, jak tyto rámce fungují a jak interpretovat získaná čísla.
Co se týče vývoje a modifikace indexů, jmenovitě klastrových indexů, hlavním cílem je pochopit, jak je nastavena logika indexů a jak to funguje.
Mějte na paměti, že primární a seskupený klíč neznamenají totéž:
Primární klíč je sloupec nebo sada sloupců, díky kterým je záznam v tabulce jedinečný. Pro primární klíč můžete vytvořit jedinečný seskupený nebo neseskupený index. Primární klíč se v jiných tabulkách používá jako cizí klíč k zajištění integrity dat.
Shlukovaný index je B-strom nebo jeho modifikace. Listy obsahují samotná data, zatímco uzly obsahují informace o indexu. Kromě toho může být seskupený index také nejedinečný. Přesto doporučuji, aby byl jedinečný.
Rád bych připomněl, že B-strom je struktura, která ukládá data v pořadí filtrovaném podle seskupeného indexu. Proto je důležité seskupit pole vybraná jako seskupený index v sestupném nebo vzestupném pořadí. Pro seskupený index můžete použít sloupce celého čísla (identity) a také data a čas. Sloupce, jako je jedinečný identifikátor, však nejsou vhodné, protože ten povede k pravidelné restrukturalizaci B-stromu, což zvýší množství čtení a záznamů na úložném zařízení, kde je databáze umístěna.
Kromě toho se musíte ujistit, že se index používá se systémovým zobrazením sys.dm_db_index_usage_stats.
P.S. Je nutné zkontrolovat, zda jsou data aktuální na záložním serveru, a také zkontrolovat systém, který tato data synchronizuje (např. replikace).
Přečtěte si také:
Automatizace defragmentace indexu v databázích MS SQL Server
Automatický sběr dat změn databázového schématu na MS SQL Server
Automatické mazání zaseknutých procesů na MS SQL Server
Odstraňování problémů s dlouho běžícími dotazy na MS SQL Server
Implementace ukazatele výkonu