3.4.1.10 「マテリアライズド・ビュー」ペイン

マテリアライズド・ビューのオプションを指定します。

問合せ: ビュー定義の問合せ部分のSQLコードが含まれます。問合せを入力するか、コピーして貼り付けます。

一般

  • 事前作成表: 「はい」の場合、既存の表が事前に初期化されたマテリアライズド・ビューとして登録されます。このオプションは、データ・ウェアハウス環境での大規模なマテリアライズド・ビューの登録に特に役立ちます。表は、作成されるマテリアライズド・ビューと同じ名前を持ち、同じスキーマ内に存在する必要があります。また、副問合せのマテリアライズ化を反映している必要があります。

  • 精度の低下: 「はい」を指定すると、表またはマテリアライズド・ビューの列の精度が副問合せで戻される精度と正確に一致しない場合に精度の低下が許可されます。「いいえ」の場合、表またはマテリアライズド・ビューの列の精度は、副問合せによって戻される精度と正確に一致する必要があります。そうしないと、作成操作が失敗します。

  • 更新対象: 副問合せ、主キー、オブジェクトまたはROWIDマテリアライズド・ビューを更新できるようにするには、「はい」を選択します。アドバンスト・レプリケーションと組み合せて使用した場合、更新はマスターにも影響します。

  • リアルタイムMV: 「はい」を選択すると、リアルタイムのマテリアライズド・ビューまたは通常のビューが作成されます。リアルタイムのマテリアライズド・ビューでは、データ変更によりマテリアライズド・ビューがその実表と同期していない場合も、ユーザーの問合せに対して最新のデータを提供します。マテリアライズド・ビューを変更するかわりに、オプティマイザはマテリアライズド・ビューの既存の行とログ・ファイル(マテリアライズド・ビュー・ログまたはダイレクト・ローダー・ログ)に記録された変更を結合する問合せを記述します。これは、問合せ時計算と呼ばれます。

  • 問合せリライト:: 「有効化」を選択した場合、マテリアライズド・ビューを問合せリライトに使用できます。クエリー・リライトは、マスター表に関して記述されたユーザー要求を、1つ以上のマテリアライズド・ビューを含む意味的に同等の要求に変換します。

  • ビルド: マテリアライズド・ビューへの移入のタイミングを指定します。「即時」を選択すると、すぐにマテリアライズド・ビューに移入されます。「遅延」を選択すると、次回のリフレッシュ操作でマテリアライズド・ビューに移入されます。「遅延」を指定した場合、最初の(遅延)リフレッシュは常に完全リフレッシュである必要があります。リフレッシュが行われるまで、マテリアライズド・ビューの値は古く使用不可の状態であるため、クエリー・リライトには使用できません。

  • 索引の使用: 「はい」の場合、デフォルト索引が作成されて使用され、マテリアライズド・ビューの増分(高速)リフレッシュの速度が向上します。いいえの場合、このデフォルト索引は作成されません。(たとえば、今は索引を作成せず、後でこのような索引を明示的に作成することもできます。)

  • 索引表領域: マテリアライズド・ビューを作成する表領域を指定します。表領域を選択しない場合、マテリアライズド・ビューは、そのビューが含まれているスキーマのデフォルトの表領域に作成されます。

  • キャッシュ: 「はい」の場合、全表スキャンの実行時、この表に取得されたブロックは、バッファ・キャッシュで最低使用頻度(LRU)リストの最高使用頻度側に配置されます。この設定は小さい参照表に役立ちます。「いいえ」の場合、ブロックは、LRUリストの最低使用頻度側に配置されます。

リフレッシュ句

  • リフレッシュ: リフレッシュ操作を有効にするには、「はい」を選択します。

  • リフレッシュ・タイプ: 実行するリフレッシュ操作の方法。次のいずれかになります。

    • 完全リフレッシュ: 高速リフレッシュが可能な場合でも、マテリアライズド・ビューの定義問合せを実行します。

    • 高速リフレッシュ: マスター表に対して行われた変更に応じてリフレッシュを実行する、増分リフレッシュ方法を使用します。従来型DML変更の場合、変更は、マスター表に関連付けられたマテリアライズド・ビュー・ログに格納されます。ダイレクト・パス・インサート操作の変更は、ダイレクト・ローダー・ログに格納されます。

    • 強制リフレッシュ: 可能な場合は高速リフレッシュを実行し、そうでない場合は完全リフレッシュを実行します。

  • アクション: 実行するリフレッシュ操作のタイプ。次のいずれかになります。

    • 要求時: いずれかのDBMS_MVIEWリフレッシュ・プロシージャのコール時にリフレッシュを実行します。

    • コミット時: マテリアライズド・ビューのマスター表で行われたトランザクションがデータベースでコミットされるたびに、高速リフレッシュを実行します。データベースはコミット・プロセスの一部としてリフレッシュ操作を実行するため、コミットの完了にかかる時間が長くなる可能性があります。

    • 指定: 「開始」および「次」フィールドに指定した内容に従って、リフレッシュ操作を実行します。

  • 開始日: 最初の自動リフレッシュ操作の開始日時。将来の日時である必要があります。

  • 次回日付: 次回の自動リフレッシュ操作の時間。「開始」および「次」に指定した時間の間隔が、それ以降の自動リフレッシュ操作の間隔になります。値を指定しない場合、リフレッシュ操作は「開始」に指定した時間に1回のみ行われます。

  • 次で: マテリアライズド・ビューのタイプを決定するリフレッシュ・タイプ。次のいずれかになります。

    • 主キー: 主キー・マテリアライズド・ビューを作成します。この場合、マテリアライズド・ビューでの高速リフレッシュの実行性に影響することなく、マテリアライズド・ビューのマスター表を再編成できます。

    • 行ID: ROWIDマテリアライズド・ビューを作成します。このタイプのビューは、マスター表のすべての主キー列がマテリアライズド・ビューに含まれていない場合に役立ちます。

  • デフォルトの記憶域: 「はい」の場合、DEFAULTでは使用するロールバック・セグメントがOracle Databaseで自動的に選択されることを指定します。DEFAULTを指定する場合、rollback_segmentは指定できません。DEFAULTは、マテリアライズド・ビューを(作成ではなく)変更する場合に有効です。

  • 記憶域のタイプ: MASTERを使用すると、個々のマテリアライズド・ビュー用のリモート・マスター・サイトで使用されるリモート・ロールバック・セグメントを指定します。LOCALを使用すると、マテリアライズド・ビューが含まれているローカル・リフレッシュ・グループで使用されるリモート・ロールバック・セグメントを指定できます。これはデフォルトです。

  • ロールバック・セグメント: ロールバック・セグメントの名前を入力します。

  • 制約の使用: このオプションを選択すると、リフレッシュ操作中により多くのリライト・オプションを使用できるため、リフレッシュをより効率的に実行できるようになります。このオプションの動作は、「強制」と「信頼」のどちらを選択するかによって異なります。

    • 強制: リフレッシュ操作中、必須の制約のみを使用します。

    • 信頼: データベース管理者は信頼できると宣言しているが、データベースでは検証されていないディメンションおよび制約の情報を使用できるようになります。ディメンションおよび制約の情報が有効であると、パフォーマンスが向上する場合があります。ただし、この情報が無効であると、正常な状態が戻されても、リフレッシュ・プロシージャによってマテリアライズド・ビューが破損する場合があります。