Všechny verze Firebird a InterBase On-Disk-Structure (ODS)

By Dmitry Kuzmenko, 24-May-2016

Co je číslo ODS (On-Disk Structure)

Jednoduše řečeno, ODS (On-Disk Structure) je číslo formátu databázového souboru pro konkrétní verzi Firebird nebo InterBase RDBMS.

Téměř všechny verze používají takzvaný „Y-valve“ pro podporu aktuálního ODS a některých starých ODS. To umožňuje serveru pracovat s databázovými soubory z předchozích verzí a zjednodušuje přechod ze starého serveru na nový. Existují však určitá omezení, která budou popsána dále.

ODS vaší databáze zjistíte spuštěním následujícího příkazu

gstat -h database_file_name

Uživatel a heslo zde nejsou nutné, protože gstat s volbou -h pouze čte fyzickou část databáze (hlavičkovou stránku, číslo 0).

Pokud gstat nerozumí přečteným informacím, zobrazí odpovídající hlášení - co očekával a co našel.

Například, pokud spustíme gstat z InterBase 4 na databázi z Firebird 2, zobrazí se

Wrong ODS version, expected 8, encountered 32779?

Zde vidíte číslo ODS 32779 - to je zakódované 11, s přidaným vysokým bitem od Firebird 2.0 (v hexadecimálním tvaru to bude 800B, kde B = 11), aby se předešlo záměně mezi databázemi InterBase a Firebird, protože od určitého bodu měly stejné číslo ODS, ale velmi odlišný formát databáze. Výjimkou pro získání srozumitelného hlášení je situace, kdy gstat nemůže najít firebird.msg nebo interbase.msg. Zobrazí se něco jako

can't format message 21:3 -- message file ...msg not found

To znamená, že máte nesprávnou instalaci Firebird nebo InterBase a je třeba ji opravit.

Několik příkladů:

Wrong ODS version, expected 8, encountered 32779? - InterBase 4.x se pokouší otevřít databázi Firebird 2.x

Wrong ODS version, expected 8, encountered 13? - InterBase 4.x se pokouší otevřít databázi InterBase 2009

Wrong ODS version, expected 15, encountered 32779 - InterBase XE/XE3 se pokouší otevřít databázi Firebird 2.x

Wrong ODS version, expected 11, encountered 11 - Firebird 2.x se pokouší otevřít databázi InterBase 7.x

Wrong ODS version, expected 11, encountered 15- Firebird 2.x se pokouší otevřít databázi InterBase XE/XE3

Někdy můžete získat jiný druh hlášení, ze serveru (ne z gstat), ale se stejným významem.

Například, když se server Firebird 1.5 pokouší otevřít databázi Firebird 2.x:

unsupported on-disk structure for file ...; found 32779, support 10

Zde vidíte tabulku verzí ODS, od InterBase 4.0 (1994).

Upgrade ODS

Každá verze serveru vždy používá (kromě InterBase XE7) své hlavní číslo ODS pro vytvořenou nebo obnovenou databázi. Pokud je ODS databáze nižší než hlavní ODS serveru, může server s touto databází pracovat, pokud její ODS podporuje.

Někdy může server povýšit starý ODS na novější, bez upozornění. To může vést k nemožnosti návratu na předchozí verzi. Například, pokud otevřete databázi s ODS 8.0 pomocí InterBase 4.2, povýší ODS na 8.2, kterému InterBase 4.0/4.1 nerozumí. Takže menší upgrade ODS činí databáze nekompatibilními v rámci stejné hlavní verze serveru. To platí také pro Firebird 2.5 a InterBase 7.5.

Abychom se vyhnuli problémům s návratem na předchozí verzi, doporučujeme provádět zálohy na aktuální verzi serveru ještě před menším upgradem verze serveru.

Rozdíl mezi ODS (hlavním nebo vedlejším) může být obrovský nebo malý. Pokud jste dostatečně zvědaví, můžete otevřít jrd\ods.h (Firebird open source) a najít rozdíly mezi ODS. Například ODS 9.0 ve srovnání s 8.x má deklarativní referenční integritu, SQL role, garbage collection v indexech. Ale ODS 9.1 se od 9.0 liší pouze jedním indexem, přidaným do některé systémové tabulky.

Všimněte si, že hlavní verzi ODS nelze povýšit za běhu. Můžete ji povýšit pouze pomocí zálohy/obnovy.

Migrace mezi InterBase a Firebird

Poslední verze Firebird (3.0) a InterBase (XE7) se velmi liší, funkcemi i ODS. Jak bylo řečeno dříve, poslední společný byl ODS 10, a od té doby (Firebird 2.0 a InterBase 7.0) jsou databáze nekompatibilní svým formátem.

Migrace bude tedy snazší, pokud jste nepoužívali funkce od InterBase 7.x nebo Firebird 1.5. Pokud ano - složitost migrace bude záviset na tom, kolik funkcí jste použili v databázi nebo v procesu správy.

V současné době, po mnoha letech vývoje Firebird a InterBase, je migrace mezi nejnovějšími verzemi těchto serverů obtížná.

V každém případě, pokud se o to pokusíte, musíte extrahovat skript metadat z databáze a poté se pokusit vytvořit novou databázi z tohoto skriptu pomocí stejného serveru.

isql -x db.gdb …
isql -i script.ddl …

To je třeba provést, abyste zkontrolovali, zda ve vaší databázi nejsou nějaká špatná stará metadata nebo chyby v extrakci skriptu na serveru, který používáte. InterBase a Firebird ukládají procedury, triggery a pohledy (a některé další objekty) v kompilované formě (BLR - Binary Language Representation), a během zálohy/obnovy nejsou metadata znovu kompilována (z SQL do BLR).

V tomto případě, pokud byla databáze vytvořena dávno a neustále upravována, může být pro některé objekty nesprávné (staré) BLR. Tyto objekty mohou stále fungovat, ale pokus o jejich znovuvytvoření (ALTER) může vyvolat syntaktickou (nebo jinou) chybu.

Poté můžete zkusit vytvořit databázi z opraveného skriptu na novém serveru. Po opravě všech nekompatibilit v tomto skriptu můžete přečerpat data ze staré databáze do nové.

I když jste zkusili zálohu na starém serveru a obnovu na novém, a fungovalo to - nikdy tomu nevěřte. Pokud vaše databáze obsahuje mnoho objektů, nemůžete je všechny najednou zkontrolovat na novém serveru, takže chyba se objeví až později.

Jak se vrátit k předchozí verzi Firebird nebo InterBase

Někdy můžete potřebovat provést downgrade a vrátit se zpět z nového serveru. Důvody se mohou lišit - náhlá chyba v serveru, problémy s výkonem atd.

Pokud jste provedli zálohu před upgradem serveru, nebude problém se vrátit zpět. Ale pokud ne, narazíte na problém návratu z nového ODS na starý ODS.

K tomu budete potřebovat 2 počítače s novým serverem a starým. Pokud jste nepoužili žádné nové funkce serveru X (verze InterBase nebo Firebird), můžete se vrátit na X-1 podle těchto kroků:

1. Vezměte utilitu gbak ze serveru X-1 a proveďte s ní zálohu na serveru X
2. Přeneste zálohu na server X-1 a obnovte ji

Pokud se v kroku 1 vyskytnou nějaké problémy, můžete zkusit

1. Proveďte zálohu na serveru X pomocí jeho gbak
2. Zkopírujte utilitu gbak z X na X-1
3. Obnovte zálohu na X-1 pomocí gbak z X

Všimněte si, že lokální protokol mezi servery X a X-1 může být nekompatibilní, takže je lepší zadat název serveru:

gbak -b localhost:c:\dir\data.gdb

Výsledek bude úspěšný pouze za podmínky, že jste na serveru X nezměnili žádné databázové objekty od doby, kdy jste povýšili z X-1.

Zde jsou příklady:

• Z 5.x na 4.2 - nesmí být použity žádné role a nová deklarativní referenční integrita
• Z 6.x na 5.x - žádné změny metadat, protože 6.x používá nový formát BLR
• Z InterBase 7.x na Firebird - žádné boolean sloupce a názvy objektů delší než 31 znaků.
• Z Firebird 1.5 na InterBase - žádné BIGINT sloupce a nová SQL rozšíření v triggerech a procedurách
• Z Firebird 2.0 na Firebird 1.5 - žádná nová funkcionalita Firebird 2.0.
• A tak dále

Pokud se stále vyskytují chyby, které nelze opravit, jediným způsobem je vytvořit databázi na serveru X-1 z SQL skriptu a přečerpat data.

Služba migrace Firebird

Migrace je často složitý úkol, zejména pro starší databáze Firebird, které byly opuštěny původními vývojáři. Naše společnost nabízí komplexní migrační službu pro složité databáze Firebird. Běžný poplatek je USD$2900.

Například jsme migrovali databázi, jejíž SQL skript měl 55 megabajtů, s více než 5000 uloženými procedurami, 1000 tabulkami a několika tisíci ad hoc SQL dotazy, za méně než 3 měsíce.

Pokud máte jakékoli dotazy, kontaktujte nás prosím na [email protected]