InterBase XE7 の新機能

提供: InterBase
移動先: 案内、 検索

メインページ へ戻る


以下のページでは、InterBase XE7 の更新での新機能について説明しています：


リリース日： 2014年11月

ようこそ

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

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

システム要件

InterBase XE7 をインストールおよび実行するためのシステム要件については、「システム要件と前提条件」を参照してください。

新機能

変更ビューの機能

変更ビュー（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 を介して追加されています：

メモ： データベースを必要とせず、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 関連オペレーションの練習です。


トピック

関連項目

「https://docwiki.embarcadero.com/InterBase/XE7/j/index.php?title=InterBase_XE7_の新機能&oldid=4390」から取得