変更ビュー入門

ODS プラットフォーム更新

変更ビューは、InterBase ODS の基礎部分での変更が必要であるため、既存のデータベースをバックアップし、この機能をサポートする ODS バージョンに復元する必要があります。新たな ODS 形式のため、復元されたデータベースは、古いエディションの InterBase からはアタッチすることができません。

FOR ROW (..., DELETE) で定義されたサブスクリプションは、行が削除される前に存在した列の値を持つ行を返します。レポートアプリケーションでの演習では、既存のデータについて、そのようなサブスクリプションがトランザクションにバインドされないよう、警告しています。そうでなければ、結果セットに、すでに存在しないデータが含まれてしまいます。

変更ビューで作業する際には、「奇数の」SQL DATA TYPES (SQLVAR variable, sqltype) を使用する必要があります。これにより、SQLVAR 内の SQL インジケータ変数は、返される列データのステータスを受け取ることができます。
変更ビューから選択する際には、トランザクションの SNAPSHOT 排他レベルを使用する必要があります。変更ビューのデータを変更する際には、どの排他レベルも使用することができます。
InterBase テーブルは、256 個までレコード形式のバージョンを保持することができます。サブスクリプションがテーブルを参照している場合、これは、そのテーブルにとって、新しいレコード形式という結果になります。大量の CREATE SUBSCRIPTION 文を発行する場合、自動コミット DDL オペレーションを無効にし、多数のサブスクリプションからの、複数のテーブル参照から、単一のレコード形式が構築されるようにします。

この機能は、変更されたデータビューの観察タイムスタンプに対するプロキシとして、トランザクション ID にかなり依存しており、変更されたデータ結果は、重複して再送されないことを前提としています。現在、データベースバックアップはコミットされたデータのトランザクション ID を保存せず、0 にリセットされたトランザクション ID でデータベースを復元します。 32 ビットのトランザクション ID 領域は、カスタマ側で消費されており、これはデータベースバックアップや復元を伴います。
このプロジェクトでは、64 ビット（どちらといえば 48 ビット）トランザクション ID への変換を想定しており、これは、一定の理にかなった期間、それらが消耗されないことを前提としています。たとえば、4KB ページサイズのデータベースは、10,000 tps を超えた状態で、100 年の間、48 ビットトランザクション ID で持続的に実行することができます。変更されたデータビューのサポートに加え、InterBase データベースは、バックアップや復元のためにシャットダウンする必要がありません。これは、トランザクション ID が消耗されているからです。

論理バックアップ/復元は、すべてのサブスクリプション定義をバックアップおよび復元します。しかし、これらサブスクリプションを使用しているサブスクライバを追跡するデータは、バックアップ/復元されません。サブスクライバは、新しい（または復元された）データベース上で、サブスクリプションを初期化/活性化する必要があります。

ソースデータベース内の変更のシーケンスまたは順番は、変更データビューによってキャプチャされません。これは異なるテーブルにわたる変更に関して、単一テーブル内での変更と同様に当てはまります。疑似列 RECORD_VERSION または TRANSACTION_ID を公開し、その列上の変更データ結果セットをソートすることで、このシーケンスを概算することは可能です。しかしながら、あらゆる使用ケースにおいて、変更の正しい順序を保証するものではありません。変更の順番は、1 つまたは複数のサブスクリプションを同期メカニズムで使用する場合に、制約チェックを実施する上で重要です。 InterBase は、IMMEDIATE 制約チェックのみサポートしており、サブスクリプションの変更が、さまざまな制約が整備されている対象データベースに提供されるよう、DEFERRED 制約チェックをサポートすることも必要な場合があります。

InterBase により、名前付きトリガは、非活性化に宣言することができます。サブスクライブされた変更が対象データベースに適用される場合、アクションの発動は抑制されるべきかもしれません。これはアプリケーションによって変わる判断事項です。ただし、トリガを非活性化する範囲は、単一のデータベースセッションに限定されるべきです。 InterBase makes the trigger inactive across all database sessions for the database. オペレーションの制限された範囲に対するものと同様の要件が、DEFERRED 制約に対しても当てはまります（それが実装されている場合）。

データベースが論理バックアップファイルまたは物理ダンプファイルから復元された場合、サブスクライバは、すでに受け取ったサブスクリプションしている変更を、受け取る可能性があります。メタデータ RDB$SUBSCRIPTIONS.RDB$CHECK_OUT_TIMESTAMP は、サブスクライバが保存しておくと、重複変更の処理の問題の助けになります。