Poškození databází u FireBirdu
Je skutečností, že FireBird je velmi spolehlivým databázovým serverem a poškození databází není příliš častým jevem. Existují ovšem obecné příčiny poškození, které konekonců platí u téměř každého databázového systému.
Výčet příčin poškození databáze (platí pouze pro FireBird):
- abnormální ukončení práce fyzického serveru, na němž běží služba FireBird server, typicky přerušení dodávky napájení. Tato skutečnost je reálnou hrozbou a snad není třeba připomínat nutnost vybavení serveru nepřerušovaným zdrojem napájení – UPS. Bez ní by server vůbec neměl být provozován.
- defekty a fyzické poruchy hardwaru serveru, typicky pevného disku, řadiče pevného disku, operační paměti nebo vyrovnávací paměti řadiče RAID
- kopírování souboru databáze nebo jiný souborově založený přístup k ní v průběhu práce serveru. Použití příkazu Shutdown nebo odpojení uživatelů nemusí být zárukou toho, že server s databází v daném okamžiku nepracuje (může probíhat např. úklid databáze v závislosti na nastaveném parametru Sweep interval).
- vyčerpání volného místa na disku během práce serveru s databází
Nyní podrobněji k možným důsledkům přerušení napájení serveru:
Při přerušení napájení serveru jsou všechny aktivity v rámci zpracování dat přerušeny a většinou tak, že se jedná o nejnevhodnější a nejnebezpečnější okamžik. V jeho důsledku mohou být informace v databázi porušeny nebo úplně ztraceny. Nejjednodušším případem takového stavu je ztracení dat "na cestě", tzv. necommitovaných dat, která dosud nebyla transkačně zpracována a tedy nejsou zapsána fyzicky v databázi. Po restartu server vyhledá takovéto neúplné transkace a odstraní je.
Ztráta napájení není ovšem vždy doprovázena pouze takovýmito témeř bezškodními průběhy. Častěji se stává případ, kdy v databázi vznikají tzv. osiřelé (orphan) datové stránky – lze je charakterizovat jako stránky, jež jsou fyzicky alokovány, ale není možno do nich zapisovat informace. Vznik osiřelých stránek nemusí nutně vést k poškození databáze a tyto nepotřebné objekty mohou být odstraněny např. pomocí utility GFIX nebo jejím voláním v rámci EMS SQL Manageru.
Dalším častým důsledkem přerušení napájení je případ, za nějž je odpovědný operační systém, a spočívá ve zpožděném zápisu informací z vyrovnávací paměti do databáze. Serverový proces předá požadovaná data operačnímu systému, který pomocí zpětné vazby informuje databázový server o tom, že data byla zapsána do databáze, ve skutečnosti se ale ještě nacházejí v cache paměti. Operační systém přitom s přenosem dat z cache na disk nespěchá, neboť se snaží v maximální míře využít vyrovnávací paměť (až do jejího zaplnění) a teprve poté zapisuje fyzicky na disk.
Přitom existuje jednoduchá a zcela bezpečná cesta, jak předcházet poškození databáze z popsaných důvodů – vytváření záložních kopií pomocí utility GBAK nebo zprostředkovaně nástroji typu EMSM, Ibexpert a dalších. Platí přitom tři pravidla: zálohovat je třeba tak často, jak je to možné, zálohování musí být sériové a záložní kopie je třeba kontrolovat, zda z nich lze obnovu provést – toto poslední pravidlo je důležité zejména proto, že po provedení zálohy můžeme získat zálohu, která není fyzicky použitelná pro obnovení.
Rozumným intervalem pro zálohování je 1 den neboli každých 24 hodin – čím nižší je perioda mezi zálohami, tím menší je objem potenciálně ztracených dat v případě, že dojde k poškození databáze. Sériovost zálohování znamená, že dílčí zálohy je třeba uchovávat po nezbytně nutno dobu – doporučen je alespoň jeden týden – může se totiž stát, že při příliš rychlém mazání záloh již nebude k dispozici ta záloha, z níž by bylo možno databázi ještě obnovit, azůstanou pouze poslední zálohy, které pro obnovu nebude možno použít. Ke třetímu pravidlu, kontrole záloh, je třeba uvést, že časová náročnost může být až třikrát větší než časová náročnost vlastní zálohy. I tak se doporučuje kontrolovat, zda zálohu lze k obnově použít, alespoň jednou týdně.
Kontaktujte nás
Pokud máte zájem o naše služby či produkty, kontaktujte nás. Můžete k tomu použít následující formulář.
