すべてのFirebirdおよびInterBaseのオンディスク構造（ODS）バージョン

By Dmitry Kuzmenko, 24-May-2016

On-Disk Structure（ODS）番号とは

簡単に言うと、ODS（On-Disk Structure）とは、特定のFirebirdまたはInterBase RDBMSバージョンのデータベースファイル形式の番号です。

ほぼすべてのバージョンは、現在のODSといくつかの古いODSをサポートするために、いわゆる「Yバルブ」を使用しています。これにより、サーバーは以前のバージョンのデータベースファイルを操作でき、古いサーバーから新しいサーバーへの移行が簡単になります。ただし、いくつかの制限があり、これについては後述します。

データベースのODSを確認するには、次のコマンドを実行します。

gstat -h database_file_name

ここでユーザー名とパスワードは不要です。なぜなら、gstatは-hオプションを使用すると、データベースの物理的な部分（ヘッダーページ、番号0）だけを読み取るからです。

gstatが読み取った情報を理解できない場合、期待される内容と見つかった内容を示す対応するメッセージが表示されます。

たとえば、Firebird 2のデータベースでInterBase 4のgstatを実行すると、次のように表示されます。

Wrong ODS version, expected 8, encountered 32779?

ここで、ODS番号32779が表示されています。これは11をエンコードしたもので、Firebird 2.0以降で高位ビットが追加されています（16進数では800B、B = 11）。これは、InterBaseとFirebirdのデータベースを混同しないようにするためです。なぜなら、ある時点から両者は同じODS番号を持っていましたが、データベース形式は大きく異なっていたからです。理解可能なメッセージが得られない例外は、gstatがfirebird.msgまたはinterbase.msgを見つけられない場合です。その場合は次のようなメッセージが表示されます。

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

つまり、FirebirdまたはInterBaseのインストールが正しくないため、修正する必要があるということです。

いくつかの例：

Wrong ODS version, expected 8, encountered 32779? - InterBase 4.xがFirebird 2.xデータベースを開こうとしています。

Wrong ODS version, expected 8, encountered 13? - InterBase 4.xがInterBase 2009データベースを開こうとしています。

Wrong ODS version, expected 15, encountered 32779 - InterBase XE/XE3がFirebird 2.xデータベースを開こうとしています。

Wrong ODS version, expected 11, encountered 11 - Firebird 2.xがInterBase 7.xデータベースを開こうとしています。

Wrong ODS version, expected 11, encountered 15 - Firebird 2.xがInterBase XE/XE3データベースを開こうとしています。

場合によっては、gstatではなくサーバーから別の種類のメッセージが表示されることもありますが、意味は同じです。

たとえば、Firebird 1.5サーバーがFirebird 2.xデータベースを開こうとした場合：

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

ここで、InterBase 4.0（1994年）以降のODSバージョンの表を示します。

ODSのアップグレード

各バージョンのサーバーは、（InterBase XE7を除いて）作成またはリストアされたデータベースに常にメインODS番号を使用します。データベースのODSがサーバーのメインODSより小さい場合、サーバーがそのODSをサポートしていれば、そのデータベースを操作できます。

サーバーが古いODSを通知なしに新しいものにアップグレードすることがあります。これにより、以前のバージョンに戻れなくなる可能性があります。たとえば、ODS 8.0のデータベースをInterBase 4.2で開くと、ODSが8.2にアップグレードされ、InterBase 4.0/4.1では理解できなくなります。つまり、ODSのマイナーアップグレードにより、同じメジャーサーバーバージョン内でもデータベースが互換性を失うことになります。これはFirebird 2.5とInterBase 7.5にも当てはまります。

以前のバージョンに戻る問題を避けるために、サーバーバージョンのマイナーアップグレードの前であっても、現在のサーバーバージョンでバックアップを取ることをお勧めします。

ODSの違い（メジャーまたはマイナー）は、大きい場合も小さい場合もあります。興味があれば、jrd\ods.h（Firebirdオープンソース）を開いて、ODS間の違いを確認できます。たとえば、ODS 9.0は8.xと比較して、宣言的参照整合性、SQLロール、インデックスのガベージコレクションがあります。しかし、ODS 9.1は9.0とは、一部のシステムテーブルに追加された1つのインデックスのみが異なります。

メジャーODSバージョンはその場でアップグレードできないことに注意してください。バックアップ/リストアによってのみアップグレードできます。

InterBaseとFirebird間の移行

最新バージョンのFirebird（3.0）とInterBase（XE7）は、機能とODSの両方で大きく異なります。前述のとおり、最後に共通だったのはODS 10で、それ以降（Firebird 2.0とInterBase 7.0）データベースは形式が互換性を持ちません。

したがって、InterBase 7.xまたはFirebird 1.5以降の機能を使用していなければ、移行は簡単です。使用している場合は、移行の複雑さは、データベースまたは管理プロセスで使用した機能の数に依存します。

現在、長年にわたるFirebirdとInterBaseの開発の後、これらのサーバーの最新バージョン間の移行は困難です。

いずれにせよ、これを試みる場合は、データベースからメタデータスクリプトを抽出し、同じサーバーを使用してそのスクリプトから新しいデータベースを作成してみる必要があります。

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

これは、データベースに古い不正なメタデータや、使用しているサーバーのスクリプト抽出のバグがないかを確認するために行う必要があります。InterBaseとFirebirdは、プロシージャ、トリガー、ビュー（およびその他の一部のオブジェクト）をコンパイル済み形式（BLR - Binary Language Representation）で保存し、バックアップ/リストア中にメタデータは（SQLからBLRへ）再コンパイルされません。

この場合、データベースが長い間前に作成され、絶えず変更されていると、一部のオブジェクトに不正な（古い）BLRが存在する可能性があります。これらのオブジェクトはまだ動作するかもしれませんが、再作成（ALTER）を試みると構文（またはその他の）エラーが発生する可能性があります。

次に、修正したスクリプトから新しいサーバーでデータベースを作成してみることができます。このスクリプトのすべての非互換性を修正したら、古いデータベースから新しいデータベースにデータを移行できます。

古いサーバーでバックアップし、新しいサーバーでリストアして成功したとしても、決してそれを信頼しないでください。データベースに多数のオブジェクトが含まれている場合、新しいサーバーでそれらすべてを一度に確認することはできないため、エラーは後で発生します。

以前のバージョンのFirebirdまたはInterBaseに戻す方法

場合によっては、ダウングレードを実行して新しいサーバーから戻る必要があるかもしれません。理由はさまざまです - サーバーの突然のバグ、パフォーマンスの問題など。

サーバーのアップグレード前にバックアップを取っていれば、戻るのに問題はありません。しかし、取っていない場合は、新しいODSから古いODSに戻るという問題に直面します。

これを行うには、新しいサーバーと古いサーバーを備えた2台のコンピューターが必要です。サーバーX（InterBaseまたはFirebirdのバージョン）の新機能を何も使用していない場合は、次の手順でX-1に戻ることができます：

1. サーバー X-1 から gbak ユーティリティを取得し、それを使用してサーバー X でバックアップを作成します
2. バックアップを X-1 サーバーに転送し、復元します

ステップ 1 で問題が発生した場合は、以下を試すことができます

1. サーバー X で、その gbak を使用してバックアップを作成します
2. gbak ユーティリティを X から X-1 にコピーします
3. X の gbak を使用して X-1 でバックアップを復元します

サーバー X と X-1 間のローカルプロトコルは互換性がない可能性があるため、サーバー名を指定することをお勧めします:

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

結果が成功するのは、X-1 からアップグレードして以来、サーバー X でデータベースオブジェクトを変更していない場合のみです。

以下に例を示します:

• 5.x から 4.2 へ - ロールと新しい宣言的参照整合性を使用していないこと
• 6.x から 5.x へ - メタデータの変更がないこと。6.x は新しい BLR 形式を使用するため
• InterBase 7.x から Firebird へ - ブール型列と 31 文字を超えるオブジェクト名がないこと
• Firebird 1.5 から InterBase へ - BIGINT 列とトリガーおよびプロシージャ内の新しい SQL 拡張がないこと
• Firebird 2.0 から Firebird 1.5 へ - 新しい Firebird 2.0 機能がないこと
• など

それでも修正できないエラーが残る場合、唯一の方法は X-1 サーバーで SQL スクリプトからデータベースを作成し、データをポンプすることです。

Firebird 移行サービス

特に元の開発者によって放棄されたレガシー Firebird データベースの場合、移行は複雑なタスクになることがよくあります。当社は、複雑な Firebird データベース向けの包括的な移行サービスを提供しています。通常料金は USD$2900 です。

例えば、SQL スクリプトが 55 メガバイト、5000 以上のストアドプロシージャ、1000 のテーブル、数千のアドホック SQL クエリを持つデータベースを 3 か月未満で移行した実績があります。

ご質問がある場合は、[email protected] までお問い合わせください。