Wszystkie wersje struktury dyskowej (ODS) Firebird i InterBase

autor: Dmitry Kuzmenko, 24 maja 2016

Czym jest numer On-Disk Structure (ODS)

Mówiąc najprościej, ODS (On-Disk Structure) to numer formatu pliku bazy danych dla konkretnej wersji Firebird lub InterBase RDBMS.

Prawie wszystkie wersje używają tzw. „Y-valve” do obsługi bieżącego ODS i niektórych starszych ODS. Pozwala to serwerowi pracować z plikami baz danych z poprzednich wersji i upraszcza przejście ze starego serwera na nowy. Istnieją jednak pewne ograniczenia, które zostaną opisane dalej.

Możesz sprawdzić ODS swojej bazy danych, uruchamiając następujące polecenie

gstat -h database_file_name

Nazwa użytkownika i hasło nie są tu potrzebne, ponieważ gstat z opcją -h odczytuje tylko fizyczną część bazy danych (stronę nagłówka, numer 0).

Jeśli gstat nie zrozumie odczytanych informacji, wyświetli odpowiedni komunikat — czego oczekiwał i co znalazł.

Na przykład, jeśli uruchomimy gstat z InterBase 4 na bazie danych z Firebird 2, wyświetli

Wrong ODS version, expected 8, encountered 32779?

Tutaj widzisz numer ODS 32779 — jest to zakodowana wartość 11 z dodanym najwyższym bitem od Firebird 2.0 (w systemie szesnastkowym będzie to 800B, gdzie B = 11), aby uniknąć pomyłek między bazami danych InterBase i Firebird, ponieważ od pewnego momentu miały one ten sam numer ODS, ale bardzo różny format bazy danych. Wyjątkiem od otrzymania zrozumiałego komunikatu jest sytuacja, gdy gstat nie może znaleźć firebird.msg lub interbase.msg. Wtedy wyświetli coś w rodzaju

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

Oznacza to, że masz nieprawidłową instalację Firebird lub InterBase i musisz ją naprawić.

Kilka przykładów:

Wrong ODS version, expected 8, encountered 32779? — InterBase 4.x próbuje otworzyć bazę danych Firebird 2.x

Wrong ODS version, expected 8, encountered 13? — InterBase 4.x próbuje otworzyć bazę danych InterBase 2009

Wrong ODS version, expected 15, encountered 32779 — InterBase XE/XE3 próbuje otworzyć bazę danych Firebird 2.x

Wrong ODS version, expected 11, encountered 11 — Firebird 2.x próbuje otworzyć bazę danych InterBase 7.x

Wrong ODS version, expected 11, encountered 15 — Firebird 2.x próbuje otworzyć bazę danych InterBase XE/XE3

Czasami możesz otrzymać inny rodzaj komunikatu, z serwera (nie z gstat), ale o tym samym znaczeniu.

Na przykład, gdy serwer Firebird 1.5 próbuje otworzyć bazę danych Firebird 2.x:

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

Tutaj możesz zobaczyć tabelę wersji ODS od InterBase 4.0 (1994).

Aktualizacja ODS

Każda wersja serwera zawsze używa (z wyjątkiem InterBase XE7) swojego głównego numeru ODS dla tworzonej lub przywracanej bazy danych. Jeśli ODS bazy danych jest mniejszy niż główny ODS serwera, serwer może pracować z tą bazą danych, jeśli obsługuje jej ODS.

Czasami serwer może zaktualizować stary ODS do jakiegoś nowszego bez powiadomienia. Może to prowadzić do niemożności powrotu do poprzedniej wersji. Na przykład, jeśli otworzysz bazę danych z ODS 8.0 za pomocą InterBase 4.2, zaktualizuje ona ODS do 8.2, który nie jest zrozumiały dla InterBase 4.0/4.1. Zatem drobna aktualizacja ODS czyni bazy danych niezgodnymi w obrębie tej samej głównej wersji serwera. Dotyczy to również Firebird 2.5 i InterBase 7.5.

Aby uniknąć problemów z powrotem do poprzedniej wersji, zalecamy wykonywanie kopii zapasowych na bieżącej wersji serwera jeszcze przed drobną aktualizacją wersji serwera.

Różnica między ODS (głównym lub drobnym) może być ogromna lub niewielka. Jeśli jesteś wystarczająco ciekawy, możesz otworzyć jrd\ods.h (Firebird open source) i znaleźć różnice między ODS. Na przykład ODS 9.0 w porównaniu z 8.x ma deklaratywną integralność referencyjną, role SQL, garbage collection w indeksach. Ale ODS 9.1 różni się od 9.0 tylko jednym indeksem dodanym do pewnej tabeli systemowej.

Należy zauważyć, że głównej wersji ODS nie można zaktualizować w locie. Można ją zaktualizować tylko przez backup/restore.

Migracja między InterBase i Firebird

Ostatnie wersje Firebird (3.0) i InterBase (XE7) bardzo się różnią, zarówno pod względem funkcji, jak i ODS. Jak wspomniano wcześniej, ostatnim wspólnym był ODS 10, a od tego czasu (Firebird 2.0 i InterBase 7.0) bazy danych są niezgodne pod względem formatu.

Zatem migracja będzie łatwiejsza, jeśli nie używałeś funkcji od czasów InterBase 7.x lub Firebird 1.5. Jeśli tak — złożoność migracji będzie zależeć od tego, ile funkcji użyłeś w bazie danych lub w procesie administracji.

Obecnie, po wielu latach rozwoju Firebird i InterBase, migracja między najnowszymi wersjami tych serwerów jest trudna.

W każdym razie, jeśli spróbujesz to zrobić, musisz wyodrębnić skrypt metadanych z bazy danych, a następnie spróbować utworzyć nową bazę danych z tego skryptu, używając tego samego serwera.

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

Należy to zrobić, aby sprawdzić, czy w bazie danych nie ma złych starych metadanych lub błędów wyodrębniania skryptu w używanym serwerze. InterBase i Firebird przechowują procedury, wyzwalacze i widoki (oraz niektóre inne obiekty) w formie skompilowanej (BLR — Binary Language Representation), a podczas backup/restore metadane nie są rekompilowane (z SQL do BLR).

W tym przypadku, jeśli baza danych została utworzona dawno temu i stale modyfikowana, dla niektórych obiektów może istnieć nieprawidłowy (stary) BLR. Te obiekty mogą nadal działać, ale próba ich odtworzenia (ALTER) może wywołać błąd składni (lub inny).

Następnie możesz spróbować utworzyć bazę danych z poprawionego skryptu na nowym serwerze. Po naprawieniu wszystkich niezgodności w tym skrypcie możesz przenieść dane ze starej bazy danych do nowej.

Nawet jeśli spróbowałeś wykonać backup na starym serwerze i restore na nowym, i to zadziałało — nigdy temu nie ufaj. Jeśli Twoja baza danych zawiera wiele obiektów, nie możesz sprawdzić wszystkich naraz na nowym serwerze, więc błąd pojawi się jakiś czas później.

Jak wrócić do poprzedniej wersji Firebird lub InterBase

Czasami możesz potrzebować wykonać downgrade i wrócić z nowego serwera. Powody mogą być różne — nagły błąd w serwerze, problemy z wydajnością i tak dalej.

Jeśli wykonałeś kopię zapasową przed aktualizacją serwera, nie będzie problemów z powrotem. Ale jeśli nie, napotkasz problem powrotu z nowego ODS do starego ODS.

Aby to zrobić, będziesz potrzebować 2 komputerów z nowym serwerem i starym. Jeśli nie używałeś żadnych nowych funkcji serwera X (wersji InterBase lub Firebird), możesz wrócić do X-1, wykonując następujące kroki:

1. Weź narzędzie gbak z serwera X-1 i wykonaj nim backup na serwerze X
2. Przenieś backup na serwer X-1 i wykonaj restore

Jeśli na kroku 1 pojawią się problemy, możesz spróbować

1. Wykonaj backup na serwerze X, używając jego gbak
2. Skopiuj narzędzie gbak z X do X-1
3. Wykonaj restore backupu na X-1, używając gbak z X

Należy zauważyć, że lokalny protokół między serwerami X i X-1 może być niezgodny, więc lepiej podać nazwę serwera:

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

Wynik będzie pomyślny tylko pod warunkiem, że nie zmieniłeś żadnych obiektów bazy danych na serwerze X od czasu aktualizacji z X-1.

Oto przykłady:

• Z 5.x do 4.2 — nie można używać ról ani nowej deklaratywnej integralności referencyjnej
• Z 6.x do 5.x — żadnych zmian metadanych, ponieważ 6.x używa nowego formatu BLR
• Z InterBase 7.x do Firebird — żadnych kolumn boolean i nazw obiektów dłuższych niż 31 znaków.
• Z Firebird 1.5 do InterBase — żadnych kolumn BIGINT i nowych rozszerzeń SQL w wyzwalaczach i procedurach
• Z Firebird 2.0 do Firebird 1.5 — żadnej nowej funkcjonalności Firebird 2.0.
• I tak dalej

Jeśli nadal występują błędy, których nie można naprawić, jedynym sposobem jest utworzenie bazy danych na serwerze X-1 ze skryptu SQL i przeniesienie danych.

Usługa migracji Firebird

Często migracja jest złożonym zadaniem, szczególnie w przypadku starszych baz danych Firebird, które zostały porzucone przez pierwotnych deweloperów. Nasza firma oferuje kompleksową usługę migracji dla złożonych baz danych Firebird. Standardowa opłata wynosi 2900 USD.

Na przykład zmigrowaliśmy bazę danych, której skrypt SQL miał 55 megabajtów, z ponad 5000 procedurami składowanymi, 1000 tabel i kilkoma tysiącami doraźnych zapytań SQL, w mniej niż 3 miesiące.

Jeśli masz jakiekolwiek pytania, skontaktuj się z nami [email protected]