Při návrhu databáze pro správu serverů a jejich instancí je důležité zajistit, že data budou uspořádána efektivně a bez redundance. Tento proces zahrnuje několik fází normalizace, které pomáhají strukturovat data do formy, která minimalizuje duplicitu a umožňuje rychlé a efektivní dotazování. Tento článek se zaměřuje na konkrétní příklady z praxe a ukazuje, jak správně přistupovat k normalizaci na různých úrovních.

Prvním krokem je návrh struktury databáze, která musí vyhovět pravidlům první normální formy (1NF). Tato fáze zahrnuje zajištění, že všechny atributy v tabulkách budou atomické, což znamená, že každý sloupec bude obsahovat pouze jednu hodnotu. Příkladem může být databáze pro správu disaster recovery (DR) serverů. Pokud máme například server s názvem „SQL001“, můžeme mít několik instancí, například „SQL002“, ale kvůli tomu, že název instance nebude unikátní, musíme použít složený klíč, který bude tvořen názvem serveru a názvem instance.

Při analýze DR serveru je tedy potřeba vzít v úvahu nejen název serveru, ale i specifické atributy jako technologie DR, RPO (Recovery Point Objective) a RTO (Recovery Time Objective). Tyto hodnoty, pokud jsou atomické, nemusí být rozdělovány do více tabulek. Avšak kvůli složenému klíči, který bude tvořen serverem a instancí, je potřeba propojit tyto entity pomocí cizího klíče.

Po vytvoření 1NF přecházíme na druhou normální formu (2NF). Aby tabulka byla v 2NF, musí být již v 1NF, a navíc nesmí existovat žádné závislosti neklíčových atributů na části klíče. Pokud k takovým závislostem dojde, je nutné atributy přesunout do nových entit. U entit Server a Instance, kde je klíč tvořen jediným atributem, jsou tyto entity již ve 2NF. U DR serveru, kde máme složený klíč, musíme zkontrolovat, zda některé neklíčové atributy závisí pouze na části klíče. V našem případě technologie DR, RPO a RTO závisí pouze na instanci, a ne na celém klíči (server + instance), což znamená, že je potřeba je přesunout do samostatné entity DR Instance. Tato změna zjednodušuje model a vyhýbá se nejednoznačným vztahům mezi servery a instancemi.

Poslední fází je přechod na třetí normální formu (3NF). Tabulka je v 3NF, pokud je v 2NF a žádný neklíčový atribut není závislý na jiném neklíčovém atributu. Takové závislosti jsou známé jako tranzitivní závislosti. V případě serverů, DR serverů a DR instancí nejsou tranzitivní závislosti přítomny, ale v případě entity Instance se objevují atributy závislé na neklíčových atributech, například hesla pro různé účty služby. Abychom předešli těmto závislostem, přesuneme detailní informace o účtech služby do nové entity nazvané Service Account a propojujeme ji s entitou Instance. Atributy týkající se účtu „sa“ (system administrator) budou uloženy v samostatné entitě sa Account, protože tento účet není sdílen mezi instancemi.

Takto vyřešené tranzitivní závislosti zajišťují, že data jsou strukturována tak, aby byla co nejvíce normalizována, což přispívá k lepší konzistenci a integritě databáze.

Po normalizaci je kladeno důraz na testování správnosti modelu, což může být provedeno pomocí ERD (Entity Relationship Diagram). Tento diagram ukazuje vztahy mezi entitami a pomáhá ověřit, zda všechny vztahy odpovídají jedinečným klíčům. Pokud ERD vykazuje problém s mnohonásobnými vztahy mezi entitami, je nutné přidat další entity, které vztahy vyřeší. Naopak, pokud objevíme vztah 1:1, je možné, že jsme normalizovali data příliš a přidání takového vztahu by způsobilo pouze zbytečnou složitost. V takovém případě je lepší některé entity denormalizovat, což znamená spojení entit, které byly dříve rozděleny, zpět do jedné.

Při návrhu databáze pro reálné prostředí může být užitečné uvažovat o technologiích vysoké dostupnosti (HA), jako jsou AlwaysOn failover cluster nebo AlwaysOn Availability Groups. Pokud se jedná o složitější strukturu, může být také výhodné modelovat servery, DR servery a HA servery jako supertypy a subtypy. Tento přístup umožňuje lépe reprezentovat různé typy serverů a jejich specifické vlastnosti, aniž by došlo k redundanci.

Při návrhu fyzického modelu databáze je třeba zvá

Jak centralizovat údržbu záloh v databázích SQL Serveru

Při správě více databázových serverů SQL je klíčové mít dobře zorganizovaný a automatizovaný systém pro údržbu databází, včetně pravidelných záloh, čištění starých záloh a aktualizace statistik. Efektivní centralizovaná údržba nejen zvyšuje bezpečnost, ale také zajišťuje optimální výkon serverů a úsporu času pro administrátory. Tento přístup vyžaduje několik kroků, které zajišťují, že všechny úkoly budou prováděny ve správný čas a na správných instancích databázového serveru.

Začneme vytvářením skriptu, který provádí úplné zálohy uživatelských databází. Skript začíná generováním seznamu údržbových úkolů, které je třeba provést na každém serveru a instanci. Tento seznam se vytváří dotazem na tabulku MaintenanceSchedule a filtrací úkolů, které již běží, nebo jsou deaktivovány. Skript také zajistí, že aktuální čas je větší nebo roven času, kdy by měl úkol být proveden, a také, že tento čas spadá do stanoveného časového okna, během něhož je možné úkol vykonat.

Skript používá časové filtry, kdy aktuální čas je převeden na typ TIME a porovnán s hodnotami sloupců StartTime a EndTime. Nakonec filtrujeme všechny úkoly, které nejsou typu 'FullBackup', což nám umožňuje zaměřit se pouze na zálohování. Výsledek tohoto dotazu je předán do smyčky foreach, která postupně připojí každý SQL Server a vygeneruje seznam uživatelských databází na dané instanci.

Po zjištění seznamu databází je tabulka MaintenanceTasks aktualizována tak, aby indikovala, že úkol je právě v průběhu provádění. Následuje smyčka, která prochází seznam databází a zálohuje každou z nich pomocí příkazu BACKUP DATABASE. Jakmile jsou všechny databáze na instanci zálohovány, smyčka pokračuje a tabulka MaintenanceTasks je opět aktualizována. Tentokrát je změněný stav úkolu na "neprobíhá" a aktualizována je i poslední doba provedení úkolu a stav provedení.

Skript je efektivní nejen pro zálohy, ale i pro kontrolu, že úkoly nejsou opakovány dříve, než je to nutné. Tento proces zajišťuje hladký průběh zálohování, což je nezbytné pro zajištění integrity a dostupnosti dat.

Dále se zaměříme na skript pro odstranění starých záloh. Tento skript vyžaduje nastavení proměnné $limit, která bude obsahovat aktuální datum a čas mínus tři dny. Cílem je odstranit zálohy starší než tento limit. Používáme příkaz Get-ChildItem, který generuje seznam souborů k odstranění, a následně tento seznam předáme příkazu Remove-Item pro jejich odstranění.

Pokud se zálohy uchovávají na síťovém disku, skript vyžaduje, aby tento disk byl sdílený. V případě, že tomu tak není, lze použít PowerShell Remoting s příkazem Invoke-Command, aby se skript spustil na vzdáleném serveru. Tento přístup je užitečný v případě, že se zálohy přesouvají na pásky nebo jiná média, což výrazně šetří místo na primárním serveru.

Ačkoli tento přístup zjednodušuje mnoho administrativních úkolů, je nutné zvážit několik důležitých aspektů. Prvním z nich je pravidelná kontrola zálohovacích a údržbových procesů, aby se předešlo neplánovaným problémům. Zálohy by měly být testovány, a to jak pro jejich integritu, tak i pro možnost obnovení dat v případě havárie. Dále je důležité mít nastavený monitorovací systém, který bude informovat administrátory o případných problémech s úkoly nebo s dostupností záložních souborů.

Přestože skripty automatizují většinu procesů, měly by být součástí širšího plánu zálohování a obnovy. Administrátoři by měli mít jasně definované politické a technické postupy pro řešení krizových situací, včetně plánů pro obnovení po havárii (DRP – Disaster Recovery Plan). Také je důležité pravidelně ověřovat, že veškeré související úkoly, jako je aktualizace statistik a čištění starých záloh, probíhají podle plánu, aby byla zajištěna dlouhodobá údržba serverů a databází.

Proč se nevyplácí volit mezi svobodou a zradou v divokém západu?
Jaký tajemství skrývá ztracený žabák?
Jaký je význam kolektivní a individuální адвокации pro zajištění lepší podpory duševního zdraví ve školách?