U702A : Správa databází

Kód úlohy:

U702A

Autor návrhu úlohy:

Valenta, M. (KSI, FIT, ČVUT), Černohorský, J. (KIT, VŠE)

Datum poslední úpravy:

2015-02-06

Předpokládaná pravděpodobnost užití v praxi:

0.8

Charakteristiky úlohy

1. “Správa databází“ – cíl, účel

Cílem úlohy je zajistit potřebnou disponibilitu databází . Identifikovat problémy v provozu a správě databáz í a připravit řešení identifikovaných problémů.

2. Obsah úlohy

Správa databází zahrnuje (dnes již automatizované) :
- sledování logů databáze,
- vytížení databáze,
- zajištění zálohování a archivace dat,
- obnovu dat.

3. Vstupy úlohy:

Datová architektura (D055A ),
Katalog datových zdrojů (D211A ),
Analýzy a plán rozvoje datových zdrojů (D212A ),
Plán zajištění kvality dat (D213A ),
Katalog požadavků na IT (D042A ),
Katalog IT služeb (D111A ),
Analýza IT dodavatelů (D121A ),
Provozní dokumentace (D711A ),
Plán rozvoje technologické infrastruktury (D235A ),
Rozpočet IT (D325A ).

4. Výstupy úlohy:

Provozní dokumentace (D711A ), aktualizovaná,
Katalog datových zdrojů (D211A ), aktualizovaný,
Analýzy a plán rozvoje datových zdrojů (D212A ), aktualizovaný.

5. Doporučené praktiky

Automatický monitoring a reporting . V současné době je třeba vše automatizovat. Stanovit metriky a jejich ukazatele. Při překročení „standardních“ hodnot řešit případný problém – analýza, řešení problému.
Praktiky (best practices) pro správu databází jsou obvykle vázány na konkrétní technologii . Níže uvedené praktiky jsou zobecněním průnikem pro relační databázové stroje (v současnosti nejpoužívanější). * /Metodika zálohování (co všechno, četnost, s jakou redundancí, způsob provedení) by mela mělo být součástí provozní dokumentace.

6. “Správa databází“ - klíčové aktivity

6.1. Sledování činnosti databáze a jejího vytížení

Jedná se o rutinní činnost, kterou provádí správce databáze. Fakticky jde o sledování log souboru, který je buď samostatný pro každou instanci nebo na úrovni celého clusteru .
Některé systémy (Oracle, MSSQL a další) mají pro sledování log souboru vytvořenou službu , která log soubor v pravidelných intervalech monitoruje a zjištěné problémy hlásí pomocí vlastního systému varování (alert) . Příkladem může být Enterprise Manager pro systém Oracle. Alert systém bývá konfigurovatelný tak, že v případě problémů upozorňuje administrátora, který má službu, pomocí mailu, SMS či jiným způsobem. Stejné funkcionality lze snadno dosáhnout i u systémů, které nedisponují sofistikovanou administrátorskou nadstavbou, pomocí služby cron (plánování úloh) na úrovni operačního systému.
U méně exponovaných databází postačí pravidelná kontrola log souboru administrátorem několikrát během služby . Na základě sledování log souboru lze:
- Včas detekovat problémy typu přeplňující se diskový prostor, nefunkční vlákno zálohování, chyba při zápisu na disk a aktivně je řešit.
- Detekovat podezřelé aktivity prováděné nad databází (pokus o neoprávněné přihlášení apod.).
- Iniciovat ladění databázového systému.
Problém, který může záhy způsobit nefunkčnost celé databáze (například nedostupný svazek pro zápis jednoho žurnálu, špatný checksum na úrovni zápisu datového souboru, docházející místo na disku apod.) je nejprve většinou s dostatečným předstihem, signalizován v log souboru databáze.

6.2. Archivace databáze

Metodika zálohování (co všechno, četnost, s jakou redundancí, způsob provedení a kam má být zálohováno) by měla být součástí provozní dokumentace . Volba zálohovací strategie je závislá na způsobu použití databáze (převažuje čtení nebo zápis, množství transakcí v čase, objem dat v čase, …) a technologii. Je třeba ji řádně otestovat a dokumentovat - viz KPI – MTTR a MTBF (I636 ).

6.3. Obnova databáze v případě incidentu / havárie

Jedná se o reakci na incident/havárii .:
- Administrátor databáze provede analýzu problému a stanoví rozsah poškození databáze.
- Na základě analýzy a metodiky zálohování zvolí postup, který minimalizuje ztrátu dat.
- Provede obnovu databáze.
Je možné, že při velkém rozsahu havárie nebude při zvolené metodice zálohování obnovit databázi zcela. Může dojít ke ztrátě některých dat, respektive k obnově do nějakého časového okamžiku v minulosti (ztráta některých transakcí).

6.4. Ladění databáze

K této činnosti dochází zpravidla tehdy, pokud odezva databáze v některých případech nebo celkově nevyhovuje požadavkům provozu. Ladění provádí správce databáze (databázový specialista), základním vstupem bývá LOG soubor databáze, případně si ladění vyžádá rozšíření logovaných událostí (což může mít dočasně vliv na odezvu celého systému). Pro ladění databázových systémů jsou často samostatné profese.
Nasazení a provoz databázového systému je diametrálně odlišná činnost od ladění databáze.
Požadavek na ladění databáze by měl být definován co nejkonkrétněji a tak, aby byl účinek ladění snadno měřitelný (například snížení času vyhodnocení konkrétního dotazu z 10 minut na méně než minutu). Konkrétní kroky ladění databázového systému závisí na použité technologii.
Fakticky lze výkon databáze ovlivňovat na těchto úrovních :
- Optimalizace databázových příkazů (doporučení pro optimalizátor, uložené prováděcí plány, systémové statistiky, …),
- Optimalizace pomocí podpůrných struktur a přístupu k datům (indexy, materializované pohledy, , …),
- Optimalizace na úrovni zdrojů (struktura a velikost přidělené operační paměti, parametry databázového stroje, …),
- Optimalizace na úrovni operačního systému (volba a konfigurace filesystem, architektura I/O podsystému, ..).