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

Dmitry Kuzmenko 著、2016年5月24日

オンディスク構造（ODS）番号とは

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

ほとんどすべてのバージョンは、いわゆる「Y-valve」を使用して、現在の ODS と一部の古い ODS をサポートしています。これにより、サーバーは以前のバージョンのデータベースファイルを扱うことができ、古いサーバーから新しいサーバーへの移行を簡素化できます。ただし、いくつかの制限があり、それについては後述します。

データベースの ODS は、次のコマンドを実行することで確認できます

gstat -h database_file_name

ここでユーザー名とパスワードは不要です。なぜなら、-h オプションを付けた gstat はデータベースの物理的な部分（ヘッダーページ、番号 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 が IntrBase 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へ - booleanカラムや31文字を超えるオブジェクト名は使用できません。
• Firebird 1.5からInterBaseへ - BIGINTカラムやトリガー・プロシージャ内の新しいSQL拡張機能は使用できません
• Firebird 2.0からFirebird 1.5へ - Firebird 2.0の新機能は一切使用できません。
• その他も同様です

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

Firebird Migrationサービス

移行はしばしば複雑な作業であり、特に元の開発者によって放棄されたレガシーなFirebirdデータベースではなおさらです。当社は複雑なFirebirdデータベース向けに包括的な移行サービスを提供しています。通常料金は2,900米ドルです。

例えば、SQLスクリプトが55メガバイト、5,000以上のストアドプロシージャ、1,000のテーブル、数千のアドホックSQLクエリを含むデータベースを、3か月足らずで移行した実績があります。

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