Databázový systém Microsoft SQL Server nám zajišťuje abstrakci nad formou uložených dat a zajišťuje pokročilé funkce jako jsou transakce, vazby, indexování a mnoho dalších (budu o nich psát v dalších dílech). Osobně myslím, že je dobré znát alespoň některé základní principy funkcí těchto souborů. Krom pocitu, že do toho, co se opravdu s daty děje alespoň zhruba vidíte, to přináší i větší pravděpodobnost, že dokážete vyřešit případný budoucí problém – ať už s nekontrolovatelně rostoucí databází nebo zotavení po havárii systému.
Jaké soubory tvoří databázi?
Databáze v Microsoft SQL Serveru se skládá vždy ze dvou základních typů souborů – datový soubor (soubor mdf) a transakční log (soubor ldf). Každá fungující databáze pro své fungování musí mít vždy oba typy těchto souborů.
Při spuštění služby databázového enginu se všechny soubory připojených databází uzamknou a tato služba k nim má výhradní přístup. To zajišťuje vždy přístup jen jedné instance k jedné databázi. Také je nemožné, aby jeden databázových soubor sdílelo více databází – každá databáze musí mít proto svůj datový soubor a svůj transakční log.
U větších databází vyžadujících zvýšený výkon je sice možné mít více jak 2 soubory (například více datových souborů umístěných na více disků), ale pořád se jedná o kombinaci datových souborů a transakčních logů. U příkladů v tomto seriálu se ale budeme zatím věnovat jen databázi se dvěma soubory – jedním datovým a jedním transakčním logem.
A k čemu slouží?
Ačkoliv jsou oba typy souborů tvořící databází nutné pro její běh, důležitějším je datový soubor – soubor s příponou mdf. Ten slouží k uchování všech informací o aktuálním stavu dat v databázi – prakticky vše, co databázi definuje strukturou i daty. V případě jakékoliv změny v datech nebo struktuře se změna provádí úprava tohoto souboru.
Pokud nejste obeznámeni s funkcí transakčního logu (soubor s příponou ldf), můžete se po právu ptát, k čemu vůbec slouží. Vždyť jsou již všechny datové objekty i s daty umístěny do datového souboru. Tak k čemu je potřeba transakční log?
Transakční log uchovává historii provedených databázových operací. Hlavním důvodem k tomu je zajištění atomicity (nedělitenost) těchto operací. Což je obecná vlastnost očekávaná od všech dnešních databází. Pro lepší pochopení zkusím uvést příklad.
Máme tabulku s nezanedbatelným počtem záznamů (500 tisíc). Chceme provést hromadnou úpravu všech řádků tabulky – například upravit hodnotu dvou sloupců. Databázový server začne záznamy postupně procházet (číst z datového souboru) a zapisovat upravenou hodnotu (zpět do datového souboru). V ideálním světe nebude nikdo po dobu zpracování nijak proces narušovat – to by také znamenalo, že transakční log vůbec nebudeme potřebovat. Jenže v průběhu zpracování může vypadnout proud nebo se objevit situace zamezující dokončení a vyžadující vrácení změn. Bez historie změn by databázový server po opětovném spuštění nevěděl, že některé záznamy byly upravené a některé ne. Tím by se porušila právě atomicita operací – stav, kdy se úpravy projeví všechny nebo žádné. Není tedy přípustný stav, kdy je polovina řádků upravených a polovina ne. Proto existuje transakční log uchovávající historii nedokončených operací. V případě neočekávané události (ať už výpadkem proudu, restartováním serveru nebo i jen vyžádáním klientem) je hlavní datový soubor obnoven podle historie v transakčním logu.
Zkusím příklad uvést na konkrétních hodnotách. Máme v databázi jednu plnou tabulku záznamů. Datový soubor má například 500MB a transakční log jen zanedbatelnou velikost. Nyní chceme změnit hodnotu u všech řádků v této tabulce. Při provádění se zapisuje historie úprav do transakčního logu a zároveň se hodnoty i ihned upravují v hlavním datovém souboru. Datový soubor zůstává přibližně stejně veliký, ale transakční log se začíná plnit daty (historie změn původních řádků). Dokud není celá operace dokončena, jsou data v transakčním logu vyžadována pro případné navrácení změn celé operace. Pokud se operace úspěšně dokončí, transakční log se opět zmenší na původní zanedbatelnou velikost, protože obsahuje pouze historii již proběhnuté operace. V případě pádu systému nebo vyžádání v průběhu provádění by se data transakčního logu využila a data v datovém souboru by se podle historie navrátila do původního stavu. U vypnutí nebo pádu systému se tento návrat do původního stavu (termínem pro tuto operaci je “recovery” - obnovení) provede automaticky při spuštění.
O konkrétním fungování se budu zmiňovat až bude reálné využití v rámci příkladů dalších dílů seriálu. Tento článek byl jen teoretický úvod do fungování transakčních logů a datových souborů.
Poznámka na závěr
Malá poznámka na konec – datové soubory a transakční logy mohou zůstávat i po vyprázdnění ve své alakované velikosti (nezmenší se), avšak při zápisu nových dat je obsah přepisován a soubor již neroste. V případě, že stále narůstá, může být problémem nastavení databáze (RECOVERY MODE) nebo neuzavřená transakční operace, která vyžaduje atomicitní přístup. O tom všem ale až jindy.
Závěr s ukázkou
Aby se neřeklo, že dnes nic neukážu prakticky, podíváme se na fyzické soubory u naší nově založené databáze mojedb (z minulého dílu). Pusťme si tedy SQL Server Management Studio a rozevřete větev databází v okně Object Explorer. Z kontextového menu nad novou databází si zvolte Properties (vlastnosti) a přepněte se na stránku Files:
Tady vidíme seznam souborů, které databáze používá. Můžeme si prohlédnout jejich umístění, nastavení a typ (sloupec File Type) zda se jedná o datový soubor (Rows Data) nebo transakční log (Log).
Závěr již bez ukázky
Dnešní díl byl opět velmi teoretický. Doufám, že objasnil smysl rozdělení databáze na datový soubor a transakční log. Slibuji, že se v příštích dílech již vrhneme do praktického používání databáze a jazyka SQL.