Diese Seite wurde maschinell übersetzt. Lesen Sie das englische Original. English

IBSurgeon-Bibliothek

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

By Dmitry Kuzmenko, 24-Mai-2016

Was ist die On-Disk Structure (ODS)-Nummer

Einfach ausgedrückt ist ODS (On-Disk Structure) eine Nummer des Datenbankdateiformats für die jeweilige Firebird- oder InterBase-RDBMS-Version.

Fast alle Versionen verwenden ein sogenanntes „Y-Ventil“, um die aktuelle ODS und einige alte ODS zu unterstützen. Dies ermöglicht es dem Server, mit Datenbankdateien aus früheren Versionen zu arbeiten und den Übergang vom alten Server zu einem neuen zu vereinfachen. Es gibt jedoch einige Einschränkungen, die im Folgenden beschrieben werden.

Sie können die ODS Ihrer Datenbank herausfinden, indem Sie den folgenden Befehl ausführen:

Code
gstat -h database_file_name

Benutzer 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 von InterBase 4 bei einer Datenbank von Firebird 2 ausführen, zeigt es:

Code
Wrong ODS version, expected 8, encountered 32779?

Hier sehen Sie die ODS-Nummer 32779 - dies ist kodiert 11, mit dem hohen Bit, das seit Firebird 2.0 hinzugefügt wurde (in hexadezimal wäre es 800B, wobei B = 11), um Verwechslungen zwischen InterBase- und Firebird-Datenbanken zu vermeiden, da sie ab einem bestimmten Punkt die gleiche ODS-Nummer, aber ein sehr unterschiedliches Datenbankformat hatten. Eine Ausnahme, bei der Sie keine verständliche Meldung erhalten, ist, wenn gstat firebird.msg oder interbase.msg nicht finden kann. Es zeigt dann etwas wie:

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

Das bedeutet also, dass Sie eine falsche Firebird- oder InterBase-Installation haben und diese korrigieren 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.

Zum Beispiel, wenn der Firebird 1.5-Server versucht, eine Firebird 2.x-Datenbank zu öffnen:

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

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

Serverversion Haupt-ODS-Nummer Kann mit ODS arbeiten Hinweis
InterBase 4.0/4.1 8.0
InterBase 4.2 8.2 8.2 InterBase 4.2 erzwingt ein Upgrade von ODS 8.0 auf 8.2
InterBase 5.0/5.1 9.0 8.2 InterBase 5.x erzwingt ein Upgrade von ODS 8.0 auf 8.2
InterBase 5.5/5.6 9.1 8.2
InterBase 6.0
Firebird 1.0
Yaffil 1.0
10.0 9.0/9.1 Es ist gefährlich, mit ODS 9.x zu arbeiten, da neue InterBase- und Firebird-Versionen ein neues Metadatenformat verwenden, das von InterBase 5.x nicht erkannt wird
Firebird 1.5 10.1 9.0/9.1/10.0 ODS 10.1 von 64-Bit-Firebird 1.5 ist inkompatibel mit 32-Bit-ODS 10.1. Dies ist die einzige bekannte Inkompatibilität des Datenbankformats zwischen 32/64-Bit-Versionen.
InterBase 7.0 11.0 10.0 Inkompatibel mit ODS 11 von Firebird 2.x
InterBase 7.1 11.1 10.0 InterBase 7.5 wird InterBase ODS 11.0/11.1 auf 11.2 upgraden, was für frühere Versionen (7.0/7.1) inkompatibel ist
InterBase 7.5 11.2 10.0
Firebird 2.0 11.0 10.x ODS 11 von Firebird 2.0 ist inkompatibel mit InterBase 7.x
Firebird 2.1 11.1 10.x/11.0 ODS 11 von Firebird 2.0 ist inkompatibel mit InterBase 7.x
Firebird 2.5 11.2 10.x/11.x ODS 11.2 ist inkompatibel mit Firebird 2.0/2.1.
Firebird 3.0 12.0 Unterstützt keine früheren ODS, nur 12.0
Firebird 4.0 13.0 13.0
Firebird 5.0 13.1 13.0, 13.1 Die Datenbank kann mit gfix -upgrade von 13.0 auf 13.1 aktualisiert werden, oder mit Backup/Restore
InterBase 2007 12.0 11.x
InterBase 2009 13.1 12.0
InterBase XE, XE3 15.0 13.1 Wo ist ODS 14?
InterBase XE7 16.0 15, 13 Die „aktuelle“ ODS kann in IBCONFIG festgelegt werden. Auf diese Weise erstellt XE7 Datenbanken (einschließlich Restore) mit der angegebenen ODS (13, 15, 16) als Standard.

ODS-Upgrade

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

Manchmal kann der Server eine alte ODS ohne Benachrichtigung auf eine neuere upgraden. 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 die ODS auf 8.2 upgegradet, was für InterBase 4.0/4.1 nicht verständlich ist. Das kleinere Upgrade der ODS macht Datenbanken innerhalb derselben Hauptserverversion 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 auf der aktuellen Serverversion zu erstellen, sogar vor dem kleineren Upgrade Ihrer Serverversion.

Der Unterschied zwischen ODS (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 finden. Zum Beispiel hat ODS 9.0 im Vergleich zu 8.x deklarative referenzielle Integrität, SQL-Rollen und Garbage Collection in Indizes. Aber ODS 9.1 unterscheidet sich von 9.0 nur durch einen Index, der zu einer Systemtabelle hinzugefügt wurde.

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

Migration zwischen InterBase und Firebird

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

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

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

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

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

Dies muss durchgeführt werden, um zu überprüfen, ob es schlechte alte Metadaten in Ihrer Datenbank oder Fehler bei der Skriptextraktion auf dem verwendeten Server gibt. 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).

In diesem Fall kann es, wenn eine Datenbank vor langer Zeit erstellt und ständig geändert wurde, falsches (altes) BLR für einige Objekte geben. Diese Objekte können weiterhin funktionieren, aber der Versuch, sie neu zu erstellen (ALTER), kann einen Syntaxfehler (oder einen 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 pumpen.

Selbst wenn Sie versucht haben, auf dem alten Server ein Backup zu erstellen und auf dem neuen wiederherzustellen, 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 überprüfen, daher wird der Fehler erst später auftreten.

Wie Sie zur vorherigen Version von Firebird oder InterBase zurückkehren

Manchmal müssen Sie ein Downgrade durchführen und vom neuen Server zurückkehren. Die Gründe können variieren - ein plötzlicher Fehler im Server, Leistungsprobleme usw.

Wenn Sie das Backup vor dem Server-Upgrade erstellt haben, gibt es keine Probleme bei der Rückkehr. Wenn nicht, stehen Sie vor dem Problem, von der neuen ODS zur 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 wie folgt zu X-1 zurückkehren:

  1. Nehmen Sie das gbak-Dienstprogramm von 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 bei Schritt 1 Probleme gibt, können Sie 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 Servern X und X-1 inkompatibel sein kann. Daher ist es besser, den Servernamen anzugeben:

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

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

Hier sind Beispiele:

  • Von 5.x auf 4.2 - keine Rollen und keine neue deklarative referenzielle 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 booleschen Spalten und keine Objektnamen länger als 31 Zeichen
  • Von Firebird 1.5 auf InterBase - keine BIGINT-Spalten und keine neuen SQL-Erweiterungen in Triggern und Prozeduren
  • Von Firebird 2.0 auf Firebird 1.5 - keine der neuen Firebird 2.0-Funktionen
  • Und so weiter

Wenn es immer noch Fehler gibt, die nicht behoben werden können, ist der einzige Weg, die Datenbank auf dem X-1-Server aus dem SQL-Skript zu erstellen und Daten zu pumpen.

Firebird-Migrationsservice

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

Zum Beispiel haben wir eine Datenbank migriert, 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.

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