| Oracle® Databaseアドバンスト・レプリケーション 12c リリース1 (12.1) E52978-02 |
|
 前 |
 次 |
この章では、マテリアライズド・ビューの概念およびアーキテクチャについて説明します。
この章には、次の項が含まれます。
Oracleでは、マテリアライズド・ビュー(以前はスナップショットと呼ばれていたもの)を使用して、レプリケーション環境のマスター・サイト以外のサイトにデータをレプリケートし、コストのかかる問合せをデータ・ウェアハウス環境にキャッシュします。この章およびこのマニュアル全体では、レプリケーション環境で使用するマテリアライズド・ビューについて説明します。
この項には、次の項目が含まれます。
|
関連項目: データ・ウェアハウスでのマテリアライズド・ビューの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。 |
マテリアライズド・ビューとは、ある一時点におけるターゲット・マスターのレプリカのことです。マスターは、マスター・サイトのマスター表またはマテリアライズド・ビュー・サイトのマスター・マテリアライズド・ビューのいずれかです。マルチマスター・レプリケーションでは、表は他のマスター・サイトによって連続的に更新されますが、マテリアライズド・ビュー・レプリケーションでは、シングル・マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトからバッチ更新(リフレッシュとも呼ばれます)が実行されるたびに、1つ以上のマスターから更新されます(図3-1を参照してください)。図3-1の矢印は、データベース・リンクを表します。
マテリアライズド・ビューが高速リフレッシュされると、Oracleでは最後のリフレッシュ以降にマスター表またはマスター・マテリアライズド・ビューに加えられたすべての変更をチェックして、マテリアライズド・ビューに適用される変更があるかどうかを調べる必要があります。したがって、最後のリフレッシュ以降にマスターに対して変更が加えられている場合は、マテリアライズド・ビューのリフレッシュでは変更を適用する時間がかかります。ただし、最後のリフレッシュ以降にマスターに対して何も変更が加えられていない場合は、マテリアライズド・ビューのリフレッシュはすばやく行われます。
マテリアライズド・ビューを使用する目的には、次のようなものがあります。
ネットワーク負荷の軽減が目的の1つである場合は、マテリアライズド・ビューを使用して会社のデータベースを地域サイトに分散できます。会社全体で1つのデータベース・サーバーにアクセスするのではなく、ユーザーの負荷を複数のデータベース・サーバーに分散します。多重化マテリアライズド・ビューを使用すると、他のマテリアライズド・ビューに基づいたマテリアライズド・ビューを作成でき、これにより、クライアントはマスター・サイトのかわりにマテリアライズド・ビューにアクセスできるため、ユーザーの負荷をさらに分散させることができます。レプリケートされるデータ量を減らすために、マテリアライズド・ビューをマスター表またはマスター・マテリアライズド・ビューのサブセットにできます。
マルチマスター・レプリケーションでも会社のデータベースが複数のサイトに分散されますが、マルチマスター・レプリケーションはトランザクションごとに処理を行うため、マテリアライズド・ビューを使用したレプリケーションよりもネットワーク要件が多くなります。また、マルチマスター・レプリケーションではリアルタイムまたはほぼリアルタイムにレプリケーションが提供されるため、ネットワークの通信量が増大する結果となり、専用のネットワーク・リンクが必要となることもあります。
マテリアライズド・ビューは、1つのマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトから効率的なバッチ処理を使用して更新されます。マテリアライズド・ビュー・レプリケーションでは一定時間おきにデータが更新されるので、マルチマスター・レプリケーションの場合よりもネットワーク要件が少なく、依存性も高くありません。マルチマスター・レプリケーションではネットワーク上で常に通信が行われますが、マテリアライズド・ビュー・レプリケーションでは定期的なリフレッシュのみが必要になります。
マテリアライズド・ビューを使用したデータのレプリケーションでは、専用のネットワーク接続が不要なうえ、ターゲット・データへのローカル・アクセスを実行できるためデータの可用性が高くなります。これらのメリットに加え、大規模デプロイメントおよびデータのサブセット化(いずれもネットワーク負荷を軽減します)というメリットにより、レプリケート・データベースのパフォーマンスと信頼性が大幅に向上します。
デプロイメント・テンプレートを使用すると、マテリアライズド・ビュー環境をローカルで事前作成できます。また、デプロイメント・テンプレートを使用すれば、マテリアライズド・ビュー環境を迅速かつ簡単に配置でき、営業支援システムやその他の大規模デプロイメント環境をサポートできます。パラメータを使用すると、デプロイメント・テンプレートを変更せずに個々のユーザー用のカスタム・データ・セットを作成できます。このテクノロジによって、データベースのインフラストラクチャを数百人または数千人のユーザーに提供できます。
マルチマスター・レプリケーションでは、表全体をレプリケートする必要がありますが、マテリアライズド・ビューでは、列レベルまたは行レベル(あるいはその両方)でのサブセット化に基づいたデータをレプリケートできます。データのサブセット化により、特定のサイトのみに関係する情報をレプリケートできます。たとえば、各地の営業所ではその地域に必要なデータのみをレプリケートし、不要なネットワークの通信量を減らすことができます。
マテリアライズド・ビューは専用のネットワーク接続を必要としません。マテリアライズド・ビューでは、ジョブをスケジュールしてリフレッシュ処理を自動化するというオプションもありますが、必要に応じて手動でリフレッシュでき、これは、ラップトップ上で実行される販売アプリケーションなどには理想的です。たとえば、開発者は、必要なときにリフレッシュを実行するレプリケーション・マネージメントAPIを販売アプリケーションに統合できます。1日の受注業務を終えた営業担当員は、ネットワークにダイアルアップ接続し、統合されたメカニズムを使用してデータベースをリフレッシュすることによって、本社に受注を転送できます。
マテリアライズド・ビューは読取り専用、更新可能または書込み可能のいずれかです。読取り専用マテリアライズド・ビューに対してはデータ操作言語(DML)文を実行できませんが、更新可能および書込み可能のマテリアライズド・ビューに対しては実行できます。
|
注意: デフォルトの主キーオプションを使用して定義された読取り専用、更新可能および書込み可能のマテリアライズド・ビューでは、マテリアライズド・ビューの定義問合せでマスター内の主キー列をすべて参照する必要があります。 |
マテリアライズド・ビューの作成中に、FOR UPDATE句を指定しないか、Oracle Enterprise Manager Cloud Controlのアドバンスト・レプリケーション・インタフェースでこれと同等のオプションを使用禁止にすると、マテリアライズド・ビューを読取り専用にできます。読取り専用マテリアライズド・ビューでは更新可能マテリアライズド・ビューと同じメカニズムを多数使用しますが、読取り専用の場合は、マテリアライズド・ビュー・グループに属する必要がありません。
また、読取り専用マテリアライズド・ビューを使用すると、マテリアライズド・ビューが原因でマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでデータ競合が発生することを回避できますが、リモート・マテリアライズド・ビュー・サイトでの更新はできなくなります。読取り専用マテリアライズド・ビューの例を次に示します。
CREATE MATERIALIZED VIEW hr.employees AS SELECT * FROM hr.employees@orc1.example.com;
マテリアライズド・ビューの作成中に、FOR UPDATE句を指定するか、Oracle Enterprise Manager Cloud Controlのアドバンスト・レプリケーション・インタフェースでこれと同等のオプションを使用可能にすると、マテリアライズド・ビューを更新可能にできます。更新可能マテリアライズド・ビューへの変更をリフレッシュ中にマスターにプッシュするには、更新可能マテリアライズド・ビューがマテリアライズド・ビュー・グループに属する必要があります。
更新可能マテリアライズド・ビューを使用すると、ユーザーがマテリアライズド・ビュー・サイトでデータを変更できるため、マスター・サイトの負荷が軽減されます。更新可能マテリアライズド・ビューの例を次に示します。
CREATE MATERIALIZED VIEW hr.departments FOR UPDATE AS SELECT * FROM hr.departments@orc1.example.com;
次の文ではマテリアライズド・ビュー・グループが作成されます。
BEGIN DBMS_REPCAT.CREATE_MVIEW_REPGROUP ( gname => 'hr_repg', master => 'orc1.example.com', propagation_mode => 'ASYNCHRONOUS'); END; /
次の文では、hr.departmentsマテリアライズド・ビューがマテリアライズド・ビュー・グループに追加され、このマテリアライズド・ビューが更新可能になります。
BEGIN DBMS_REPCAT.CREATE_MVIEW_REPOBJECT ( gname => 'hr_repg', sname => 'hr', oname => 'departments', type => 'SNAPSHOT', min_communication => TRUE); END;
/
Oracle Enterprise Manager Cloud Controlのアドバンスト・レプリケーション・インタフェースを使用して、マテリアライズド・ビュー・グループを作成し、これにマテリアライズド・ビューを追加することもできます。
更新可能マテリアライズド・ビューが存在するシングル・マスター・サイト環境では、次のような場合に、マスター・サイトの管理操作を実行するときの静止が不要になります。
マスター・グループへの管理操作を実行する前に、更新可能マテリアライズド・ビューを含むデータベースで遅延トランザクションをすべて伝播する場合。
マスター・サイトに対する管理操作を完了し、更新可能マテリアライズド・ビューのレプリケーション・サポートを再生成するまで、そのマテリアライズド・ビューに対してデータ操作言語(DML)による変更を許可しない場合。
これらのアクションを実行しない場合は、マスター・グループに管理操作を実行する前にマスター・グループを静止します。
書込み可能マテリアライズド・ビューとは、FOR UPDATE句を使用して作成されるが、マテリアライズド・ビュー・グループには属さないマテリアライズド・ビューです。ユーザーは書込み可能マテリアライズド・ビューに対してDML操作を実行できますが、マテリアライズド・ビューをリフレッシュしたときに、この変更はマスターにプッシュされず、マテリアライズド・ビュー自体からも変更が失われます。通常、高速リフレッシュが可能な読取り専用マテリアライズド・ビューが使用できる場合は、書込み可能マテリアライズド・ビューも使用できます。
|
注意: 書込み可能マテリアライズド・ビューはほとんど使用されないため、マテリアライズド・ビューに関するドキュメントのほとんどは、読取り専用および更新可能マテリアライズド・ビューのみを説明しています。 |
Oracleでは、様々なレプリケーション環境(および非レプリケーション環境)で使用できるいくつかのタイプのマテリアライズド・ビューを用意しています。次の項では、それぞれのタイプのマテリアライズド・ビューと、各マテリアライズド・ビューに最適な環境について説明します。
次の項では、様々なタイプのマテリアライズド・ビューの作成例を示しています。
どのタイプのマテリアライズド・ビューを作成する場合でも、マテリアライズド・ビューの問合せで表所有者のスキーマ名を指定します。たとえば、次のCREATE MATERIALIZED VIEW文について考えます。
CREATE MATERIALIZED VIEW hr.employees AS SELECT * FROM hr.employees@orc1.example.com;
この文では、問合せにスキーマhrが指定されています。
|
注意: ON COMMITオプションが指定されたマテリアライズド・ビューのマスター表に対する変更を含む分散トランザクションを実行することはできません。ON COMMITオプションが指定されたマテリアライズド・ビューとは、CREATE MATERIALIZED VIEW文でON COMMIT REFRESH句を使用して作成するマテリアライズド・ビューです。ON DEMANDオプションが指定されたマテリアライズド・ビューのマスター表に対する変更を含む分散トランザクションは実行できます。 |
主キー・マテリアライズド・ビューがマテリアライズド・ビューのデフォルト・タイプです。マテリアライズド・ビューがマテリアライズド・ビュー・グループの一部として作成され、マテリアライズド・ビューの定義でFOR UPDATEを指定した場合、マテリアライズド・ビューは更新可能です。更新可能マテリアライズド・ビューは、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでレプリケーション・グループと同じ名前のマテリアライズド・ビュー・グループに属する必要があります。さらに、更新可能マテリアライズド・ビューは、マスター・レプリケーション・グループと別のデータベースに配置する必要があります。
変更は、(ROWIDではなく)行の主キー値によって識別される、行レベルの変更に従って伝播されます。更新可能な主キー・マテリアライズド・ビューを作成するSQL文の例を次に示します。
CREATE MATERIALIZED VIEW oe.customers FOR UPDATE AS SELECT * FROM oe.customers@orc1.example.com;
リモート・マテリアライズド・ビュー・サイトで行のサブセットを作成できるように、主キー・マテリアライズド・ビューには副問合せを含められます。副問合せは主問合せに埋め込まれた問合せで、CREATE MATERIALIZED VIEW文に複数のSELECT文が使用されます。この副問合せには、基本的なWHERE句のように単純なものと、マルチレベルのWHERE EXISTS句のように複雑なものとがあります。参照される各マスターにマテリアライズド・ビュー・ログがある場合は、選択されたクラスの副問合せを含む主キー・マテリアライズド・ビュー・サイトに高速リフレッシュを実行できます。高速リフレッシュでは、マテリアライズド・ビュー・ログを使用して、最後のリフレッシュ以降に変更が加えられた行のみを更新します。
次のマテリアライズド・ビューは、副問合せを含むWHERE句を使用して作成されています。
CREATE MATERIALIZED VIEW oe.orders REFRESH FAST AS
SELECT * FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT * FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id AND c.credit_limit > 10000);
このタイプのマテリアライズド・ビューは、副問合せマテリアライズド・ビューと呼ばれます。
|
注意: このoe.ordersマテリアライズド・ビューを作成するには、マスターのマテリアライズド・ビュー・ログにcredit_limitをロギングする必要があります。詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。 |
|
関連項目:
|
マテリアライズド・ビューがオブジェクト表に基づいてOF type句を使用して作成されている場合、このマテリアライズド・ビューはオブジェクト・マテリアライズド・ビューと呼ばれます。オブジェクト・マテリアライズド・ビューは、オブジェクト表と同じ構造です。つまり、オブジェクト・マテリアライズド・ビューは行オブジェクトから構成され、各行オブジェクトはオブジェクト識別子(OID)列により識別されます。
Oracleでは、デフォルトの主キー・マテリアライズド・ビューの他に、ROWIDマテリアライズド・ビューもサポートしています。ROWIDマテリアライズド・ビューは、マスター表の行の物理的な行識別子(ROWID)に基づいて作成されます。ROWIDマテリアライズド・ビューを使用するのは、主キーを持たないマスター表に基づくマテリアライズド・ビュー、またはマスター表の一部の主キー列を含むマテリアライズド・ビューの場合です。
ROWIDマテリアライズド・ビューを作成するCREATE MATERIALIZED VIEW文の例を次に示します。
CREATE MATERIALIZED VIEW oe.orders REFRESH WITH ROWID AS SELECT * FROM oe.orders@orc1.example.com;
|
関連項目:
|
高速リフレッシュを実行するには、マテリアライズド・ビューの定義問合せで一定の制限事項を守る必要があります。マテリアライズド・ビューの定義問合せが汎用的なものであり、制限事項を守ることができない場合は、そのマテリアライズド・ビューは複合マテリアライズド・ビューであり、高速リフレッシュを実行できません。
具体的には、マテリアライズド・ビューの定義問合せに次のものが含まれる場合、そのマテリアライズド・ビューは複合マテリアライズド・ビューとみなされます。
CONNECT BY句
たとえば、次の文では複合マテリアライズド・ビューが作成されます。
CREATE MATERIALIZED VIEW hr.emp_hierarchy AS
SELECT LPAD(' ', 4*(LEVEL-1))||email USERNAME
FROM hr.employees@orc1.example.com START WITH manager_id IS NULL
CONNECT BY PRIOR employee_id = manager_id;
INTERSECT、MINUSまたはUNION ALL集合演算
たとえば、次の文にはUNION ALL集合演算が含まれているため、複合マテリアライズド・ビューが作成されます。
CREATE MATERIALIZED VIEW hr.mview_employees AS SELECT employees.employee_id, employees.email FROM hr.employees@orc1.example.com UNION ALL SELECT new_employees.employee_id, new_employees.email FROM hr.new_employees@orc1.example.com;
DISTINCTまたはUNIQUEキーワード
たとえば、次の文では複合マテリアライズド・ビューが作成されます。
CREATE MATERIALIZED VIEW hr.employee_depts AS SELECT DISTINCT department_id FROM hr.employees@orc1.example.com ORDER BY department_id;
集計関数(場合による)。集計関数を定義問合せに指定して、単純マテリアライズド・ビューを作成することもできます。
たとえば、次の文では複合マテリアライズド・ビューが作成されます。
CREATE MATERIALIZED VIEW hr.average_sal AS SELECT AVG(salary) "Average" FROM hr.employees@orc1.example.com;
副問合せ以外で指定される結合(場合による)。結合を定義問合せに指定して、単純マテリアライズド・ビューを作成することもできます。
たとえば、次の文では複合マテリアライズド・ビューが作成されます。
CREATE MATERIALIZED VIEW hr.emp_join_dep AS SELECT last_name FROM hr.employees@orc1.example.com e, hr.departments@orc1.example.com d WHERE e.department_id = d.department_id;
UNION演算子(場合による)。
具体的には、次の条件のいずれかが満たされた場合に、UNION演算子を指定したマテリアライズド・ビューは複合マテリアライズド・ビューになります。
UNION内の問合せが複合問合せの場合。ここまでの箇条書きの項目は、問合せによりマテリアライズド・ビューが複合マテリアライズド・ビューになる場合を示します。
最も外側のSELECTリスト列が、UNION内の問合せに一致しない場合。次の例で、最初の問合せの最も外側のSELECTリストにはorder_totalのみが含まれ、2番目の問合せの最も外側のSELECTリストにはcustomer_idが含まれています。したがって、マテリアライズド・ビューは複合マテリアライズド・ビューです。
CREATE MATERIALIZED VIEW oe.orders AS
SELECT order_total
FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT cust_first_name, cust_last_name
FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id
AND c.credit_limit > 50)
UNION
SELECT customer_id
FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT cust_first_name, cust_last_name
FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id
AND c.account_mgr_id = 30);
最も内側のSELECTリストは、マテリアライズド・ビューが複合マテリアライズド・ビューであるかどうかには関係しません。この例では、UNION内の両方の問合せで、最も内側のSELECTリストはcust_first_nameとcust_last_nameです。
「副問合せを使用するマテリアライズド・ビューでの制限事項」で説明されている要件に適合しない句。
|
注意: 複合マテリアライズド・ビューでは高速リフレッシュができず、ネットワークのパフォーマンスが低下する場合があるため、できるだけ使用しないでください(詳細は、「リフレッシュ処理」を参照してください)。 |
|
関連項目:
|
アプリケーションによっては、複合マテリアライズド・ビューの使用を考慮することが必要な場合があります。図3-2とその後に続く本文では、考慮の必要な場合について説明します。
複合マテリアライズド・ビュー: 図3-2の方法Aは、複合マテリアライズド・ビューを示しています。データベースII内のマテリアライズド・ビューでは、マテリアライズド・ビューのリフレッシュ中に結合操作が完了しているので、非常に効率的に問合せが行われます。ただし、複合マテリアライズド・ビューであるため完全リフレッシュを実行する必要があり、多くの場合、完全リフレッシュは、高速リフレッシュに比べ実行速度が遅くなります。
結合ビューを含む単純マテリアライズド・ビュー: 図3-2の方法Bは、データベースII内の2つの単純マテリアライズド・ビューと、マテリアライズド・ビューのデータベース内で結合を実行するビューを示しています。ビューに対する問合せのパフォーマンスは、方法Aの複合マテリアライズド・ビューに対する問合せのパフォーマンスに比べよくありません。ただし、単純マテリアライズド・ビューの方が、高速リフレッシュとマテリアライズド・ビュー・ログを使用してより高速にリフレッシュできます。
要約すると、使用する方法は次のようにして判断できます。
リフレッシュを実行する頻度が少なく、より高速な問合せのパフォーマンスを優先する場合は、方法A(複合マテリアライズド・ビュー)を使用します。
頻繁にリフレッシュを実行し、問合せのパフォーマンスを優先する必要がない場合は、方法B(単純マテリアライズド・ビュー)を使用します。
マテリアライズド・ビューに対しては、次の3種類のユーザーが操作を実行します。
作成者: マテリアライズド・ビューを作成するユーザー。
リフレッシャ: マテリアライズド・ビューをリフレッシュするユーザー。
所有者: マテリアライズド・ビューを所有するユーザー。マテリアライズド・ビューは、このユーザーのスキーマ内に入れられます。
1人のユーザーが特定のマテリアライズド・ビューに対してこのすべての操作を実行できます。ただし、レプリケーション環境によっては、特定のマテリアライズド・ビューに対して別々のユーザーがこの操作を実行します。これらの操作の実行に必要な権限は、1人のユーザーが操作を実行するか別々のユーザーが実行するかにより異なります。以降の項で、権限要件を詳しく説明します。
マテリアライズド・ビュー・サイトのマテリアライズド・ビューの所有者に、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトへのプライベート・データベース・リンクがある場合は、このデータベース・リンクがマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのマスターの所有者に接続します。それ以外の場合は、データベース・リンク経由の接続に関する通常の規則が適用されます。
|
注意: 以降の項では、クエリー・リライトが使用可能なマテリアライズド・ビューの作成に必要な要件については説明されていません。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
|
関連項目: 以降の項ではデータベース・リンクについて説明しています。データベース・リンクの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
マテリアライズド・ビューの作成者が所有者でもある場合、このユーザーには、マテリアライズド・ビューを作成する次の権限が必要であり、これらの権限は明示的に付与されるか、ロールを介して付与されます。
CREATE MATERIALIZED VIEWまたはCREATE ANY MATERIALIZED VIEW。
CREATE TABLEまたはCREATE ANY TABLE。
マスターおよびマスターのマテリアライズド・ビュー・ログに対するREADあるいはSELECTオブジェクト権限またはREAD ANY TABLEあるいはSELECT ANY TABLEシステム権限。マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトがリモートの場合は、マテリアライズド・ビュー・サイトのユーザーがデータベース・リンクを介して接続する先のマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのユーザーに、READまたはSELECTオブジェクト権限を付与する必要があります。
マテリアライズド・ビューの作成者が所有者でない場合は、マテリアライズド・ビューを作成する権限を作成者と所有者に付与する必要があります。作成者の権限と所有者の権限は、いずれもロールを介してではなく、明示的に付与する必要があります。
表3-1は、マテリアライズド・ビューの作成者が所有者でない場合に必要な権限を示します。
表3-1 マテリアライズド・ビューの作成に必要な権限(作成者が所有者でない場合)
| 作成者 | 所有者 |
|---|---|
|
|
マスターおよびマスターのマテリアライズド・ビュー・ログに対する |
マテリアライズド・ビューのリフレッシャが所有者でもある場合、このユーザーには、マスターおよびマスターのマテリアライズド・ビュー・ログに対するREADあるいはSELECTオブジェクト権限またはREAD ANY TABLEあるいはSELECT ANY TABLEシステム権限が必要です。マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトがリモートの場合は、マテリアライズド・ビュー・サイトのユーザーがデータベース・リンクを介して接続する先のマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのユーザーに、READまたはSELECTオブジェクト権限を付与する必要があります。この権限は、明示的にまたはロールを介して付与できます。
マテリアライズド・ビューのリフレッシャが所有者でない場合は、リフレッシャと所有者に権限を付与する必要があります。これらの権限は、明示的にまたはロールを介して付与できます。
表3-2は、マテリアライズド・ビューのリフレッシャが所有者でない場合に必要な権限を示します。
表3-2 マテリアライズド・ビューのリフレッシュに必要な権限(リフレッシャが所有者でない場合)
| リフレッシャ | 所有者 |
|---|---|
|
|
マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトがローカルの場合は、マスターおよびマスターのマテリアライズド・ビュー・ログに対する マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトがリモートの場合は、マテリアライズド・ビュー・サイトのユーザーがデータベース・リンクを介して接続する先のマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのユーザーに、 |
ある状況において、マテリアライズド・ビューにマスター表またはマスター・マテリアライズド・ビューのデータのサブセットを反映させる必要のある場合があります。行のサブセット化では、WHERE句を使用して、マスター内の必要な行のみをマテリアライズド・ビューに含めることができます。列のサブセット化では、マスター内の必要な列のみをマテリアライズド・ビューに含めることができます。これを行うには、マテリアライズド・ビューの作成中に、SELECT文に該当する列を指定します。デプロイメント・テンプレートを使用してマテリアライズド・ビューを作成する場合には、更新可能マテリアライズド・ビューで列サブセットを定義できます。
データのサブセット化の使用目的には、次のようなものがあります。
ネットワークの通信量の軽減: 列のサブセットを含むマテリアライズド・ビューでは、マテリアライズド・ビューの定義問合せのWHERE句を満たす変更のみがマテリアライズド・ビュー・サイトに伝播されます。このため、転送データ量が減少し、ネットワーク通信量が軽減されます。
機密データの保護: マテリアライズド・ビューの定義問合せを満たすデータ以外は表示できません。
リソース要件の削減: マテリアライズド・ビューがラップトップに格納される場合は、一般にハード・ディスクは会社のサーバーよりもはるかに小さくなります。サブセット化したマテリアライズド・ビューにより、使用する記憶領域をかなり小さくすることができます。
リフレッシュ時間の短縮: マテリアライズド・ビュー・サイトに伝播されるデータが少なくなるため、リフレッシュ処理が高速になります。これは、ラップトップからダイアルアップ接続を使用してマテリアライズド・ビューをリフレッシュする必要のあるユーザーにとって不可欠です。
たとえば、次の文では、oe.orders@orc1.example.comマスター表に基づいたマテリアライズド・ビューが作成され、sales_rep_id番号が173の営業担当員の行のみが含まれます。
CREATE MATERIALIZED VIEW oe.orders REFRESH FAST AS SELECT * FROM oe.orders@orc1.example.com WHERE sales_rep_id = 173;
受注表でsales_rep_id番号が173以外の行は、このマテリアライズド・ビューからは除外されます。
前述の例は、他のマテリアライズド・ビューへの参照制約がない個別のマテリアライズド・ビューでは非常にうまく機能します。しかし、複数の表の情報に基づいたデータをレプリケートする場合は、これらのマテリアライズド・ビューのメンテナンスと定義が難しくなります。次の項では、副問合せが役立つ場合の例を示します。
oeスキーマにcustomers表とorders表が含まれている場合に、orders表とcustomers表の両方のデータに基づいたorders表のマテリアライズド・ビューを作成するとします。たとえば、営業担当員が、信用限度額が$10,000を超える顧客の注文をすべて調べる必要があるとします。この場合、ordersマテリアライズド・ビューを作成するCREATE MATERIALIZED VIEW文には、多対1関係の副問合せが含まれますが、これは、それぞれの顧客が多数の注文をしている可能性があるためです。
図3-3では、customers表とorders表はcustomer_id列を介して関係していることが示されています。営業担当員の目的は、次の文で達成されます。つまり、次の文では、信用限度額が$10,000より大きい顧客の注文が含まれたマテリアライズド・ビューが作成されます。
CREATE MATERIALIZED VIEW oe.orders REFRESH FAST FOR UPDATE AS
SELECT * FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT * FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id AND c.credit_limit > 10000);
|
注意: このoe.ordersマテリアライズド・ビューを作成するには、マスターのマテリアライズド・ビュー・ログにcredit_limitをロギングする必要があります。詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。 |
この文により作成されるマテリアライズド・ビューは、高速リフレッシュが可能で更新も可能です。信用限度額が$10,000を超える新規顧客が発生した場合は、後続のリフレッシュ処理中に新規データがこのマテリアライズド・ビュー・サイトに伝播されます。同様に、顧客の信用限度額が$10,000以下になった場合は、後続のリフレッシュ処理中に、その顧客のデータがこのマテリアライズド・ビューから削除されます。
oeスキーマにcustomers表とorders表が含まれている場合に、customers表とorders表の両方のデータに基づいたcustomers表のマテリアライズド・ビューを作成するとします。たとえば、営業担当員が、受注合計額が$20,000以上の全顧客を調べる必要があるとすると、最も効率的な方法は、定義問合せに1対多副問合せを指定したマテリアライズド・ビューを作成することです。
customers表に対するCREATE MATERIALIZED VIEW文の定義問合せには、1対多関係を持つ副問合せが含まれます。つまり、それぞれの顧客が多数の注文をしている可能性があります。
図3-4では、orders表とcustomers表はcustomer_id列を介して関係していることが示されています。営業担当員の目的は、次の文で達成されます。つまり、次の文では、受注合計額が$20,000より大きい全顧客が含まれたマテリアライズド・ビューが作成されます。
CREATE MATERIALIZED VIEW oe.customers REFRESH FAST FOR UPDATE AS
SELECT * FROM oe.customers@orc1.example.com c
WHERE EXISTS
(SELECT * FROM oe.orders@orc1.example.com o
WHERE c.customer_id = o.customer_id AND o.order_total > 20000);
|
注意: このoe.customersマテリアライズド・ビューを作成するには、orders表のマテリアライズド・ビュー・ログにcustomer_idとorder_totalをロギングする必要があります。詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。 |
この文により作成されるマテリアライズド・ビューは、高速リフレッシュが可能で、更新も可能です。受注合計額が$20,000を超える新規顧客が発生した場合は、後続のリフレッシュ処理中に新規データがこのマテリアライズド・ビュー・サイトに伝播されます。同様に、$20,000を超える受注合計額に含まれている注文を顧客が取り消して、受注合計額が$20,000より低くなった場合は、後続のリフレッシュ処理中に、その顧客のデータがこのマテリアライズド・ビューから削除されます。
oeスキーマにorder_items表とinventories表が含まれている場合に、inventories表とorder_items表の両方のデータに基づいたinventories表のマテリアライズド・ビューを作成するとします。たとえば、営業担当員が、現在のインベントリ数が1以上の各製品で、製品のproduct_idがorder_items表に含まれている全製品のインベントリを調べる必要があるとします。つまり、営業担当員は、顧客が注文した全製品について、インベントリが1以上の製品を調べる必要があります。この場合、インベントリとは、特定の倉庫にある製品の数です。このため、特定の製品は多数の受注項目と多数のインベントリに含まれる可能性があります。
この営業担当員の目的を達成するには、order_items表とinventories表との間の多対多関係に対する副問合せを使用したマテリアライズド・ビューを作成します。
inventoriesマテリアライズド・ビューを作成する場合は、order_items表に含まれている製品に関して、現在の数量が1以上のインベントリを取り出します。図3-5では、inventories表とorder_items表はproduct_id列を介して関係していることが示されています。次の文によりこのマテリアライズド・ビューが作成されます。
CREATE MATERIALIZED VIEW oe.inventories REFRESH FAST FOR UPDATE AS
SELECT * FROM oe.inventories@orc1.example.com i
WHERE i.quantity_on_hand > 0 AND EXISTS
(SELECT * FROM oe.order_items@orc1.example.com o
WHERE i.product_id = o.product_id);
|
注意: このoe.inventoriesマテリアライズド・ビューを作成するには、マスターのマテリアライズド・ビュー・ログにorder_items表のproduct_id列をロギングする必要があります。詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。 |
この文により作成されるマテリアライズド・ビューは、高速リフレッシュが可能で、更新も可能です。製品に対して1以上のインベントリがorder_items表で見つかった場合は、後続のリフレッシュ処理中に新規データがこのマテリアライズド・ビュー・サイトに伝播されます。同様に、顧客が製品の注文を取り消して、その製品に対する他の注文がorder_items表にない場合は、後続のリフレッシュ処理中に、その製品のインベントリがこのマテリアライズド・ビューから削除されます。
1つのマテリアライズド・ビューに、複数の問合せの結果に完全に一致するデータを含める場合は、UNION演算子を使用できます。UNION演算子を使用してマテリアライズド・ビューを作成する場合は、UNION演算子の前後に1つずつSELECT文を使用します。結果のマテリアライズド・ビューには、いずれかの問合せにより選択された行が含まれます。
UNION演算子は、副問合せのWHERE句にOR式を使用せずに「OR」条件を満たす高速リフレッシュ可能なマテリアライズド・ビューを作成する方法として使用できます。副問合せのWHERE句にOR式を使用すると、場合によっては結果のマテリアライズド・ビューが複合マテリアライズド・ビューになり、高速リフレッシュができなくなることがあります。
たとえば、営業担当員が、特定のcategory_idの製品で、カリフォルニアの倉庫にある製品、または翻訳された製品説明(フランス語翻訳用)に「Rouge」という単語が含まれている製品の製品情報を求めているとします。次の文では、UNION演算子と副問合せを使用して、category_id 29の製品について、マテリアライズド・ビューにこのデータを取り出します。
CREATE MATERIALIZED VIEW oe.product_information REFRESH FAST FOR UPDATE AS
SELECT * FROM oe.product_information@orc1.example.com pi
WHERE pi.category_id = 29 AND EXISTS
(SELECT * FROM oe.product_descriptions@orc1.example.com pd
WHERE pi.product_id = pd.product_id AND
pd.translated_description LIKE '%Rouge%')
UNION
SELECT * FROM oe.product_information@orc1.example.com pi
WHERE pi.category_id = 29 AND EXISTS
(SELECT * FROM oe.inventories@orc1.example.com i
WHERE pi.product_id = i.product_id AND EXISTS
(SELECT * FROM oe.warehouses@orc1.example.com w
WHERE i.warehouse_id = w.warehouse_id AND EXISTS
(SELECT * FROM hr.locations@orc1.example.com l
WHERE w.location_id = l.location_id
AND l.state_province = 'California')));
|
注意: oe.product_informationマテリアライズド・ビューを作成するには、各マスターのマテリアライズド・ビュー・ログに、oe.product_descriptions表のtranslated_description、hr.locations表のstate_provinceおよびoe.warehouses表のlocation_id列をロギングする必要があります。詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。 |
図3-6に、この文に含まれているマスター表の関係を示します。
この文には、UNION演算子の他に次の副問合せが含まれています。
product_information表とproduct_descriptions表を参照する副問合せ。1つの製品には複数の製品説明(異なる言語用)があるため、これは1対多副問合せです。
product_information表とinventories表を参照する副問合せ。1つの製品は多数のインベントリに含まれることがあるため、これは1対多副問合せです。
inventories表とwarehouses表を参照する副問合せ。多数のインベントリを1つの倉庫に格納できるため、これは多対1副問合せです。
warehouses表とlocations表を参照する副問合せ。多数の倉庫を1つの場所に配置できるため、これは多対1副問合せです。
この文により作成されるマテリアライズド・ビューは、高速リフレッシュが可能で、更新も可能です。カリフォルニアの倉庫に格納されているか、翻訳された製品説明に文字列「Rouge」を含む新製品が追加されると、後続のリフレッシュ処理中に新規データがproduct_informationマテリアライズド・ビューに伝播されます。
副問合せを使用するマテリアライズド・ビューの定義問合せには、マテリアライズド・ビューの高速リフレッシュ機能を保つためのいくつかの制限事項があります。
副問合せを使用する高速リフレッシュ・マテリアライズド・ビューの制限事項は、次のとおりです。
マテリアライズド・ビューは、主キー・マテリアライズド・ビューである必要があります。
マスターのマテリアライズド・ビュー・ログに、副問合せで参照されている列が含まれている必要があります。含める列の詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。
副問合せが多対多または1対多の場合は、主キーの一部ではない結合列をマスターのマテリアライズド・ビュー・ログに含める必要があります。この制限は、多対1の副問合せには適用されません。
副問合せは、肯定副問合せであることが必要です。たとえば、EXISTS条件は使用できますが、NOT EXISTS条件は使用できません。
副問合せは、EXISTSを使用して各ネスト・レベルを接続する必要があります(INは使用できません)。
各表は1つのEXISTS式にのみ含められます。
各表は副問合せ内で1回のみ結合できます。
各ネスト・レベルの各表に、主キーが存在している必要があります。
各ネスト・レベルでは、上位のレベルの表のみを参照できます。
副問合せにはAND条件を含められますが、各OR条件は1行に含まれている列のみを参照できます。1つの副問合せ内の複数のOR条件は、AND条件を使用して接続できます。
副問合せ内で参照されている表はすべて、同一のマスター・サイトまたはマスター・マテリアライズド・ビュー・サイト内にある必要があります。
副問合せを含むUNIONを使用する高速リフレッシュ・マテリアライズド・ビューには、次の制限事項があります。
各UNIONブロック内の副問合せには、「副問合せを使用するマテリアライズド・ビューでの制限事項」で説明したすべての制限事項が適用されます。
副問合せが多対1の場合でも、すべての結合列をマスターのマテリアライズド・ビュー・ログに含める必要があります。
「複合マテリアライズド・ビュー」で説明した、UNIONSを含む句に対するすべての制限事項が適用されます。
次の文は、oe.ordersマテリアライズド・ビューを作成します。各UNIONブロック内の副問合せが、「副問合せを使用するマテリアライズド・ビューでの制限事項」で説明した副問合せに関する制限事項を満たしているため、このマテリアライズド・ビューは高速リフレッシュができます。
CREATE MATERIALIZED VIEW oe.orders REFRESH FAST AS
SELECT * FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT * FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id
AND c.credit_limit > 50)
UNION
SELECT *
FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT * FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id
AND c.account_mgr_id = 30);
副問合せには、各表は1つのEXISTS式にしか含められないという制限事項があります。ここでは、customers表が2つのEXISTS式で使用されていますが、これらのEXISTS式は別々のUNIONブロックにあります。「副問合せを使用するマテリアライズド・ビューでの制限事項」で説明した制限事項は、各UNIONブロックに対してのみ適用されるもので、CREATE MATERIALIZED VIEW文全体に適用されるものではないため、このマテリアライズド・ビューは高速リフレッシュが可能です。
これに対して、次の文で作成されたマテリアライズド・ビューは高速リフレッシュができません。これは、orders表が同一UNIONブロック内の2つのEXISTS式で参照されているためです。
CREATE MATERIALIZED VIEW oe.orders AS
SELECT * FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT * FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id -- first reference to orders table
AND c.credit_limit > 50
AND EXISTS
(SELECT * FROM oe.orders@orc1.example.com o
WHERE order_total > 5000
AND o.customer_id = c.customer_id)) -- second reference to orders table
UNION
SELECT *
FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT * FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id
AND c.account_mgr_id = 30);
マテリアライズド・ビューの副問合せが前述の制限事項を満たすかどうかを判断するには、高速リフレッシュを指定してマテリアライズド・ビューを作成します。副問合せマテリアライズド・ビューに関する制限事項に違反している場合は、エラーが戻されます。強制リフレッシュを指定した場合、Oracleでは高速リフレッシュが実行できなければ完全リフレッシュが自動的に実行されるため、エラーは戻されません。
また、DBMS_MVIEWパッケージ内のEXPLAIN_MVIEWプロシージャを使用して、既存のマテリアライズド・ビュー、あるいはまだ作成されていないマテリアライズド・ビューに関して次の情報を判断できます。
マテリアライズド・ビューの機能
各機能を使用できるかどうか
機能を使用できない場合にはできない理由
この情報は、VARRAYまたはMV_CAPABILITIES_TABLEに格納できます。この表に情報を格納する場合は、EXPLAIN_MVIEWプロシージャを実行する前に、Oracle_home/rdbms/adminディレクトリにあるutlxmv.sqlスクリプトを実行してこの表を作成する必要があります。
たとえば、oe.ordersマテリアライズド・ビューの機能を判断するには、次のように入力します。
EXECUTE DBMS_MVIEW.EXPLAIN_MVIEW ('oe.orders');
または、マテリアライズド・ビューがまだ作成されていない場合は、その作成に使用する問合せを指定できます。
BEGIN
DBMS_MVIEW.EXPLAIN_MVIEW ('SELECT * FROM oe.orders@orc1.example.com o
WHERE EXISTS (SELECT * FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id AND c.credit_limit > 500)');
END;
/
MV_CAPABILITIES_TABLEを問い合せて結果を表示します。
|
注意: MV_CAPABILITIES_TABLEは、事前作成されたコンテナ表に依存するマテリアライズド・ビューのリフレッシュ機能を示しません。たとえば、事前作成されたコンテナ表でのパーティション・メンテナンス操作の後に完全なリフレッシュが必要ですが、MV_CAPABILITIES_TABLEではこの制限が示されません。 |
|
関連項目: EXPLAIN_MVIEWプロシージャの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。 |
他のマテリアライズド・ビューに基づいたマテリアライズド・ビューを作成する機能により、多重化マテリアライズド・ビューを作成できます。他のマテリアライズド・ビューに基づいたマテリアライズド・ビューは、読取り専用または更新可能です。図3-7の矢印は、データベース・リンクを表します。
多重化マテリアライズド・ビューを使用する場合、マスター表に基づいたマテリアライズド・ビューはレベル1のマテリアライズド・ビューと呼ばれます。次に、レベル1のマテリアライズド・ビューに基づいたマテリアライズド・ビューは、レベル2のマテリアライズド・ビューと呼ばれます。その次はレベル3、その次はレベル4というようになります。図3-8は、これらのレベルを示します。
他のマテリアライズド・ビューのマスターとして機能するマテリアライズド・ビューは、マスター・マテリアライズド・ビューと呼ばれます。どのレベルのマテリアライズド・ビューでもマスター・マテリアライズド・ビューにすることができ、図3-8に示したように、マスター・マテリアライズド・ビューに基づいたマテリアライズド・ビューは複数あります。図3-8では、レベル2の2つのマテリアライズド・ビューがレベル1の1つのマテリアライズド・ビューに基づいています。
図3-9は、レベル1(orders_1)とレベル2(orders_2)にあるマスター・マテリアライズド・ビューを示します。
レベル1のマテリアライズド・ビューorders_1のマスターは、マスター・サイトにあるマスター表ordersですが、レベル2から開始すると、各マテリアライズド・ビューにはその上のレベルにマスター・マテリアライズド・ビューがあります。たとえば、レベル2のマテリアライズド・ビューorders_2のマスターは、レベル1のマテリアライズド・ビューorders_1です。
マスター・マテリアライズド・ビューは、マスター・サイトのマスター表と同じように機能します。つまり、レベル2のマテリアライズド・ビューからレベル1のマテリアライズド・ビューにプッシュされる変更は、レベル1のマテリアライズド・ビューからマスター表にプッシュされる変更と同じ方法で処理されます。
マスター・マテリアライズド・ビュー・サイトには受信者を登録する必要があります。受信者は、マスター・マテリアライズド・ビューに基づいた多重化マテリアライズド・ビュー・サイトのプロパゲータから遅延トランザクションを受信し、それを適用する必要があります。
多重化マテリアライズド・ビューを使用すると、レプリケーション環境を柔軟に設計できます。マテリアライズド・ビュー・サイトによっては、マスター表のデータをすべてレプリケートする必要のないサイトもあり、実際、このようなサイトにはすべてのデータを格納する記憶域容量がない場合があります。さらに、レプリケートするデータが少ないことにより、ネットワーク上のアクティビティも減少します。
多重化マテリアライズド・ビューは、3レベル以上の構造を持つ組織や、ネットワーク・リソースの制約がある組織に理想的です。たとえば、統合本社、各国本社、各国支店を持つ会社があるとします。この会社では、各国本社レベルと支店レベルにデータをレプリケートするコンピュータが多数あります。この場合、レプリケーション環境は、統合本社にマスター・サイトを、各国本社レベルにマテリアライズド・ビューを配置して構成できます。各国本社レベルのマテリアライズド・ビューは、それぞれの国にあてはまるデータ・サブセットのみをマスター表からレプリケートします。ここで多重化マテリアライズド・ビューを使用すると、各国本社レベルのマテリアライズド・ビューに基づいて支店レベルのマテリアライズド・ビューを配置できます。支店レベルのマテリアライズド・ビューには、レベル1のマテリアライズド・ビューからのデータで、ローカルな顧客にあてはまるデータ・サブセットのみが含まれます。
全社員の情報を本社(米国)でメンテナンスする多国籍企業があったとします。この会社では、hrスキーマ内の表を使用して社員情報をメンテナンスします。この会社には14か国に本店がそれぞれ1つと、その14か国の主要都市に地区オフィスが多数あります。
たとえば、英国全体で本店が1つありますが、ロンドンにもオフィスが1つあります。英国本店では英国全土の全社員の情報をメンテナンスし、ロンドン・オフィスではこのオフィスの社員のみの社員情報をメンテナンスします。この例では、hr.employeesマスター表が米国の本社にあり、各地区オフィスには必要な社員情報のみを含むhr.employeesマテリアライズド・ビューがあります。
次の文では、英国本店のhr.employeesマテリアライズド・ビューを作成します。この文は、本社のデータベース内のマスター表orc1.example.comに問い合せます。この文では、country_idがUKの社員のみがマテリアライズド・ビューに含まれるように、副問合せを使用しています。
CREATE MATERIALIZED VIEW hr.employees REFRESH FAST FOR UPDATE AS
SELECT * FROM hr.employees@orc1.example.com e
WHERE EXISTS
(SELECT * FROM hr.departments@orc1.example.com d
WHERE e.department_id = d.department_id
AND EXISTS
(SELECT * FROM hr.locations@orc1.example.com l
WHERE l.country_id = 'UK'
AND d.location_id = l.location_id));
|
注意: このhr.employeesマテリアライズド・ビューを作成するには、次の列をロギングする必要があります。
詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。 |
次の文では、英国本店のレベル1のマテリアライズド・ビューに基づいてロンドン・オフィスのhr.employeesマテリアライズド・ビューを作成します。この文は、英国本店のデータベースにあるマテリアライズド・ビューreg_uk.example.comに問い合せます。この文では、cityがLondonの社員のみがマテリアライズド・ビューに含まれるように、副問合せを使用しています。
CREATE MATERIALIZED VIEW hr.employees REFRESH FAST FOR UPDATE AS
SELECT * FROM hr.employees@reg_uk.example.com e
WHERE EXISTS
(SELECT * FROM hr.departments@reg_uk.example.com d
WHERE e.department_id = d.department_id
AND EXISTS
(SELECT * FROM hr.locations@reg_uk.example.com l
WHERE l.city = 'London'
AND d.location_id = l.location_id));
|
注意: このhr.employeesマテリアライズド・ビューを作成するには、次の列をロギングする必要があります。
詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。 |
マスター・マテリアライズド・ビューおよびマテリアライズド・ビューに基づいたマテリアライズド・ビューの両方は、主キー・マテリアライズド・ビューである必要があります。
次のタイプのマテリアライズド・ビューは、更新可能マテリアライズド・ビューのマスターとしては指定できません。
ROWIDマテリアライズド・ビュー
複合マテリアライズド・ビュー
読取り専用マテリアライズド・ビュー
ただし、これらのマテリアライズド・ビューは、読取り専用マテリアライズド・ビューのマスターとして指定できます。
Oracleのオブジェクト型はユーザー定義データ型で、これを使用すると現実の複雑なエンティティ(顧客や注文など)をデータベース内に単一エンティティ(オブジェクト)としてモデル化できます。オブジェクト型は、CREATE TYPE ... AS OBJECT文を使用して作成します。オブジェクト型とオブジェクトは、レプリケーション環境のマスター・サイトとマテリアライズド・ビュー・サイト間でレプリケートできます。
表の1列を占有するOracleオブジェクトを、列オブジェクトと呼びます。一般に、列オブジェクトが含まれている表にはその他の列も含まれており、このような列のデータ型は組込みデータ型(VARCHAR2やNUMBERなど)の場合があります。オブジェクト表とは、各行がオブジェクトを表す特殊な表です。オブジェクト表の各行は行オブジェクトです。
コレクションをレプリケートすることもできます。コレクションとは、VARRAYデータ型およびネストした表のデータ型に基づいたユーザー定義データ型です。VARRAYはCREATE TYPE ... AS VARRAY文を、ネストした表はCREATE TYPE ... AS TABLE文を使用して作成します。
|
関連項目:
|
ユーザー定義型には、オブジェクト、ネストした表、VARRAY、索引タイプなど、CREATE TYPE文で作成された型がすべて含まれます。ユーザー定義型に基づいたスキーマ・オブジェクトをレプリケートするには、全レプリケーション・サイトに同一のユーザー定義型自体が存在する必要があります。さらに、ユーザー定義型が使用されるレプリケーション・グループにユーザー定義型を追加することをお薦めします(ただし、これは必須ではありません)。
ユーザー定義型とそれに基づいたスキーマ・オブジェクトをレプリケートする場合は、次の条件が適用されます。
マスター・サイトとマテリアライズド・ビュー・サイトでレプリケートされるユーザー定義型は、これらの型に依存するマテリアライズド・ビューを作成する前にマテリアライズド・ビュー・サイトで作成する必要があります。
ユーザー定義型を持つマテリアライズド・ビューを作成するには、マテリアライズド・ビューの基になるマスターがすべて同一マスター・サイト上にある必要があります。
ユーザー定義型は全レプリケーション・サイトで同一にする必要があります。
レプリケートされる各ユーザー定義型について、オブジェクト識別子(OID)、スキーマ所有者および型の名前を全レプリケーション・サイトで同一にする必要があります。
ユーザー定義型がオブジェクト型の場合は、全レプリケーション・サイトで、オブジェクト型の属性の順序とデータ型が一致する必要があります。属性の順序とデータ型は、オブジェクト型を作成するときに設定します。たとえば、次のようなオブジェクト型の場合を考えます。
CREATE TYPE cust_address_typ AS OBJECT
(street_address VARCHAR2(40),
postal_code VARCHAR2(10),
city VARCHAR2(30),
state_province VARCHAR2(10),
country_id CHAR(2));
/
全レプリケーション・サイトで、street_addressはこの型の最初の属性でVARCHAR2(40)、postal_codeは2番目の属性でVARCHAR2(10)、cityは3番目の属性でVARCHAR2(30)、というようになっている必要があります。
全レプリケーション・サイトで、ユーザー定義型のハッシュコードが一致する必要があります。Oracleでは、ユーザー定義型が検査され、ハッシュコードが割り当てられます。この検査では、型の属性、属性の順序および型の名前が調べられます。複数の型についてこれらの項目がすべて同じである場合、型のハッシュコードは同じです。型のハッシュコードは、DBA_TYPE_VERSIONSデータ・ディクショナリ・ビューを問い合せて表示できます。
全レプリケーション・サイトでユーザー定義型を同一にするには、次のいずれかの方法でマテリアライズド・ビュー・サイトにユーザー定義型を作成する必要があります。
マテリアライズド・ビュー・サイトでユーザー定義型を含むレプリケート・オブジェクトを作成、変更または削除する場合は、レプリケーション・マネージメントAPIの使用をお薦めします。レプリケーション・マネージメントAPIを使用しない場合、レプリケーション・エラーが発生することがあります。
マスター・サイトとマテリアライズド・ビュー・サイトで同一のユーザー定義型を作成するには、DBMS_REPCATパッケージ内のCREATE_MVIEW_REPOBJECTプロシージャを使用します。このプロシージャは型を作成してマテリアライズド・ビュー・グループに追加します。マテリアライズド・ビュー・サイトからユーザー定義型を削除するには、DBMS_REPCATパッケージ内のDROP_MVIEW_REPOBJECTプロシージャを使用します。
|
関連項目: 『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』 |
型を作成するには、マテリアライズド・ビュー・サイトでCREATE TYPE文を使用できます。型を使用する読取り専用マテリアライズド・ビューを作成し、この読取り専用マテリアライズド・ビューをマテリアライズド・ビュー・グループに追加しない場合は、この方法が必要になることがあります。
この方法を選択する場合は、次のことを確認する必要があります。
マテリアライズド・ビュー・サイトとマスター・サイトで型が同一スキーマ内にあること。
マテリアライズド・ビュー・サイトとマスター・サイトで型の属性および順序が同一であること。
マテリアライズド・ビュー・サイトとマスター・サイトで型の各属性のデータ型が同一であること。
マテリアライズド・ビュー・サイトとマスター・サイトで型のオブジェクト識別子が同一であること。
型のオブジェクト識別子は、DBA_TYPESデータ・ディクショナリ・ビューを問い合せると検出できます。たとえば、cust_address_typのオブジェクト識別子(OID)を検出するには、次の問合せを入力します。
SELECT TYPE_OID FROM DBA_TYPES WHERE TYPE_NAME = 'CUST_ADDRESS_TYP'; TYPE_OID -------------------------------- 6F9BC33653681B7CE03400400B40A607
これで、マスター・サイトでの型のOIDが認識できたため、次の手順を実行して、マテリアライズド・ビュー・サイトでこの型を作成します。
マスター・サイトでこの型を所有するユーザーとして、マテリアライズド・ビュー・サイトにログインします。マテリアライズド・ビュー・サイトにこのユーザーがない場合はユーザーを作成します。
CREATE TYPE文を発行し、OIDを指定します。
CREATE TYPE oe.cust_address_typ OID '6F9BC33653681B7CE03400400B40A607'
AS OBJECT (
street_address VARCHAR2(40),
postal_code VARCHAR2(10),
city VARCHAR2(30),
state_province VARCHAR2(10),
country_id CHAR(2));
/
これで、マテリアライズド・ビュー・サイトでこの型を使用できます。
読取り専用マテリアライズド・ビューでは、その他の属性はレプリケートせずに列オブジェクトの特定の属性のみをレプリケートできます。たとえば、前述のcust_address_typユーザー定義データ型を使用して、customers_subマスター表がマスター・サイトorc1.example.comに作成されているとします。
CREATE TABLE oe.customers_sub (
customer_id NUMBER(6) PRIMARY KEY,
cust_first_name VARCHAR2(20),
cust_last_name VARCHAR2(20),
cust_address oe.cust_address_typ);
次の読取り専用マテリアライズド・ビューをリモート・マテリアライズド・ビュー・サイトに作成できます。
CREATE MATERIALIZED VIEW oe.customers_mv1 AS SELECT customer_id, cust_last_name, c.cust_address.postal_code FROM oe.customers_sub@orc1.example.com c;
ここでは、postal_code属性がcust_address列オブジェクト内に指定されています。
更新可能マテリアライズド・ビューでは列オブジェクト全体をレプリケートします。列オブジェクトの属性を部分的にレプリケートすることはできません。次の文はcust_address列オブジェクト全体を指定しているため有効です。
CREATE MATERIALIZED VIEW oe.customers_mv1 FOR UPDATE AS SELECT customer_id, cust_last_name, cust_address FROM oe.customers_sub@orc1.example.com;
|
関連項目: デプロイメント・テンプレートを使用した列のサブセット化の詳細は、「デプロイメント・テンプレートを使用した列のサブセット化」を参照してください。列のサブセット化は、デプロイメント・テンプレートを使用した場合にのみサポートされます。 |
マテリアライズド・ビューがオブジェクト表に基づいてOF type句を使用して作成されている場合、このマテリアライズド・ビューはオブジェクト・マテリアライズド・ビューと呼ばれます。オブジェクト・マテリアライズド・ビューは、オブジェクト表と同じ構造です。つまり、オブジェクト・マテリアライズド・ビューは行オブジェクトで構成されます。オブジェクト表に基づいたマテリアライズド・ビューがOF type句を使用せずに作成されている場合、このマテリアライズド・ビューは読取り専用で、オブジェクト・マテリアライズド・ビューではありません。つまり、このようなマテリアライズド・ビューには、行オブジェクトではなく通常の行が含まれています。
オブジェクト表に基づいたマテリアライズド・ビューを作成するには、マテリアライズド・ビューが依存する型がマテリアライズド・ビュー・サイトに必要で、それぞれの型にはマスター・サイトと同じオブジェクト識別子が必要です。
必要な型をマテリアライズド・ビュー・サイトに作成した後、OF type句を指定してオブジェクト・マテリアライズド・ビューを作成できます。
たとえば、次のSQL文でorc1.example.comマスター・サイトにoe.categories_tabオブジェクト表を作成するとします。
CREATE TYPE oe.category_typ AS OBJECT
(category_name VARCHAR2(50),
category_description VARCHAR2(1000),
category_id NUMBER(2));
/
CREATE TABLE oe.categories_tab OF oe.category_typ
(category_id PRIMARY KEY);
oe.categories_tabマスター表に基づいて高速リフレッシュが可能なマテリアライズド・ビューを作成するには、この表のマテリアライズド・ビュー・ログを作成します。
CREATE MATERIALIZED VIEW LOG ON oe.categories_tab WITH OBJECT ID;
オブジェクト表に対するマテリアライズド・ビュー・ログを作成する場合には、WITH OBJECT ID句が必要です。
マスター・サイトの同じ型と同じオブジェクト識別子を持つoe.category_typ型をマテリアライズド・ビュー・サイトに作成した後、次のSQL文のようにOF type句を使用して、oe.categories_tabオブジェクト表に基づくオブジェクト・マテリアライズド・ビューを作成できます。
CREATE MATERIALIZED VIEW oe.categories_objmv OF oe.category_typ REFRESH FAST FOR UPDATE AS SELECT * FROM oe.categories_tab@orc1.example.com;
この場合、typeはoe.category_typです。
オブジェクト表に基づいてOF type句を使用せずにマテリアライズド・ビューを作成した場合、このマテリアライズド・ビューは読取り専用となり、基になるオブジェクト表のオブジェクト・プロパティは失われます。つまり、作成された読取り専用マテリアライズド・ビューにはマスターの列が1つ以上含まれますが、それぞれの行はリレーショナル表の行として機能します。行は行オブジェクトではありません。
たとえば、次のSQL文を使用して、categories_tabマスター表に基づいたマテリアライズド・ビューを作成できます。
CREATE MATERIALIZED VIEW oe.categories_relmv AS SELECT * FROM oe.categories_tab@orc1.example.com;
この場合、categories_relmvマテリアライズド・ビューは読取り専用で、このマテリアライズド・ビューの行は、リレーショナル表の行と同じように機能します。
オブジェクト・マテリアライズド・ビューは、マスターのオブジェクト識別子(OID)指定を継承します。マスターに主キー・ベースのOIDがある場合、マテリアライズド・ビューの行オブジェクトのOIDは主キー・ベースになります。マスターにシステム生成されたOIDがある場合、マテリアライズド・ビューの行オブジェクトのOIDはシステム生成されたOIDです。また、オブジェクト・マテリアライズド・ビューの各行のOIDは、マスター内の同じ行のOIDと一致し、マテリアライズド・ビューのリフレッシュ中、OIDは保持されます。この結果、オブジェクト表の行に対するREFは、マテリアライズド・ビュー・サイトでも有効になります。
コレクション列とは、VARRAYデータ型およびネストした表のデータ型に基づいた列です。Oracleではコレクション列を含むマテリアライズド・ビューの作成をサポートしています。
コレクション列がネストした表の場合は、マテリアライズド・ビューの作成中にオプションとしてnested_table_storage_clauseを指定できます。nested_table_storage_clauseを使用すると、ネストした表用の記憶表の名前をマテリアライズド・ビューに指定できます。たとえば、マスター・サイトorc1.example.comにマスター表people_reltabを作成し、この表にネストした表phones_ntabが含まれているとします。
CREATE TYPE oe.phone_typ AS OBJECT ( location VARCHAR2(15), num VARCHAR2(14)); / CREATE TYPE oe.phone_ntabtyp AS TABLE OF oe.phone_typ; / CREATE TABLE oe.people_reltab ( id NUMBER(4) CONSTRAINT pk_people_reltab PRIMARY KEY, first_name VARCHAR2(20), last_name VARCHAR2(20), phones_ntab oe.phone_ntabtyp) NESTED TABLE phones_ntab STORE AS phone_store_ntab ((PRIMARY KEY (NESTED_TABLE_ID, location)));
このSQL文の最後の行のPRIMARY KEY指定に注意してください。親表に基づいてマテリアライズド・ビューを作成する場合は、記憶表に主キーを指定する必要があります。この例では、記憶表はphone_store_ntabで、親表はpeople_reltabです。
高速リフレッシュ可能なマテリアライズド・ビューを作成する場合は、親表と記憶表の両方にマテリアライズド・ビュー・ログを作成し、ネストした表の列を親表のマテリアライズド・ビュー・ログのフィルタ列として指定します。
CREATE MATERIALIZED VIEW LOG ON oe.people_reltab; ALTER MATERIALIZED VIEW LOG ON oe.people_reltab ADD(phones_ntab); CREATE MATERIALIZED VIEW LOG ON oe.phone_store_ntab WITH PRIMARY KEY;
マテリアライズド・ビュー・サイトで必要な型を作成し、それぞれの型のオブジェクト識別子がマスター・サイトのオブジェクト識別子と同じになるようにします。この後、people_reltabに基づいてマテリアライズド・ビューを作成し、次の文を使用してその記憶表を指定できます。
CREATE MATERIALIZED VIEW oe.people_reltab_mv NESTED TABLE phones_ntab STORE AS phone_store_ntab_mv REFRESH FAST AS SELECT * FROM oe.people_reltab@orc1.example.com;
この場合、nested_table_storage_clauseは前述の例の「NESTED TABLE」で始まる行であり、これによって記憶表の名前がphone_store_ntab_mvであることを指定します。nested_table_storage_clauseはオプションです。この句を指定しない場合、記憶表には自動的に名前が付けられます。記憶表の名前を表示するには、DBA_NESTED_TABLESデータ・ディクショナリ表を問い合せます。
記憶表には次の特性があります。
個別のセカンダリ・マテリアライズド・ビューです。
ネストした表を含むマテリアライズド・ビューをリフレッシュすると、自動的にリフレッシュされます。
ネストした表を含むマテリアライズド・ビューを削除すると、自動的に削除されます。
マスターの記憶表の主キー制約を継承します。
記憶表はマスターの記憶表の主キー制約を継承するため、STORE AS句にはPRIMARY KEYを指定しないでください。
マテリアライズド・ビュー内のネストした表の記憶表に対して次のアクションを直接実行することはできません。
記憶表のリフレッシュ
レプリケーション・グループへの記憶表の追加
記憶表の変更
記憶表の削除
記憶表に対するレプリケーション・サポートの生成
これらのアクションは、ネストした表を含むマテリアライズド・ビューに対する実行時に間接的に発生します。さらに、記憶表内の列のサブセットはレプリケートできません。
|
関連項目: nested_table_col_propertiesの詳細は、『Oracle Database SQL言語リファレンス』のCREATE TABLE文に関する説明を参照してください。 |
REF列を含むマテリアライズド・ビューを作成できます。REFとはOracleの組込みデータ型で、オブジェクト表内の行オブジェクトを指す論理的なポインタです。有効範囲付きREFは、指定されたオブジェクト表のみへの参照を含めることができるREFで、有効範囲なしREFは、データベース内で対応するオブジェクト型に基づいたすべてのオブジェクト表に対する参照を含めることができます。有効範囲付き REFは、有効範囲なしREFと比べて必要とする記憶領域が少なく、より効率的なアクセスを提供します。
次の項で説明するように、マテリアライズド・ビューの作成中にREF列の有効範囲を変更して、マテリアライズド・ビュー・サイトのローカルなマテリアライズド・ビューまたは表を指すように変更できます。REF列の有効範囲を変更しないと、リモートのマスターを指したままになります。有効範囲なしREF列は、常にマスターを指します。マテリアライズド・ビュー・サイトのREF列がリモート・マスターを指す場合、REFには参照先がないとみなされます。SQLでは、参照先がないREFを参照解除すると、NULLが返されます。また、PL/SQLではUTL_OBJECTパッケージを使用したREFの参照解除のみがサポートされ、参照先がないREFに対しては例外が発生します。
有効範囲付きREF列を含むマスターに基づいてマテリアライズド・ビューを作成する場合は、REFの有効範囲をマテリアライズド・ビュー・サイトの別のオブジェクト表またはオブジェクト・マテリアライズド・ビューに変更できます。通常、REF列の有効範囲は、元のリモート・オブジェクト表ではなくローカル・オブジェクト・マテリアライズド・ビューに変更します。マテリアライズド・ビューの有効範囲を変更するには、CREATE MATERIALIZED VIEW文にSCOPE FOR句を使用するか、マテリアライズド・ビューを作成した後でALTER MATERIALIZED VIEW文を使用します。REF列の有効範囲を変更しないと、マテリアライズド・ビューはマスターのREF列をそのまま保持します。
たとえば、次の文を使用してorc1.example.comマスター・サイトにcustomers_with_refマスター表を作成するとします。
-- Create the user-defined data type cust_address_typ.
CREATE TYPE oe.cust_address_typ AS OBJECT
(street_address VARCHAR2(40),
postal_code VARCHAR2(10),
city VARCHAR2(30),
state_province VARCHAR2(10),
country_id CHAR(2));
/
-- Create the object table cust_address_objtab.
CREATE TABLE oe.cust_address_objtab OF oe.cust_address_typ;
-- Create table with REF to cust_address_typ.
CREATE TABLE oe.customers_with_ref (
customer_id NUMBER(6) PRIMARY KEY,
cust_first_name VARCHAR2(20),
cust_last_name VARCHAR2(20),
cust_address REF oe.cust_address_typ
SCOPE IS oe.cust_address_objtab);
マスター・サイトの型と同じオブジェクト識別子を持つcust_address_typがマテリアライズド・ビュー・サイトにあると仮定した場合、次の文を使用するとcust_address_objtab_mvオブジェクト・マテリアライズド・ビューを作成できます。
CREATE MATERIALIZED VIEW oe.cust_address_objtab_mv OF oe.cust_address_typ AS SELECT * FROM oe.cust_address_objtab@orc1.example.com;
これで、次の文を使用してcustomers_with_refマスター表のマテリアライズド・ビューを作成し、REFの有効範囲をcust_address_objtab_mvマテリアライズド・ビューに変更できます。
CREATE MATERIALIZED VIEW oe.customers_with_ref_mv (SCOPE FOR (cust_address) IS oe.cust_address_objtab_mv) AS SELECT * FROM oe.customers_with_ref@orc1.example.com;
マテリアライズド・ビューを作成するときにSCOPE FOR句を使用する場合は、SCOPE FOR句に指定するマテリアライズド・ビューまたは表を先に作成する必要があります。そうしないと、マテリアライズド・ビューの作成中にSCOPE FOR句を指定できません。たとえば、cust_address_objtab_mvマテリアライズド・ビューを作成する前に、customers_with_ref_mvマテリアライズド・ビューを作成すると、customers_with_ref_mvマテリアライズド・ビューを作成するときにSCOPE FOR句を使用できません。この場合、REFはリモート・マスター・サイトのオブジェクト表を指すため、参照先がないとみなされます。
ただし、マテリアライズド・ビューを作成するときにSCOPE FOR句を使用しない場合でも、SCOPE FOR句を指定するようにマテリアライズド・ビューを変更できます。たとえば、次の文でcustomers_with_ref_mvマテリアライズド・ビューを変更できます。
ALTER MATERIALIZED VIEW oe.customers_with_ref_mv MODIFY SCOPE FOR (cust_address) IS oe.cust_address_objtab_mv;
有効範囲なしREF列を含むリモート・マスターに基づいてマテリアライズド・ビューを作成した場合、マテリアライズド・ビューにREF列は作成されますが、REFはリモート・データベースを指すため参照先がないとみなされます。
REF列に対してWITH ROWID句を指定すると、REFで参照されているオブジェクトの行IDがメンテナンスされます。REFに含まれている行IDを使用して、参照されているオブジェクトを直接検出できます(OID索引から行IDをフェッチする必要はありません)。したがって、WITH ROWID句は行IDヒントを指定するために使用します。WITH ROWID句は、有効範囲付きREFに対してはサポートされていません。
WITH ROWID句を使用して作成されたREFをレプリケートすると、REFが最初に作成または変更されたサイトを除き、各レプリケーション・サイトでは行IDヒントが正しくなくなります。他のサイトではREFに含まれているROWID情報が無意味になります(行IDヒントは自動的には修正されません)。無効な行IDヒントは、パフォーマンス上の問題の原因になります。この場合は、ANALYZE TABLE文のVALIDATE STRUCTUREオプションを使用して、各レプリケーション・サイトの正しくない行IDヒントを判断できます。
|
関連項目: ANALYZE TABLE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
マスター・サイトとマスター・マテリアライズド・ビュー・サイトでは、マテリアライズド・ビューに関する情報がマスター表またはマスター・マテリアライズド・ビューに基づいて自動的に登録されます。次の項では、マテリアライズド・ビューの登録メカニズムについて説明します。
レベル1のマテリアライズド・ビューまたはマテリアライズド・ビュー・グループは、マスター・サイトに登録されます。レベル2以上の多重化マテリアライズド・ビューまたはマテリアライズド・ビュー・グループは、マスター・サイトではなくマスター・マテリアライズド・ビュー・サイトに登録されます。マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでDBA_REGISTERED_MVIEWSデータ・ディクショナリ・ビューを問い合せると、リモート・マテリアライズド・ビューに関する次の情報を表示できます。
所有者、名前およびマテリアライズド・ビューを含むデータベース
マテリアライズド・ビューの定義問合せ
マテリアライズド・ビューのその他の特性(リフレッシュ方式など)
さらに、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでDBA_MVIEW_REFRESH_TIMESビューを問い合せると、各リモート・マテリアライズド・ビューの最新リフレッシュ時刻を取得できます。管理者は、この情報を使用してマテリアライズド・ビューのアクティビティを監視し、マスター表またはマスター・マテリアライズド・ビューの削除、変更または再配置が必要な場合にマテリアライズド・ビュー・サイトへの変更を調整できます。
Oracleでは、マテリアライズド・ビューが作成されると、それをマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに登録し、マテリアライズド・ビューが削除されるとその登録を解除します。同じことがマテリアライズド・ビュー・グループにも当てはまります。
マスター・マテリアライズド・ビューを削除した場合、これに基づいたマテリアライズド・ビューは自動的には削除されません。これらのマテリアライズド・ビューは手動で削除する必要があります。このようなマテリアライズド・ビューを削除せずに、すでに削除されているマスター・マテリアライズド・ビューに対してそのマテリアライズド・ビューからリフレッシュしようとすると、エラーが戻されます。
たとえば、orders_lev1というマテリアライズド・ビューがoe.ordersマスター表に基づいており、orders_lev2というマテリアライズド・ビューがorders_lev1に基づいているとします。orders_lev1を削除しても、orders_lev2はそのまま残ります。ここで、orders_lev2をリフレッシュしようとすると、orders_lev1はすでに存在しないため、エラーが戻されます。
|
注意: マテリアライズド・ビューを作成(または削除)するとき、このマテリアライズド・ビューがマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに登録(または登録解除)されるとはかぎりません。マテリアライズド・ビューを作成中にOracleで正常に登録できない場合は、DBMS_MVIEWパッケージ内のREGISTER_MVIEWプロシージャを使用して手動で登録を完了する必要があります。マテリアライズド・ビューを削除するときにOracleで正常にその登録を解除できない場合は、手動で登録を解除するまで、そのマテリアライズド・ビューの登録情報がマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに残ります。複合マテリアライズド・ビューは登録されない場合があります。 |
図3-10は、マテリアライズド・ビューのレプリケーションに使用されるオブジェクトを示します。これらのオブジェクトの一部はオプションで、作成したマテリアライズド・ビュー環境のサポートに必要な場合にのみ使用します。たとえば、読取り専用マテリアライズド・ビューがある場合は、マテリアライズド・ビュー・サイトには更新可能マテリアライズド・ビュー・ログや内部トリガーはありません。また、高速リフレッシュができない複合マテリアライズド・ビューがある場合は、マスター・サイトにマテリアライズド・ビュー・ログがない可能性があります。
マスター・マテリアライズド・ビューには、マテリアライズド・ビュー・ログと更新可能マテリアライズド・ビュー・ログの両方が含まれている場合があります。マスター・マテリアライズド・ビュー・サイトを計画する場合は、この2つのログに必要な追加領域を考慮してください。
この項には、次の項目が含まれます。
マテリアライズド・ビューの高速リフレッシュをサポートするために、図3-11に示されている3つのメカニズムがマスター・サイトとマスター・マテリアライズド・ビュー・サイトの両方で必要です。
マスター表またはマスター・マテリアライズド・ビューは、マテリアライズド・ビューの基礎です。マスター表はターゲット・マスター・サイトにあり、マスター・マテリアライズド・ビューはマスター・マテリアライズド・ビュー・サイトにあります。マスターがマスター表の場合、この表はマテリアライズド・ビュー・レプリケーションとマルチマスター・レプリケーションの両方に関与している可能性があります。マテリアライズド・ビューが指すマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトは1つのみです。マスター表またはマスター・マテリアライズド・ビューに加えられた変更はマテリアライズド・ビュー・ログに記録され、リフレッシュ処理中にマテリアライズド・ビューに伝播されます。
|
注意: 高速リフレッシュ可能マテリアライズド・ビューは、マスター表、マスター・マテリアライズド・ビュー、またはマスター表かマスター・マテリアライズド・ビューのシノニムに基づく必要があります。完全リフレッシュは、ビューに基づいたマテリアライズド・ビューで使用する必要があります。 |
DMLを使用してマスター表またはマスター・マテリアライズド・ビューに変更が加えられると、内部トリガーにより、影響を受けた行に関する情報がマテリアライズド・ビュー・ログに記録されます。この情報には、主キー、行IDまたはオブジェクト識別子(あるいはこれらすべて)の値のみでなく、マテリアライズド・ビュー・ログにロギングされる他の列の値も含まれます。これは、ターゲットのマスター表またはマスター・マテリアライズド・ビューのマテリアライズド・ビュー・ログを作成するときに自動的にアクティブになるAFTER ROW内部トリガーです。このトリガーは、INSERT文、UPDATE文またはDELETE文により表のデータが変更されるたびに、マテリアライズド・ビュー・ログに行を挿入します。このトリガーは、常に最後に起動されるトリガーです。
|
注意: マテリアライズド・ビューに副問合せが含まれている場合は、副問合せで参照される列のログが必要になることがあります。副問合せマテリアライズド・ビューの詳細は、「マテリアライズド・ビューを使用したデータのサブセット化」、ログが必要になる列の詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。 |
マスターに基づいてマテリアライズド・ビューを高速リフレッシュする場合は、マスター上にマテリアライズド・ビュー・ログが必要です。マスター表またはマスター・マテリアライズド・ビューにマテリアライズド・ビュー・ログを作成すると、基になる表がマテリアライズド・ビュー・ログとして作成されます。マテリアライズド・ビュー・ログには、マスター表またはマスター・マテリアライズド・ビューで更新された行の主キー、行IDまたはオブジェクト識別子(あるいはこれらすべて)を含められます。マテリアライズド・ビュー・ログには、副問合せを含むマテリアライズド・ビューの高速リフレッシュをサポートする他の列を含めることもできます。
マテリアライズド・ビュー・ログの表の名前は、MLOG$_master_nameです。マテリアライズド・ビュー・ログは、ターゲット・マスターと同じスキーマ内に作成されます。1つのマテリアライズド・ビュー・ログは、マスター表またはマスター・マテリアライズド・ビューに対する複数のマテリアライズド・ビューをサポートできます。前の項で説明したように、ターゲット・マスターに対してDMLトランザクションが発生するたびに、内部トリガーによってマテリアライズド・ビュー・ログに変更情報が追加されます。
マテリアライズド・ビュー・ログには次のタイプがあります。
主キー: マテリアライズド・ビューは、マスター表またはマスター・マテリアライズド・ビューが変更されると、影響を受けた行の主キーに基づいて変更内容を記録します。
行ID: マテリアライズド・ビューは、マスター表またはマスター・マテリアライズド・ビューが変更されると、影響を受けた行の行IDに基づいて変更内容を記録します。
オブジェクトID: マテリアライズド・ビューは、マスター・オブジェクト表またはマスター・オブジェクト・マテリアライズド・ビューが変更されると、影響を受けた行オブジェクトのオブジェクト識別子に基づいて変更内容を記録します。
組合せ: マテリアライズド・ビューは、3つのオプションの組合せに基づいてマスター表またはマスター・マテリアライズド・ビューへの変更を記録します。主キー、ROWID、影響を受ける行のオブジェクト識別子に基づいて変更を記録できます。このようなマテリアライズド・ビュー・ログは、主キー、ROWIDおよびオブジェクト・マテリアライズド・ビューをサポートし、マスターに基づく3つのすべてのタイプのマテリアライズド・ビューのある環境で役立ちます。
組合せマテリアライズド・ビュー・ログは、1種類のタイプの値を追跡するマテリアライズド・ビュー・ログと同じように機能しますが、複数のタイプの値が記録されるという点のみが異なります。たとえば、組合せマテリアライズド・ビュー・ログは、影響を受けた行の主キーと行IDの両方を追跡および記録できます。
主キーに基づいたマテリアライズド・ビュー・ログと行IDに基づいたマテリアライズド・ビュー・ログの間に大きな違いはありませんが(影響を受けた行を記録する際に、主キーと物理行IDのどちらを使用するかという点のみが異なります)、実際に与える影響は非常に大きくなります。ROWIDマテリアライズド・ビューとマテリアライズド・ビュー・ログを使用すると、ROWIDマテリアライズド・ビューを高速リフレッシュできなくなるため、マスター表の再編成および切捨てが難しくなります。マスター表の再編成または切捨てを実行した場合はマスター表の行IDが変更されるため、ROWIDマテリアライズド・ビューは完全リフレッシュする必要があります。
オブジェクト表に対してマテリアライズド・ビュー・ログを作成できます。たとえば、次のSQL文を使用して、categories_typユーザー定義型を作成できます。
CREATE TYPE oe.category_typ AS OBJECT
(category_name VARCHAR2(50),
category_description VARCHAR2(1000),
category_id NUMBER(2));
/
この型に基づいてオブジェクト表を作成するとき、オブジェクト識別子がシステム生成のものか主キーに基づいたものかを指定できます。
CREATE TABLE oe.categories_tab_sys OF oe.category_typ
(category_id PRIMARY KEY)
OBJECT ID SYSTEM GENERATED;
CREATE TABLE oe.categories_tab_pkbased OF oe.category_typ
(category_id PRIMARY KEY)
OBJECT ID PRIMARY KEY;
オブジェクト表に基づいてマテリアライズド・ビューを作成するときは、WITH OBJECT ID句を指定してオブジェクト識別子をロギングする必要がありますが、オブジェクト識別子が主キー・ベースの場合は、主キーもロギングされるように指定できます。
たとえば、次の文ではcategories_tab_sysオブジェクト表のマテリアライズド・ビュー・ログを作成し、オブジェクト識別子列をロギングするように指定します。
CREATE MATERIALIZED VIEW LOG ON oe.categories_tab_sys WITH OBJECT ID;
次の文では、categories_tab_pkbasedオブジェクト表のマテリアライズド・ビュー・ログを作成し、オブジェクト識別子列とともに主キー列をロギングするように指定します。
CREATE MATERIALIZED VIEW LOG ON oe.categories_tab_pkbased WITH OBJECT ID, PRIMARY KEY;
マテリアライズド・ビュー・ログは、DDL文で明示的に指定されたスキーマ名でエクスポートされます。そのため、マテリアライズド・ビュー・ログは、エクスポート元のスキーマとは異なるスキーマにはインポートできません。指定したスキーマのマテリアライズド・ビュー・ログを含むエクスポート・ダンプ・ファイルをインポートするために、REMAP_SCHEMAインポート・パラメータを指定するデータ・ポンプ・インポート・ユーティリティを使用してインポートを試行すると、インポート・ログ・ファイルにエラーが書き込まれ、項目はインポートされません。
マテリアライズド・ビューを作成すると、そのマテリアライズド・ビューをサポートするための追加のメカニズムがマテリアライズド・ビュー・サイトで作成されます。具体的には、1つ以上の索引が作成されます。更新可能なマテリアライズド・ビューを作成する場合は、マテリアライズド・ビュー・サイトに内部トリガーとローカル・ログ(更新可能なマテリアライズド・ビュー・ログ)も作成されます。
|
注意:
|
主キーおよびROWIDマテリアライズド・ビューのそれぞれに対して、リモート・マテリアライズド・ビュー・サイトに1つ以上の索引が作成されます。主キー・マテリアライズド・ビューの場合、索引はターゲット・マスター表またはマスター・マテリアライズド・ビューの主キーに対応し、名前に_PKが含まれます。マテリアライズド・ビュー・サイトに同じ名前の索引がすでに存在する場合は、番号が追加されます。ROWIDマテリアライズド・ビューの場合、索引はROWID列に対応し、名前にI_SNAP$_が含まれます。副問合せを使用するマテリアライズド・ビューの高速リフレッシュをサポートするために、リモート・マテリアライズド・ビュー・サイトに追加の索引が作成されることもあります。
更新可能マテリアライズド・ビュー・ログ(USLOG$_materialized_view_name)は、高速リフレッシュ中にマテリアライズド・ビューで上書きまたは削除する行を判断するために使用されます。このログは読取り専用マテリアライズド・ビューでは作成されず、また完全リフレッシュ中にはこのログは使用されません(完全リフレッシュの場合はマテリアライズド・ビュー全体が置き換えられるためです)。
更新可能マテリアライズド・ビューとマスターとの間に競合がある場合は、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのマテリアライズド・ビュー・ログには存在しないエントリが、リフレッシュ中に更新可能マテリアライズド・ビュー・ログに残ることがあります。この場合は、更新可能マテリアライズド・ビュー・ログを使用してマテリアライズド・ビューの行が削除または上書きされます。
更新可能マテリアライズド・ビュー・ログは、次のように、書込み可能マテリアライズド・ビューの高速リフレッシュにも使用されます。
ユーザーが、リモート・マスターを持つ書込み可能マテリアライズド・ビューに行を挿入します。このビューは書込み可能であり更新可能ではないため、このトランザクションはマテリアライズド・ビュー・サイトの遅延トランザクション・キューには格納されません。
この挿入に関する情報が、更新可能マテリアライズド・ビュー・ログにロギングされます。
ユーザーがマテリアライズド・ビューを高速リフレッシュします。
更新可能マテリアライズド・ビュー・ログの情報を使用して、挿入された行が削除されます。高速リフレッシュの完了後、マテリアライズド・ビューはマスターと同一である必要があります。このため、挿入された行を削除する必要があります。
前項で説明されているメカニズムに加えて、マテリアライズド・ビュー・サイトのマテリアライズド・ビューを編成するメカニズムが他にもいくつかあります。このメカニズムによって、マテリアライズド・ビュー・サイトと、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイト間の編成上の整合性、およびターゲット・レプリケーション・グループとのトランザクション(読取り)一貫性が保たれます。これらのメカニズムは、マテリアライズド・ビュー・グループとリフレッシュ・グループです。
レプリケーション・システム内のマテリアライズド・ビュー・グループは、ターゲット・レプリケーション・グループにあるオブジェクトの一部または完全なコピーをマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでメンテナンスします。マテリアライズド・ビュー・グループは、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのレプリケーション・グループの境界を超えられません。図3-12は、マスター・サイトのグループAおよびグループBと、マテリアライズド・ビュー・サイトのグループAおよびグループBとの相関関係を示します。
マテリアライズド・ビュー・サイトのグループA(図3-12を参照)には、マスター・サイトの対応するグループAにあるオブジェクトの一部しか含まれていません。マテリアライズド・ビュー・サイトのグループBには、マスター・サイトのグループBのオブジェクトがすべて含まれています。しかし、マテリアライズド・ビュー・サイトのグループBにマスター・サイトのグループAのオブジェクトが含まれることはありません。図3-12に示されているように、マテリアライズド・ビュー・グループの名前は、その基になるマスター・グループと同じ名前になります。たとえば、personnelマスター・グループに基づいたマテリアライズド・ビュー・グループは、personnelという名前です。
マテリアライズド・ビュー・グループは、マテリアライズド・ビュー・サイトとマスター・サイトまたはマスター・マテリアライズド・ビュー・サイト間の編成上の整合性を維持するという目的のみでなく、更新可能マテリアライズド・ビューのサポートでも必要になります。マテリアライズド・ビューがマテリアライズド・ビュー・グループに属していない場合は、読取り専用または書込み可能マテリアライズド・ビューです。
マテリアライズド・ビューのグループ所有者により、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトの単一のレプリケーション・グループに基づいた複数のマテリアライズド・ビュー・グループが使用可能になります。たとえば、マテリアライズド・ビュー・サイトと同じデータベース内で複数のユーザーをサポートするには、1つのターゲット・マスター・グループに複数のマテリアライズド・ビュー・グループを作成できます。複数のマテリアライズド・ビュー・グループを作成すると、各マテリアライズド・ビュー・グループのマテリアライズド・ビュー定義に異なる副問合せを定義でき、各ユーザーは自分用のデータのサブセットのみにアクセスできます。
複数のマテリアライズド・ビュー・グループを定義すると、データ・セットをグループ・レベルで制御できるようになります。たとえば、これらの部門に対してhr、personnelおよびmanufacturingという異なるマテリアライズド・ビュー・グループを作成した場合、各部門を個々のオブジェクトとしてではなく、グループとして管理できます。たとえば、オブジェクトをグループとして削除できます。
マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトの単一のレプリケーション・グループに基づいた複数のマテリアライズド・ビュー・グループを同一マテリアライズド・ビュー・サイトで使用できるようにするには、マテリアライズド・ビュー・グループを定義するときにグループ所有者を追加識別子として指定します。
グループ所有者を指定してマテリアライズド・ビュー・グループを定義した後、同じグループ所有者を定義してマテリアライズド・ビュー・オブジェクトをターゲット・マテリアライズド・ビュー・グループに追加します。グループ所有者を使用する場合は、各マテリアライズド・ビュー・オブジェクトが一意の名前を持つ必要があります。1つのマテリアライズド・ビュー・サイトに、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトの同一レプリケーション・グループに基づいたマテリアライズド・ビュー・グループが複数ある場合は、マテリアライズド・ビュー・グループのオブジェクト名に、別のマテリアライズド・ビュー・グループのマテリアライズド・ビュー・オブジェクトと同じ名前を使用することはできません。名前の競合を避けるには、オブジェクト名の最後にグループ所有者を追加します。たとえば、hrとacというグループ所有者がいる場合は、employeesマテリアライズド・ビュー・オブジェクトには、それぞれemployees_hrおよびemployees_acという名前を付けます。
また、1つのマテリアライズド・ビュー・サイトの同じレプリケーション・グループに基づいたマテリアライズド・ビュー・グループはすべて、同じマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトを指す必要があります。たとえば、hrとpersonnelにより所有されるグループが同一マテリアライズド・ビュー・サイトにあると想定して、hrにより所有されているhr_repgマテリアライズド・ビュー・グループがorc1.example.comマスター・サイトの対応するマスター・グループに基づいている場合、personnelにより所有されているhr_repgマテリアライズド・ビュー・グループも、orc1.example.comの対応するマスター・グループに基づいている必要があります。
|
関連項目: レプリケーション・マネージメントAPIを使用したグループ所有者の定義方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。 |
複数のマテリアライズド・ビュー間の参照整合性およびトランザクション(読取り)一貫性を保つために、Oracle Databaseでは、個々のマテリアライズド・ビューをリフレッシュ・グループの一部としてリフレッシュできます。リフレッシュ・グループ内のすべてのマテリアライズド・ビューのリフレッシュが終了すると、グループ内のすべてのマテリアライズド・ビューのデータはトランザクションの一貫性を保つ特定の時点のデータに対応します。
図3-13に示すように、リフレッシュ・グループには複数のマテリアライズド・ビュー・グループのマテリアライズド・ビューを含めることができるため、レプリケーション・グループ境界にまたがってトランザクション(読取り)一貫性を保つことができます。
マテリアライズド・ビュー・グループごとに1つのリフレッシュ・グループを定義するよりも、複数のマテリアライズド・ビュー・グループのオブジェクトを含む1つの大きなリフレッシュ・グループを使用する方が効率的な場合があります。このように構成すると、マテリアライズド・ビューのリフレッシュに必要なオーバーヘッドの量が削減されます。リフレッシュ・グループには、マテリアライズド・ビューを最大400個まで含められます。
1つのマテリアライズド・ビュー・グループの内容をリフレッシュするために複数のリフレッシュ・グループを使用する構成は避けてください。複数のリフレッシュ・グループを使用して1つのマテリアライズド・ビュー・グループの内容をリフレッシュすると、マテリアライズド・ビュー・データの整合性が失われる原因となり、マテリアライズド・ビュー・サイトで参照整合性の問題が発生することがあります。このような構成は、データベース環境について十分な知識があり、参照整合性の問題の発生を回避できる場合にのみ使用してください。
リフレッシュ・グループのサイズを決定するときは、サイズの違いによるメリットとデメリットの両方を考慮する必要があります。Oracleは、大規模リフレッシュ・グループに対応できるように最適化されています。したがって、大規模リフレッシュ・グループと小規模リフレッシュ・グループを比較した場合、グループ内のマテリアライズド・ビューが類似していると想定すると、大規模リフレッシュ・グループの方が同じ数のマテリアライズド・ビューを高速にリフレッシュできます。たとえば、マテリアライズド・ビューを20ずつ含む5つのリフレッシュ・グループよりも、100のマテリアライズド・ビューを含む1つのリフレッシュ・グループの方が高速にリフレッシュできます。また、大規模リフレッシュ・グループを使用すると、1回のレプリケーション・マネージメントAPIコールで、より多くのマテリアライズド・ビューをリフレッシュできます。
リフレッシュ・グループのリフレッシュ時に、グループ内の各マテリアライズド・ビューは、マテリアライズド・ビュー・サイトでグループ内のすべてのマテリアライズド・ビューのリフレッシュが終了するまでロックされます。リフレッシュ操作中にユーザーがマテリアライズド・ビューを更新するとデータの整合性が損なわれる可能性があるので、これを回避するためにマテリアライズド・ビューのロックは必須です。したがって、リフレッシュ・グループの規模が小さいということは、リフレッシュ実行時のマテリアライズド・ビューのロック時間が短くなることを意味します。
リフレッシュの実行時は、ネットワーク接続を維持する必要があります。リフレッシュ実行時にネットワーク接続が切断または妨害されると、データベースの整合性を保つためにすべての変更がロールバックされます。したがって、ネットワーク接続を維持することが困難な場合は、リフレッシュ・グループの規模を小さくします。
アドバンスト・レプリケーションでは、NULLリフレッシュの最適化が行われます。つまり、特定のマテリアライズド・ビューの最後のリフレッシュ以降にマスター表またはマスター・マテリアライズド・ビューが変更されなかった場合、このマテリアライズド・ビューに対してマテリアライズド・ビュー・グループのリフレッシュ時に余分な時間はほとんどかかりません。
表3-3に、大規模リフレッシュ・グループと小規模リフレッシュ・グループの利点をまとめます。
マテリアライズド・ビューのデータは、そのマスター表またはマスター・マテリアライズド・ビューの現行のデータと常に一致しているとはかぎりません。マテリアライズド・ビューは、ある一時点(作成時またはリフレッシュ時)に存在していたデータとして、トランザクション(読取り)一貫性を保ってマスターを反映したものです。マテリアライズド・ビューのデータをマスターのデータとほぼ一致させるには、マテリアライズド・ビューを定期的にリフレッシュする必要があります。マテリアライズド・ビュー・リフレッシュは、より新しい状態のマスター表またはマスター・マテリアライズド・ビューをマテリアライズド・ビューに反映させる効果的なバッチ操作です。
更新可能マテリアライズド・ビューのリフレッシュでは、まず、マテリアライズド・ビュー・サイトの遅延トランザクションがマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトにプッシュされます。次に、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのデータがプルされ、マテリアライズド・ビューに適用されます。
マスター表の1行は、マテリアライズド・ビューのリフレッシュとリフレッシュの間に何度も更新される場合がありますが、リフレッシュでは、その行はマテリアライズド・ビュー内で現行のデータを使用して1回のみ更新されます。たとえば、マテリアライズド・ビューの前回のリフレッシュ以降に、マスター表の1行が10回更新されても、次回のリフレッシュではマテリアライズド・ビュー内の対応する行は1度のみ更新されます。
より新しいマスター・データを反映するために、各マテリアライズド・ビューのリフレッシュ間隔およびリフレッシュ方法を決定します。たとえば、アプリケーションで頻繁に更新されるマスター表に基づいたマテリアライズド・ビューは、頻繁にリフレッシュする必要があります。これに対して、比較的静的なマスターに基づいたマテリアライズド・ビューは、あまり頻繁にリフレッシュする必要はありません。つまり、アプリケーションの特性および要件を分析して、マテリアライズド・ビューの適切なリフレッシュ間隔を判断します。
マテリアライズド・ビューのリフレッシュには、いくつかのリフレッシュ・タイプとリフレッシュ開始方法がサポートされています。
マテリアライズド・ビューをリフレッシュするには、高速リフレッシュ、完全リフレッシュまたは強制リフレッシュのいずれかを使用できます。
マテリアライズド・ビューの完全リフレッシュを実行するには、マテリアライズド・ビューを管理するサーバーがマテリアライズド・ビューの定義問合せを実行します(これは基本的に、マテリアライズド・ビューを再作成する処理です)。マテリアライズド・ビューをリフレッシュするために、問合せの結果セットが現在のマテリアライズド・ビュー・データを置き換えます。完全リフレッシュはあらゆるマテリアライズド・ビューで実行できます。定義問合せを満たすデータの量によっては、完全リフレッシュの実行に高速リフレッシュの場合よりもかなり長い時間がかかる場合があります。
マスター・マテリアライズド・ビューの完全リフレッシュを実行した場合、それ以降にこのマスター・マテリアライズド・ビューに基づいたマテリアライズド・ビューに対して実行するリフレッシュは、完全リフレッシュにする必要があります。マスター・マテリアライズド・ビューが完全リフレッシュを実行した後でこのようなマテリアライズド・ビューに高速リフレッシュを実行しようとすると、次のエラーが戻されます。
ORA-12034 mview log is younger than last refresh
高速リフレッシュを実行するには、マテリアライズド・ビューを管理しているマスターが、マテリアライズド・ビューの最新リフレッシュ後にマスターに加えられた変更を識別し、その変更内容をマテリアライズド・ビューに適用します。高速リフレッシュは、関係する各サーバーおよびネットワークでレプリケートするデータが少なくて済むため、マスターに加えられた変更が少ないときは完全リフレッシュよりも効率的です。
マテリアライズド・ビューの高速リフレッシュは、マスター表またはマスター・マテリアライズド・ビューにマテリアライズド・ビュー・ログがある場合にのみ可能です。また、高速リフレッシュを完全リフレッシュより高速にするには、CREATE MATERIALIZED VIEW文の各結合列に対して索引が必要です。
SQL*Loaderを使用してマスター表またはマスター・マテリアライズド・ビューでダイレクト・パス・ロードを行うと、それ以後は高速リフレッシュを実行してもダイレクト・パス・ロード中に発生した変更は適用されません。また、マスターに対してその他のバルク・ロード操作を行った結果加えられた変更も適用されません。このような操作の例としては、APPENDヒントを指定したINSERT文と、INSERT ... SELECT * FROM文などがあります。
パーティション化されたマスター表に基づくマテリアライズド・ビューがある場合、パーティション・チェンジ・トラッキング(PCT)を使用して、特定のパーティションに対応しているマテリアライズド・ビューの行を識別できます。また、PCTは、マテリアライズド・ビューのマスター表のパーティション・メンテナンス操作後、高速リフレッシュをサポートするために使用されます。マテリアライズド・ビューでのPCTに基づくリフレッシュは、様々な条件が満たされた場合のみ可能になります。
|
関連項目: PCTおよびPCTに基づいたリフレッシュの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。 |
更新可能な多重化マテリアライズド・ビューがある場合、多重化マテリアライズド・ビューに対して加えられたDML変更はこのマテリアライズド・ビューに複数回取り出され、マテリアライズド・ビューがリフレッシュされるたびにデータ整合性が保たれます。次に、この動作をわかりやすく説明します。
次のような特性を持つレプリケーション環境の例について考えます。
マスター・サイトorc1.example.comにoe.customers表があります。
レベル1のマテリアライズド・ビュー・サイトca.usに、orc1.example.comのoe.customers表に基づいたoe.customers_region更新可能マテリアライズド・ビューがあります。
レベル2の更新可能マテリアライズド・ビュー・サイトsf.caに、ca.usのoe.customers_regionマテリアライズド・ビューに基づいたoe.customers_sf更新可能マテリアライズド・ビューがあります。
前述の内容を前提として、次のような使用例が考えられます。
sf.caのoe.customers_sf更新可能マテリアライズド・ビューで、顧客のcredit_limitが3000から5000に変更されました。
この変更が、sf.caの遅延トランザクション・キューに入れられます。
レベル2のマテリアライズド・ビューoe.customers_sfの高速リフレッシュにより、credit_limitの新しい値がca.usのoe.customers_regionマテリアライズド・ビューにプッシュされます。
この変更が、ca.usのoe.customers_regionマテリアライズド・ビューに適用されます。
ca.usサイトでのcredit_limitに対する更新が、レベル1のマテリアライズド・ビュー・サイトの遅延トランザクション・キューとマテリアライズド・ビュー・ログの両方に記録されます。
レベル2のマテリアライズド・ビューoe.customers_sfの高速リフレッシュにより、このsf.caのマテリアライズド・ビューにcredit_limitの5000という値がプルされます。
レベル1のマテリアライズド・ビューoe.customers_regionの高速リフレッシュにより、credit_limitの新しい値がorc1.example.comのoe.customersマスター表にプッシュされます。
この変更が、orc1.example.comのoe.customersマスター表に適用されます。
orc1.example.comサイトでのcredit_limitに対する更新が、このマスター・サイトの遅延トランザクション・キューとマテリアライズド・ビュー・ログの両方に記録されます。
レベル1のマテリアライズド・ビューoe.customers_regionが新しく高速リフレッシュされ、ca.usのこのマテリアライズド・ビューにcredit_limitの5000という値がプルされます。
ca.usサイトでのcredit_limitに対する更新が、このレベル1のマテリアライズド・ビュー・サイトのマテリアライズド・ビュー・ログに記録されます。
レベル2のマテリアライズド・ビューoe.customers_sfの高速リフレッシュにより、このsf.caのマテリアライズド・ビューにcredit_limitの5000という値が再度プルされます。
管理者は、リフレッシュ・グループを作成するときに、スケジュールした間隔でマテリアライズド・ビューを自動的にリフレッシュするようにグループを構成できます。逆に、リフレッシュ・グループを手動または必要に応じてリフレッシュするように、スケジュール情報を省略することもできます。ダイアルアップ・ネットワーク接続を使用してリフレッシュを実行する場合は、手動リフレッシュが理想的なソリューションになります。
自動リフレッシュのためのリフレッシュ・グループを作成するには、作成プロセスで、スケジュールしたリフレッシュ間隔をグループに指定する必要があります。グループのリフレッシュ間隔を設定するときは、次の特性を考慮してください。
リフレッシュ間隔を指定する日付または日付式の値は、将来の特定の時点である必要があります。
リフレッシュ間隔は、リフレッシュの実行に必要な時間よりも長くする必要があります。
相対日付式の値は、最新のリフレッシュ日付から計算される特定の時点である必要があります。ネットワークまたはシステムの障害により、グループのリフレッシュがスケジュールどおりに実行されない場合、相対日付式の結果は状況に応じて変更されることがあります。
明示的日付式の値は、最新のリフレッシュ日付に関係なく特定の時点である必要があります。
古いデータに対する環境の許容度を考慮してください。許容度が低い場合はリフレッシュ間隔を小さくし、許容度が高い場合はリフレッシュ間隔を大きくします。
リフレッシュ間隔の指定に使用できる単純な日付式の例を、次に示します。
1時間間隔の指定:
SYSDATE + 1/24
7日間隔の指定:
SYSDATE + 7
|
関連項目: 日付算術の詳細は、『Oracle Database管理者ガイド』および『Oracle Database SQL言語リファレンス』を参照してください。 |
環境や状況によっては、スケジュールしたマテリアライズド・ビュー・リフレッシュの実行が適切でない場合もあります。たとえば、マスター表にバルク・データをロードした直後は、依存マテリアライズド・ビューにマスター表のデータは反映されていません。次に実行予定の自動グループ・リフレッシュを待たずに、対応付けられたマテリアライズド・ビューにマスター表の新規行をすぐに伝播するために、依存マテリアライズド・ビュー・グループを手動でリフレッシュすることもできます。
マテリアライズド・ビューが非接続環境のラップトップの営業支援システムと統合されている場合は、マテリアライズド・ビューを必要に応じてリフレッシュすることもできます。営業支援ソフトウェアを設計する開発者がアプリケーション・コントロール(ボタンなど)を作成し、営業担当員は、1日の受注をサーバーに転送するときに、ダイアルアップ・ネットワーク接続を確立し、アプリケーション・コントロールを使用してマテリアライズド・ビューをリフレッシュできます。
hr_refgリフレッシュ・グループを必要に応じてリフレッシュする例を次に示します。
EXECUTE DBMS_REFRESH.REFRESH('hr_refg');
