InterBase XE7 Update 4 Readme
InterBase Readme へ戻る
リリース: 2015年7月
本リリースでは、複数の更新と強化が行われています。各機能の一覧と説明については「新機能」を参照してください。 このファイルには重要な情報が含まれており、その中にはオンライン ヘルプにまだ記載されていないものもあります。 このファイルはひと通り目を通してください。
重要: このドキュメントの最新バージョンについては、こちら をご覧ください。
この Readme は、次のセクションから構成されています:
1. システム要件
InterBase Developer、Desktop および Server Edition
メモ: Desktop Edition は、Windows でのみ利用可能です。
- サポートされるオペレーティング システム:
- Windows(64 ビット、32 ビット):
- Windows 11
- Windows 10
- Windows 8、8.1
- Windows 7
- Windows Vista
- Windows Server 2022
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012、2012 R2
- Windows Server 2008、2008 R2
- Linux(64 ビット、32 ビット):
- RHEL 8
- SuSE 11.3
- Ubuntu 20
- Ubuntu 18
- Windows(64 ビット、32 ビット):
- サポートされるプロセッサ アーキテクチャ:
- Windows、Linux
- Intel x86 または Intel x86-64
- Windows、Linux
- ハード ディスク領域
- インストール ファイル: 250MB(日本語版の場合 350MB)
- インストールに必要な容量:
- クライアントのみインストールするには ~46 MB
- サーバーとクライアントをインストールするには ~117 MB
InterBase ToGo Edition
- サポートされるオペレーティング システム:
- Windows(64 ビット、32 ビット):
- Windows 11
- Windows 10
- Windows 8、8.1
- Windows 7
- Windows Vista
- Windows Server 2016
- Windows Server 2012、2012 R2
- Windows Server 2008、2008 R2
- Linux(64 ビット、32 ビット):
- RHEL 8
- SuSE 11.3
- Ubuntu 20
- Ubuntu 18
- macOS(64 ビット、32 ビット):
- Monterey (12)
- Big Sur (11)
- Catalina (10.15)
- Android:
- 13
- 12
- 11
- 10
- Pie (9.x)
- Oreo (8.x)
- iOS
- iOS 17
- iOS 16
- iOS 15
- iOS 14
- Windows(64 ビット、32 ビット):
- 必須ライブラリ:
- JRE
JRE は Windows、Linux、macOS の各システム上でライセンス マネージャを実行するために必要です。 Linux システムは openjdk-8 が必須で、例えば Ubuntu では、
sudo apt install openjdk-8jdk
で実行できます。
RHLE 9 に InterBase をインストールする場合、fapolicyd がインストーラーに含まれる JDK バージョンの実行をブロックすることにより、インストールが失敗する場合があります。 これを解決するには、fapolicyd の実行を停止してください:
systemctl stop fapolicyd
を実行後、InterBase インストーラーを実行し、インストール完了後に fapolicyd を開始します。 fapolicy の詳細については、fapolicy のドキュメントを参照してください。
2. 新機能
InterBase 2020 Update 6 Update 4:
- 解決された不具合については、こちらを参照してください。
InterBase 2020 Update 6 Update 3:
- 解決された不具合については、こちらを参照してください。
InterBase 2020 Update 6 Update 2:
- 解決された不具合については、こちらを参照してください。
InterBase 2020 Update 6 Update 1:
- 解決された不具合については、こちらを参照してください。
InterBase 2020 Update 6:
- 解決された不具合については、こちらを参照してください。
- 変更ビューの機能
- Linux 32 ビットと 64 ビット
- パフォーマンスの強化
- パフォーマンス モニタリング カウンタ
- 部分セグメントの選択性
- 64 ビット トランザクション ID
- ODS の変更
- OpenSSL のアップグレード
- オンライン ダンプおよびジャーナル アーカイブ操作のための Services APIサポート
- メモ: InterBase XE7 より前のリリース情報については、「過去のリリースの Readme」を参照してください。
新機能: InterBase XE7 update 2
InterBase ToGo for Mac OS X でのサンドボックス
Mac OS X 用の RAD Studio Delphi/C++ データベース アプリケーションに、サンドボックスを提供することができます。 RAD Studio を利用した InterBase アプリケーションのサンドボックス環境に関する詳細については、「InterBase ToGo for Mac OS X でのアプリケーションのサンドボックス」を参照してください。
新機能: InterBase XE7 update 1
ToGo Edition でのワークフローに対する更新
本リリースには、登録後 30 日で期限切れとなる ToGo Trial Edition が含まれています。 ライセンス情報については、「InterBase ToGo トライアル ライセンス」を参照してください。
変更ビューの機能
本リリースでは、変更ビューに次の更新が含まれています:
DROP SUBSCRIPTION
サブスクリプションをドロップする機能が、変更ビューに追加されました。 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 オペレーションによる、列の変更を検知します。
既知の制約
- InterBase XE7 Update 1 より、SELECT リストのすべての項目は、INTO リストの該当する項目に一致してなければならない、という新しい要件が、FOR EXECUTE STATEMENT にに対して追加されました。
- CREATE SUBSCRIPTION 構文は基本テーブルに限定されます。
- CREATE SUBSCRIPTION は、テーブルの所有者によってのみ、テーブルに適用されます。
IBConsole での更新
本リリースには、IBConsole 機能に対する大きな更新がいくつか含まれています:
[Start Here]タブ
[Start Here]タブは、IBConsole にアクセスすると開きます。 このタブには、ビデオ、ユーザー ガイド、チュートリアルのコレクションがあります。 また、InterBase の Web サイトへのアクセスも提供しており、そこでは、概要、新機能の説明、FAQ、用語集、チュートリアル ビデオなどは公開されています。
IBConsole のデータベース ペイン
左下隅にあるペインには、頻繁に使用されるデータベースが一覧されます。 ペインには、そのデータベースへ接続するためのリンクであるデータベース エイリアスと、サーバー名、そして、データベースが最後にアクセスされた日付が表示されます。
変更ビューのサブスクリプション サポート
IBConsole が、サブスクリプション エディタをサポートしました。 このサブスクリプション エディタは、暗黙ビューで観察できた前のトランザクション移行に変更されたデータを返します。 これにより、前回自分が見た後に変更されたデータを確認することができます。
- データベースのサブスクリプション フィールドをクリックし、Create をクリックすると、サブスクリプション エディタ ダイアログにアクセスすることができます。 既存のサブスクリプションの名前を入力できます。 エディタには、tablename、fieldnames、Change、Insert、Update、Delete の詳細事項が一覧されます。 これらの詳細は、追加または削除することができます。 また、編集されたサブスクリプションの説明を入力することも可能です。
新機能: 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 は、現在、インデックス毎に単一の選択値を維持するようになっています(単一または複合キー)。 値は降順で格納されており、全体のインデックスでいくつ重複が存在するか情報を追跡します -- ただし第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 使用に関する詳細については、『操作ガイド』の「ネットワーク設定」と、同様に 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 関連オペレーションの練習です。
3. 移行における問題
4. 既知の問題
- 変更ビューの SQL キーワード - 変更ビューの機能でいくつか予約キーワードが追加されており、これらは SQL オブジェクトと競合する場合があります。そのキーワードは次の通りです: CHANGE、CHANGED、INSERTED、UPDATED、DELETED
- 古いクライアント(古い IBConsole)が、新しい ODS 16 データベースに接続しようとすると、例外が発生する点に注意してください。これは、そのクライアントが INTEGER として定義されていないデータ型に直面するためです。
- 回避策: 新たな IBConsole をインストールして、新旧の InterBase サーバーに接続します。 新しい IBConsole は、この用途のために後方互換性があります。
- IBConsole パフォーマンス モニタリングが、誤った値を ODS 16、ダイアレクト 1 データベースに対して提供します。
- 回避策: ODS 16 ダイアレクト 1 では回避策はありません。 ダイアレクト 3 データベースを使用して、IBConsole パフォーマンス モニタリングを試してみてください。
- UNICODE_LE と UNICODE_BE (いずれも 16 ビットの UNICODE 文字セット)は、サーバーの文字セットとしてのみ使用できます。 これら 2 つの文字セットはクライアントの文字セットとしては利用できません。 クライアントで UNICODE 文字を完全にサポートする必要がある場合、クライアントのキャラクタ セット(別名 LC_CSET)には、UNICODE_LE や UNICODE_BE ではなく UTF8 を使用してください。 クライアントでは、UTF-8(またはその他のネイティブな)クライアント キャラクタ セットを使用して、UNICODE データベースに接続できます。
- InterBase サーバーがクラッシュすると、Windows エラー報告(WER)ダイアログが間欠的に現れます。
- 解決方法: 弊社では、把握しているクラッシュを修正するよう努力しています。 それまでの間は、Windows レジストリを変更すると、Windows エラー報告ダイアログが現れないようにすることができます。 レジストリ属性 HKEY_CURRENT_USERS\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI の値を 1 に設定すると、表示されなくなります。 これは、MSDN の記事 http://msdn.microsoft.com/en-us/library/bb513638(VS.85).aspx の推奨事項によります。 今後のビルドでは、ibserver.exe 内からオプションを構成して、InterBase サーバーのバイナリの場合にだけダイアログを表示しないよう WER を設定できるようにすることを検討しています。
- 問題: ハイパースレッディング: InterBase は、ハイパースレッディングを Windows 上の 32 ビット エディション、およびそれ以前の Intel CPU アーキテクチャでのみサポートしています。 この機能が一部の最新 CPU アーキテクチャ上で動作しないことは、既知の問題です。 お使いの InterBase のデプロイメントが、システム上で利用可能な CPU コア数より少なくライセンス許可されている場合、IBConfig 内の CPU_AFFINITY の設定で、インストールをカスタマイズして、InterBase 用に期待する CPU コア数を選択することができます。
5. 解決された不具合
6. ヘルプが必要なときには
Copyright 2015 Embarcadero Technologies Inc. すべての Embarcadero のブランド名および製品名は、米国、およびその他の国における Embarcadero Technologies の商標または登録商標です。 その他のブランド名または製品名に関する権利はすべてその所有者に帰属します。
本製品は、米国特許または特許出願の、特に 米国特許 5592664 ~ 5918224 によって保護されています。