1. データベース管理者ガイド
  2. 読取り専用マテリアライズド・ビューの管理
  3. 読取り専用マテリアライズド・ビューのアーキテクチャ

59 読取り専用マテリアライズド・ビューのアーキテクチャ

マテリアライズド・ビューのレプリケーションに複数のオブジェクトが使用されています。これらのオブジェクトの一部はオプションで、作成したマテリアライズド・ビュー環境のサポートに必要な場合にのみ使用します。たとえば、高速リフレッシュができない複合マテリアライズド・ビューがある場合は、マスター・データベースにマテリアライズド・ビュー・ログがない可能性があります。

  • マスター・データベースのメカニズム
    マスター・データベースでマテリアライズド・ビューをサポートするメカニズムがあります。
  • マテリアライズド・ビュー・データベースのメカニズム
    マテリアライズド・ビューを作成すると、そのマテリアライズド・ビューをサポートするための追加のメカニズムがマテリアライズド・ビュー・データベースで作成されます。具体的には、1つ以上の索引が作成されます。
  • 編成メカニズム
    いくつかのメカニズムは、マテリアライズド・ビュー・データベースでマテリアライズド・ビューを編成します。これらのメカニズムは、マテリアライズド・ビュー・データベースとそのマスター・データベース間の編成上の一貫性を維持します。
  • リフレッシュ処理
    マテリアライズド・ビューとマスター表との一貫性を確保するには、マテリアライズド・ビューを定期的にリフレッシュする必要があります。

親トピック: 読取り専用マテリアライズド・ビューの管理

59.1 マスター・データベースのメカニズム

マスター・データベースでマテリアライズド・ビューをサポートするメカニズムがあります。

親トピック: 読取り専用マテリアライズド・ビューのアーキテクチャ

59.1.1 マスター・データベース・オブジェクト

マテリアライズド・ビューの高速リフレッシュをサポートするために、マスター・データベースで特定のデータベース・オブジェクトが必要です。

マテリアライズド・ビューの高速リフレッシュをサポートするために、図59-1に表示された3つのデータベース・オブジェクトがマスター・データベースで必要です。

図59-1 マスター・データベース・オブジェクト

図59-1の説明が続きます
「図59-1 マスター・データベース・オブジェクト」の説明

親トピック: マスター・データベースのメカニズム

59.1.2 マスター表

マスター表は、マテリアライズド・ビューの基礎です。

マスター表は、ターゲット・マスター・データベースにあります。マテリアライズド・ビューは、1つのマスター・データベースのみを指します。マテリアライズド・ビュー・ログに記録されたマスター表へのデータ操作言語(DML)の変更は、リフレッシュ・プロセス中にマテリアライズド・ビューに伝播されます。

注意:

高速リフレッシュ可能なマテリアライズド・ビューは、マスター表またはマスター表のシノニムに基づいている必要があります。完全リフレッシュは、ビューに基づいたマテリアライズド・ビューで使用する必要があります。

親トピック: マスター・データベースのメカニズム

59.1.3 マテリアライズド・ビュー・ログの内部トリガー

DMLを使用してマスター表に変更が加えられると、内部トリガーにより、影響を受けた行に関する情報がマテリアライズド・ビュー・ログに記録されます。

この情報には、主キー、行IDまたはオブジェクト識別子(あるいはこれらすべて)の値のみでなく、マテリアライズド・ビュー・ログにロギングされる他の列の値も含まれます。これは、ターゲット・マスター表のマテリアライズド・ビュー・ログを作成するときに自動的にアクティブになるAFTER ROW内部トリガーです。このトリガーは、INSERT文、UPDATE文またはDELETE文により表のデータが変更されるたびに、マテリアライズド・ビュー・ログに行を挿入します。このトリガーは、常に最後に起動されるトリガーです。

注意:

マテリアライズド・ビューに副問合せが含まれている場合は、副問合せで参照される列のログが必要になることがあります。副問合せのマテリアライズド・ビューの詳細は、「マテリアライズド・ビューを使用したデータのサブセット化」、ログを必要とする列の詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。

親トピック: マスター・データベースのメカニズム

59.1.4 マテリアライズド・ビュー・ログ

マテリアライズド・ビュー・ログは、マテリアライズド・ビューの高速リフレッシュを可能にします。

親トピック: マスター・データベースのメカニズム

59.1.4.1 マテリアライズド・ビュー・ログについて

マスター表に基づいてマテリアライズド・ビューの高速リフレッシュを実行する場合は、マスター表のマテリアライズド・ビュー・ログが必要です。

マスター表のマテリアライズド・ビュー・ログを作成すると、Oracleデータベースにより基になる表がマテリアライズド・ビュー・ログとして作成されます。マテリアライズド・ビュー・ログには、マスター表で更新されている行の主キー、行IDまたはオブジェクト識別子を含めることができます。マテリアライズド・ビュー・ログには、副問合せを含むマテリアライズド・ビューの高速リフレッシュをサポートする他の列を含めることもできます。

マテリアライズド・ビュー・ログの表の名前は、MLOG$_master_table_nameです。マテリアライズド・ビュー・ログは、ターゲット・マスター表と同じスキーマに作成されます。1つのマテリアライズド・ビュー・ログは、マスター表の複数のマテリアライズド・ビューをサポートできます。前の項で説明したように、ターゲット・マスター表に対してDMLトランザクションが発生するたびに、内部トリガーによってマテリアライズド・ビュー・ログに変更情報が追加されます。

マテリアライズド・ビュー・ログには次のタイプがあります。

  • 主キー: マテリアライズド・ビューは、影響を受けた行の主キーに基づいてマスター表への変更内容を記録します。

  • 行ID: マテリアライズド・ビューは、影響を受けた行の行IDに基づいてマスター表への変更内容を記録します。

  • オブジェクトID: マテリアライズド・ビューは、影響を受けた行オブジェクトのオブジェクト識別子に基づいてマスター・オブジェクト表への変更内容を記録します。

  • 組合せ: マテリアライズド・ビューは、3つのオプションの任意の組合せに基づいてマスター表への変更を記録します。主キー、ROWID、影響を受ける行のオブジェクト識別子に基づいて変更を記録できます。このようなマテリアライズド・ビュー・ログは、主キー、ROWIDおよびオブジェクト・マテリアライズド・ビューをサポートし、マスター表に基づく3つのすべてのタイプのマテリアライズド・ビューのある環境で役立ちます。

組合せマテリアライズド・ビュー・ログは、1種類のタイプの値を追跡するマテリアライズド・ビュー・ログと同じように機能しますが、複数のタイプの値が記録されるという点のみが異なります。たとえば、組合せマテリアライズド・ビュー・ログは、影響を受けた行の主キーと行IDの両方を追跡できます。

主キーに基づいたマテリアライズド・ビュー・ログと行IDに基づいたマテリアライズド・ビュー・ログの間に大きな違いはありませんが(影響を受けた行を記録する際に、主キーと物理行IDのどちらを使用するかという点のみが異なります)、実際に与える影響は非常に大きくなります。ROWIDマテリアライズド・ビューとマテリアライズド・ビュー・ログを使用すると、ROWIDマテリアライズド・ビューを高速リフレッシュできなくなるため、マスター表の再編成および切捨てが難しくなります。マスター表の再編成または切捨てを実行した場合はマスター表の行IDが変更されるため、ROWIDマテリアライズド・ビューは完全リフレッシュする必要があります。

注意:

  • マスター表の再編成には、DBMS_MVIEWパッケージのBEGIN_TABLE_REORGANIZATIONおよびEND_TABLE_REORGANIZATIONプロシージャを使用します。詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

  • マスター表を再編成するもう1つの方法としては、表のオンライン再定義がありますが、オンライン再定義は、マテリアライズド・ビュー・ログおよびマテリアライズド・ビューを持つマスター表では使用できません。オンライン再定義は、マテリアライズド・ビュー・ログを持たないマスター表に対して実行できます。「表のオンライン再定義」を参照してください。

59.1.4.2 マテリアライズド・ビュー・ログに記録される列

マテリアライズド・ビュー・ログを作成する場合は、必要に応じてログに列を追加できます。

マテリアライズド・ビューを高速リフレッシュするには、マテリアライズド・ビュー・ログに次のタイプの列を追加する必要があります。

  • 副問合せのWHERE句で参照される列で、等価結合の一部ではなく、主キー列でもない列。このような列は、フィルタ列と呼ばれます。

  • 副問合せが多対多または1対多のいずれかの関係の場合に、等価結合内の列で主キー列ではない列。副問合せが多対1の場合は、マテリアライズド・ビュー・ログに結合列を追加する必要はありません。

コレクション列はマテリアライズド・ビュー・ログに追加できません。また、完全リフレッシュを使用するマテリアライズド・ビューの場合は、マテリアライズド・ビュー・ログは不要です。

たとえば、次のようなDDLを考えてみます。

1) CREATE MATERIALIZED VIEW oe.customers REFRESH FAST AS
2)  SELECT * FROM oe.customers@orc1.example.com c
3)  WHERE EXISTS
4)    (SELECT * FROM oe.orders@orc1.example.com o
5)     WHERE c.customer_id = o.customer_id AND o.order_total > 20000);

このDDLの5行目では、WHERE句内で3つの列が参照されています。列orders.customer_idとcustomers.customer_idは等価結合句の一部として参照されています。customers.customer_idは主キー列であるため、この列はデフォルトでロギングされますが、orders.customer_idは主キー列ではないため、マテリアライズド・ビュー・ログに追加する必要があります。また、列orders.order_totalは追加フィルタ列であるため、これもロギングする必要があります。

したがって、orders.customer_idとorders.order_totalをoe.orders表のマテリアライズド・ビュー・ログに追加します。

作成するマテリアライズド・ビューの定義問合せを分析し、マテリアライズド・ビュー・ログに追加する必要がある列を識別することをお薦めします。マテリアライズド・ビュー・ログに列を追加せずに、追加列を必要とするマテリアライズド・ビューを作成またはリフレッシュしようとした場合、マテリアライズド・ビューの作成またはリフレッシュは失敗します。

注意:

マテリアライズド・ビューを高速リフレッシュするには、副問合せ内の結合列をマテリアライズド・ビュー・ログに追加する必要があります(結合列が主キー列ではなく、副問合せが多対多または1対多のいずれかの関係の場合)。副問合せが多対1の場合は、マテリアライズド・ビュー・ログに結合列を追加する必要はありません。

関連項目:

親トピック: マテリアライズド・ビュー・ログ

59.1.4.3 異なるスキーマへのマテリアライズド・ビュー・ログのインポートに関する制限事項

マテリアライズド・ビュー・ログは、DDL文で明示的に指定されたスキーマ名でエクスポートされます。そのため、マテリアライズド・ビュー・ログは、エクスポート元のスキーマとは異なるスキーマにはインポートできません。

指定したスキーマのマテリアライズド・ビュー・ログを含むエクスポート・ダンプ・ファイルをインポートするために、REMAP_SCHEMAインポート・パラメータを指定するデータ・ポンプ・インポート・ユーティリティを使用してインポートを試行すると、インポート・ログ・ファイルにエラーが書き込まれ、項目はインポートされません。

59.2 マテリアライズド・ビュー・データベースのメカニズム

マテリアライズド・ビューを作成すると、そのマテリアライズド・ビューをサポートするための追加のメカニズムがマテリアライズド・ビュー・データベースで作成されます。具体的には、1つ以上の索引が作成されます。

注意:

マテリアライズド・ビュー名のサイズの上限は30バイトです。31バイト以上の名前を付けてマテリアライズド・ビューを作成しようとすると、Oracleデータベースがエラーを返します。

  • マテリアライズド・ビューの索引
    主キーおよびROWIDのマテリアライズド・ビューのそれぞれに対して、リモート・マテリアライズド・ビュー・データベースに1つ以上の索引が作成されます。

親トピック: 読取り専用マテリアライズド・ビューのアーキテクチャ

59.2.1 マテリアライズド・ビューの索引

主キーおよびROWIDのマテリアライズド・ビューのそれぞれに対して、リモート・マテリアライズド・ビュー・データベースに1つ以上の索引が作成されます。

主キーのマテリアライズド・ビューの場合、索引は、ターゲット・マスター表の主キーに対応し、名前に_PKが含まれます。マテリアライズド・ビュー・データベースに同じ名前の索引がすでに存在する場合は、番号が追加されます。ROWIDマテリアライズド・ビューの場合、索引はROWID列に対応し、名前にI_SNAP$_が含まれます。副問合せを含むマテリアライズド・ビューの高速リフレッシュをサポートするために、リモート・マテリアライズド・ビュー・データベースに追加の索引が作成されることもあります。

親トピック: マテリアライズド・ビュー・データベースのメカニズム

59.3 編成メカニズム

いくつかのメカニズムは、マテリアライズド・ビュー・データベースでマテリアライズド・ビューを編成します。これらのメカニズムは、マテリアライズド・ビュー・データベースとそのマスター・データベース間の編成上の一貫性を維持します。

  • リフレッシュ・グループ
    複数のマテリアライズド・ビュー間の参照整合性およびトランザクション(読取り)一貫性を保つために、Oracle Databaseでは、個々のマテリアライズド・ビューをリフレッシュ・グループの一部としてリフレッシュできます。
  • リフレッシュ・グループのサイズ
    リフレッシュ・グループのサイズを決定するときは、サイズの違いによるメリットとデメリットの両方を考慮する必要があります。

親トピック: 読取り専用マテリアライズド・ビューのアーキテクチャ

59.3.1 リフレッシュ・グループ

複数のマテリアライズド・ビュー間の参照整合性およびトランザクション(読取り)一貫性を保つために、Oracle Databaseでは、個々のマテリアライズド・ビューをリフレッシュ・グループの一部としてリフレッシュできます。

リフレッシュ・グループ内のすべてのマテリアライズド・ビューのリフレッシュが終了すると、グループ内のすべてのマテリアライズド・ビューのデータはトランザクションの一貫性を保つ特定の時点のデータに対応します。

親トピック: 編成メカニズム

59.3.2 リフレッシュ・グループのサイズ

リフレッシュ・グループのサイズを決定するときは、サイズの違いによるメリットとデメリットの両方を考慮する必要があります。

Oracleデータベースは、大規模なリフレッシュ・グループのために最適化されています。したがって、大規模リフレッシュ・グループと小規模リフレッシュ・グループを比較した場合、グループ内のマテリアライズド・ビューが類似していると想定すると、大規模リフレッシュ・グループの方が同じ数のマテリアライズド・ビューを高速にリフレッシュできます。たとえば、マテリアライズド・ビューを20ずつ含む5つのリフレッシュ・グループよりも、100のマテリアライズド・ビューを含む1つのリフレッシュ・グループの方が高速にリフレッシュできます。また、大規模なリフレッシュ・グループでは、1回のPL/SQLサブプログラムの呼出しにより、多数のマテリアライズド・ビューをリフレッシュできます。

リフレッシュの実行時は、ネットワーク接続を維持する必要があります。リフレッシュ実行時にネットワーク接続が切断または妨害されると、データベースの整合性を保つためにすべての変更がロールバックされます。したがって、ネットワーク接続を維持することが困難な場合は、リフレッシュ・グループの規模を小さくします。

NULLリフレッシュも最適化されます。つまり、特定のマテリアライズド・ビューの最後のリフレッシュ以降にマスター表が変更されなかった場合、リフレッシュ時にマテリアライズド・ビューのための追加の時間はほとんどかかりません。

親トピック: 編成メカニズム

59.4 リフレッシュ処理

マテリアライズド・ビューとマスター表との一貫性を確保するには、マテリアライズド・ビューを定期的にリフレッシュする必要があります。

  • リフレッシュ処理について
    マテリアライズド・ビューのリフレッシュは、最新のマスター表の状態をマテリアライズド・ビューに反映させる効果的なバッチ操作です。
  • リフレッシュ・タイプ
    Oracleデータベースでは、高速リフレッシュ、完全リフレッシュまたは強制リフレッシュのいずれかを使用して、マテリアライズド・ビューをリフレッシュできます。
  • リフレッシュの開始
    リフレッシュ・グループを作成するときに、スケジュールした間隔でグループのマテリアライズド・ビューが自動的にリフレッシュされるようにグループを構成できます。逆に、リフレッシュ・グループを手動または必要に応じてリフレッシュするように、スケジュール情報を省略することもできます。ネットワークに常時接続されていないシステムでリフレッシュを実行する場合は、手動リフレッシュが理想的なソリューションです。
  • 制約およびリフレッシュ
    マテリアライズド・ビューのリフレッシュ中の整合性制約違反を回避するために、各マテリアライズド・ビューの主キー以外の整合性制約を遅延可能にします。

親トピック: 読取り専用マテリアライズド・ビューのアーキテクチャ

59.4.1 リフレッシュ処理について

マテリアライズド・ビューのリフレッシュは、最新のマスター表の状態をマテリアライズド・ビューに反映させる効果的なバッチ操作です。

マテリアライズド・ビューのデータは、現在のマスター表のデータといつも一致しているとはかぎりません。マテリアライズド・ビューは、ある一時点(作成時またはリフレッシュ時)に存在していたデータとして、トランザクション(読取り)一貫性を保ってマスター表を反映したものです。マテリアライズド・ビューのデータをマスター表のデータとほぼ一致させるには、マテリアライズド・ビューを定期的にリフレッシュする必要があります。

マスター表の1行は、マテリアライズド・ビューのリフレッシュとリフレッシュの間に何度も更新される場合がありますが、リフレッシュでは、その行はマテリアライズド・ビュー内で現行のデータを使用して1回のみ更新されます。たとえば、マテリアライズド・ビューの前回のリフレッシュ以降に、マスター表の1行が10回更新されても、次回のリフレッシュではマテリアライズド・ビュー内の対応する行は1度のみ更新されます。

より新しいマスター・データを反映するために、各マテリアライズド・ビューのリフレッシュ間隔およびリフレッシュ方法を決定します。たとえば、アプリケーションで頻繁に更新されるマスター表に基づいたマテリアライズド・ビューは、頻繁にリフレッシュする必要があります。これに対して、比較的静的なマスター表に基づいたマテリアライズド・ビューは、あまり頻繁にリフレッシュする必要はありません。つまり、アプリケーションの特性および要件を分析して、マテリアライズド・ビューの適切なリフレッシュ間隔を判断します。

マテリアライズド・ビューのリフレッシュのために、Oracleデータベースではいくつかのリフレッシュ・タイプとリフレッシュ開始方法がサポートされています。

親トピック: リフレッシュ処理

59.4.2 リフレッシュ・タイプ

Oracleデータベースでは、高速リフレッシュ、完全リフレッシュまたは強制リフレッシュのいずれかを使用して、マテリアライズド・ビューをリフレッシュできます。

  • 完全リフレッシュ
    マテリアライズド・ビューの完全リフレッシュを実行するには、マテリアライズド・ビューを管理するサーバーがマテリアライズド・ビューの定義問合せを実行します(これは基本的に、マテリアライズド・ビューを再作成する処理です)。
  • 高速リフレッシュ
    高速リフレッシュを実行するときは、まずマテリアライズド・ビューを管理するマスター表が、マテリアライズド・ビューの最後のリフレッシュ以降にマスター表で発生した変更を識別し、次にそれらの変更をマテリアライズド・ビューに適用します。
  • 強制リフレッシュ
    マテリアライズド・ビューの強制リフレッシュを実行するために、マテリアライズド・ビューを管理するサーバーは高速リフレッシュの実行を試みます。高速リフレッシュが実行できない場合は、完全リフレッシュが実行されます。

親トピック: リフレッシュ処理

59.4.2.1 完全リフレッシュ

マテリアライズド・ビューの完全リフレッシュを実行するには、マテリアライズド・ビューを管理するサーバーがマテリアライズド・ビューの定義問合せを実行します(これは基本的に、マテリアライズド・ビューを再作成する処理です)。

マテリアライズド・ビューをリフレッシュするために、問合せの結果セットが現在のマテリアライズド・ビュー・データを置き換えます。Oracleデータベースでは、任意のマテリアライズド・ビューの完全リフレッシュを実行できます。定義問合せを満たすデータの量によっては、完全リフレッシュの実行に高速リフレッシュの場合よりもかなり長い時間がかかる場合があります。

注意:

マテリアライズド・ビューで完全リフレッシュを実行する場合は、効率を最大化するために、PCTFREEを0に、PCTUSEDを99に設定します。

59.4.2.2 高速リフレッシュ

高速リフレッシュを実行するときは、まずマテリアライズド・ビューを管理するマスター表が、マテリアライズド・ビューの最後のリフレッシュ以降にマスター表で発生した変更を識別し、次にそれらの変更をマテリアライズド・ビューに適用します。

高速リフレッシュは、関係する各サーバーおよびネットワークでレプリケートするデータが少なくて済むため、マスター表」に加えられた変更が少ないときは完全リフレッシュよりも効率的です。マテリアライズド・ビューの高速リフレッシュは、マスター表にマテリアライズド・ビュー・ログがある場合にのみ可能です。また、高速リフレッシュを完全リフレッシュより高速にするには、CREATE MATERIALIZED VIEW文の各結合列に対して索引が必要です。

SQL*Loaderを使用してマスター表でダイレクト・パス・ロードを行った後、高速リフレッシュではダイレクト・パス・ロード中に発生した変更は適用されません。また、高速リフレッシュでは、マスター表へのその他のバルク・ロード操作によって生じた変更も適用されません。このような操作の例としては、APPENDヒントを指定したINSERT文と、INSERT ... SELECT * FROM文などがあります。

パーティション化されたマスター表に基づくマテリアライズド・ビューがある場合、パーティション・チェンジ・トラッキング(PCT)を使用して、特定のパーティションに対応しているマテリアライズド・ビューの行を識別できます。また、PCTは、マテリアライズド・ビューのマスター表のパーティション・メンテナンス操作後、高速リフレッシュをサポートするために使用されます。マテリアライズド・ビューでのPCTに基づくリフレッシュは、様々な条件が満たされた場合のみ可能になります。

関連項目:

PCTおよびPCTに基づいたリフレッシュの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

親トピック: リフレッシュ・タイプ

59.4.2.3 強制リフレッシュ

マテリアライズド・ビューの強制リフレッシュを実行するために、マテリアライズド・ビューを管理するサーバーは高速リフレッシュの実行を試みます。高速リフレッシュが実行できない場合は、完全リフレッシュが実行されます。

高速リフレッシュが実行できない場合にマテリアライズド・ビューのリフレッシュを実行するには、強制リフレッシュの設定を使用します。

59.4.3 リフレッシュの開始

リフレッシュ・グループを作成するときに、スケジュールした間隔でグループのマテリアライズド・ビューが自動的にリフレッシュされるようにグループを構成できます。逆に、リフレッシュ・グループを手動または必要に応じてリフレッシュするように、スケジュール情報を省略することもできます。ネットワークに常時接続されていないシステムでリフレッシュを実行する場合は、手動リフレッシュが理想的なソリューションです。

  • スケジュールしたリフレッシュ
    自動リフレッシュのためのリフレッシュ・グループを作成するには、作成プロセスで、スケジュールしたリフレッシュ間隔をグループに指定する必要があります。
  • 必要に応じたリフレッシュ
    必要に応じたリフレッシュは、明示的なプロシージャ・コールによりマテリアライズド・ビューをリフレッシュすることを意味します。

親トピック: リフレッシュ処理

59.4.3.1 スケジュールしたリフレッシュ

自動リフレッシュのためのリフレッシュ・グループを作成するには、作成プロセスで、スケジュールしたリフレッシュ間隔をグループに指定する必要があります。

グループのリフレッシュ間隔を設定するときは、次の特性を考慮してください。

  • リフレッシュ間隔を指定する日付または日付式の値は、将来の特定の時点である必要があります。

  • リフレッシュ間隔は、リフレッシュの実行に必要な時間よりも長くする必要があります。

  • 相対日付式の値は、最新のリフレッシュ日付から計算される特定の時点である必要があります。ネットワークまたはシステムの障害により、グループのリフレッシュがスケジュールどおりに実行されない場合、相対日付式の結果は状況に応じて変更されることがあります。

  • 明示的日付式の値は、最新のリフレッシュ日付に関係なく特定の時点である必要があります。

  • 古いデータに対する環境の許容度を考慮してください。許容度が低い場合はリフレッシュ間隔を小さくし、許容度が高い場合はリフレッシュ間隔を大きくします。

リフレッシュ間隔の指定に使用できる単純な日付式の例を、次に示します。

  • 1時間間隔の指定:

    SYSDATE + 1/24

  • 7日間隔の指定:

    SYSDATE + 7

関連項目:

日付算術の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

親トピック: リフレッシュの開始

59.4.3.2 必要に応じたリフレッシュ

必要に応じたリフレッシュは、明示的なプロシージャ・コールによりマテリアライズド・ビューをリフレッシュすることを意味します。

環境や状況によっては、スケジュールしたマテリアライズド・ビュー・リフレッシュの実行が適切でない場合もあります。たとえば、マスター表にバルク・データをロードした直後は、依存マテリアライズド・ビューにマスター表のデータは反映されていません。

マテリアライズド・ビューが非接続環境のラップトップの営業支援システムと統合されている場合は、マテリアライズド・ビューを必要に応じてリフレッシュすることもできます。営業支援ソフトウェアを設計する開発者がアプリケーション・コントロール(ボタンなど)を作成し、営業担当員は、1日の受注をサーバーに転送するときに、ネットワーク接続を確立した後、アプリケーション・コントロールを使用してマテリアライズド・ビューをリフレッシュできます。

hr_refgリフレッシュ・グループを必要に応じてリフレッシュする例を次に示します。 

EXECUTE DBMS_REFRESH.REFRESH('hr_refg');

注意:

レプリケーション環境で使用するマテリアライズド・ビューは、DBMS_MVIEW.REFRESH_ALL_MVIEWSまたはDBMS_MVIEW.REFRESH_DEPENDENTプロシージャを使用してリフレッシュしないでください。レプリケーション環境のマテリアライズド・ビューは、DBMS_REFRESH.REFRESHまたはDBMS_MVIEW.REFRESHプロシージャを使用してリフレッシュします。

親トピック: リフレッシュの開始

59.4.4 制約およびリフレッシュ

マテリアライズド・ビューのリフレッシュ中の整合性制約違反を回避するために、各マテリアライズド・ビューの主キー以外の整合性制約を遅延可能にします。

これには、NOT NULL制約を持つLOB列が必要です。また、外部キー制約によって関連付けられているすべてのマテリアライズド・ビューは、まとめてリフレッシュするか、同じリフレッシュ・グループでリフレッシュする必要があります。

注意:

マテリアライズド・ビューの主キー制約は、遅延可能である場合とない場合があります。

関連項目:

制約を遅延可能にする方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

親トピック: リフレッシュ処理