Průvodce obnovou InterBase a Firebird

NOTICE: Tento dokument je kapitolou z knihy „The InterBase World“, kterou napsali Alexey Kovyazin a Serg Vostrikov.

Kapitola z knihy „The InterBase World“ věnovaná opravám databází.

1. Historie této příručky

Ruská kniha „The InterBase World“ byla vydána v září 2002.

Její náklad byl 3000 výtisků. Po 3 měsících byla vyprodána a v dubnu 2003 vyšlo druhé, vylepšené vydání s nákladem 5000 výtisků.

Nyní je na špici v největších ruských internetových knihkupectvích a předpokládáme, že bude velmi brzy vyprodána.

Autory knihy jsou Alexey Kovyazin, vývojář IBSurgeon a

známý ruský specialista na InterBase, a Serg Vostrikov, generální ředitel společnosti Devrace

www.devrace.com

Je to zvláštní věc, ale ani jedna kniha věnovaná InterBase nebyla vydána v angličtině!

Tisíce a tisíce vývojářů používají InterBase a Firebird, diskutují o

tomto tématu na různých konferencích (podívejte se sem: Odkazy).

Komunita vývojářů InterBase čítá v průměru desítky tisíc

lidí. Silná poptávka po knihách o InterBase v různých zemích dokazuje, že komunita InterBase je opravdu velká.

Vsadíme se o krabici piva, že vydání o 10 000 výtiscích bude smeteno z Amazon.com během měsíce. Ale lidé ve vydavatelských společnostech

„vědí všechno“ a jsou si jisti, že si nikdo nekoupí knihu o InterBase. To je opravdová škoda.

Zde bychom vám rádi nabídli návrh jedné kapitoly z této knihy věnované obnově databází InterBase/Firebird.

2. Jak obnovit databázi InterBase/Firebird

2.1. Přehled hlavních příčin poškození databáze

Bohužel vždy existuje pravděpodobnost, že jakékoli úložiště informací bude

poškozeno a některé informace z něj budou ztraceny. Databáze není výjimkou z tohoto pravidla. V této kapitole se budeme zabývat hlavními příčinami, které vedou k poškození databáze InterBase, některými metodami opravy databází a získávání informací z nich. Také se seznámíme s doporučeními a preventivními opatřeními, která minimalizují pravděpodobnost ztráty informací z databáze.

Nejprve, pokud mluvíme o opravě databáze, bychom měli objasnit pojem

„poškození databáze“. Databáze je obvykle nazývána poškozenou, pokud se při pokusu o získání nebo úpravu některých informací objeví chyby a/nebo se získané informace ukáží jako ztracené, neúplné nebo zcela nesprávné. Existují případy, kdy jsou poškození databáze skrytá a jsou zjištěna pouze testováním speciálními nástroji, ale existují také skutečná poškození databáze, kdy není možné se k databázi připojit, kdy upravené klientské programy zobrazují podivné chyby (když nebyly s databází provedeny žádné manipulace), nebo kdy není možné obnovit databázi ze záložní kopie.

2.2. Hlavní příčiny poškození databáze jsou:

Abnormální ukončení serverového počítače, zejména přerušení elektrické energie. Pro IT průmysl je to skutečný bič, a proto doufáme, že není třeba znovu připomínat nutnost mít na serveru zdroj nepřerušovaného napájení.
Vady a poruchy serverového počítače, zejména HDD (pevného disku), řadičů disků, hlavní paměti počítače a vyrovnávací paměti řadičů RAID.
Nesprávný připojovací řetězec k multi-klientské databázi jednoho nebo více uživatelů (ve verzích před 6.x). Při připojení přes TCP/IP musí být cesta k databázi uvedena jako název serveru: jednotka:/cesta/název_databáze /pro servery na platformě UNIX název_serveru: /cesta/název_databáze /, podle protokolu NETBEUI \\název_serveru\jednotka:\cesta\název_databáze. Dokonce i při připojení databáze z počítače, na kterém je databáze umístěna a server běží, je třeba použít stejný řádek s přejmenováním názvu serveru na localhost. V připojovacím řádku nelze použít mapovanou jednotku. Pokud porušíte některé z těchto pravidel, server se domnívá, že pracuje s různými databázemi, a poškození databáze je zaručeno.
Kopírování souboru nebo jiný přístup k souboru databáze, když server běží. Provedení příkazu „shut-down“ nebo odpojení uživatelů obvyklým způsobem není zárukou, že server s databází nic nedělá, pokud není interval sweep nastaven na „0“, může být proveden garbage collection. Obecně se garbage collection provádí okamžitě po odpojení posledního uživatele od databáze. Obvykle to trvá několik sekund, ale pokud předtím bylo potvrzeno mnoho operací DELETE nebo UPDATE, může být proces delší.
Používání nestabilních verzí serveru InterBase 5.1-.5.5. Společnost Borland oficiálně přiznala, že v těchto serverech bylo několik chyb, a stabilní upgrade 5.6 byl odstraněn až po vydání certifikovaného InterBase 6 ve volném režimu pro všechny klienty serverů 5.1-5.5 na svých stránkách.
Překročení limitu velikosti databázového souboru (ne databáze!). Pro verze před InterBase 6 a některé beta verze InterBase 6 je limit databázového souboru 4 GB, pro InterBase 6.5 a všechna vydání Firebird (1.0, 1.5, 2.0, 2.1) - 32 TB. Když se velikost databáze blíží limitní hodnotě, musí být vytvořen další soubor.
Vyčerpání volného místa na disku při práci s databází.
Pro servery Borland InterBase verzí pod 6.0.1.6 - překročení limitu počtu generátorů podle výzkumu a vývoje Borland InterBase definovaného následujícím způsobem (viz tabulka 1).


Verze	Velikost stránky=1024	Velikost stránky=2048	Velikost stránky=4096	Velikost stránky=8192
Před 6	248	504	1016	2040
6.0.x	124	257	508	102

Tabulka 1: Kritický počet generátorů v raných verzích InterBase

• Pro všechny servery Borland InterBase - překročení přípustného počtu

transakcí bez provedení zálohy/obnovy. Počet transakcí, které proběhly v databázi od posledního vytvoření, lze zjistit vyvoláním nástroje gstat s klíčem - h - parametr NEXT TRANSACTION ID bude požadovaný

počet transakcí. Podle Ann W. Harrisona kritický počet transakcí závisí na velikosti stránky a má následující hodnoty (viz tabulka 2):


Velikost stránky databáze	Kritický počet transakcí
1024 bajtů	131 596 287
2048 bajtů	265 814 016
4096 bajtů	534 249 472
8192 bajtů	1 071 120 384

Tabulka 2: Kritický počet transakcí v serverech Borland InterBase

Omezení serverů Borland InterBase uvedená výše se nevztahují na

servery Firebird kromě nejranějších verzí 0.x., jejichž existence se již stala historií. Pokud používáte finální verzi Firebird 1.0 nebo InterBase 6.5-7.x, neměli byste se obávat bodů 5, 6, 8 a 9 a měli byste se soustředit na jiné příčiny. Nyní se budeme podrobně zabývat nejčastějšími z nich.

2.3. Výpadek napájení

Při vypnutí napájení na serveru jsou všechny činnosti zpracování dat

přerušeny na nejneočekávanějších a (podle Murphyho zákona) nejnebezpečnějších místech. V důsledku toho mohou být informace v databázi zkresleny nebo ztraceny. Nejjednodušší případ je, když všechna nepotvrzená data z klientských aplikací byla ztracena v důsledku nouzového vypnutí serveru. Po restartu po výpadku napájení server analyzuje data, zaznamená neúplné transakce, které se nevztahují k žádnému klientovi, a zruší všechny úpravy provedené v rámci těchto „mrtvých“ transakcí. Takové chování je vlastně normální a bylo předpokládáno od začátku vývojáři InterBase.

Přerušení napájení však není vždy doprovázeno pouze takovými nevýznamnými

ztrátami. Pokud server prováděl rozšiřování databáze v okamžiku přerušení napájení, existuje velká pravděpodobnost výskytu osiřelých stránek v databázovém souboru (stránek, které jsou fyzicky alokovány a registrovány na stránce inventáře stránek (PIP), na které není možné zapisovat data). Pokud se chcete dozvědět více o osiřelých stránkách, podívejte se na kapitolu „Struktura databáze InterBase“.

Pouze nástroj pro opravu a úpravu gfix (který zvážíme níže) je schopen bojovat s osiřelými stránkami v databázovém souboru. Osiřelé stránky vlastně vedou ke zbytečnému plýtvání místem na disku a jako takové nejsou příčinou ztráty dat nebo poškození.

Ztráta napájení vede k vážnějším škodám. Například po vypnutí

napájení a restartu může být ztraceno velké množství dat, včetně potvrzených (po jejichž přidání nebo úpravě byl proveden příkaz „commit transaction“). K tomu dochází, protože potvrzená data nejsou zapsána přímo do databázového souboru na disku. K tomuto účelu se používá souborová vyrovnávací paměť operačního systému (OS). Serverový proces předal příkaz k zápisu dat operačnímu systému. Poté OS ujistil server, že všechna data byla uložena na disk, a ve skutečnosti byla data uložena ve vyrovnávací paměti souborů. OS nespěchá s vyprázdněním těchto dat na disk, protože se domnívá, že je v hlavní paměti dostatek místa, a odkládá pomalé operace zápisu na disk, dokud není hlavní paměť zaplněna.

2.4. Vynucené zápisy - dvojsečná zbraň

Aby bylo možné ovlivnit situaci, je v InterBase 6 poskytnuto nastavení režimu zápisu dat. Tento parametr se nazývá forced writes (FW) a má 2 režimy - ON (synchronní) a OFF (asynchronní). Režimy FW definují, jak InterBase komunikuje s diskem. Pokud je FW zapnuto, je zapnuto nastavení synchronního zápisu na disk, kdy jsou potvrzená data zapisována na disk ihned po příkazu commit, server čeká na dokončení zápisu a teprve poté pokračuje ve zpracování. Pokud je FW vypnuto, InterBase nespěchá se zápisem dat na disk po příkazu potvrzení transakce a deleguje tento úkol paralelnímu vláknu, zatímco hlavní vlákno pokračuje ve zpracování dat, aniž by čekalo, dokud nebudou zápisy na disk dokončeny. Režim synchronního zápisu je jedním z nejopatrnějších a minimalizuje jakoukoli možnou ztrátu dat, může však způsobit určitou ztrátu výkonu. Režim asynchronního zápisu zvyšuje pravděpodobnost ztráty velkého množství dat. Pro dosažení maximálního výkonu se obvykle nastavuje režim FW Off. Ale v důsledku přerušení napájení se při asynchronním zápisu ztratí mnohem více dat než při synchronním. Při nastavování režimu zápisu byste se měli rozhodnout, zda je několik procent výkonu důležitějších než několik hodin práce, pokud dojde k neočekávanému přerušení napájení.

Velmi často jsou uživatelé k InterBase nedbalí. Malé organizace šetří na každé maličkosti, často na počítači-serveru, kde je nainstalován DBMS server a různé serverové programy (a nejen server). Pokud se zaseknou, lidé bez dlouhého přemýšlení stisknou RESET (stává se to několikrát denně). Ačkoli je InterBase ve srovnání s jinými DBMS velmi odolný vůči takovým činnostem a umožňuje začít pracovat s databází ihned po nouzovém restartu, takové použití není žádoucí. Počet osiřelých stránek se zvyšuje a data ztrácejí vzájemné spojení v důsledku chybných restartů.

Může to pokračovat dlouho, ale dříve nebo později to skončí. Když se poškozené stránky objeví mezi stránkami PIP nebo generátorů, nebo pokud je poškozena hlavičková stránka databáze, databáze se může navždy přestat otevírat a stát se velkým kusem oddělených dat, ze kterých nelze získat ani jeden bajt užitečných informací.

2.5. Poškození pevného disku

Poškození pevného disku vede ke ztrátě důležitých systémových stránek databáze a/nebo k poškození spojení mezi zbývajícími stránkami. Taková poškození patří k nejobtížnějším případům, protože téměř vždy vyžadují zásah na nízké úrovni k obnovení databáze.

2.6. Chyby v návrhu databáze

Je nutné, abyste věděli o některých chybách, kterých se dopouštějí vývojáři databází

a které mohou vést k nemožnosti obnovení databáze ze záložní kopie (*.gbk souborů vytvořených programem gbak). Především je to neopatrné používání omezení na úrovni databáze. Typickým příkladem jsou omezení NOT NULL. Předpokládejme, že máme tabulku naplněnou počtem záznamů. Nyní do této tabulky pomocí příkazu ALTER TABLE přidáme další sloupec a uvedeme, že nesmí obsahovat nedefinované hodnoty NULL. Něco takového:

ALTER TABLE sometable Field/INTEGER NOT NULL

A v tomto případě nedojde k očekávané chybě serveru. Tato změna metadat bude potvrzena a neobdržíme žádnou chybovou ani varovnou zprávu, což vytváří iluzi normality této situace.

Pokud však provedeme zálohu databáze a pokusíme se ji obnovit ze záložní kopie, obdržíme chybovou zprávu ve fázi obnovy (protože do sloupce s omezením NOT NULL jsou vkládány hodnoty NULL a proces obnovy bude přerušen. (Důležitá poznámka od Craiga Stuntze - ve verzi InterBase 7.1 jsou omezení při obnově ve výchozím nastavení ignorována (lze to řídit přepínačem příkazového řádku) a téměř jakoukoli nepoškozenou zálohu lze obnovit. Vždy je dobré provést testovací obnovu po vytvoření zálohy, ale tento problém by měl ve verzi 7.1 prakticky zmizet.) Tuto záložní kopii nelze obnovit. Pokud byla obnova směrována do souboru se stejným názvem jako existující databáze (během obnovy byl přepisován pracovní soubor existující databáze), ztratíme všechny informace.

Souvisí to s tím, že omezení NOT NULL jsou implementována systémovými triggery, které kontrolují pouze přicházející data. Během obnovy jsou data ze záložní kopie vkládána do prázdných, právě vytvořených tabulek - zde můžeme najít nepřípustné hodnoty NULL ve sloupci s omezením NOT NULL.

Někteří vývojáři považují toto chování InterBase za nesprávné, ale jiní nebudou schopni přidat pole s omezením NOT NULL do databázové tabulky.

Otázka požadované výchozí hodnoty a jejího vyplnění v okamžiku vytvoření byla široce diskutována architekty Firebirdu, ale nebyla přijata kvůli tomu, že programátor ji zjevně vyplní podle algoritmu, který je poměrně složitý a možná i iterativní. Neexistuje však žádná záruka, zda bude schopen rozlišit záznamy ignorované předchozí iterací od nevyplněných záznamů či nikoli.

Podobný problém může způsobit chyba garbage collection kvůli nastavení nesprávné cesty k databázi (příčina poškození 3) v době připojení a přístupu k databázovým souborům, když s nimi server pracuje (příčina poškození 4), a v některých tabulkách se mohou objevit záznamy celé vyplněné hodnotou NULL. Tyto záznamy je velmi obtížné odhalit, protože neodpovídají omezením integrity a operátor Select je prostě nevidí, i když se dostanou do záložní kopie. Pokud z tohoto důvodu není možné obnovení, měli byste spustit program gfix (viz níže), najít a odstranit tyto záznamy pomocí neindexovaných polí jako vyhledávacích podmínek, poté znovu vytvořit záložní kopii a obnovit databázi z ní. Na závěr můžeme říci, že existuje velké množství příčin poškození databáze a vždy byste měli být připraveni na nejhorší - že vaše databáze bude poškozena z toho či onoho důvodu. Musíte být také připraveni obnovit a zachránit cenné informace. A nyní se podíváme na preventivní opatření, která zaručují bezpečnost databáze InterBase, stejně jako na metody opravy poškozených databází.

2.7. Preventivní opatření proti poškození databáze InterBase

Aby se zabránilo poškození databáze, měli byste vždy vytvářet záložní kopie (pokud se chcete dozvědět více o zálohování, podívejte se do kapitoly „Zálohování a obnova“). Je to nejspolehlivější způsob ochrany proti poškození databáze. Pouze záloha dává 100% záruku bezpečnosti databáze. Jak je popsáno výše, v důsledku zálohování můžeme získat nepoužitelnou kopii (kopii, kterou nelze obnovit), proto obnova databáze z kopie nesmí být prováděna přepisem skriptu a záloha musí být prováděna podle určitých pravidel. Za prvé, záloha musí být prováděna co nejčastěji, za druhé musí být sériová a za třetí, záložní kopie musí být kontrolovány na schopnost obnovy.

Častá záloha znamená, že je nutné vytvářet záložní kopii poměrně často, například jednou za dvacet čtyři hodin. Čím kratší je období mezi zálohami databáze, tím méně dat bude ztraceno v důsledku poruchy. Sériovost zálohy znamená, že počet záloh musí narůstat a musí být uchováván alespoň týden. Pokud je to možné, je nutné zapisovat zálohy na speciální zařízení, jako je streamer, ale pokud to není možné - stačí je zkopírovat na jiný počítač. Historie záložních kopií pomůže odhalit skrytá poškození a vypořádat se s chybou, která vznikla dávno a projevila se neočekávaně. Je třeba zkontrolovat, zda je možné obnovit přijatou zálohu bez chyb či nikoli. Lze to zkontrolovat pouze jedním způsobem - prostřednictvím testovacího procesu obnovy. Je třeba říci, že proces obnovy trvá 3krát déle než záloha, a je obtížné provádět validaci obnovy každý den u velkých databází, protože to může přerušit práci uživatelů na několik hodin (noční přestávka nemusí stačit).

Bylo by lepší, kdyby velké organizace nešetřily na „zápalkách“ a ponechaly jeden počítač pro tyto účely.

V tomto případě, pokud server musí pracovat s vážným zatížením 24 hodin 7 dní v týdnu, můžeme použít mechanismus SHADOW pro pořizování snímků databáze a další zálohovací operace z okamžité kopie. Proces zálohování a obnovy databáze je podrobně popsán v kapitole „Zálohování a obnova“. Při vytváření zálohy a následné obnově databáze z ní dochází k rekreaci všech dat v databázi. Tento proces (záloha/obnova nebo z/o) přispívá k opravě většiny nefatálních chyb v databázi, souvisejících s poškozením pevného disku, odhalování problémů s integritou v databázi, čištění databáze od odpadu (staré verze a fragmenty záznamů, neúplné transakce), výraznému zmenšení velikosti databáze.

Pravidelné z/o je zárukou bezpečnosti databáze InterBase. Pokud databáze funguje, doporučuje se provádět z/o každý týden. Pravdou je, že existují příklady databází InterBase, které jsou intenzivně používány po stejné roky bez zálohování/obnovy.

Nicméně, pro jistotu je žádoucí provést tento postup, zejména proto, že může být snadno automatizován (viz kapitola „Zálohování“).

Pokud z nějakých důvodů není možné provádět zálohování/obnovu často, lze použít nástroj gfix pro kontrolu a obnovu databáze. gfix umožňuje zkontrolovat a odstranit mnoho chyb bez z/o.

2.8. Nástroj příkazového řádku gfix

Nástroj příkazového řádku gfix se používá pro kontrolu a obnovu databáze. Kromě toho může gfix provádět také různé činnosti správy databáze: změnu dialektu databáze, nastavení a zrušení režimu „pouze pro čtení“, nastavení velikosti mezipaměti pro konkrétní databázi a také některé důležité funkce (můžete se o nich dozvědět v InterBase 6 Operations Guide [4.) gfix se spouští v režimu příkazového řádku a má následující syntaxi:

Gfix [ možnosti] název_db

Možnosti - je sada voleb pro spuštění gfix, název_db je název databáze, nad kterou budou operace prováděny, definovaný sadou voleb. Tabulka 3 představuje volby gfix související s opravou databáze:


Volba	Popis
-f[ull]	Tato volba se používá v kombinaci s -v a znamená, že je čas zkontrolovat všechny fragmenty záznamů
-i[gnore]	Volba způsobí, že gfix ignoruje chyby kontrolních součtů při validaci nebo čištění databáze
-m[end]	Označí poškozené záznamy jako nedostupné, v důsledku čehož budou smazány během následující zálohy/obnovy. Volba se používá v době přípravy poškozené databáze na z/o.
-n[o_update]	Volba se používá v kombinaci s -v pro validaci databáze pouze pro čtení bez opravy poškození
-pas[sword]	Volba umožňuje nastavit heslo při připojování k databázi. (Poznámka: v dokumentaci InterBase je chyba -pa[ssword], ale zkratka “-pa” nebude fungovat - použijte “-pas” )
-user	Volba umožňuje nastavit uživatelské jméno pro připojení k databázi
-v[alidate]	Volba nastavující validaci databáze způsobem, při kterém jsou odhalovány chyby
-m[ode]	Volba nastavující režim zápisu pro databázi - pouze pro čtení nebo čtení/zápis. Tento parametr může přijímat 2 hodnoty - read write nebo read only.
-w[rite] {sync \| async}	Volba, která zapíná a vypíná režim synchronního/asynchronního vynuceného zápisu do databáze. sync - zapnutí synchronního zápisu (FW ON); async - zapnutí asynchronního zápisu (FW OFF);

Tabulka 1: Volby nástroje gfix pro obnovu databáze

Existuje několik typických příkladů použití gfix:

gfix -w sync -user SYSDBA -pass masterkey firstbase.gdb

V tomto příkladu nastavíme pro naši testovací databázi firstbase.gdb režim synchronního zápisu (FW ON). (Samozřejmě je to užitečné před vznikem poškození). A níže je první příkaz, který byste měli použít pro kontrolu databáze po vzniku poškození:

gfix -v -full -user SYSDBA -pass masterkey firstbase.gdb

V tomto příkladu spouštíme kontrolu naší testovací databáze (volba -v) a uvádíme, že musí být zkontrolovány také fragmenty záznamů (volba -full). Samozřejmě je pohodlnější nastavit různé volby pro proces kontroly a obnovy pomocí nějakého GUI, ale my se podíváme na funkce obnovy databáze pomocí nástrojů příkazového řádku. Tyto nástroje jsou součástí InterBase a můžete si být jisti, že jejich chování bude stejné na všech OS, na kterých InterBase běží. Je velmi důležité, aby byly vždy po ruce.

Kromě toho stávající nástroje, které umožňují provádět správu databáze z klientského počítače, k tomu používají Services API, které není podporováno architekturou serveru InterBase Classic. To znamená, že můžete používat produkty třetích stran s architekturou serveru SuperServer.

2.9. Oprava poškozené databáze

Předpokládejme, že v naší databázi jsou nějaké chyby. Za prvé musíme zkontrolovat existenci těchto chyb; za druhé se musíme pokusit tyto chyby opravit. Měli byste dodržovat následující pokyny.

Měli byste zastavit server InterBase, pokud stále běží, a vytvořit kopii souboru nebo souborů databáze. Všechny činnosti obnovy by měly být prováděny pouze s kopií databáze, protože zvolený způsob může vést k nepříznivému výsledku a budete muset restartovat postup obnovy (z výchozího bodu). Po vytvoření kopie provedeme kompletní validaci databáze (kontrolu fragmentů záznamů).

Měli bychom pro to spustit následující příkaz:

gfix -v - full corruptbase gdb -user SYSDBA - password

V tomto případě corruptbase.gdb - je kopie poškozené databáze. Příkaz zkontroluje databázi na jakékoli strukturální poškození a poskytne seznam nevyřešených problémů. Pokud jsou takové chyby zjištěny, budeme muset odstranit poškozená data a připravit se na zálohu/obnovu pomocí následujícího příkazu:

gfix -mend -user SYSDBA -password your_masterkey corruptbase gdb

Po provedení příkazu byste měli zkontrolovat, zda v databázi nezůstaly nějaké chyby. Musíte pro to spustit gfix s volbami -v -full, a když proces skončí, provést zálohu databáze:

gbak -b -v -ig -user SYSDBA -password corruptbase.gdb corruptbase.gbk

Tento příkaz provede zálohu databáze (volba - b o tom vypovídá) a získáme podrobné informace o průběhu zálohování (volba -v). Chyby týkající se kontrolních součtů budou ignorovány (volba - ig). Pokud se chcete dozvědět více informací o volbách nástroje příkazového řádku gbak, najdete je v kapitole „Zálohování a obnova“. Pokud se při zálohování vyskytnou nějaké chyby, měli byste jej spustit v jiné konfiguraci:

gbak -b -v -ig -g -user SYSDBA -password corruptbase.gdb

corruptbase.gbk

Kde volba - g vypne garbage collection během zálohování. To často pomáhá vyřešit problém se zálohováním.

Může být také možné provést zálohu databáze, pokud předtím nastavíme databázi do režimu pouze pro čtení. Tento režim zabraňuje zápisu jakýchkoli modifikací do databáze a někdy pomáhá provést zálohu poškozené databáze. Pro nastavení databáze do režimu pouze pro čtení byste měli použít následující příkaz: gfix -m read _only

-user SYSDBA -password masterkey Disk:\Path\file.gdb

Poté byste měli znovu zkusit provést zálohu databáze pomocí výše uvedených parametrů.

Pokud byla záloha úspěšná, měli byste databázi obnovit ze záložní kopie. Použijte následující příkaz:

gbak -c -user SYSDBA -password masterkey Disk:\Path\backup.gbk

Disk:\Path\newbase,gdb

Při obnově databáze můžete narazit na některé problémy, zejména při vytváření indexů. V tomto případě by měly být k příkazu pro obnovu přidány možnosti -inactive a -one_at_a_time. Tyto možnosti deaktivují indexy při vytváření ze zálohy databáze a potvrzují data pro každou tabulku zvlášť.

2.10. Jak můžete zkusit extrahovat data z poškozené databáze

Je možné, že výše uvedené operace nepovedou k obnově databáze. To znamená, že databáze je vážně poškozena, nebo ji nelze obnovit jako celek, nebo je třeba vynaložit velké úsilí na její obnovu. Například lze provést modifikaci systémových metadat, použít nedokumentované funkce a podobně. Je to velmi těžká, zdlouhavá a nevděčná práce s pochybnými šancemi na úspěch. A pokud je to možné, snažte se tomu vyhnout a použijte jiné metody. Pokud se poškozená databáze otevře a umožňuje provádět čtení a modifikace s některými daty, měli byste tuto možnost využít a data uložit jejich zkopírováním do nové databáze a se starou se navždy rozloučit.

Než tedy přenesete data ze staré databáze, je nutné vytvořit cílovou databázi. Pokud se databáze dlouho nezměnila, můžete použít starou zálohu, ze které lze extrahovat metadata pro vytvoření cílové databáze. Na základě těchto metadat je třeba vytvořit cílovou databázi a začít kopírovat data. Hlavním úkolem je extrahovat data z poškozené databáze. Poté budeme muset data umístit do nové databáze, ale to není příliš obtížné, i když budeme muset obnovit strukturu databáze z paměti. Při extrakci dat z tabulek byste měli použít následující algoritmus operací:

Nejprve byste měli zkusit provést SELECT* z tabulky N. Pokud to proběhlo normálně, můžete uložit získaná data do externího zdroje. Je lepší ukládat data do skriptu (téměř všechny GUI tuto funkci nabízejí), pokud tabulka neobsahuje BLOB pole. Pokud jsou v tabulce BLOB pole, měla by být data z nich uložena do jiné databáze klientským programem, který bude hrát roli prostředníka. Možná budete muset napsat tento triviální program speciálně pro účely obnovy dat.
Pokud se vám nepodařilo získat všechna data, měli byste smazat všechny indexy a zkusit to znovu. Indexy lze prakticky smazat ze všech tabulek od začátku obnovy, protože už nebudou potřeba. Samozřejmě, pokud nemáte strukturu metadat, stejnou jako poškozená, je nutné zaznamenat protokol všech operací, které provádíte s poškozenou zdrojovou databází.
Pokud se vám nepodaří přečíst všechna data z tabulky po smazání indexů, můžete zkusit provést rozsahový dotaz podle primárního klíče. To znamená vybrat určitý rozsah dat. Například:

SELECT * FROM table N WHERE field_PK >=0 and field_PK <=10000 Field_PK

zde je primární klíč. InterBase má stránkovou organizaci dat, a proto může být rozsahový dotaz hodnot poměrně efektivní, i když to vypadá jako nějaké šamanství. Přesto to funguje, protože můžeme vyloučit data z dotazu z poškozených stránek a naštěstí přečíst ostatní. Můžete si připomenout naši tezi, že v SQL neexistuje definované pořadí ukládání záznamů. Opravdu nikdo nezaručuje, že neuspořádaný dotaz při opakovaném spuštění vrátí záznamy ve stejném pořadí, ale přesto jsou fyzické záznamy uloženy v databázi v definovaném vnitřním pořadí. Je zřejmé, že server nebude míchat záznamy jen proto, aby dodržel standard SQL. Toto vnitřní pořadí lze zkusit využít při extrakci dat z poškozené databáze (pokud chcete vědět více informací o datových stránkách a jejich vztazích, podívejte se na kapitolu „Struktura databáze InterBase“).

Vitaliy Barmin, jeden ze zkušených ruských vývojářů InterBase, uvedl, že tímto způsobem dokázal obnovit až 98 % informací z neobnovitelné databáze (bylo tam velké množství poškozených stránek). Data z poškozené databáze musí být tedy přesunuta do nové databáze nebo do externích zdrojů, jako jsou SQL skripty. Při kopírování dat věnujte pozornost hodnotám generátorů v poškozené databázi (musí být uloženy pro restartování správné práce v nové databázi. Pokud nemáte úplnou kopii metadat, měli byste extrahovat texty uložených procedur, triggerů, omezení a definice indexů.

2.11. Obnova beznadějné databáze

Obecně platí, že obnova databáze může být velmi problematická a obtížná, a proto je lepší vytvořit záložní kopii databáze, než obnovovat poškozená data, a ať se stane cokoli, neměli byste zoufat, protože řešení lze najít i v těch nejobtížnějších situacích. A nyní zvážíme 2 případy.

První případ (klasický problém). Záloha, kterou nelze obnovit kvůli hodnotám NULL ve sloupci s omezením NOT NULL (proces obnovy byl spuštěn nad pracovním souborem). Pracovní soubor byl vymazán a proces obnovy byl přerušen kvůli chybě. A v důsledku bezmyšlenkovitých akcí jsme místo záložní kopie získali velké množství nepoužitelných dat (která nelze obnovit). Ale řešení bylo nalezeno. Programátorovi se podařilo vzpomenout si, která tabulka a který sloupec měly omezení NOT NULL. Záložní soubor byl načten do hexadecimálního editoru. A kombinace bajtů odpovídající definici tohoto sloupce byla nalezena vyhledáváním. Po nesčetných experimentech se ukázalo, že omezení NOT NULL přidává 1 poblíž názvu sloupce. V HEX editoru byla tato „1“ opravena na „0“ a záložní kopie byla obnovena. Po tomto případě si programátor navždy zapamatoval, jak provádět proces zálohování a obnovy.

Druhý případ. Situace byla katastrofální. Databáze byla poškozena ve fázi rozšiřování kvůli nedostatku místa na disku. Při zvětšování velikosti databáze server vytváří řadu kriticky důležitých stránek (například stránku inventáře transakcí a stránku inventáře stránek, další stránky pro relaci RDB$Pages) a zapisuje je na konec databáze. Výsledkem bylo, že se databáze neotevřela ani pomocí administrativních nástrojů, ani pomocí utility GBAK. A když jsme se pokusili připojit k databázi, objevila se chybová zpráva („Unexpected end of file“).

Když jsme spustili utilitu gfix, děly se podivné věci: Program pracoval v nekonečné smyčce. Když gfix pracoval, server zapisoval chyby do logu (soubor InterBase log) vysokou rychlostí (kolem 100 Kb za sekundu). Výsledkem bylo, že log soubor velmi rychle zaplnil veškeré volné místo na disku. Dokonce jsme museli napsat program, který tento log vymazával podle časovače. Tento proces trval dlouho - gfix pracoval více než 16 hodin bez jakýchkoli výsledků. Log byl zaplněn chybami následujícího typu: „Page XXX doubly allocated“. V počátečních zdrojích InterBase (v souboru val.#) je krátký popis této chyby. Říká se, že tato chyba se objeví, když je stejná datová stránka použita dvakrát. Je zřejmé, že tato chyba je výsledkem poškození kriticky důležitých stránek.

Výsledkem bylo, že po několika dnech neúspěšných experimentů byly pokusy o obnovu dat standardními způsoby opuštěny. A proto jsme museli použít nízkoúrovňovou analýzu dat uložených v poškozené databázi.

Alexander Kozelskiy, vedoucí oddělení informačních technologií East View Publications Inc, je autorem myšlenky, jak extrahovat informace z podobných neobnovitelných databází.

Metoda obnovy, kterou jsme získali jako výsledek výzkumu, byla založena na skutečnosti, že databáze má stránkovou organizaci a data z každé tabulky jsou shromažďována na datových stránkách. Každá datová stránka obsahuje identifikátor tabulky, pro kterou ukládá data. Bylo obzvláště důležité obnovit data z několika kritických tabulek. Byly tam data z podobných tabulek, získaná ze staré záložní kopie, která fungovala perfektně a mohla být vzorem. Vzorová databáze byla načtena do editoru hexadecimálních zdrojů a poté jsme hledali vzory těch dat, která nás zajímala. Tato data byla zkopírována do bufferu v hexadecimálním formátu a poté byly do editoru načteny zbytky poškozené databáze. Sekvence bajtů odpovídající vzoru byla nalezena v poškozené databázi a stránka byla analyzována (na které byla tato sekvence nalezena).

Nejprve jsme definovali počáteční stránku, ale nebylo to obtížné, protože velikost souboru databáze je dělitelná velikostí datové stránky. Číslo aktuálního bajtu dělené velikostí stránky - 8192 bajtů, aproximuje výsledek na celé číslo (a získali jsme číslo aktuální stránky). Poté jsme vynásobili číslo aktuální stránky velikostí stránky a získali číslo bajtu odpovídající začátku aktuální stránky. Po analýze hlavičky jsme definovali typ stránky (pro stránky s daty je typ 5 - viz soubor ods.h ze sady počátečních zdrojů InterBase a také kapitola „Struktura databáze InterBase“) a také identifikátor potřebné tabulky.

Poté byl napsán program, který analyzoval celou databázi, shromáždil všechny stránky pro potřebnou tabulku do jednoho celku a přesunul je do souboru.

Když jsme tedy získali data, která jsme potřebovali v první řadě, začali jsme analyzovat obsah vybraných stránek. InterBase široce používá kompresi dat pro úsporu místa. Například řetězec typu VARCHAR obsahující řetězec „ABC“ ukládá sekvenci následujících hodnot: délku řetězce (2 bajty), v našem případě 0003, a poté samotné symboly a poté kontrolní součet. Museli jsme napsat analyzátor řetězců a také dalších databázových typů, který převáděl data z hexadecimálního formátu do běžného zobrazení. Podařilo se nám extrahovat až 80 % informací z několika kritických tabulek pomocí „ruční“ metody analýzy obsahu databáze. Později na základě zkušeností Oleg Kulkov a Alexey Kovyazin, jeden z autorů této knihy, vyvinuli utilitu InterBase Surgeon, která provádí přímý přístup k databázi, obchází engine InterBase a umožňuje číst a interpretovat data v databázi InterBase správným způsobem.

Pomocí InterBase Surgeon se nám podařilo zjistit příčiny poškození a obnovit až 90 % naprosto neobnovitelných databází, které nelze otevřít pomocí InterBase a obnovit standardními metodami.

Tento program si můžete stáhnout z oficiálních stránek programu www.ib-aid.com.

3. Poděkování

Rád bych poděkoval všem, kteří mi pomohli vytvořit tuto příručku:

Craig Stuntz, Alexander Nevsky, Konstantin Sipachev, Tatjana Sipacheva a všem ostatním laskavým a znalým lidem z komunity InterBase a Firebird.

Pokud máte jakékoli návrhy nebo dotazy k této kapitole, neváhejte nám napsat e-mail.