Toutes les versions Firebird et InterBase de la structure sur disque (ODS)

By Dmitry Kuzmenko, 24-May-2016

Qu’est-ce que le numéro ODS (On-Disk Structure)

En termes simples, l’ODS (On-Disk Structure) est un numéro de format de fichier de base de données pour une version particulière de Firebird ou InterBase RDBMS.

Presque toutes les versions utilisent ce qu’on appelle la « Y-valve » pour prendre en charge l’ODS actuel et certains anciens ODS. Cela permet au serveur de travailler avec des fichiers de base de données de versions précédentes et de simplifier la transition de l’ancien serveur vers un nouveau. Mais il y a certaines limitations, qui seront décrites plus loin.

Vous pouvez connaître l’ODS de votre base de données en exécutant la commande suivante

gstat -h database_file_name

L’utilisateur et le mot de passe ne sont pas nécessaires ici, car gstat avec l’option -h lit uniquement la partie physique de la base de données (page d’en-tête, numéro 0).

Si gstat ne comprend pas les informations lues, il affichera un message correspondant - ce qu’il attendait et ce qu’il a trouvé.

Par exemple, si nous exécutons gstat depuis InterBase 4 sur une base de données de Firebird 2, il affichera

Wrong ODS version, expected 8, encountered 32779?

Ici, vous voyez le numéro ODS 32779 - c’est 11 encodé, avec le bit de poids fort ajouté depuis Firebird 2.0 (en hexadécimal ce sera 800B, où B = 11), pour éviter toute confusion entre les bases de données InterBase et Firebird, car à un certain moment elles avaient le même numéro ODS, mais un format de base de données très différent. L’exception pour obtenir un message compréhensible est lorsque gstat ne peut pas trouver firebird.msg ou interbase.msg. Il affichera quelque chose comme

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

Donc, cela signifie que votre installation Firebird ou InterBase est incorrecte et doit être corrigée.

Quelques exemples :

Wrong ODS version, expected 8, encountered 32779? - InterBase 4.x essaie d’ouvrir une base de données Firebird 2.x

Wrong ODS version, expected 8, encountered 13? - InterBase 4.x essaie d’ouvrir une base de données InterBase 2009

Wrong ODS version, expected 15, encountered 32779 - InterBase XE/XE3 essaie d’ouvrir une base de données Firebird 2.x

Wrong ODS version, expected 11, encountered 11 - Firebird 2.x essaie d’ouvrir une base de données InterBase 7.x

Wrong ODS version, expected 11, encountered 15 - Firebird 2.x essaie d’ouvrir une base de données InterBase XE/XE3

Parfois, vous pouvez obtenir un autre type de message, provenant du serveur (pas de gstat) mais avec la même signification.

Par exemple, lorsque le serveur Firebird 1.5 essaie d’ouvrir une base de données Firebird 2.x :

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

Vous pouvez voir ici le tableau des versions ODS, depuis InterBase 4.0 (1994).

Mise à niveau de l’ODS

Chaque version du serveur utilise toujours (sauf InterBase XE7) son numéro ODS principal pour la base de données créée ou restaurée. Si l’ODS de la base de données est inférieur à l’ODS principal du serveur, le serveur peut travailler avec cette base de données s’il prend en charge son ODS.

Parfois, le serveur peut mettre à niveau un ancien ODS vers un plus récent, sans notification. Cela peut conduire à l’impossibilité de revenir à la version précédente. Par exemple, si vous ouvrez une base de données avec l’ODS 8.0 avec InterBase 4.2, il mettra à niveau l’ODS vers 8.2, ce qui n’est pas compréhensible par InterBase 4.0/4.1. Ainsi, la mise à niveau mineure de l’ODS rend les bases de données incompatibles au sein de la même version majeure du serveur. Cela est également vrai pour Firebird 2.5 et InterBase 7.5.

Pour éviter les problèmes de retour à la version précédente, nous recommandons d’effectuer des sauvegardes sur la version actuelle du serveur, même avant la mise à niveau mineure de votre version de serveur.

La différence entre les ODS (majeurs ou mineurs) peut être énorme ou minime. Si vous êtes assez curieux, vous pouvez ouvrir jrd\ods.h (Firebird open source) et trouver les différences entre les ODS. Par exemple, l’ODS 9.0 par rapport au 8.x possède l’intégrité référentielle déclarative, les rôles SQL, le garbage collection dans les index. Mais l’ODS 9.1 diffère du 9.0 uniquement par un index, ajouté à une table système.

Notez que la version majeure de l’ODS ne peut pas être mise à niveau à la volée. Vous ne pouvez la mettre à niveau que par sauvegarde/restauration.

Migration entre InterBase et Firebird

Les dernières versions de Firebird (3.0) et InterBase (XE7) sont très différentes, par leurs fonctionnalités et leur ODS. Comme il a été dit précédemment, le dernier ODS commun était l’ODS 10, et depuis lors (Firebird 2.0 et InterBase 7.0), les bases de données sont incompatibles avec leur format.

Ainsi, la migration sera plus facile si vous n’avez pas utilisé de fonctionnalités depuis InterBase 7.x ou Firebird 1.5. Si c’est le cas, la complexité de la migration dépendra du nombre de fonctionnalités que vous avez utilisées dans la base de données ou le processus d’administration.

Actuellement, après de nombreuses années de développement de Firebird et InterBase, la migration entre les dernières versions de ces serveurs est difficile.

Quoi qu’il en soit, si vous essayez de le faire, vous devez extraire le script de métadonnées de la base de données, puis essayer de créer la nouvelle base de données à partir de ce script, en utilisant le même serveur.

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

Cela doit être fait pour vérifier s’il y a d’anciennes métadonnées incorrectes dans votre base de données ou des bogues d’extraction de script dans le serveur que vous utilisez. InterBase et Firebird stockent les procédures, les déclencheurs et les vues (et certains autres objets) sous forme compilée (BLR - Binary Language Representation), et lors de la sauvegarde/restauration, les métadonnées ne sont pas recompilées (de SQL vers BLR).

Dans ce cas, si une base de données a été créée il y a longtemps et constamment modifiée, il peut y avoir un BLR incorrect (ancien) pour certains objets. Ces objets peuvent encore fonctionner, mais essayer de les recréer (ALTER) peut générer une erreur de syntaxe (ou autre).

Ensuite, vous pouvez essayer de créer une base de données à partir du script corrigé sur le nouveau serveur. Après avoir corrigé toutes les incompatibilités dans ce script, vous pouvez transférer les données de l’ancienne base de données vers la nouvelle.

Même si vous avez essayé de sauvegarder sur l’ancien serveur et de restaurer sur le nouveau, et que cela a fonctionné - ne faites jamais confiance à cela. Si votre base de données contient beaucoup d’objets, vous ne pouvez pas tous les vérifier d’un coup sur le nouveau serveur, donc l’erreur apparaîtra plus tard.

Comment revenir à la version précédente de Firebird ou InterBase

Parfois, vous pouvez avoir besoin d’effectuer une rétrogradation et de revenir du nouveau serveur. Les raisons peuvent varier - un bogue soudain dans le serveur, des problèmes de performance, etc.

Si vous avez effectué la sauvegarde avant la mise à niveau du serveur, il n’y aura aucun problème pour revenir en arrière. Mais si ce n’est pas le cas, vous serez confronté au problème du retour de l’ancien ODS vers le nouvel ODS.

Pour ce faire, vous aurez besoin de 2 ordinateurs avec le nouveau serveur et l’ancien. Si vous n’avez utilisé aucune nouvelle fonctionnalité du serveur X (version d’InterBase ou Firebird), vous pouvez revenir à X-1 en suivant ces étapes :

1. Prenez l’utilitaire gbak du serveur X-1 et effectuez une sauvegarde en l’utilisant sur le serveur X
2. Transférez la sauvegarde vers le serveur X-1 et restaurez-la

S’il y a des problèmes à l’étape 1, vous pouvez essayer

1. Effectuez une sauvegarde sur le serveur X, en utilisant son gbak
2. Copiez l’utilitaire gbak de X vers X-1
3. Restaurez la sauvegarde sur X-1 en utilisant gbak depuis X

Notez que le protocole local entre les serveurs X et X-1 peut être incompatible, il est donc préférable de spécifier le nom du serveur :

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

Le résultat ne sera réussi qu’à la condition que vous n’ayez modifié aucun objet de base de données sur le serveur X depuis la mise à niveau depuis X-1.

Voici des exemples :

• De 5.x vers 4.2 - aucun rôle ni nouvelle intégrité référentielle déclarative ne doit être utilisé
• De 6.x vers 5.x - aucune modification de métadonnées, car 6.x utilise un nouveau format BLR
• D’InterBase 7.x vers Firebird - aucune colonne booléenne ni nom d’objet de plus de 31 caractères.
• De Firebird 1.5 vers InterBase - pas de colonnes BIGINT ni de nouvelles extensions SQL dans les déclencheurs et procédures
• De Firebird 2.0 vers Firebird 1.5 - aucune des nouvelles fonctionnalités de Firebird 2.0.
• Et ainsi de suite

S’il y a encore des erreurs qui ne peuvent pas être corrigées, la seule solution est de créer la base de données sur le serveur X-1 à partir du script SQL et de transférer les données.

Service de migration Firebird

Souvent, la migration est une tâche complexe, en particulier pour les bases de données Firebird héritées, qui ont été abandonnées par les développeurs d’origine. Notre entreprise propose le service de migration complet pour les bases de données Firebird complexes. Les frais habituels sont de 2900 USD.

Par exemple, nous avons migré une base de données dont le script SQL faisait 55 mégaoctets, avec plus de 5000 procédures stockées, 1000 tables et plusieurs milliers de requêtes SQL ad hoc, en moins de 3 mois.

Si vous avez des questions, veuillez nous contacter à [email protected]