以前のリリース

提供: InterBase

新機能 へ戻る

以下に一覧されているのは、以前のリリースにおける新機能です:

目次

InterBase 2017

InterBase の機能をさらに拡張する新機能と拡張機能が導入されています。新機能または拡張機能のいくつかを以下に示します。

ODS の新バージョン

InterBase 2017 で作成されたデータベースは、ODS 17 を使用します。

isql

新しい RECONNECT コマンド
isql は新しいコマンド、RECONNECT をサポートしました。 RECONNECTisql や SQL スクリプトで使用して、最後に接続に成功したデータベースに再接続します。 詳細については、RECONNECT を参照してください。
新しい -names コマンドライン オプション
isql は、新しいコマンドライン オプション、-names <<文字セット名>> をサポートします。 のオプションを使用すると、現在のデータベース接続に使用する文字セットを指定することができます。詳細については、「コマンドライン オプション」を参照してください。

全オンライン データベースのモニタリング

InterBase 2017 では、単一のコネクションで、サーバー内の全オンライン データベースのモニタリングを提供します。管理者は、サーバー レベルの統計を使用して、インスタンスの利用状況をさらにモニタリングすることができます。

メモ:この機能は、ODS 17 以降でのみ利用可能です。

この機能を使用するには:

  1. システム上の管理データベースに接続します。
  2. 単一のデータベースで行うのと同じ要領で、パフォーマンス モニタリング クエリを、任意の TMP$ テーブルに対して実行します。現在オンライン上にあるすべてのデータベースの累積データを見ることができます。

制限事項

  • admin 以外のデータベースに対する SWEEP、FLUSH、RECLAIM については、TMP$DATABASE に対して UPDATE オペレーションを実行します。
  • admin 以外のデータベースに対する COMMIT、ROLLBACK については、TMP$TRANSACTIONS に対して UPDATE オペレーションを実行します。


サブスクリプションは、ALTER TABLE の変更を反映する

サブスクリプションは、ALTER TABLE で列が追加された際に、変更を反映するようになりました。たとえば、次のコード FOO_SUBS は、新たに追加された列 BID を表示します。

CREATE TABLE FOO (AID INT);
CREATE SUBSCRIPTION FOO_SUBS ON FOO;
INSERT INTO FOO VALUES (1);

ALTER TABLE FOO ADD BID INT;
UPDATE FOO SET BID=2;
COMMIT;

メモ: データベースは ODS 17 でなければなりません。


排他的隔離レベル

排他的隔離により、トランザクションは、対象テーブルに対して排他的ロックを取得することができ、テーブルに対して、SELECTINSERTUPDATEDELETE を実行できる唯一のものとなることができます。 詳細については、「排他的隔離レベル」を参照してください。

SQL 派生テーブルのサポート

InterBase が、よく使用される SQL 開発機能である、派生テーブルをサポートするようになりました。 派生テーブル構文により、既存のアプリケーションの機能を強化して、InterBase をバックエンド RDMBS として使用できるようにします。 詳細については、「派生テーブル」ドキュメントを参照してください。

Truncate Table

Truncate Table コマンドにより、ユーザーおよびアプリケーションは、データベース テーブルのコンテンツを空にします。 この機能は、行を頻繁に削除する必要があるテーブルの場合に便利です。 Truncate Table コマンドは、同等の DELETE FROM テーブル コマンドに比べ、実行はより高速であり、必要な入出力はより少なく、そしてはるかに少ない情報をジャーナル記録およびアーカイブします。 詳細については、「Truncate Table」を参照してください。

トランザクションの待機時間

ロック可能なリソースを取得するために、トランザクションが待機する時間を指定します。 ロック可能なリソースが取得できるまで、トランザクションが待機する時間を指定できるようになりました。 詳細については、「待機時間」を参照してください。

一行コメント

2 つのダッシュを使用して、SQL 文に一行コメントを追加することができます。詳細と例については、「コメント」を参照してください。

--This is a comment line.



InterBase XE7

InterBase XE7 Update 6 表「解決された不具合」の XE7 Update 6 の修正された不具合のところを参照してください。 このリリースでは、新機能はありません。

InterBase XE7 Update 5 表「解決された不具合」の Update 5 の修正された不具合のところを参照してください。 このリリースでは、新機能はありません。

InterBase XE7 Update 4 表「解決された不具合」の Update 4 の修正された不具合のところを参照してください。 このリリースでは、新機能はありません。

InterBase XE7 Update 3 表「解決された不具合」の Update 3 の修正された不具合のところを参照してください。 このリリースでは、新機能はありません。

InterBase XE7 Update 2 本リリースでは、次の新機能と、既存機能に対する強化が行われています:

InterBase XE7 Update 1 本リリースでは、次の新機能と、既存機能に対する強化が行われています:

InterBase XE7 InterBase の機能をさらに拡張するため、多くの新機能追加と強化が行われています。 新しいまたは強化された機能の一部を、ここでは紹介していきます:

  • 変更ビュー 「前回、私が参照してからどのデータが変更された?」といった質問に、迅速に答えられるになりました。
  • Linux キット Linux キット、32 ビットおよび 64 ビットが、InterBase XE7 リリースより利用可能になりました。
  • パフォーマンスの強化 これらの強化には、改良された SMP パフォーマンス、識別ダンプの強化、読み込みコミット(RC)トランザクション処理の向上などが含まれています。
  • ODS の変更 変更ビューや、パフォーマンス向上のために新しいインデックス マネージャをサポートするため、新たに ODS バージョン 16 が導入されました。 また、データベース バックアップ ファイルを、ODS の古いサポート バージョンまで復元できるようになりました。サポートされている ODS の旧バージョンには、13 と 15 があります。

InterBase ToGo for Mac OS X でのサンドボックス

Mac OS X 用の RAD Studio Delphi/C++ データベース アプリケーションに、サンドボックスを提供することができます。 RAD Studio を利用した InterBase アプリケーションのサンドボックス環境に関する詳細については、「InterBase ToGo for Mac OS X でのアプリケーションのサンドボックス」を参照してください。

ToGo Edition でのワークフローに対する更新

本リリースには、登録後 30 日で期限切れとなる ToGo Trial Edition が含まれています。 ライセンス情報については、「InterBase ToGo トライアル ライセンス」を参照してください。

変更ビューの更新

このリリースには、変更ビューについて次の変更が含まれています:

DROP SUBSCRIPTIONS
SQL 拡張

DROP SUBSCRIPTIONS

サブスクリプションをドロップする機能は、InterBase XE7 Update 1 リリースでは、変更ビューに追加されました: DROP SUBSCRIPTION の構文:

DROP SUBSCRIPTION <subscription_name> [RESTRICT | CASCADE];

一連の変更ビューの監視に対する関心を解除するには、サブスクリプションをドロップしなければなりません。

  • RESTRICT が指定されている場合、既存のサブスクライバのチェックが実行されます。
  • サブスクライバがいた場合、サブスクリプションのドロップは行われず、エラーが返されます。
  • CASCADE が指定されている場合、このサブスクリプションのすべてのサブスクライバがドロップされます。
  • RESTRICT と CASCADE のどちらも指定されていない場合、RESTRICT が指定されているとされます。


SQL 拡張

InterBase SQL では、変更ビューに対するサポートを、IS [NOT] {CHANGED | INSERTED | UPDATED | DELETED} 句によって提供しています。

SET SUBSCRIPTION sub_employee_changes ACTIVE;
SELECT EMP_NO, DEPT_NO, SALARY FROM EMPLOYEE WHERE SALARY IS UPDATED;
EMP_NO     DEPT_NO           SALARY
--------   ----------        ----------
109        600               75000

上記の例では EMP_NO=37 の社員の部署の再割り当てが、この人事異動のための賃金調整がなかったため、返ってきてないことが分かります。 IS CHANGED 句は、いずれかの SQL オペレーションによる、列の変更を検知します。


IBConsole での更新

本リリースには、IBConsole 機能に対する大きな更新がいくつか含まれています:

[Start Here]タブ

[Start Here]タブは、IBConsole にアクセスすると開きます。 このタブには、ビデオ、ユーザー ガイド、チュートリアルのコレクションがあります。 また、InterBase の Web サイトへのアクセスも提供しており、そこでは、概要、新機能の説明、FAQ、用語集、チュートリアル ビデオなどは公開されています。

IBConsole のデータベース ペイン

左下隅にあるペインには、頻繁に使用されるデータベースが一覧されます。 データベース名のリンクをクリックすると、そのデータベースに接続します。

IBConsoleDatabasePane.png

変更ビューのサブスクリプション サポート

IBConsole が、サブスクリプション エディタをサポートしました。 このサブスクリプション エディタは、暗黙ビューで観察できた前のトランザクション移行に変更されたデータを返します。 これにより、前回自分が見た後に変更されたデータを確認することができます。

  • データベースのサブスクリプション フィールドをクリックし、Create をクリックすると、サブスクリプション エディタ ダイアログにアクセスすることができます。
IBConsoleSubscription.png


変更ビューの機能

変更ビュー 機能は、InterBase の複数世代アーキテクチャを使用して、データへの変更をキャプチャしています。 この機能により、「前回、私が参照してからどのデータが変更された?」といった質問に、迅速に答えられるになりました。

以前は、これには、トリガ、ログ記録、および/または、トランザクションのログ先行書き込みスクレイピングを伴いました。 これは開発者にとって時間のかかる作業であり、特定のトランザクション負荷や変更量によっては、データベース パフォーマンスにも影響を及ぼしました。 今は、変更ビューにより、既存のトランザクションについてパフォーマンスのオーバーヘッドは発生しません。なぜなら、他のトランザクションからも見ることのできる、変更されたデータの一貫したビューが保持されているからです。

変更ビュー™ 機能は、InterBase の複数世代アーキテクチャを使用して、データへの変更をキャプチャしています。 この機能により、「前回、私が参照してからどのデータが変更された?」といった質問に、迅速に答えられるになりました。 以前は、これには、トリガ、ログ記録、および/または、トランザクションのログ先行書き込みスクレイピングを伴いました。 これは開発者にとって時間のかかる作業であり、特定のトランザクション負荷や変更量によっては、データベース パフォーマンスにも影響を及ぼしました。 今は、変更ビューにより、既存のトランザクションについてパフォーマンスのオーバーヘッドは発生しません。なぜなら、他のトランザクションからも見ることのできる、変更されたデータの一貫したビューが保持されているからです。

変更ビュー メカニズムは、それが基としているデータに依存してはいませんが、既存の基本テーブルまたは基本テーブルから派生したビューにすでに格納されているデータをベースとしています。 この暗黙的なビュー メカニズムは一時的にベースとするもので、この暗黙ビューで観察できた前のトランザクション以降に変更されたデータを返します。

データベース接続を超えて、変更されたデータを表示させるためには、変更ビューにサブスクライブします。 複数のデータベース接続に広がる、長期生存トランザクションが可能になります。

  • 特にサブスクリプションは、1 つまたは複数のテーブルへの行の挿入、更新、削除を、列レベルでの細かさで、切断されてもそれを超えた時間に及んで、すべて追跡します。
  • InterBase SQL クエリ言語は、前回の観察時以降変更されたデータがある列を検索するため、変更されました。
  • データ変更は、列の単位で追跡されます。


Linux 32 ビットと 64 ビット

Linux キット、32 ビットおよび 64 ビットが、InterBase XE7 リリースより利用可能になりました。 新しい Linux ビルド(12.0.0.124)が、InterBase XE7 で入手可能です。

ライセンス マネージャ

ライセンス マネージャが InterBase XE3 から InterBase XE7 に変更されました。

パフォーマンスの強化

  • SMP パフォーマンスの向上: 複数の読み書きのパフォーマンスが、このリリースで向上されました。
  • 識別ダンプ機能: InterBase XE3 における「インクリメンタル ダンプ」では、データベース サーバーがデータベース ファイルからすべてのページを読み込む必要がありましたが、変更されたページのみ、ターゲットのデータベース ダンプ ファイルに書き出していました。 XE7 での追跡システムの実装により、最後のダンプ以降、更新の必要があったページのみをフェッチします。 これにより、ターゲットに対する瞬時の更新が提供されています。 ソース データベース毎に「識別ダンプ」が 1 しか発生しません。
「識別ダンプ」の選択肢は次のとおりです:
  • ソース データベース ファイル上の最初の「ダンプ」は「識別ダンプ」となります。それ以降のダンプ ターゲットはすべて、「通常のダンプ」ターゲットです。
  • 「最初の」ダンプは、オンラインでなければならず、それゆえサーバーはソース データベースへリンクし、インクリメンタルに更新される次の「ダンプ」は、「識別ダンプ」となります。
  • 大規模(OIT-OAT)トランザクション ギャップのための、読み込みコミット(RC)トランザクション処理の向上: XE3 以前のバージョンにおいて、RC トランザクション処理は、"ハウスキーピング"(OIT-OAT)ギャップが大きくなるにつれ、きしんで停止する可能性があります。 データベースが自動内部スイープ機能を無効にしてないかぎり、もしくは、ハウスキーピング ギャップが非常に高い値に設定されていない限り、通常これは起こりません。 このギャップは通常、数千万でパフォーマンスの劣化が見られます。 OIT は通常、サーバーの異常終了や、トランザクションのセーブポイントが破棄された場合に付き出ます。なぜなら、実行トランザクションの変更を追跡するには大きくなりすぎてしまい、そのトランザクションは最終的にはロール バックするからです。
    • XE7 では、RC トランザクションは、ずっと高速に上記のシナリオを実行します。 テーブル内の 100 万レコードをカウントする、あるテストでは、XE3 では 14.48秒かかりました。 XE7 では、そのクエリを実行する時間は 0.97 秒です。 RC トランザクションのパフォーマンスは現在、スナップショット モードのトランザクションに相当します。 ちなみに、スナップショット トランザクションは、旧バージョンで低速であったことはありません。
  • より迅速なトランザクション作成: 以前の InterBase バージョンに比べ、XE7 では、1 秒間により多くのトランザクションを作成することができます。

パフォーマンス モニタリング カウンタ

パフォーマンス モニタリング カウンタが、32 ビット値から 64 ビット値にスケールアップされました。 これは、データベース内に格納されるすべてのデータを含みます。 IBConsole は、このリリースのために更新されました。

注意を要する ODS 関連の差違がいくつかあります。

  • ODS <= 15 は、以前と同様、32 ビット INTEGER カウンタを引き続き維持します(ダイアレクト 1 およびダイアレクト 3 の両データベースに対して)。
  • ODS >= 16 は、ダイアレクト 1 データベースに対して、「倍精度」データ型で定義されたカウンタを持ちます。
  • ODS >= 16 は、ダイアレクト 3 データベースに対して、「NUMERIC(18,0)」データ型で定義されたカウンタを持ちます。 デフォルトでは、新しいデータベースは、ODS 16、ダイアレクト 3 で作成されます。

ダイアレクト 3 の場合、パフォーマンス モニタリング データ カウンタは、64 ビット Integer 型へ更新されました。 ダイアレクト 1 では 64 ビット Integer 型をサポートできないため、64 ビット Integer 型は、内部的に「倍精度」型(同じサイズ=8 バイトであるため)へ変換され、64 ビット アドレス用の大きな値やカウンタ値にも対応します。

ダイアレクト 1 とダイアレクト 3 の違いを識別する最良の方法は、データベースに対する SQL クエリの結果のフィールド定義をチェックすることです。 たとえば、次のクエリを実行する場合: SELECT RDB$FIELD_NAME FROM RDB$FIELDS WHERE RDB$FIELD_LENGTH=8 AND RDB$FIELD_TYPE=16;、結果は次のように示します:

  • FIELD_TYPE 16 は NUMERIC(18,0)、そしてダイアレクト 3 で設定される。
  • ダイアレクト 1 データベースは double であるため、このフィルード型のいずれも持たない。

下位互換性

パフォーマンス モニタリングのための 64 ビット Integer データ カウンタのサポートで、後方互換性は、ODS 15 データベースで動作する新しいサーバーに対しても保持されています。そこでは、カウンタは 32 ビット Integer なります。

これを行うには、gpre をコマンドライン オプション "-ods <major_ods_number>" で有効にし、GPRE が、メジャー ODS になるまで有効ではない関連/テーブルへの GDML/ESQL プログラムの解析を制限させることができます。

 gpre [-ods <number>] ... <foo.e>
  For e.g.:
  gpre -ods 15 tmp.e


部分セグメントの選択性

InterBase は、現在、インデックス毎に単一の選択値を維持するようになっています(単一または複合キー)。 値は降順で格納されており、全体のインデックスでいくつ重複が存在するか情報を追跡します -- ただし第1レベルまでです。 しかし、下位レベルでの情報があると有益な場合もあります。 InterBase XE7 では、その追跡が可能になりました。 変更は新しい ODS(バージョン 16)に対して実装されており、RDB$INDEX_SEGMENTS.RDB$STATISTICS に対して、特定の選択のもと、セグメントを集めで保存および取得することができます。

以下に例を示します。 インデックスが列 F1、F2、F3 に存在し、 クエリは、最初の 2 列の F1 と F2 にのみ、結合(条件)を提供します。 オプティマイザは、基礎となる選択肢、列 F1 と F2 のみを反映する(F1+F2+F3 ではなく)値を使用して、そのインデックスを使用するかどうかを決断することができます。

特定のクエリがより高速に実行されるのは見えても、データにおける変更は見えません。

64 ビット トランザクション ID

InterBase XE3 は、符号付き 32 ビット トランザクション ID のみサポートしていました。 これにより、バックアップ/復元プロシージャを使ってトランザクション ID がリセットされるまで、20 億のトランザクションしか、1 つのデータベースで実行されませんでした。 これは、24/7 データベースにとって、そして、トランザクション中心のアプリケーション スイートにとって、制限でした。

InterBase XE7 は、トランザクション ID を 64 ビット(実際には 48 ビット)に拡張しました。これにより、データベースは今までの制限がなくなり、さらにトランザクションに対応できるようになりました。 これが自分自身を 48 ビットに制限しているのは、今後のトランザクション ID に拡張に備えるためです。

トランザクションの制限は、現在次のように作用します:

  • ODS 15 以前のデータベースは、20 億トランザクション ID 制限に到達する前に、バックアップおよび復元される必要があります。
  • ODS 16 以降のデータベースは、64 ビット トランザクション ID をサポートしているため、20 億トランザクションを超えてもオンラインを維持できます。 これの利点は、データベースをオンラインにキープし、アプリケーションを 24/7 シナリオに近い状態でサービス提供させることができる点です。以前の 32 ビットの制限によるバックアップ/復元は必要ありません。
  • 64 ビット変換
  • このプロジェクトでは、64 ビット(どちらといえば 48 ビット)トランザクション ID への変換を想定しており、これは、一定の理にかなった期間、それらが消耗されないことを前提としています。
  • たとえば、4KB ページ サイズのデータベースは、10,000 tps を超えた状態で、100 年の間、48 ビット トランザクション ID で持続的に実行することができます。


ODS の変更

データベース バックアップが、古い ODS の特定のバージョンに復元できるようになりました。

このデータベースの復元オペレーションは、自動的にデータベースを最新の ODS バージョン(そのエンジンでサポートされている)で作成します。 しかし、開発者が古いバージョンで復元したい場合もあるでしょう:

  • 同じデータベース ファイルを、他の互換性のあるデータベース エンジン バージョンに配布するため
  • 解決が難しい現在の ODS のバグを回避するため
  • ODS の現行バージョンと古いバージョン間で、パフォーマンス重視のオペレーションをテストするため。単一のサーバー/エンジンを使って、同じデータベースの複数のコピーを復元し(ODS につき 1 つ)、それらデータベースのそれぞれに地あしてクエリを実行する。 たとえば、ODS の新しいバージョン群でリリースされたインデックス マネージャの、特定のバージョンをテストするため。

この実装を利用するための複数の方法:

IBConfig パラメータ

DATABASE_ODS_VERSION。 ODS のメジャー バージョン番号を、サーバー全体に渡って指定できます。 新たに作成されたデータベースや GBAK を使用して復元されたものは、この ODS バージョンで復元されます。 64 ビット Integer 用の新しいパフォーマンス モニタリング成果物を完全サポートしており、古いODS データベースへの後方互換性も保持されています。
IBConfig ファイルには、後述のとおり、このアクションのために新しいパラメータがあります。
#DATABASE_ODS_VERSION 16
##Platforms: All
##Version: starting in InterBase XE7
##The database server/engine will automatically create/restore
##databases to this major ODS version number, if specified.
##Valid ODS major versions are in the range 13 to 16
##Default major ODS version is the latest version supported by the product

DPB パラメータ

アプリケーションは、新しい DPB パラメータ isc_dpb_ods_version_major を使って、データベースを選択的に作成/復元することができます。

GBAK 復元オプション

"-ods_version <n>" -- ここでの <n> は、サポートされる ODS のメジャー バージョンです。 対象となるデータベース エンジンは、それぞれ許容する独自の ODS メジャー バージョン リストがあります。 XE7 は、ODS バージョン 13 から 16 に対応しています。
新しい GBAK 復元オプションは、特定の ODS メジャー バージョンを復元するのに利用できます。 復元時にこのオプションが指定されると、これはサーバー側の IBConfig 設定 DATABASE_ODS_VERSION を上書きします。
gbak -r employee.gbk emp15.ib -ods_version 15 -user sysdba -pass masterkey
gbak -c employee.gbk emp16.ib -ods_version 16 -user sysdba -pass masterkey
gbak -service localhost:service_mgr -r <path>/employee.gbk <path>/emp13.ib -ods_version 13 -user sysdba -pass masterkey

OpenSSL のアップグレード

InterBase XE7 に含まれている OpenSSL ライブラリは、バージョン 1.0.0d から 1.01i へ、セキュリティの脆弱性の修正でアップグレードされました。 OpenSSL は、InterBase における暗号化と OTW/SSL の機能で使用されています。

InterBase XE7 での OpenSSL 使用に関する詳細については、『操作ガイド』の「ネットワーク設定」と、『データ定義ガイド』の「データの暗号化」を参照してください。

OpenSSL の詳細については、「SSL」を参照してください。。

オンライン ダンプおよびジャーナル アーカイブ操作のための Services API サポート

オンライン ダンプおよびインクリメンタル ダンプ

データベースのオンライン ダンプとインクリメンタル ダンプは、このリリースの前は、DPB オプションとしてのみサポートされていました。 Services API オプションとしては利用できず、IBX といった接続レイヤが、この「バックアップ」機能を、他の「Services API」対応のバックアップ機能と別のものとして識別するのを、難しくしていました。 Services API が、オンライン ダンプとインクリメンタル ダンプをサポートするようになりました。

以下は、この機能のための関数を一覧したものです:

  • タスク isc_action_svc_dump は、ファイルはデータベースをダンプする目的で追加されました。 これは、gbak -d に相当します。
  • クラスタ識別子 isc_action_svc_dump を使用すると、Services Manager にダンプ処理を行うよう要求することができます。 これは、ibserver プロセスのスレッドとして gbak ツールを起動するためのプログラム的な方法です。 データベース一次ファイルのパスとダンプ出力ファイルのパスを指定する必要があります。 ダンプ ファイルのパスは、サーバーを基準にして指定します。 Services Manager は、ダンプ タスクをサーバーホスト上で実行するので、ダンプ ファイルの読み込みや書き込みはサーバーホスト上で行われます。 Services Manager は、サーバーのコンテキスト内にもファイルを作成します。
  • 次のオンライン ダンプおよびインクリメンタル ダンプのアクションが、isc_action_svc_dump を介して追加されています:
アクション 引数 用途 引数の長さ 引数の値
isc_action_svc_dump isc_spb_dmp_create Online Dump オペレーションの実行を要求し、ソース データベースからオンライン ダンプ データベースを作成します。 これは、スタンドアロンのオプション値として isc_spb_options に渡されます。 "gbak -dump" コマンドに相当。 0 0
isc_action_svc_dump isc_spb_dbname データベースの一次ファイルのパス。サーバーから見て、のもの。 2 バイト + 文字列 String
isc_action_svc_dump isc_spb_dmp_file ダンプ出力ファイルのパス。複数の出力ファイルを指定することができます。 2 バイト + 文字列 String
isc_action_svc_dump isc_spb_dmp_overwrite 既存のダンプ ファイルを上書き。これが欠けている場合、既存のダンプ ファイルが追加の形で更新されることを意味します。 "gbak -overwrite_dump" コマンドに相当。 このパラメータは、SPB バイト配列で単独で渡されなければなりません。 任意の引数。 0 0

メモ: データベースを必要とせず、Services API を使用するだけで、オンラインまたはインクリメンタルのデータベース ダンプを作成するには、新たな SPB パラメータ、isc_spb_dmp_create を使用します。 これは、スタンドアロン オプション値として isc_spb_options に渡され、同等のものです。

ジャーナル アーカイブ管理アクション

ジャーナル アーカイブ管理アクションは、今までは、次のコマンドライン ツールでのみサポートされていました:

  • GBAK -- Archive Database、Archive Journals、Archive Recover のアクション群
  • GFIX -- Archive Dumps、Archive Sweep のアクション群

以前のバージョンでは、アプリケーションが呼び出すことのできるサービス API のサポートはありませんでした。 しかし、現在では、クラスタ識別子 isc_action_svc_backup、isc_action_svc_restore、または isc_action_svc_properties を使用することにより、サービス マネージャが InterBase ジャーナル アーカイブ上で様々な操作を行うよう、要求できるようになりました。

これは、ibserver プロセスのスレッドとして gbak ツールを起動するためのプログラム的な方法です。 データベース一次ファイルの絶対完全パスと、リカバリ関連のデータベース ファイルのパスを指定する必要があります。 Services Manager は、アーカイブ管理タスクをサーバーホスト上で実行するので、ジャーナル アーカイブ ロケーション ファイルの読み込みや書き込みはサーバーホスト上で行われます。 Services Manager は、サーバーのコンテキスト内にもファイルを作成します。

  • 次の Services API ジャーナル アーカイブ管理アクションが追加されました:
アクション 引数 用途 引数の長さ 引数の値
isc_action_svc_backup isc_spb_bkp_archive_database Archive Database オペレーションの実行を要求し、ソース データベースからアーカイブ データベース コピーを作成します。 これは、スタンドアロンのオプション値として isc_spb_options に渡されます。 "gbak -archive_database" コマンドに相当。 0 0
isc_action_svc_backup isc_spb_dbname データベースの一次ファイルのパス。サーバーから見て、のもの。 このデータベースは、データベース エンジンによって、CREATE JOURNAL ARCHIVE コマンドを使ってそのデータベースに対して定義されている Journal Archive の場所にコピーされます。 2 バイト + 文字列 String
isc_action_svc_backup isc_spb_bkp_archive_journals Archive Journals オペレーションの実行を要求し、ソース データベースのジャーナル ファイルを、ジャーナル アーカイブ ディレクトリの場所にコピーします。 これは、スタンドアロンのオプション値として isc_spb_options に渡されます。 "gbak -archive_journals" コマンドに相当。 0 0
isc_action_svc_backup isc_spb_dbname データベースの一次ファイルのパス。サーバーから見て、のもの。 このデータベースのジャーナル ファイルは、データベース エンジンによって、CREATE JOURNAL ARCHIVE コマンドを使ってそのデータベースに対して定義されている Journal Archive の場所にコピーされます。 2 バイト + 文字列 String
isc_action_svc_restore isc_spb_res_archive_recover Archive Recover オペレーションの実行を要求し、データベース アーカイブから、ジャーナル アーカイブ ディレクトリの場所へ復元します。 これは、スタンドアロンのオプション値として isc_spb_options に渡されます。 "gbak -archive_recover" コマンドに相当。 0 0
isc_action_svc_restore isc_spb_bkp_file Journal Archive の場所でのデータベースのパス。サーバーから見て、のもの。 指定されたデータベース ファイルは、復元してくるソース データベースとして使用され、同じアーカイブ場所にある関連づけられたジャーナルからの復元データを伴います。 2 バイト + 文字列 String
isc_action_svc_restore isc_spb_dbname 復元(または作成)するデータベース ファイルのパス。サーバーから見て、のもの。 新たに復元されたデータベースは、読み取り専用モードに設定され、のちほどオンラインに戻されます。 2 バイト + 文字列 String
isc_action_svc_restore isc_spb_res_archive_recover_until これは、Point-in-Time リカバリのための任意の引数。"gbak -until <timestamp>" コマンドに相当。 引数値は、タイムスタンプ形式の文字列。 使用できるタイムスタンプの文字列形式については、『埋め込み SQL ガイド』の「日時の操作」-「入力のための日付の書式」を参照。

例: "2006-08-21 18:08:15"。

2 バイト + 文字列 String
isc_action_svc_properties isc_spb_prp_archive_dumps Archive Dumps オペレーションの実行を要求し、ジャーナル アーカイブ ディレクトリの場所での、データベース ダンプ バージョンの制限を設定します。 "gfix -archive_dumps <n>" コマンドに相当。 4 バイト 符号なし 32 ビット Integer 値で、保持するダンプ ファイル数を示す。
isc_action_svc_properties isc_spb_prp_archive_sweep Archive Sweep オペレーションの実行を要求し、ジャーナル アーカイブ ディレクトリでの値より低いシーケンス番号を持つ、データベース ダンプ ファイルをスイープ(削除)します。 スイープではまた、それらデータベース ダンプ ファイルに関連するジャーナル ファイルも削除します。 "gfix -archive_sweep <n>" コマンドに相当。 4 バイト 符号なし 32 ビット Integer 値で、データベース ダンプ ファイルをスイープするシーケンス番号を示す。



InterBase XE3

InterBase XE3 Update 4 Hotfix 2: 既知の不具合の修正が含まれています。 それら解決された問題については、解決された不具合を参照してください。

InterBase XE3 Update 4: 既知の不具合の修正が含まれています。 それら解決された問題については、解決された不具合を参照してください。

InterBase XE3 Update 3: 既知の不具合の修正が含まれています。 それら解決された問題については、解決された不具合を参照してください。

InterBase XE3 Update 2: 次の新機能と、既存機能に対する強化が行われています。 それら解決された問題については、解決された不具合を参照してください。

InterBase XE3 Update 1: 次の新機能と、既存の機能に対する強化が行われています。 それら解決された問題については、解決された不具合を参照してください。

InterBase XE3: 次の新機能と、既存の機能に対する強化が行われています。 それら解決された問題については、解決された不具合を参照してください。

モバイル プラットフォーム

Android プラットフォームのサポートが、RAD/Delphi XE6 より開始されました。 iOS プラットフォームのサポートは、RAD/Delphi XE6 より開始されています。

InterBase XE3 Update 2 Update では、InterBase に Android モバイル プラットフォームを導入しています。 Android 用 InterBase ToGo and IBLite エディションは、RAD Studio/Delphi XE5 より利用可能です。 RAD Studio RAD Studio XE7 評価版(インストール可能、および InstantOn)には、IBToGo Test Deployment および IBLite の期間制限ライセンスが含まれており、RAD ユーザーは、製品入手後すぐにテスト アプリケーションをデプロイすることができます。

これらのモバイル プラットフォームを対象とした開発者は、ToGo または IBLite ライセンスでデプロイすることができます。 IBLite は配布自由で、同じプラットフォーム上の InterBase ToGo エディションに比べ、機能に制限があります。 ただし、追加費用により、IBLite を、より機能の豊富な InterBase ToGo にアップグレードすることは可能です。 詳細については、次を参照してください:http://www.embarcadero.com/products/interbase/interbase-feature-matrix.pdf

要件と制約

  • iOS バージョン 5.1、6.0 以上必須。 この OS バージョンより前が稼働するデバイスは、サポートされていません。
  • Android バージョン 2.3 以降が必要。特に、Android OS バージョン Gingerbread、ICE、Jelly Bean。 この OS バージョンより前が稼働するデバイスは、サポートされていません。
  • Android 上の InterBase は、InterBase UDF および Filters をサポートしません。これは、すべてのサポート モバイル プラットフォーム(iOS と Android の両方)上の機能セットを、同じものにするためです。
  • Android 上の InterBase アプリケーションは、ネットワーク上のリモート InterBase サーバーへ接続する、ピュア「クライアント」モードとして動作することができます。 このためには、InterBase サーバー バージョンは、2009(9.x)以降でなければなりません。
  • Android 上の InterBase アプリケーションは、ODS バージョンが 13 以降の組み込みデータベース ファイルとのみ、接続することができます。 データベース ファイルが Android InterBase プラットフォーム以外からコピーされた場合には、InterBase バージョン 2009 以降で作成(もしくは復元)されたエータベースのみがサポートされる、ということになります。
  • ibconfig 制限: Android デバイスは、その他のデスクトップ/サーバー マシンと比較して、限られた RAM しか備えていないため、次のパラメータにより、InterBase のフットプリントを、より小さいサイズに維持する必要があります:
    • パラメータ DATABASE_CACHE_PAGES は、デフォルト 75 ページに
    • パラメータ SORTMEM_BUFFER_SIZE は、デフォルト 128KB に

メモ: 現在、ToGo および IBLite は、InterBase XE3、ToGo および IBLite XE3 エディション上でのみサポートされています。

  • InterBase iOS モバイル プラットフォームとの InterBase は、InterBase XE3 で導入されています。 ToGo および IBLite は、RAD Studio XE7 により iOS プラットフォームで利用可能になります。 モバイル デバイス上にデプロイされたデータベースは、admin.ib を介した集中ユーザー認証か、EUA を使用して、データベース内のユーザー アクセスを制御することができます。 VAR および OEM は、自分のアプリケーションを InterBase XE3 ToGo XE3 エディションとリンクすることにより、モバイル デバイス上で InterBase を使用できるようになりました。
  • iOS 用に構築されたアプリケーションは、InterBase ToGo を、Lite ライセンスで埋め込むことができます。 IBLite は、配布「無料」です。 このアプリケーションには、同じプラットフォーム上で InterBase ToGo Edition と比較した際、機能に制限があります。 ただし、追加費用により、IBLite を、より機能の豊富な InterBase ToGo にアップグレードすることは可能です。
  • 重要: 詳細については、「ToGo クイック スタート」 を参照してください。

InterBase JDBC アプリケーションへの新しい接続プロパティ

InterBase XE3 Update 3 では、JDBC ドライバにおいて、新しい接続プロパティ returnColumnLabelAsColumnName を導入しています。 Pentaho では、エイリアス/ラベル名を実際に返すために(アプリケーションから提供されている場合)、ResultSetMetaData.getColumnName() が必要です。 JDBC 仕様に準拠し、既存の InterBase JDBC アプリケーションへの後方互換性を維持するために、この新しい接続プロパティは、デフォルトで FALSE になっています。

Pentaho 型の動作のために、新しいプロパティを使用する場合には、次の接続プロパティを設定します:

properties.put ("returnColumnLabelAsColumnName", "true")

重要: 詳細については、『開発者ガイド』を参照してください。

タイムスタンプの表示

InterBase XE3 Update 3 では、「gbak -v」コマンドを使用して、タイムスタンプ詳細情報を見れるようになりました。 InterBase Service 呼び出しの場合、この情報は、リモート サーバーが InterBase XE3 Update 3 以降の場合にのみ、出力されます。

IBConsole の場合、「詳細出力」オプションが有効になっていると、コマンド ライン呼び出しに対する「gbak verbose」と同じ出力が返されます。

GLOBAL TEMPORARY TABLE のサポート

InterBase XE3 Update 2 リリースで、GLOBAL TEMPORARY TABLE サポートにおいて動作に変更がありました。 SQL スクリプトが実行された際、グローバル一時テーブルで、COMMIT/ROLLBACK することなく EXIT が呼び出されると、ISQL は「デッドロック」を報告しました。 この問題を解決するために、GLOBAL TEMPORARY TABLES 関数が再設計され、これにより動作は変更され、デッドロック エラーが改善されました。

同じ接続から発生したトランザクション群が、お互い他者のトランザクション固有(ON COMMIT DELETE)の一時テーブルにある行を見ることは、できなくなりました。 これを行うためには、セッション固有(ON COMMIT PRESERVE)の一時テーブルを使用しなければなりません。このテーブルではすべての行が、同じセッション内で開始されたトランザクション群に可視状態になります。 この場合でも行が接続が終了するまで行が保持されるという点で異なります。

ホーム呼び出し機能

サード パーティから、サード パーティ アプリケーションの一部として InterBase を取得している場合、「ホーム呼び出し」機能を含めることができます。 この機能は、Embarcadero Product Registration System に 1 回限り自動接続を行い、次の情報を渡します:

  • 使用中のライセンス
  • 基盤とするオペレーティング システム

ODBC ドライバの変更

DataDirect ODBC ドライバは、InterBase XE7 に同梱されなくなりました。InterBase XE7 では、新たな InterBase ODBC ドライバが含まれるようになりました。

  • この変遷の詳細説明については、http://edn.embarcadero.com/article/42838 を参照してください。
  • ODBC ドライバの利用に関するさらなる情報については、『開発者ガイド』 の「ODBC を使用するアプリケーションのプログラミング」を参照してください。

並列インデックスの作成

データベースを復元する際、テーブルのデータが復元されると、そのテーブルに対するインデックスもすべて同時に作成することができます。 これは、エンジンが作業を容易に行えうためのスレッド/コアにアイドル状態がある場合、テーブル データのキャッシュ共有による恩恵よりもさらに迅速に、応答時間を復元する助けになります。 また、SET STATISTICS を使用したインデックスの SELECTIVITY の再計算も同時に行うことができます。 InterBase は、デフォルトでこのようなオペレーションのためにアシスタント スレッドを 1 つ有効にします。このようなオペレーションで利用できる並列スレッドの数は、ibconfig ファイルの MAX_ASSISTANTS 設定パラメータを変更することにより調整することができます。

データベースおよびユーザー テーブルのスペース予約の防止

この機能は、本来保管目的のテーブルを持つ非常に大規模なデータベース(VLDB)などの場合に便利です。 保管テーブルとは、テーブルの行が、低頻度かほとんど更新または削除されず、多くの部分の行を処理する集計や分析など複雑なクエリを持っており、インデックスが再構築されたり、データベースが頻繁にバックアップ/復元される場であることを意味します。 これらのデータベース オペレーションにより、20% 以上のパフォーマンス向上と、保管スペースの節約が見込めるでしょう。

デフォルトでは、InterBase は、内在行上に、UPDATE や DELETE オペレーションを最適化するためのテーブルの各データ ページ内に、少量の領域を予約します。 この予約領域は、最終的にはすべてのテーブル行によって占められる合計領域の 20% 以上になります。 テーブルによっては、低頻度もしくはほとんど更新(UPDATE)されない、または、行が決して削除されない、履歴データまたはデータをアーカイブします。 ほとんどまたはすべての行を処理するデータベース オペレーション(バックアップ、復元、インデックス作成、集計)は常に、この予約オーバーヘッドに比例してパフォーマンスのペナルティに苦しみます。

このため、CREATE/ALTER TABLE 句が取り入れられています。これは、領域予約を回避し、最も効果的な圧縮率で行パッキングを最大化します。 データベース レベルでは、-USE_ALL_SPACE スイッチでデータベースの復元を可能にして、テーブルのための領域予約を不要にします。 新規または既存のデータベースに対して、同様の方法でストレージの振る舞いを変更するには、CREATE/ALTER DATABASE. に対して同じ句を導入します。

ユーザー インターフェイス

新しいストレージの振る舞いを実現するため、非標準 SQL 句が追加されました:

  • CREATE DATABASE <file name> ... [NO] RESERVE SPACE. 句は、2 つ目のファイル指定の前に現れます。
  • CREATE TABLE <table name> ... [NO] RESERVE SPACE. 句は、列リスト指定および任意の一時テーブルに対する ON COMMIT 句の後に現れます。
  • ALTER DATABASE ... SET [NO] RESERVE SPACE. 句は、他の SET 要素と共に、任意の順番で現れます。
  • ALTER TABLE <table name> ... SET [NO] RESERVE SPACE. 句は、他の ADD、DROP、ALTER 要素と共に、任意の順番で現れます。

これは、新たに挿入された(INSERTED)行に、DELETE レコード バージョン スタブのためのデータ ページ上に、通常ならそうであるところ、領域を予約をさせないようにします。 多数の行挿入を行うにつれ、この機能がない場合のテーブルサイズに比べて、ストレージ サイズの減少が観察できるでしょう。 ALTER TABLE と使用される任意の NO キーワードは、そのテーブルに対する現在のストレージの振る舞いを別の状態へ切り替えます。

NO RESERVE ストレージ修飾子は、データベースを超えてバックアップや復元を維持します。 この状態は、システム テーブル RDB$RELATIONS 内のユーザーのテーブル エントリに対して、フラグ ビット 64 (0x100) の RDB$RELATIONS.RDB$FLAGS として保存されます。

この句は、ISQL の SHOW TABLE コマンド表示され、続いてテーブルの列定義が列挙されます。 これはまた、ISQL の抽出(-x)コマンドを正しい構文方法で、各テーブルを列挙する CREATE TABLE 出力に対して使用することで表示することができます。 データベース レベルのストレージ動作の状態は、RDB$RELATIONS 内の RDB$DATABASE エントリと同じように保管されます。

要件と制約

  • InterBase 2020 Update 4 は、NO RESERVE テーブルの状態を、それがアタッチできるどのデータベース ODS に対しても設定できます。 データベースがインストール済みの古いバージョンの InterBase にコピーされた場合、ストレージの動作は強化されず、それ以降の INSERT された行は、記録戻し用バージョンのためにページ上に領域を予約します。 これは、領域を消耗する以外の損害がありません。
  • 既存のテーブルを領域を予約しないよう変更(ALTER)しても、既存の行に影響はありません。 テーブルが非常に大きくなることが想定される場合には、それに応じてユーザーが計画し、必要に応じてバックアップ/復元を行います。 ただし、新たに挿入された行はその領域を再度確保し始め、指定されたデータ ページの状態は、新たな行のために領域が使用可能になったことを示すよう変更されます。
  • データベース レベルの状態が NO RESERVE SPACE に設定された場合、これはテーブル レベルで設定されたものより優先されます。
  • テーブルレベルの状態は「固定」され、データベースレベルの状態がデフォルトの RESERVE SPACE に戻されるまで保持されます。
  • 新しい設定を有効にするために、データベースをデタッチし、再度アタッチし直す必要はありません。
  • 新しいキーワード RESERVE および SPACE は、SQL キーワード トークンとして「予約」されていません。
  • デフォルトの動作に戻った際、RDB$RELATIONS.RDB$FLAGS の RESERVE ビットがクリアされる以外、出力(例、RESERVE SPACE)や見える状態の変化はありません。 これは意図的なもので、移植性に影響を及ぼすかもしれない非標準 SQL 拡張で、他のクリーンな ISQL の抽出物を乱さないようにするためです。
  • データベース全体に対する gbak に USE_ALL_SPACE オプションを指定することにより、復元時にこの予約を止めることができます。

Windows、MacOS X、Linux、iOS、Android の各デバイス間での物理データベースの移植性

InterBase では、Windows、Mac OSX、Linux、iOS、Android 上でのデプロイメントがより簡単になりました。 これにより、Windows 32 ビットおよび 64 ビット、Mac OSX、Linux、iOS、Android 間で、データベース ファイルをコピーが可能になっています。 あるプラットフォーム上で開発をし、開発プラットフォーム上でデータベースを作成し、その後、別のサポートされているプラットフォームに容易にデータベースを配布することができます。 たとえば、Windows 32 ビット上の RAD Studio で開発し、データベースをそこで作成し、その後、それらのデータベースをそのまま、Windows 64 ビットや Mac OS X、iOS、Android 用のデプロイメントの一部に含めることができます。

制限も一部あり、特定の機能を使用できない場合もあります。 これらの機能を利用したい場合には、以下に一覧されているものをご確認ください。 このコピー機能は、次のものを保有していない、単一ファイル データベースに対して承認されています: UDF またはフィルタ、外部テーブル、ジャーナル機能、オンラインおよびインクリメンタル ダンプ、シャドーイング。

以前のバージョンの InterBase のように、GBAK スイッチ -transportable を、「安全な」転送メカニズムとして使用することができます。 このスイッチは、InterBase によって、データベースが別のサポートされているプラットフォームに復元することを許可します。 異種エンディアン間対応なため、gbak -t の使用により、データベースを、Windows、MacOS X、Linux、iOS、Android から Solaris へ移動させることができます。

さらなる情報については、『操作ガイド』の「gbak 使用のための一般的ガイドライン」を参照してください。

メモ: データベース ファイルを、リトル エンディアンからビック エンディアンのプラットフォームへ、またはその逆へ、直接移動させることはできない点には、特に注意してください。

制限付き機能

以下に一覧されている機能は、特に注意が必要とするものです。 これは通常、プラットフォーム特有のパス名の慣習にまつわるものであり、たとえば、パス名の区切り文字、パス名の大文字小文字の区別などが挙げられます。

  • UDF とフィルタ ライブラリ
  • マルチファイル データベース
  • 外部テーブル
  • ジャーナル機能
  • オンライン ダンプおよびインクリメンタル ダンプ
  • シャドウ データベース ファイル(この機能は ToGo エディションでは使用できません)
  • システム暗号化パスワード(SEP: 外部 SEP ストレージ機能は NodeID に依存します)。
  • ディスク上のデータベース ファイル名は、あるプラットフォーム(UNIX)では大文字小文字を区別し、他では区別しない。
  • これについては、接続 URL でデータベース ファイル名を直接指定する際、または、データベース ファイル名を使用する機能(データベース エイリアス機能など)を使用する際、意識してください。

InterBase のマルチファイル DB の設定をコピーする、さまざまな方法をすべて承認するのは不可能なことです。 このため、使用している特定の環境での問題を把握しなければなりません。 一つの選択肢は、単一 DB ファイルに簡易化し、後でデプロイメント時にマルチファイル操作用に構成する方法です。 詳細については、「操作ガイド」 の次の項を参照してください: 「マルチ ファイルと単一ファイルのバックアップと初期化」

新しい IBCONFIG パラメータ

InterBase XEU4 パッチ インストーラには、ibconfig.orig ファイルが入っています。 このファイルには、新しい IBCONFIG パラメータの "MAX_DB_VIRMEM_USE" が含まれています。 このパラメータは、データベース キャッシュ割り当ておよび拡張が使用できなくなった後の、仮想メモリ使用の制限をコントロールします。 デフォルトは 90 です(ただし、データベース キャッシュ割り当ての要求が、プロセスの仮想メモリの 90% を使用する前に来ていた場合、それは許可されます)。

前のバージョンでインストールされたデフォルトの "ibconfig" に変更を加えていない場合、ibconfig.orig を ibconfig 上にコピーし、サーバーを再起動するだけで利用することができます。 さらなる詳細については、"ibconfig" ファイル内のパラメータ定義およびコメントを参照してください。

InterBase(32 ビットおよび 64 ビット)向け ADO.NET プロバイダ

RAD Studio に dbExpress 用 64 ビット ドライバが追加されています(RAD Studio XE2 において)。これにより、64 ビット Ado.NET ドライバを使用することができます。

既存の Ado.NET ドライバの 32 ビット インストーラは変更され、64 ビット アセンブリと統合して同じインストーラとなりました。 このインストーラは、ターゲット OS プラットフォームに必要なアセンブリを判別してインストールするようになっています(32 ビット OS には 32 ビット アセンブリ、64 ビット OS には 64 ビット アセンブリを)。

さらなる情報については、『開発者ガイド』の「InterBase(32 ビットおよび 64 ビット)向け ADO.NET プロバイダ」を参照してください。

OTW SSL TCP/IP 接続の更新

OTW SSL TCP/IP 接続を使用する場合: InterBase XEU3 リリースより、/secure/server/ibss_config ファイルの IBSSL_SERVER_HOST_NAME パラメータで、サーバー ホスト名を指定する必要がなくなりました。 このため、本リリースの新しい ibss_config デフォルト ファイルでは、このパラメータはコメントアウトされています。 IBSSL_SERVER_HOST_NAME パラメータが設定されていない場合、InterBase サーバーは、非 SSL TCP/IP 接続で使用されているのと同じホスト名を使用します。

ibss_config ファイルでホスト名を指定する場合、そのホスト名で、IPv6 アドレスではなく、IPv4 TCP/IP アドレスを解決できることを確認してください。 強制的に IPv4 を解決する 1 つの方法は、ホスト名を、有効化 IPv4 アドレスと共に、hosts ファイルに記述することです。 Windows では、ホスト名は、<Windows システム フォルダ>\drivers\etc\hosts ファイルに記述します。

DES 暗号化キーのバックアップおよび復元の強化

バックアップ/復元操作は、暗号化されたデータベースに対してのみに制限することが可能になりました。 さらなる情報については、『データ定義ガイド』 の「データの暗号化」を参照してください。

OpenSSL 1.0.0a から 1.0.0d への更新

InterBase XEU2 では、OpenSSL が 1.0.0a から 1.0.0d に更新されました。

InterBase XE での OpenSSL 使用に関する詳細については、『操作ガイド』の「ネットワーク設定」と、『データ定義ガイド』の「データの暗号化」を参照してください。

OpenSSL の詳細については、「OpenSSL」を参照してください。。

データベース ファイルに対する InterBase ダイレクト入出力

InterBase XE3 Update 4 Hotfix 1(バージョン 11.0.4.816)以降で、Windows 2008 R2 および Windows 7 の 64 ビット OS エディションでの、同期/非同期データベース書き込みモードにおけるパフォーマンス問題が解決されています。 データベースに対して「ダイレクト」入出力を行い、システム ファイル キャッシュを完全に回避することも引き続き可能ですが、旧バージョンで報告されていたパフォーマンス問題のためにそれを行う必要はありません。

さらなる情報については、「データベース ファイルに対する InterBase ダイレクト入出力」(『操作ガイド』)を参照してください。

InterBase (32 ビットおよび 64 ビット)ネイティブ バイナリ アプリケーション

32 ビット版でも 64 ビット版でも、まだダイアレクト 1 を使用している場合には、ダイアレクト 3 に移行する必要があります。 パフォーマンス モニタ テーブルではカウンタが正しく動作せず、エラーが発生します。 詳細は、『操作ガイド』の「SQL ダイアレクトを理解する」を参照してください。

InterBase 32 ビット ネイティブ バイナリ アプリケーション

ib_install.exe には 32 ビット版が含まれています。 32 ビット版を Windows 上で使用したい場合には、このインストーラを実行する必要があります。

InterBase 64 ビット ネイティブ バイナリ アプリケーション

  • 64 ビット版でも、32 ビットの InterBase アプリケーションを引き続き使用することができます。
  • 32 ビット オペレーティング システムに 64 ビット キットをインストールすることはできません。
  • InterBase では下位互換性を重視しているため、新しいエディションへの移行が容易です。

以下のトピックでは、64 ビット アプリケーションを実装する際に必要な重要な情報を取り上げます。

互換性について

  • 古いバージョンのクライアントからのローカルおよびリモートの接続は、新しいバージョンの 32 ビットおよび 64 ビットのサーバーと問題なく連動し、逆も同様です。
  • IBMgr.exe および IBConsole.exe は 32 ビット アプリケーションのままです。 32 ビットおよび 64 ビットのサーバーそれぞれと問題なく連動します。
  • このバージョンでは、InterBase のこれまでのリリースで導入された、既存の ODS 12.x および ODS 13.x のデータベースをサポートしています。
  • データベースでサポートしている ODS バージョンに互換性があれば、(このバージョンの)InterBase の 32 ビット キットと 64 ビット キットでデータベースを移動することができます。

64 ビット DLL のクライアント ライブラリ名の変更

以下の表に、64 ビット DLL の新しいクライアント ライブラリ名を示します。

ライブラリ名 位置 メモ
ibclient64.dll /bin ネイティブ 64 ビット アプリケーション用の新しい InterBase クライアント DLL です。 現在、64 ビット InterBase コマンドライン ツールで使われており、(32 ビット ターゲット用の gds32.dll の代わりに)顧客が作成した 64 ビット アプリケーションと一緒に配置する必要があります。


ibxml64.dll /bin ネイティブ 64 ビット アプリケーション用の新しい InterBase XML DLL です。 顧客が作成した 64 ビット アプリケーションで InterBase XML API を使用している場合には、(32 ビット ターゲット用の ibxml.dll の代わりに)アプリケーションと一緒に配置する必要があります。


ib_util64.dll /bin ネイティブ 64 ビット アプリケーション用の新しい InterBase UTILS DLL です。 (32 ビット ターゲット用の ib_util.dll の代わりに)顧客が作成した 64 ビット アプリケーションと一緒に配置する必要があります。


ibclient64_ms.lib /SDK/lib_ms ibxml64.dll を対象とする 64 ビット アプリケーションを作成するためのインポート ライブラリ。


ib_util64_ms.lib /SDK/lib_ms ib_util64.dll を対象とする 64 ビット アプリケーションを作成するためのインポート ライブラリ。


BLOB/CLOB をサポートするための JDBC ドライバの更新

JDBC に対して新しいインターフェイスが実装されています。 BLOB、CLOB、その他関連 API インターフェイスに関するさらなる情報については、『開発者ガイド』の「JDBC を使ったプログラミング」を参照してください。

強度の高いパスワード保護

InterBase データベース上での強度の高いパスワード保護が、InterBase XE で実装されました。 この追加機能では、パスワードの有効文字数が増えるため、パスワード保護が強力になります。 さらなる情報については、『操作ガイド』の「強度の高いパスワード保護の実装」を参照してください。

64 ビット版 InterBase でのデータベース キャッシュ設定の拡大

64 ビット版 InterBase でデータベース キャッシュ設定に指定できる値が大きくなりました。 32 ビット版エンジンでは上限が 750K ページでしたが、64 ビット版エンジンでは 7500 万ページになりました。 さらなる情報については、『操作ガイド』の「InterBase の制限」を参照してください。

ストアド プロシージャの EXECUTE STATEMENT

InterBase XE で EXECUTE STATEMENT 機能をサポートするようになりました。 この機能によって、InterBase のストアド プロシージャ言語が強化されています。 これが実装されると、ストアド プロシージャの開発時に 3 種類の EXECUTE STATEMENT をストアド プロシージャ内に埋め込むことができます。 この種類は、EXECUTE STATEMENT コマンドから返される行の数によって分かれています。 次の 3 種類です。 データ行が返されないもの、データが 1 行だけ返されるもの、複数のデータ行が返されるもの。

重要: InterBase XE7 Update 1 より、SELECT リストのすべての項目は、INTO リストの該当する項目に一致してなければならない、という新しい要件が、FOR EXECUTE STATEMENT にに対して追加されました。

さらなる情報については、『言語リファレンス ガイド』の「EXECUTE STATEMENT」を参照してください。

データベースの高速スイープ

データベースをスイープすることで、古いレコードを系統立てて削除することができます。 定期的にスイープを実行すると、データベースのサイズが大きくなりすぎるのを防ぐことができます。 これまではスイープ処理を行うとシステムのパフォーマンスが低下していたため、ユーザーは本番運用に影響が出ないよう、自動データベース スイープ機能を無効化していました。

InterBase XE で高速スイープの最適化が実装されたことで、メモリ割り当ての問題が軽減されました。 そのため、ユーザーはデータベースに自動スイープを構成するという選択ができるようになりました。 さらなる情報については、『操作ガイド』「スイープ間隔と自動保守」を参照してください。

テーブル固有のブロック化因数

ブロック化因数という用語は、1 つのブロックに格納されるレコードの数を表します。 InterBase では、1 つのデータ ページに格納できる行数を最大にするための、データベース レベルのブロック化因数を 1 つ持っています。

個々のテーブルのブロック化因数の値は、次のシステム列で確認できます。

  • RDB$RELATIONS.RDB$DATA_BLOCKING_FACTOR
  • RDB$RELATIONS.RDB$BLOB_BLOCKING_FACTOR

さらなる情報については、『言語リファレンス ガイド』の「表 6.26 - RDB$RELATIONS」を参照してください。

インデックス キーのセグメント サイズの拡大

ODS 15 データベースでは、インデックス キーのサイズの上限が引き上げられています。 列がシングルバイト キャラクタ セットかマルチバイト キャラクタ セット(UTF8 など)かを問わず、サイズの大きい列データでこの機能を使用できるようになりました。 さらなる情報については、『操作ガイド』の「InterBase の制限」表 B.1を参照してください。

新しい IBCONFIG パラメータ APPDATA_DIRECTORY

上記の「プログラム データ」の場所を示す値を、すべての InterBase アプリケーション(および、データベース エンジン)に示すため、APPDATA_DIRECTORY(InterBase XE3 での新しいパラメータ)のための新しい IBCONFIG パラメータ値が、インストール時に自動的に追加されるようになりました。 この値では、上記の「プログラム データ」場所への、絶対パスを提供します。 さらなる詳細については、<interbase>/ibconfig ファイルを参照してください。

  • プログラム データの場所
  • [Program Files] の位置が、読み取り専用である必要のあるファイルのために、まず使用されます。
    • ディレクトリ: システムの [Program Files] フォルダ (Windows 32 ビット、64 ビットで異なる)
      • ibconfig (古いバージョンの InterBase から移行している場合には、ここに古いカスタマイズ済みのファイル配置する)
      • バイナリ(サーバー、グラフィカル ツールやコマンドライン ツールなど)
      • SDK
      • interbase.msg
      • Doc サブフォルダ(PDF や HTML のドキュメントなど)
      • 製品の使用許諾書(License.txt および oss_license_notice.txt)
  • Borland から Embarcadero への Windows レジストリの変更
  • InterBase は、Windows レジストリを使用して、InterBase サーバー ベースの製品の特定のインストール インスタンスについての情報を保有しています。 Borland からの遺産により、以前の InterBase バージョンでは、この情報を Windows レジストリ キー 「HKEY_LOCAL_MACHINE\Software\Borland\InterBase\Servers\」以下に保持していました。
  • InterBase XE3 より、「HKEY_LOCAL_MACHINE\Software\Embarcadero\InterBase\Servers\」以下の Windows レジストリ階層を使用します。 InterBase サーバー、ガーディアン、クライアント ライブラリ、IBMgr、および IBConsole の各プログラムについて、この変更をサポートするよう変更されています。