Fyzické soubory databáze – datové soubory a transakční log

5. díl - Fyzické soubory databáze – datové soubory a transakční log

Tomáš Jecha, MVP, MCSD       23.12.2009       SQL, Databáze       37867 zobrazení

Každá běžná databáze je fyzicky reprezentována soubory. V tomto článku se dočtete o jejich významu v Microsoft SQL Serveru.

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:

Database properties - 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.

 

hodnocení článku

0       Hodnotit mohou jen registrované uživatelé.

 

Všechny díly tohoto seriálu

7. Datové typy 29.12.2009
6. Tabulky 27.12.2009
5. Fyzické soubory databáze – datové soubory a transakční log 23.12.2009
4. První kroky s databází 22.12.2009
3. Správa služeb a komponent Microsoft SQL Serveru 16.12.2009
2. Seznámení a instalace Microsoft SQL Serveru 14.12.2009
1. Lehký úvod – teorie databází 12.12.2009

 

Mohlo by vás také zajímat

Windows Azure - díl 3.: SQL Database – relační databáze hostovaná v cloudu

Tento díl seriálu je věnován prvnímu druhu úložiště dat ve Windows Azure, kterým je relační databáze SQL Database.

Windows Azure - díl 4.: SQL Database – Nasazení databáze, dostupnost a škálovatelnost

Tento díl seriálu je věnován migraci databáze do Windows Azure a také dostupnosti a škálovatelnosti této služby.

Pooling v .NET

 

 

Nový příspěvek

 

Diskuse: Fyzické soubory databáze, systémové databáze

Autorovi moc děkuji za článek, byl bych moc rád, kdyby další díl věnoval hlubší analýze velikosti souborů ldf, mdf a principu jejich fungování.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Dobrý den,

další články rozhodně chystám, nicméně předem říkám, že se fungování souborů mdf a ldf věnovat budu maximálně na úrovni zdokumentovaných funkcí (Shrink, Recovery mode atp.). Fyzický princip vnitřního fungování a struktury souborů používám jen v extrémních případech obnov systémů a není smyslem seriálu o tak pokročilých a vyjímečných věcech psát.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Fyzické soubory databáze, systémové databáze

Dobrý den,

chtěl bych se zeptat, pokud bych chtěl zálohovat databázy MS SQL. Stačí si fyzicky zálohovat jen datové soubory? nebo stačí pouze používat nastroj z Managment studia pro zálohování, který asi zálohuje vše potřebné?)

Například pokud by SQL server havaroval postačí soubory mdf a ldf k obnově? nebo je potřeba ještě soubory backup.

Děkuji za odpověď

Marek

PS:

Jestli je v plánu v dalším díle i něco o zálohování a obnově dat. Omlouvám se za předbíhání, jinak jsem za předchozí články moc rád.

Díky.

nahlásit spamnahlásit spam 0 odpovědětodpovědět
                       
Nadpis:
Antispam: Komu se občas házejí perly?
Příspěvek bude publikován pod identitou   anonym.

Nyní zakládáte pod článkem nové diskusní vlákno.
Pokud chcete reagovat na jiný příspěvek, klikněte na tlačítko "Odpovědět" u některého diskusního příspěvku.

Nyní odpovídáte na příspěvek pod článkem. Nebo chcete raději založit nové vlákno?

 

  • Administrátoři si vyhrazují právo komentáře upravovat či mazat bez udání důvodu.
    Mazány budou zejména komentáře obsahující vulgarity nebo porušující pravidla publikování.
  • Pokud nejste zaregistrováni, Vaše IP adresa bude zveřejněna. Pokud s tímto nesouhlasíte, příspěvek neodesílejte.

přihlásit pomocí externího účtu

přihlásit pomocí jména a hesla

Uživatel:  
Heslo:  

zapomenuté heslo

 

založit nový uživatelský účet

zaregistrujte se

 
zavřít

Nahlásit spam

Opravdu chcete tento příspěvek nahlásit pro porušování pravidel fóra?

Nahlásit Zrušit

Chyba

zavřít

feedback