Alle Firebird- und InterBase-On-Disk-Structure-(ODS-)Versionen

Von Dmitry Kuzmenko, 24. Mai 2016

Was ist die On-Disk Structure (ODS) Number

Einfach gesagt ist ODS (On-Disk Structure) eine Nummer für das Datenbankdateiformat einer bestimmten Version des Firebird- oder InterBase-RDBMS.

Fast alle Versionen verwenden das sogenannte „Y-valve“, um das aktuelle ODS und einige ältere ODS zu unterstützen. Dadurch kann der Server mit Datenbankdateien aus früheren Versionen arbeiten und den Übergang vom alten Server auf einen neuen vereinfachen. Es gibt jedoch einige Einschränkungen, die im Folgenden beschrieben werden.

Sie können das ODS Ihrer Datenbank mit folgendem Befehl ermitteln:

gstat -h database_file_name

Benutzername und Passwort sind hier nicht erforderlich, da gstat mit der Option -h nur den physischen Teil der Datenbank liest (Header-Seite, Nummer 0).

Wenn gstat die gelesenen Informationen nicht versteht, zeigt es eine entsprechende Meldung an – was es erwartet hat und was es gefunden hat.

Wenn wir beispielsweise gstat aus InterBase 4 auf eine Datenbank von Firebird 2 anwenden, wird Folgendes angezeigt:

Wrong ODS version, expected 8, encountered 32779?

Hier sehen Sie die ODS-Nummer 32779 – das ist die kodierte 11, mit dem seit Firebird 2.0 hinzugefügten höchsten Bit (in Hex ist das 800B, wobei B = 11), um Verwechslungen zwischen InterBase- und Firebird-Datenbanken zu vermeiden, da sie ab einem bestimmten Punkt dieselbe ODS-Nummer hatten, aber ein sehr unterschiedliches Datenbankformat. Die Ausnahme von einer verständlichen Meldung ist, wenn gstat firebird.msg oder interbase.msg nicht finden kann. Dann wird etwa Folgendes angezeigt:

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

Das bedeutet also, dass Sie eine fehlerhafte Firebird- oder InterBase-Installation haben und diese reparieren müssen.

Einige Beispiele:

Wrong ODS version, expected 8, encountered 32779? – InterBase 4.x versucht, eine Firebird 2.x-Datenbank zu öffnen

Wrong ODS version, expected 8, encountered 13? – InterBase 4.x versucht, eine InterBase 2009-Datenbank zu öffnen

Wrong ODS version, expected 15, encountered 32779 – InterBase XE/XE3 versucht, eine Firebird 2.x-Datenbank zu öffnen

Wrong ODS version, expected 11, encountered 11 – Firebird 2.x versucht, eine InterBase 7.x-Datenbank zu öffnen

Wrong ODS version, expected 11, encountered 15 – Firebird 2.x versucht, eine InterBase XE/XE3-Datenbank zu öffnen

Manchmal erhalten Sie eine andere Art von Meldung, vom Server (nicht von gstat), aber mit derselben Bedeutung.

Wenn beispielsweise der Firebird 1.5-Server versucht, eine Firebird 2.x-Datenbank zu öffnen:

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

Hier sehen Sie die Tabelle der ODS-Versionen seit InterBase 4.0 (1994).

ODS-Upgrade

Jede Serverversion verwendet (außer InterBase XE7) immer ihre Haupt-ODS-Nummer für die erstellte oder wiederhergestellte Datenbank. Wenn das ODS der Datenbank kleiner ist als das Haupt-ODS des Servers, kann der Server mit dieser Datenbank arbeiten, sofern er deren ODS unterstützt.

Manchmal kann der Server ein altes ODS ohne Benachrichtigung auf ein neueres aktualisieren. Dies kann dazu führen, dass eine Rückkehr zur vorherigen Version unmöglich wird. Wenn Sie beispielsweise eine Datenbank mit ODS 8.0 mit InterBase 4.2 öffnen, wird das ODS auf 8.2 aktualisiert, was von InterBase 4.0/4.1 nicht verstanden wird. Das kleinere ODS-Upgrade macht also Datenbanken innerhalb derselben Haupt-Serverversion inkompatibel. Dies gilt auch für Firebird 2.5 und InterBase 7.5.

Um Probleme bei der Rückkehr zur vorherigen Version zu vermeiden, empfehlen wir, Backups mit der aktuellen Serverversion durchzuführen, noch bevor Sie ein kleineres Upgrade Ihrer Serverversion vornehmen.

Der Unterschied zwischen ODS-Versionen (Haupt- oder Nebenversion) kann groß oder klein sein. Wenn Sie neugierig genug sind, können Sie jrd\ods.h (Firebird Open Source) öffnen und die Unterschiede zwischen den ODS-Versionen finden. Beispielsweise hat ODS 9.0 im Vergleich zu 8.x deklarative referentielle Integrität, SQL-Rollen und Garbage Collection in Indizes. ODS 9.1 unterscheidet sich von 9.0 jedoch nur durch einen Index, der zu einer Systemtabelle hinzugefügt wurde.

Beachten Sie, dass eine Haupt-ODS-Version nicht im laufenden Betrieb aktualisiert werden kann. Sie können sie nur durch Backup/Restore aktualisieren.

Migration zwischen InterBase und Firebird

Die letzten Versionen von Firebird (3.0) und InterBase (XE7) sind sehr unterschiedlich, sowohl in Bezug auf Funktionen als auch auf ODS. Wie bereits erwähnt, war das letzte gemeinsame ODS 10, und seitdem (Firebird 2.0 und InterBase 7.0) sind die Datenbanken mit ihrem Format inkompatibel.

Die Migration wird also einfacher sein, wenn Sie seit InterBase 7.x oder Firebird 1.5 keine Funktionen verwendet haben. Wenn doch, hängt die Komplexität der Migration davon ab, wie viele Funktionen Sie in der Datenbank oder im Administrationsprozess verwendet haben.

Derzeit ist nach vielen Jahren der Entwicklung von Firebird und InterBase die Migration zwischen den neuesten Versionen dieser Server schwierig.

Wenn Sie es dennoch versuchen, müssen Sie ein Metadaten-Skript aus der Datenbank extrahieren und dann versuchen, mit demselben Server eine neue Datenbank aus diesem Skript zu erstellen.

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

Dies muss durchgeführt werden, um zu prüfen, ob es schlechte alte Metadaten in Ihrer Datenbank gibt oder Fehler bei der Skriptextraktion im verwendeten Server. InterBase und Firebird speichern Prozeduren, Trigger und Views (und einige andere Objekte) in kompilierter Form (BLR – Binary Language Representation), und während Backup/Restore werden Metadaten nicht neu kompiliert (von SQL zu BLR).

Wenn eine Datenbank vor langer Zeit erstellt und ständig geändert wurde, kann es in diesem Fall für einige Objekte fehlerhaftes (altes) BLR geben. Diese Objekte können weiterhin funktionieren, aber der Versuch, sie neu zu erstellen (ALTER), kann einen Syntax- (oder anderen) Fehler auslösen.

Dann können Sie versuchen, eine Datenbank aus dem korrigierten Skript auf dem neuen Server zu erstellen. Nachdem Sie alle Inkompatibilitäten in diesem Skript behoben haben, können Sie Daten von der alten Datenbank in die neue Datenbank übertragen.

Selbst wenn Sie ein Backup auf dem alten Server durchgeführt und auf dem neuen wiederhergestellt haben und es funktioniert hat – vertrauen Sie dem niemals. Wenn Ihre Datenbank viele Objekte enthält, können Sie nicht alle auf einmal auf dem neuen Server prüfen, sodass der Fehler erst einige Zeit später auftritt.

Wie man zur vorherigen Version von Firebird oder InterBase zurückkehrt

Manchmal müssen Sie möglicherweise ein Downgrade durchführen und vom neuen Server zurückkehren. Die Gründe können unterschiedlich sein – ein plötzlicher Fehler im Server, Performance-Probleme und so weiter.

Wenn Sie das Backup vor dem Server-Upgrade erstellt haben, wird es keine Probleme geben, zurückzukehren. Wenn nicht, stehen Sie vor dem Problem, vom neuen ODS zum alten ODS zurückzukehren.

Dazu benötigen Sie 2 Computer mit dem neuen Server und dem alten. Wenn Sie keine neuen Funktionen von Server X (Version von InterBase oder Firebird) verwendet haben, können Sie mit folgenden Schritten zu X-1 zurückkehren:

1. Nehmen Sie das gbak-Dienstprogramm vom Server X-1 und erstellen Sie damit ein Backup auf Server X
2. Übertragen Sie das Backup auf den X-1-Server und stellen Sie es wieder her

Wenn es beim 1. Schritt Probleme gibt, können Sie Folgendes versuchen:

1. Erstellen Sie ein Backup auf Server X mit dessen gbak
2. Kopieren Sie das gbak-Dienstprogramm von X nach X-1
3. Stellen Sie das Backup auf X-1 mit gbak von X wieder her

Beachten Sie, dass das lokale Protokoll zwischen den Servern X und X-1 inkompatibel sein kann, daher ist es besser, den Servernamen anzugeben:

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

Das Ergebnis wird nur unter der Bedingung erfolgreich sein, dass Sie seit dem Upgrade von X-1 keine der Datenbankobjekte auf Server X geändert haben.

Hier sind Beispiele:

• Von 5.x auf 4.2 – keine Rollen und neue deklarative referentielle Integrität dürfen verwendet werden
• Von 6.x auf 5.x – keine Metadatenänderungen, da 6.x das neue BLR-Format verwendet
• Von InterBase 7.x auf Firebird – keine Boolean-Spalten und Objektnamen, die länger als 31 Zeichen sind.
• Von Firebird 1.5 auf InterBase – keine BIGINT-Spalten und neuen SQL-Erweiterungen in Triggern und Prozeduren
• Von Firebird 2.0 auf Firebird 1.5 – keine der neuen Funktionen von Firebird 2.0.
• Und so weiter

Wenn es weiterhin Fehler gibt, die nicht behoben werden können, besteht die einzige Möglichkeit darin, die Datenbank auf dem X-1-Server aus dem SQL-Skript zu erstellen und Daten zu übertragen.

Firebird-Migrationsservice

Oft ist die Migration eine komplexe Aufgabe, insbesondere bei älteren Firebird-Datenbanken, die von den ursprünglichen Entwicklern aufgegeben wurden. Unser Unternehmen bietet den umfassenden Migrationsservice für komplexe Firebird-Datenbanken an. Die reguläre Gebühr beträgt USD$2900.

Beispielsweise haben wir die Datenbank, deren SQL-Skript 55 Megabyte groß war, mit mehr als 5000 gespeicherten Prozeduren, 1000 Tabellen und mehreren tausend Ad-hoc-SQL-Abfragen, in weniger als 3 Monaten migriert.

Wenn Sie Fragen haben, kontaktieren Sie uns bitte unter [email protected]