V dnešní době, kdy je automatizace klíčovým nástrojem pro efektivní správu databázových systémů, je nezbytné mít dobře navrženou inventární databázi, která bude sloužit jako centrální bod pro řízení a orchestrace všech automatizovaných procesů v organizaci. Tato databáze se stává srdcem celkové strategie automatizace a přispívá k její stabilitě a škálovatelnosti. Přestože je tato databáze relativně malá a jednoduchá, její role je zásadní pro úspěch všech automatizovaných úkolů v rámci podniku.

Při návrhu inventární databáze by mělo být jedním z hlavních zaměření optimalizování a přizpůsobení databáze specifickým potřebám správy a údržby SQL Serveru. Jedním z nejdůležitějších aspektů je, že tato databáze by měla být plně pod kontrolou DBA (Database Administrator), což umožní mít nad celým systémem maximální kontrolu a flexibilitu při implementaci a rozšíření automatizačních nástrojů. Hlavní výhodou tohoto přístupu je nejen možnost centralizovaného řízení údržby, ale také schopnost efektivně sledovat a spravovat všechny SQL Server instance napříč organizací.

Důležitým prvkem při návrhu inventární databáze je její platformní návrh. Pokud organizace provozuje více datových center, například ve Velké Británii a Spojených státech, a zároveň má svou přítomnost v cloudu (například v Azure), je důležité zvážit, jak zajistit dostupnost a redundanci této databáze. V případě výpadku jednoho z datových center by měla být databáze replikována mezi více lokalitami, aby byla zachována její dostupnost pro všechny SQL Server instance. To je klíčové pro zachování plynulosti automatizačních procesů a minimalizaci rizika výpadků.

Pro tento účel může být ideálním řešením použití technologie AlwaysOn Availability Groups, která umožňuje synchronizaci databáze mezi dvěma nebo více geograficky oddělenými lokalitami. V případě, že organizace využívá cloudové služby, například Azure, je možné nasadit Availability Group mezi dvěma různými regiony v Azure, což poskytuje ještě větší flexibilitu a škálovatelnost.

Pokud jde o platformní volby, je důležité si uvědomit, že používání služeb jako Azure SQL Database pro inventární databázi nemusí být ideální. Přestože nabízí jednoduchost správy a odstranění administrativního zatížení spojeného s Windows OS a SQL Server instancí, neumožňuje využití některých klíčových funkcí, jako je SQL Server Agent, který je nezbytný pro správu automatizovaných úloh. V takových případech je lepší volbou Azure Managed Instances, které poskytují více flexibility pro komplexní automatizační scénáře.

Pokud je inventární databáze správně navržena a implementována, může být silným nástrojem pro zajištění, že všechny údržbové úkoly, jako jsou kontroly integrity databází nebo obnovení indexů, budou prováděny efektivně a včas. Databáze může poskytovat seznam SQL Server instancí, které mají být zpracovány během těchto údržbových úloh, což umožní automatizaci a centralizované řízení celého procesu.

V neposlední řadě, i když vytvoření inventární databáze může být náročné, její správné fungování a údržba zajišťují, že automatizované procesy v rámci organizace poběží hladce a efektivně. A to i v případě, že dojde k výpadkům infrastruktury, protože redundantní a distribuované platformy zajistí vysokou dostupnost databáze a minimalizují riziko jejího výpadku.

Je také důležité pamatovat na to, že efektivní automatizace není pouze o technologii, ale i o správném řízení a monitorování celého procesu. K tomu slouží metody, jako je sledování výkonu a shromažďování metadat, která mohou být použita pro další optimalizace a zlepšení výkonu databázových systémů.

Jak implementovat správu konfigurace pro SQL Server pomocí PowerShell DSC

Správa konfigurace je klíčovým aspektem moderního IT prostředí, a to nejen pro správu operačního systému, ale i pro správu databázových serverů. Pro SQL Server existuje několik přístupů, jak zajistit konzistenci a správnost konfigurace v průběhu jeho životního cyklu. Tento proces zahrnuje jak nastavení serveru, tak i zajištění jeho bezpečnosti a výkonnosti. Využití nástroje PowerShell DSC (Desired State Configuration) se ukazuje jako efektivní způsob, jak předejít odchylkám v konfiguraci a minimalizovat rizika, která mohou vzniknout při změnách provedených mimo standardizované procesy.

Při návrhu konfigurace pro SQL Server je důležité nejenom zvážit jeho instalaci, ale především způsob, jakým bude server nakonfigurován. Kromě samotné instalace SQL Serveru bychom měli brát v úvahu faktory jako bezpečnost, výkonnost a minimalizaci administrativních operací v budoucnu. PowerShell DSC nám umožňuje definovat požadavky pro konfiguraci, přičemž každou změnu lze automatizovat a zajistit, že server bude neustále odpovídat těmto standardům.

Jedním z prvních kroků při definování požadavků na konfiguraci je zabezpečení SQL Serveru. Bezpečnost je široké téma, a ačkoli je možné se jí podrobně zabývat v jiných publikacích, pro účely této kapitoly se zaměříme na tři klíčové oblasti. Prvním z těchto aspektů je zákaz použití xp_cmdshell. Tento systémový uložený postup umožňuje administrátorům interagovat s operačním systémem přímo z SQL Serveru, což činí server zranitelným vůči útokům. Pokud je SQL Server kompromitován, xp_cmdshell může sloužit jako vstupní bod pro šíření útoku v rámci sítě. Další konfigurací je deaktivace OLE Automation, což eliminuje riziko, že uživatelé mohou spouštět externí funkce mimo SQL Server a v rámci kontextu bezpečnosti databázového enginu. Nakonec je důležité, aby byl veškerý přístup k SQL Serveru kontrolován a aby se vyhnulo automatickému přidávání místní skupiny Administrators jako SQL Server login. Tento krok je v novějších verzích SQL Serveru již neproveditelný, ale přesto zůstává dobrým bezpečnostním postupem.

Kromě bezpečnosti se v rámci správy konfigurace musíme zaměřit i na optimalizaci výkonnosti. Pro každý SQL Server je vhodné přizpůsobit konfiguraci podle typu pracovního zatížení, které server vykonává. Například OLTP (Online Transaction Processing) databáze, které vykonávají mnoho operací INSERT a UPDATE, vyžadují jinou konfiguraci než databáze používané pro datové sklady, které provádějí noční ETL operace a primárně čtou velké objemy dat. Bez ohledu na konkrétní typ databáze existují však některé konfigurace, které by měly být vždy správně nastaveny. Jedním z klíčových parametrů je MAXDOP (maximum degree of parallelism), který určuje maximální počet jader, která může jedno dotazování využívat. Optimální hodnota pro většinu systémů je maximálně 8 jader, ale díky použití DSC můžeme tuto hodnotu automaticky upravit při změně velikosti serveru.

Další výzvou pro správu výkonnosti SQL Serveru je paměť. Doporučené nastavení je, aby SQL Server využíval maximálně 75 % dostupné paměti serveru pro svůj buffer cache. Tato hodnota by měla být v případě vícenásobných instancí správně rozdělená mezi jednotlivé instance. Kromě toho se doporučuje nastavit minimální a maximální paměť stejným způsobem, aby se zabránilo dynamickému přerozdělování paměti, což může vést k problémům v případech, kdy SQL Server není jedinou aplikací běžící na serveru.

Další oblastí, kterou by měla konfigurace SQL Serveru pokrývat, je automatizace operací. Cílem je minimalizovat potřebu manuálního zásahu a zajistit, že všechny požadované úkoly budou vykonány automaticky. Například vytvoření přístupových práv pro administrátory DBA, kteří by měli mít potřebná oprávnění pro správu instance, může být provedeno předem, čímž se eliminují budoucí problémy. Automatizace může také zahrnovat centralizovanou správu serverů, kde je možné spravovat více SQL Server instancí z jednoho místa.

Pokud jde o budoucí operace a správu serverů, důležitým aspektem je také jejich monitorování a údržba. Využití nástroje DSC nejen že eliminuje lidskou chybu při konfiguraci, ale také umožňuje provádět pravidelné kontroly a automaticky napravovat jakékoliv odchylky od stanovené konfigurace. To je zvláště důležité v prostředí, kde je více administrátorů nebo když se serverové prostředí často mění.

Endtext

Jak efektivně automatizovat řešení problémů a údržby v IT prostředí

Vytváření komplexního řešení pro automatizaci opravy problémů v IT systémech od začátku je přístup, který téměř vždy vede k neúspěchu. Prvním důvodem je vysoká nákladovost a náročnost tohoto procesu. Druhým je, že každá firma je nejen jedinečná, ale také se neustále mění, což znamená, že implementace automatizovaných opravných scénářů musí být dynamická a flexibilní. Proto by automatizace opravy problémů měla být součástí neustálého zlepšování služeb (CSI - Continuous Service Improvement).

Doporučený přístup spočívá v používání jednoduché formulace pro rozhodování o tom, které scénáře opravy a údržby by měly být automatizovány. Tato formule zní: "Pokud problém nastane xkrát za n týdnů a (doba opravy * n) > odhadovaná náročnost automatizace." Hodnoty v této formuli budou závislé na konkrétním prostředí firmy. Například: "Pokud problém nastane 5krát za 4 týdny a (doba opravy * 20) > 4 hodiny." Tato formule vypočítává, zda bude automatizace schopná se vrátit zpět během tří měsíců. Pokud se návratnost v tomto časovém rámci potvrdí, je téměř jisté, že je rozumné věnovat úsilí implementaci automatizované odpovědi.

Pokud vaše firma používá sofistikovaný systém pro správu tiketů, jako je například ServiceNow nebo ITSM 365, máte možnost efektivně sledovat opakující se problémy. Problém je tiket, který se opakovaně vyskytuje. Systém může být nakonfigurován tak, že pokud je tiket otevřen pro stejný problém pětkrát za čtyři týdny, stane se problémovým tiketem. To poskytuje efektivní nástroj pro analýzu kořenových příčin a okamžitě se spojuje s naší formulí pro automatizaci.

Pro hledání vhodných scénářů pro automatizaci je ideálním výchozím bodem analýza problémových tiketů v rámci DB admin týmu. Zde můžeme začít identifikovat opakující se problémy a automatizovat jejich řešení.

Příklad konkrétního scénáře, který lze automatizovat, je reakce na chyby typu 9002. Tato chyba se objeví, když není dostatek místa pro zápis do transakčního logu a log se nemůže zvětšit. Pro tuto situaci si ukážeme, jak navrhnout a implementovat automatizovanou odpověď.

Nejprve musíme vytvořit procesní tok, který nám pomůže při psaní kódu a zároveň poslouží jako dokumentace procesu. Tento procesní tok bude vizuálně znázorněn a následně použijeme kód pro automatizovanou odpověď.

Automatizace odpovědi na chyby 9002 zahrnuje nastavení SQL Server Agentu, který aktivuje náš proces, když dojde k této chybě. V SQL Server Management Studiu se musíme připojit k SQL Server Agentu a zvolit "Nový alert". V okně pro nový alert definujeme název a konfigurujeme ho tak, aby byl spuštěn při výskytu chyby číslo 9002. Na stránce pro odpovědi pak zaškrtneme možnost "Spustit úkol" a vytvoříme nový úkol, který bude následně spouštěn.

Tento úkol bude obsahovat kód pro provedení několika akcí: nejprve bude vytvořena dočasná tabulka pro ukládání logových záznamů, poté budou zjištěny potřebné informace o databázi a logu, kde došlo k chybě. Následně systém provede několik kroků, včetně zjištění a zabití aktivních dotazů, což umožní úklid logu, a to i v případě, že dojde k chybám v procesu zálohování nebo správy transakčního logu.

Pokud je databáze v režimu zjednodušené obnovy, systém provede kontrolní bod a následně zmenší transakční log. V případě složitějších scénářů, například pokud jde o databázi v plném režimu obnovy, bude automatizace zahrnovat zálohování transakčního logu a následné zmenšení logu.

Takto navržený proces nejenže automatizuje rutinní operace, ale také umožňuje včasné upozornění a eskalaci problémů, jako jsou chyby 9002, které mohou mít vážný dopad na výkon a stabilitu databázového systému.

Důležité je si uvědomit, že implementace automatizace by měla být postupná a dynamická. Není rozumné se snažit pokrýt všechny možné scénáře naráz. Každý automatizovaný proces by měl být pečlivě analyzován, testován a monitorován, aby byla zajištěna jeho efektivita a minimalizována rizika, jako jsou nežádoucí vedlejší účinky.

Co znamená boj a strach, když se přítel stává nepřítelem?
Jak Docker a cloudové technologie mění vývoj a testování softwaru
Jak komunikovat v Německu se zvířetem: Základní fráze a slovní zásoba pro majitele domácích mazlíčků
Jak se orientovat ve městě a správně komunikovat na veřejných místech