新機能: InterBase XE7

InterBase XE7 では、次の新機能と、既存機能に対する強化が行われています。

変更ビュー
Linux 32 ビットと 64 ビット
パフォーマンスの強化
パフォーマンスモニタリングカウンタ
部分セグメントの選択性
64 ビットトランザクション ID
ODS の変更
OpenSSL のアップグレード
オンラインダンプとジャーナルアーカイブ操作のためのサービス API サポート

1 変更ビューの機能
2 Linux 32 ビットと 64 ビット
3 ライセンスマネージャ
4 パフォーマンスの強化
5 パフォーマンスモニタリングカウンタ
- 5.1 後方互換性
6 部分セグメントの選択性
7 64 ビットトランザクション ID
8 ODS の変更
- 8.1 データベースバックアップが、古い ODS の特定のバージョンに復元できるように
- 8.2 この実装を利用するための複数の方法
9 OpenSSL のアップグレード
10 オンラインダンプおよびジャーナルアーカイブ操作のための Services API サポート
- 10.1 オンラインダンプおよびインクリメンタルダンプ
- 10.2 ジャーナルアーカイブ管理アクション

変更ビューの機能

変更ビュー（Change View™) 機能は、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 は、現在、インデックス毎に単一の選択値を維持するようになっています（単一または複合キー）。値は降順で格納されており、全体のインデックスでいくつ重複が存在するか情報を追跡します -- ただし第１レベルまでです。しかし、下位レベルでの情報があると有益な場合もあります。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 使用に関する詳細については、『操作ガイド』の「ネットワーク設定」と、同様に http://docs.embarcadero.com/products/interbase/ 『データ定義ガイド』] の「データの暗号化」を参照してください。

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

オンラインダンプおよびジャーナルアーカイブ操作のための 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 バイト + 文字列	文字列
isc_action_svc_dump	isc_spb_dmp_file	ダンプ出力ファイルのパス。複数の出力ファイルを指定することができます。	2 バイト + 文字列	文字列
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 のアクション群

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

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

次の Services API ジャーナルアーカイブ管理アクションが追加されました：

アクション	引数	目的	引数の長さ	引数の値
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
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 値で、データベースダンプファイルをスイープするシーケンス番号を示す。

上記に掲載された SPB パラメータすべてのサンプルアプリケーションが、<interbase>/examples に提供されています。start_dump.c は、オンライン/インクリメンタルダンプオペレーションの練習です。ib_archive.c は、Journal Archive 関連オペレーションの練習です。