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

Od Dmitrije Kuzmenka, 24. května 2016

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

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

Téměř všechny verze používají tzv. „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 své databáze zjistíte spuštěním následujícího příkazu

gstat -h database_file_name

Uživatelské jméno a heslo zde nejsou potřeba, protože gstat s volbou -h pouze čte fyzickou část databáze (hlavičková stránka, číslo 0).

Pokud gstat přečteným informacím nebude rozumět, zobrazí odpovídající zprávu – co očekával a co našel.

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

Wrong ODS version, expected 8, encountered 32779?

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

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

To tedy znamená, že máte nesprávnou instalaci Firebird nebo InterBase a musíte 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 dostat jiný druh zprávy, 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).

Povýšení ODS

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

Někdy může server povýšit starý ODS na nějaký novější, bez upozornění. To může vést k nemožnosti vrátit se zpět k předchozí verzi. Například pokud otevřete databázi s ODS 8.0 pomocí InterBase 4.2, povýší ODS na 8.2, čemuž InterBase 4.0/4.1 nerozumí. Takže drobné povýšení 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 k předchozí verzi, doporučujeme provádět zálohy na aktuální verzi serveru ještě před drobným povýšením 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ějaké 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) jsou velmi odlišné, co se týče funkcí a 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 navzájem nekompatibilní svým formátem.

Migrace tedy bude 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 v databázi nebo v procesu správy použili.

V současnosti, 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 z databáze extrahovat skript metadat 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 extrakce skriptu v serveru, který používáte. InterBase a Firebird ukládají procedury, triggery a pohledy (a některé další objekty) v kompilované podobě (BLR – Binary Language Representation) a během zálohy/obnovy se metadata nepřekompilovávají (z SQL do BLR).

V tomto případě, pokud byla databáze vytvořena dávno a neustále upravována, mohou pro některé objekty existovat nesprávné (staré) BLR. Tyto objekty mohou stále fungovat, ale pokus o jejich opětovné vytvoř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. Poté, co opravíte všechny nekompatibility v tomto skriptu, můžete přenést data ze staré databáze do nové databáze.

I když jste zkusili provést 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 na novém serveru zkontrolovat všechny najednou, takže chyba se objeví až po nějaké době.

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

Někdy může být nutné provést downgrade a vrátit se zpět z nového serveru. Důvody mohou být různé – náhlá chyba v serveru, problémy s výkonem a tak dále.

Pokud jste provedli zálohu před povýšením serveru, nebudou s návratem žádné problémy. 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 k X-1 podle těchto kroků:

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

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

1. Provést zálohu na serveru X pomocí jeho gbak
2. Zkopírovat nástroj gbak z X na X-1
3. Obnovit 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 od povýšení z X-1 nezměnili žádné objekty databáze na serveru X.

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á z nových funkcí Firebird 2.0.
• A tak dále

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

Služba migrace Firebird

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

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]