Tutte le versioni Firebird e InterBase dell'On-Disk-Structure (ODS)

Di Dmitry Kuzmenko, 24-maggio-2016

Cos’è il numero ODS (On-Disk Structure)

In parole semplici, ODS (On-Disk Structure) è un numero del formato del file di database per una particolare versione di Firebird o InterBase RDBMS.

Quasi tutte le versioni utilizzano la cosiddetta “Y-valve” per supportare l’ODS corrente e alcuni ODS precedenti. Questo consente al server di lavorare con file di database di versioni precedenti e semplifica la transizione dal vecchio server a uno nuovo. Ma ci sono alcune limitazioni, che saranno descritte di seguito.

Puoi scoprire l’ODS del tuo database eseguendo il seguente comando

Code

gstat -h nome_file_database

Utente e password qui non sono necessari, perché gstat con l’opzione -h legge solo la parte fisica del database (pagina di intestazione, numero 0).

Se gstat non comprende le informazioni lette, mostrerà un messaggio corrispondente - cosa si aspettava e cosa ha trovato.

Ad esempio, se eseguiamo gstat da InterBase 4 su un database di Firebird 2, mostrerà

Code

Wrong ODS version, expected 8, encountered 32779?

Qui vedi il numero ODS 32779 - questo è 11 codificato, con il bit alto aggiunto da Firebird 2.0 (in esadecimale sarà 800B, dove B = 11), per evitare confusione tra database InterBase e Firebird, perché da un certo punto avevano lo stesso numero ODS, ma un formato di database molto diverso. L’eccezione per ottenere un messaggio comprensibile è quando gstat non riesce a trovare firebird.msg o interbase.msg. Mostrerà qualcosa come

Code

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

Quindi, questo significa che hai un’installazione errata di Firebird o InterBase e devi correggerla.

Alcuni esempi:

Wrong ODS version, expected 8, encountered 32779? - InterBase 4.x tenta di aprire un database Firebird 2.x

Wrong ODS version, expected 8, encountered 13? - InterBase 4.x tenta di aprire un database InterBase 2009

Wrong ODS version, expected 15, encountered 32779 - InterBase XE/XE3 tenta di aprire un database Firebird 2.x

Wrong ODS version, expected 11, encountered 11 - Firebird 2.x tenta di aprire un database InterBase 7.x

Wrong ODS version, expected 11, encountered 15 - Firebird 2.x tenta di aprire un database InterBase XE/XE3

A volte puoi ottenere un altro tipo di messaggio, dal server (non da gstat) ma con lo stesso significato.

Ad esempio, quando il server Firebird 1.5 tenta di aprire un database Firebird 2.x:

Code

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

Qui puoi vedere la tabella delle versioni ODS, da InterBase 4.0 (1994).

Versione server	Numero ODS principale	Può funzionare con ODS	Nota
InterBase 4.0/4.1	8.0
InterBase 4.2	8.2	8.2	InterBase 4.2 aggiorna forzatamente ODS 8.0 a 8.2
InterBase 5.0/5.1	9.0	8.2	InterBase 5.x aggiorna forzatamente ODS 8.0 a 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	È pericoloso lavorare con ODS 9.x, perché i nuovi InterBase e Firebird usano un nuovo formato di metadati, che non è riconosciuto da InterBase 5.x
Firebird 1.5	10.1	9.0/9.1/10.0	L’ODS 10.1 di Firebird 1.5 a 64 bit è incompatibile con l’ODS 10.1 a 32 bit. Questa è l’unica incompatibilità nota del formato di database tra versioni 32/64 bit.
InterBase 7.0	11.0	10.0	Incompatibile con ODS 11 di Firebird 2.x
InterBase 7.1	11.1	10.0	InterBase 7.5 aggiornerà InterBase ODS 11.0/11.1 a 11.2, che è incompatibile per le versioni precedenti (7.0/7.1)
InterBase 7.5	11.2	10.0
Firebird 2.0	11.0	10.x	L’ODS 11 di Firebird 2.0 è incompatibile con InterBase 7.x
Firebird 2.1	11.1	10.x/11.0	L’ODS 11 di Firebird 2.0 è incompatibile con InterBase 7.x
Firebird 2.5	11.2	10.x/11.x	L’ODS 11.2 è incompatibile con Firebird 2.0/2.1.
Firebird 3.0	12.0	Non supporta ODS precedenti, solo 12.0
Firebird 4.0	13.0	13.0
Firebird 5.0	13.1	13.0, 13.1	Il database può essere aggiornato da 13.0 a 13.1 con gfix -upgrade da 13.0, o con backup/restore
InterBase 2007	12.0	11.x
InterBase 2009	13.1	12.0
InterBase XE, XE3	15.0	13.1	Dov’è l’ODS 14?
InterBase XE7	16.0	15, 13	L’ODS “corrente” può essere impostato in IBCONFIG. In questo modo XE7 creerà database (incluso il restore) con l’ODS specificato (13, 15, 16) come predefinito.

Aggiornamento ODS

Ogni versione del server utilizza sempre (tranne InterBase XE7) il suo numero ODS principale per il database creato o ripristinato. Se l’ODS del database è inferiore all’ODS principale del server, il server può lavorare con quel database se ne supporta l’ODS.

A volte il server può aggiornare un vecchio ODS a uno più recente, senza notifica. Questo può portare all’impossibilità di tornare alla versione precedente. Ad esempio, se apri un database con ODS 8.0 con InterBase 4.2, aggiornerà l’ODS a 8.2, che non è comprensibile da InterBase 4.0/4.1. Quindi, l’aggiornamento minore dell’ODS rende i database incompatibili all’interno della stessa versione maggiore del server. Questo vale anche per Firebird 2.5 e InterBase 7.5.

Per evitare problemi di ritorno alla versione precedente, raccomandiamo di eseguire backup sulla versione corrente del server anche prima dell’aggiornamento minore della versione del server.

La differenza tra ODS (maggiore o minore) può essere enorme o piccola. Se sei abbastanza curioso, puoi aprire jrd\ods.h (Firebird open source) e trovare le differenze tra gli ODS. Ad esempio, l’ODS 9.0 rispetto all'8.x ha integrità referenziale dichiarativa, ruoli SQL, garbage collection negli indici. Ma l’ODS 9.1 differisce dal 9.0 solo per un indice, aggiunto a qualche tabella di sistema.

Nota che la versione maggiore dell’ODS non può essere aggiornata al volo. Puoi aggiornarla solo tramite backup/restore.

Migrazione tra InterBase e Firebird

Le ultime versioni di Firebird (3.0) e InterBase (XE7) sono molto diverse, per funzionalità e ODS. Come detto prima, l’ultimo comune era ODS 10, e da allora (Firebird 2.0 e InterBase 7.0) i database sono incompatibili nel loro formato.

Quindi, la migrazione sarà più facile se non hai utilizzato funzionalità da InterBase 7.x o Firebird 1.5. Se sì - la complessità della migrazione dipenderà da quante funzionalità hai usato nel database o nel processo di amministrazione.

Attualmente, dopo molti anni di sviluppo di Firebird e InterBase, la migrazione tra le ultime versioni di questi server è difficile.

In ogni caso, se provi a farlo, devi estrarre lo script dei metadati dal database e poi provare a creare il nuovo database da quello script, usando lo stesso server.

Code

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

Questo deve essere fatto per verificare se ci sono metadati vecchi errati nel tuo database o bug nell’estrazione dello script nel server che usi. InterBase e Firebird memorizzano procedure, trigger e viste (e alcuni altri oggetti) in forma compilata (BLR - Binary Language Representation), e durante il backup/restore i metadati non vengono ricompilati (da SQL a BLR).

In questo caso, se un database è stato creato molto tempo fa e costantemente modificato, possono esserci BLR errati (vecchi) per alcuni oggetti. Questi oggetti possono ancora funzionare, ma tentare di ricrearli (ALTER) può sollevare un errore di sintassi (o altro).

Poi puoi provare a creare un database dallo script corretto sul nuovo server. Dopo aver corretto tutte le incompatibilità in questo script, puoi trasferire i dati dal vecchio database al nuovo.

Anche se hai provato a fare un backup sul vecchio server e a ripristinarlo sul nuovo, e ha funzionato - non fidarti mai. Se il tuo database contiene molti oggetti, non puoi controllarli tutti in una volta sul nuovo server, quindi l’errore si presenterà qualche tempo dopo.

Come tornare alla versione precedente di Firebird o InterBase

A volte potresti aver bisogno di eseguire un downgrade e tornare dal nuovo server. Le ragioni possono variare - un bug improvviso nel server, problemi di prestazioni e così via.

Se hai fatto il backup prima dell’aggiornamento del server, non ci saranno problemi a tornare indietro. Ma se non l’hai fatto, affronterai il problema di tornare dal nuovo ODS al vecchio ODS.

Per farlo avrai bisogno di 2 computer con il nuovo server e quello vecchio. Se non hai usato alcuna nuova funzionalità del server X (versione di InterBase o Firebird), puoi tornare a X-1 seguendo questi passaggi:

Prendi l’utility gbak dal server X-1 e fai un backup usandola sul server X
Trasferisci il backup al server X-1 e ripristinalo

Se ci sono problemi al passaggio 1, puoi provare

Fai un backup sul server X, usando il suo gbak
Copia l’utility gbak da X a X-1
Ripristina il backup su X-1 usando gbak da X

Nota che il protocollo locale tra i server X e X-1 può essere incompatibile, quindi è meglio specificare il nome del server:

Code

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

Il risultato avrà successo solo a condizione che tu non abbia modificato nessuno degli oggetti del database sul server X da quando hai aggiornato da X-1.

Ecco alcuni esempi:

Da 5.x a 4.2 - nessun ruolo e nessuna nuova integrità referenziale dichiarativa deve essere usata
Da 6.x a 5.x - nessuna modifica dei metadati, perché 6.x usa un nuovo formato BLR
Da InterBase 7.x a Firebird - nessuna colonna boolean e nomi di oggetti più lunghi di 31 caratteri.
Da Firebird 1.5 a InterBase - nessuna colonna BIGINT e nuove estensioni SQL in trigger e procedure
Da Firebird 2.0 a Firebird 1.5 - nessuna delle nuove funzionalità di Firebird 2.0.
E così via

Se ci sono ancora errori che non possono essere corretti, l’unico modo è creare il database sul server X-1 dallo script SQL e trasferire i dati.

Servizio di migrazione Firebird

Spesso la migrazione è un compito complesso, specialmente per database Firebird legacy, che sono stati abbandonati dagli sviluppatori originali. La nostra azienda offre il servizio di migrazione completo per database Firebird complessi. La tariffa regolare è USD $2900.

Ad esempio, abbiamo migrato un database il cui script SQL era di 55 Megabyte, con più di 5000 stored procedure, 1000 tabelle e diverse migliaia di query SQL ad hoc, in meno di 3 mesi.

Se hai domande, contattaci a [email protected]