| Oracle® Databaseアドバンスト・レプリケーション 12c リリース1 (12.1) E52978-02 |
|
 前 |
 次 |
この章では、デプロイメント・テンプレートの概要と、デプロイメント・テンプレートを使用して簡単かつ効率的にマテリアライズド・ビュー・サイトを配布する方法について説明します。
この章には、次の項が含まれます。
|
注意: デプロイメント・テンプレートを作成する前に、第3章「マテリアライズド・ビューの概要とアーキテクチャ」を読んでください。マテリアライズド・ビューについての理解は、デプロイメント・テンプレートを作成する際に役立ちます。 |
Oracleデプロイメント・テンプレートは、広範囲に分散したマテリアライズド・ビュー環境を効率的にデプロイし、管理するためのツールです。デプロイメント・テンプレートの概念、アーキテクチャおよび使用方法について説明する前に、大規模デプロイメントの環境の課題について検討します。
時と場所を問わず正確な情報を入手する必要性は、ますます強くなっています。また、情報は分散し、ユーザーもネットワークに接続されていない環境にいることが多く、実際に利用する場所に情報を配布する必要があります。
たとえば、モバイル端末を使用する営業担当員の場合を考えます。正確な顧客情報をラップトップ上で自由自在に参照したいと考えている営業担当員の数は、数百名あるいは数千名にも及ぶ可能性があります。これに応えるため、データベース管理者は、データおよびデータベース・インフラストラクチャ(表、索引、制約、トリガーなど)を適切なタイミングで効率よくすべてのサイトに提供する必要があります。
これまでDBAは、独自のデプロイ方法を開発する必要がありました。一般に、DBAは、リモート・マテリアライズド・ビュー・サイトにマテリアライズド・ビュー環境を作成するための非常に複雑なスクリプトを作成する必要がありました。さらに、それに加えて、DBAはデータ・セットをマテリアライズド・ビュー・サイトでカスタマイズすることが必要な場合もありました。スクリプトを作成した後も、スクリプトをデプロイするために手動でパッケージ化し、実装する必要があり、多くの場合その両方に多大なトラブルシューティングが必要でした。
このような問題点をもとに、効率的な大規模デプロイメントを行うための新しいテクノロジとリソースが生まれました。大規模デプロイメントとは、データベース・インフラストラクチャ、データおよびフロントエンド・アプリケーションを多数のユーザーに配布するプロセスのことです。アドバンスト・レプリケーションでは、大規模デプロイメントという用語はデータおよびデータ・インフラストラクチャの配布のみを指します。
大規模デプロイメントのツールおよびテクノロジは、データおよびデータベース・インフラストラクチャを配布するデータベース管理者を支援する必要があります。デプロイメント・テンプレートの目標は、一度定義した環境をもとに必要な数のデプロイメント・テンプレートのインスタンスを作成し、個々のサイトでカスタマイズを行えるようにすることです。
この目標を実現するために、Oracleのデプロイメント・テンプレートでは次のことが可能です。
1回のマテリアライズド・ビュー環境の定義
デプロイメント・テンプレートを使用してマテリアライズド・ビュー環境の構造を1回定義することにより、各ユーザー(サイト)がフロントエンド・アプリケーションをサポートするデータベース・インフラストラクチャを利用できるようにします。
個別のマテリアライズド・ビュー・サイトのカスタマイズ
デプロイメント・テンプレートのパラメータを使用して各マテリアライズド・ビュー環境をカスタマイズし、各ユーザーが必要な特定のデータ・サブセットを受信できるようにします。
大規模デプロイメントには、モバイル端末を使用する営業担当員やサービス技術員、小売店、リモートの在庫保管サイトなどへの情報の配布といった様々な用途があります。このような環境では、デプロイメント・テンプレートを使用してリモート・サイトにデータベース・インフラストラクチャを作成しますが、これは主に、デプロイメント・テンプレートがデータのサブセット化、非接続環境でのレプリケーション、および少ないリソース要件をサポートしているからです(これはラップトップ・ユーザーに最適です)。
データベース管理者は、Oracleから提供されているデプロイメント・テンプレートを使用して、マテリアライズド・ビュー環境をパッケージ化し、安全性の高いカスタム・デプロイを簡単に実行できます。デプロイメント・テンプレートのパッケージ化とは、デプロイメント・テンプレートにより作成されるマテリアライズド・ビュー環境を定義するプロセスです。デプロイメント・テンプレートのパッケージ化により、テンプレートをリモート・マテリアライズド・ビュー・サイトでインスタンス化する準備が整います。インスタンス化によって、マテリアライズド・ビュー・サイトのオブジェクトが作成され、マテリアライズド・ビューにデータが移入されます。
デプロイメント・テンプレートには、固定データ・セットを使用する1つのマテリアライズド・ビューのみを含む単純なものも、1つ以上の変数に基づく動的データ・セットを使用する数百のマテリアライズド・ビューを含む複雑なものもあります。デプロイメント・テンプレートには、次の機能があります。
集中制御
マテリアライズド・ビュー環境を繰り返しデプロイする機能
リモート・サイトでのデータのサブセット化およびカスタマイズを可能にする、テンプレート・パラメータ
テンプレートのインスタンス化およびデータ・アクセスを制御する、認証ユーザー・リスト
マテリアライズド・ビュー環境をデプロイするには、その前にマスター・サイトにデプロイメント・テンプレートを作成します。このテンプレートには、リモート・サイトのオブジェクトやターゲット・リフレッシュ・グループを作成するデータ定義言語(DDL)など、マテリアライズド・ビュー環境をデプロイするために必要なすべての情報を格納します。また、このテンプレートには、ユーザーのセキュリティ情報へのリンクや、カスタム・マテリアライズド・ビュー作成のためのテンプレート・パラメータも格納します。
この項には、次の項目が含まれます。
各デプロイメント・テンプレートには、マテリアライズド・ビュー・サイトに必要なマテリアライズド・ビューおよびそれに関連するオブジェクトを作成するための設計図を含めます。具体的には、デプロイメント・テンプレートをマスター・サイトに作成し、マテリアライズド・ビュー環境を作成するために必要なマテリアライズド・ビュー、トリガー、ビューなどをこのデプロイメント・テンプレートに追加します。また、オプションでテンプレート・パラメータや認証ユーザーを定義して、インスタンス化プロセス実行時の柔軟性や安全性を大幅に向上させることもできます。
デプロイメント・テンプレートの要素は、次の4つのカテゴリに分類できます。
テンプレート名、ターゲット・リフレッシュ・グループ、およびプライベートまたはパブリックの状態から構成されるテンプレート一般情報は、Oracleデプロイメント・テンプレートで使用される情報です。図4-1に示すように、REFRESH_TEMPLATE_NAMEは、デプロイメント・テンプレートのデータ・ディクショナリ・ビューのどの場面でも使用します。マテリアライズド・ビュー環境のオブジェクトをテンプレートに追加し、その後、指定されたテンプレートの識別に応じて配布するテンプレートをリリースします(図4-2を参照してください)。
デプロイメント・テンプレートは、1つのマスター・サイトで定義します。マスター・サイトに同じ名前のデプロイメント・テンプレートを2つ定義することはできませんが、デプロイメント・テンプレートを同じ名前で他のサイトにコピーすることはできます。
デプロイメント・テンプレートを定義した後で、テンプレートにオブジェクトを追加します。テンプレートがマテリアライズド・ビュー・サイトでインスタンス化されると、オブジェクトDDL(CREATE MATERIALIZED VIEW、CREATE TABLEなど)が実行され、適切なオブジェクトがマテリアライズド・ビュー・サイトに作成されます。
デプロイメント・テンプレートには既存のマスター・オブジェクトに基づいたオブジェクトを追加できますが、必要な場合は、DDLを定義し、テンプレート・オブジェクトを作成してオブジェクトを作成することもできます。新しいオブジェクトDDLを作成した場合は、実行エラーを防ぐためにDDLが字句規則に適合しているかどうかのチェックが行われます。デプロイメント・テンプレートに追加する更新可能マテリアライズド・ビューはマスター・グループ内の表に基づいている必要がありますが、読取り専用マテリアライズド・ビューなどのその他のオブジェクトは、マスター・グループに属していないオブジェクトに基づいていてもかまいません。
通常、テンプレートにはマテリアライズド・ビューを追加しますが、必要な場合はその他のオブジェクトも追加できます。たとえば、マテリアライズド・ビュー・サイトでのデータ整合性を規定するための制約、データ表示のためのビュー、ローカルなデータ記憶域に格納するための表などを追加できます。場合によっては、デプロイメント・テンプレートにアプリケーションのすべてのオブジェクトを含めることもできます。デプロイメント・テンプレートを使用して作成したマテリアライズド・ビューは、テンプレートに定義されたリフレッシュ・グループに自動的に追加されます。
デプロイメント・テンプレートを使用してインスタンス化できないオブジェクト型は、次のとおりです。
ユーザー定義型
ユーザー定義型の本体
ユーザー定義演算子
索引タイプ
デプロイメント・テンプレートを使用して、これらのオブジェクト型に基づいたオブジェクトをインスタンス化することもできません。
各ターゲット・マテリアライズド・ビュー・サイトで一意のデータ・セットが必要な場合は、オブジェクトDDLで変数を定義できます。変数を定義してパラメータ付きテンプレートを作成すると、テンプレートをインスタンス化するときにカスタム・データ・セットを使用できるため、マテリアライズド・ビュー・サイトごとに異なるデータ・セットを使用できます。これらのパラメータは、オブジェクトDDLに組み込まれます。テンプレートのインスタンス化時に、個別のユーザー値がパラメータに代入されます。
Oracleでは、テンプレートにデフォルト値およびユーザー固有のパラメータ値を指定できます。パラメータ値は、デプロイメント・テンプレートの作成時または作成後に指定できますが、テンプレートをインスタンス化する前に指定する必要があります。テンプレートのインスタンス化時にパラメータの値を指定することはできません。
ユーザー固有のパラメータ値を使用した場合は、指定されたユーザーがテンプレートをインスタンス化するときにそのパラメータ値が自動的に使用されます。たとえば、変数regionについて考えます。テンプレートsales_tempに対して次のようなユーザー固有のパラメータ値を指定したとします。
| ユーザー | 地域 |
|---|---|
| fay | east |
| baer | west |
この場合、マテリアライズド・ビューの定義SELECT文は次のようになります。
SELECT cust_id, sales_to_date, status FROM table_x WHERE region_id=:region;
ユーザーfayおよびbaerがテンプレートsales_tempをインスタンス化すると、作成されるマテリアライズド・ビュー・データ・セットは次のようになります。
| ユーザーfay | - | ユーザーbaer | ||
|---|---|---|---|---|
| cust_id | 地域 | - | cust_id | 地域 |
| a123 | east | - | b123 | west |
| a234 | east | - | b234 | west |
| a345 | east | - | b345 | west |
| a456 | east | - | b456 | west |
カスタマイズしたデータ・サブセットを作成する他に、CREATE MATERIALIZED VIEW文のWHERE句でテンプレート・パラメータを指定して、マテリアライズド・ビュー・サイトではWHERE句の条件を満たすデータのみを表示および変更するようにできます。たとえば、ユーザー固有のパラメータ・リストのregionパラメータに次のように指定したとします。
| ユーザー | 地域 |
|---|---|
| fay | east |
| baer | west |
ユーザーfayがインスタンス化したマテリアライズド・ビューにアクセスするユーザーは、地域eastのデータのみを参照でき、このWHERE句に適合するデータのみを表示、更新または削除できます。つまり、このマテリアライズド・ビューには地域eastのデータしか含まれていないため、このマテリアライズド・ビューのユーザーは地域westのデータを表示、更新または削除できません。
デプロイメント・テンプレートの定義が完了した後で、テンプレートをパッケージ化して、リモート・マテリアライズド・ビュー・サイトでインスタンス化できます。パッケージ化したデプロイメント・テンプレートがマテリアライズド・ビュー・サイトでインスタンス化されると、マテリアライズド・ビュー・サイト・オブジェクトが作成され、マテリアライズド・ビューにデータが移入されます。リモート・マテリアライズド・ビュー・サイトは、オンライン・インスタンシエーションまたはオフライン・インスタンシエーションのいずれかを使用して作成できます。
オンライン・インスタンシエーションでは、マテリアライズド・ビュー・サイトはターゲット・マスター・サイトに接続した状態でデプロイメント・テンプレートをインスタンス化できます。オンライン・インスタンシエーション・プロセスでは、マテリアライズド・ビュー・サイトの構造が作成され、指定したデータ・サブセットがマスター・サイトから取り出されて適切なマテリアライズド・ビューに格納されます。
オンライン・インスタンシエーション用のデプロイメント・テンプレートのパッケージ化は、スクリプト・ファイルの生成を意味し、このスクリプト・ファイルがマテリアライズド・ビュー・サイトで実行されると、マテリアライズド・ビュー・オブジェクトが作成された後にマスター・サイトに接続され、マテリアライズド・ビューにデータが移入されます。マスター・サイトからネットワーク経由でマテリアライズド・ビューにデータを移入するには、CREATE MATERIALIZED VIEW ... AS SELECTなどのSQL文を使用します。
オンライン・インスタンシエーションのメリットの1つは、データ・サブセットがインスタンス化プロセス実行時点の最新の状態である点です。ただし、これにはデメリットもあります。オンライン・インスタンシエーションの実行中はマテリアライズド・ビュー・サイトとマスター・サイトが接続されている必要があるため、作成するマテリアライズド・ビュー環境のサイズによっては、ネットワークの通信量が増大する可能性があります。
また、モデム接続を使用しているラップトップ・ユーザーは、接続時間が長くなることがあります。接続時間は、作成されるオブジェクトの数、マテリアライズド・ビューの副問合せの複雑さ、送信されるデータの量によって変わり、低帯域幅のモデムで接続している場合、これらの要素による影響は特に大きくなります。
ピーク使用期間中のサーバー負荷を小さくし、リモートの接続時間を短縮するには、使用環境のテンプレートのオフライン・インスタンシエーションを選択します。オフライン・インスタンシエーション用のテンプレートのパッケージ化は、DDLおよびデータ操作言語(DML)を含むスクリプトまたはバイナリ・ファイルの生成を意味し、このスクリプトまたはバイナリ・ファイルによって、デプロイメント・テンプレートに定義したマテリアライズド・ビュー環境が作成され、データが移入されます。スクリプトまたはバイナリ・ファイルをパッケージ化してストレージ・メディア(テープ、CD-ROMなど)に保存し、マテリアライズド・ビュー・サイトに転送する方法を提供します。各マテリアライズド・ビュー・サイトで、それぞれのオフライン・インスタンシエーション・スクリプトが必要です。
インスタンス化用のテンプレートをパッケージ化すると、マテリアライズド・ビューの基になっているテンプレートの各マスター表のマテリアライズド・ビュー・ログに対して、変更のロギングが開始されます。特定のマスター表のマテリアライズド・ビュー・ログに記録された変更内容は、マスター表に基づくすべてのマテリアライズド・ビューがインスタンス化後にリフレッシュされるまで消去されません。したがって、テンプレートをパッケージ化した後で、テンプレートのインスタンス化とマテリアライズド・ビューのリフレッシュをできるだけ早く実行して、マテリアライズド・ビュー・ログが大きくなりすぎないようにする必要があります。
インスタンス化時は、テンプレートとデータがマスター・サイトではなくストレージ・メディアからプルされます。この操作により、ネットワークの通信量を軽減でき、ネットワークに常時接続する必要がなくなります。ただし、インスタンス化後は、マテリアライズド・ビュー・サイトにはパッケージ化した時点のマスター・サイトのデータが反映されているので、リフレッシュによって更新する必要があります。
オフライン・インスタンシエーションは、多数のラップトップやその他の非接続環境のコンピュータでターゲット・テンプレートをインスタンス化する大規模デプロイメントに最適なソリューションです。
表4-1に、デプロイメント・テンプレートのインスタンス化の使用例の概要を示します。
表4-1 デプロイメント・テンプレートのインスタンス化の使用例
| インスタンス化のタイプ | 説明 |
|---|---|
|
オフライン |
ユーザーは、SQL*Plusを使用してオフライン・インスタンシエーション・スクリプトを実行します。オフライン・インスタンシエーション・スクリプトには、マテリアライズド・ビュー・サイトのオブジェクトを作成する |
|
オンライン |
ユーザーは、SQL*Plusを使用してオンライン・インスタンシエーション・スクリプトを実行します。オンライン・インスタンシエーション・スクリプトには、マテリアライズド・ビュー・サイトのオブジェクトを作成する |
DBAまたはターゲット・ユーザーのいずれかが、デプロイメント・テンプレートをパッケージ化できます。デプロイメント・テンプレートをパッケージ化するには、アドバンスト・レプリケーション・インタフェースの「配置テンプレートの作成」ウィザード(オフライン・インスタンシエーションの場合)またはレプリケーション・マネージメントAPI(オフラインまたはオンライン・インスタンシエーションの場合)を使用します。デプロイメント・テンプレートをパッケージ化するには、エンド・ユーザーはパブリックAPIを使用し、DBAは一般的にプライベートAPIを使用します。
通常、デプロイメント・テンプレートをオフラインでインスタンス化する場合はDBAがパッケージ化を実行しますが、デプロイメント・テンプレートをオンラインでインスタンス化する場合はユーザーがパッケージ化を実行する可能性があります。ただし、ユーザーまたはDBAにとっては使用するAPIコールが異なること以外に制約はなく、どちらもオンラインまたはオフラインによるパッケージ化を実行できます。
デプロイメント・テンプレートをパッケージ化するには、次のレプリケーション・マネージメントAPIのファンクションを使用できます。
プライベート・ファンクション(DBAのみ使用):
DBMS_REPCAT_RGT.INSTANTIATE_OFFLINEファンクション
DBMS_REPCAT_RGT.INSTANTIATE_ONLINEファンクション
パブリック・ファンクション:
DBMS_REPCAT_INSTANTIATE.INSTANTIATE_OFFLINEファンクション
DBMS_REPCAT_INSTANTIATE.INSTANTIATE_ONLINEファンクション
|
関連項目: 「デプロイメント・テンプレートをインスタンス化するマテリアライズド・ビュー・サイトの準備」を参照してください。ファンクションの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。 |
Oracleでは、マテリアライズド・ビュー環境を迅速かつ効率的に配布するために、デプロイメント・テンプレートに標準マテリアライズド・ビュー・アーキテクチャを使用しています。デプロイメント・テンプレートでは、マテリアライズド・ビュー定義の作成、リフレッシュ特性、競合解消およびグループ化に、マテリアライズド・ビュー環境を手動で作成する場合と同じ方法を使用します。ただし、デプロイメント・テンプレートではDDLを実行してオブジェクトを即時に作成するのではなく、テンプレートをインスタンス化するときに、デプロイメント・テンプレートに含まれるオブジェクトDDLが実行される点が異なります。
この項には、次の項目が含まれます。
デプロイメント・テンプレートでは、マテリアライズド・ビュー・サイトでDDLを実行してマテリアライズド・ビュー環境を即時に作成するのではなく、マテリアライズド・ビューおよび関連するオブジェクト定義がデプロイメント・テンプレートに格納されます。すべてのオブジェクト定義をデプロイメント・テンプレートに追加した後、テンプレートをインスタンス化すると、格納されているすべてのDDLがリモート・マテリアライズド・ビュー・サイトで実行され、必要なマテリアライズド・ビュー環境が作成されます。
これらのオブジェクト定義はすべて、デプロイメント・テンプレートの定義サイトにあるシステム表に、デプロイメント・テンプレート名をキーにして格納されます。デプロイメント・テンプレートをパッケージ化すると、格納されているオブジェクトDDLがシステム表からプルされ、バイナリ・ファイルのインスタンス化スクリプトが作成されます。
テンプレートのオブジェクト定義は、マテリアライズド・ビュー・サイトでローカルにオブジェクトを作成する場合と同じDDLを使用して作成されます。たとえば、次の文を発行するとマテリアライズド・ビューが作成されます。
CREATE MATERIALIZED VIEW hr.departments_mv
REFRESH FAST WITH PRIMARY KEY FOR UPDATE AS SELECT
department_id, department_name, manager_id, location_id
FROM hr.departments@orc1.example.com;
これと同じマテリアライズド・ビューをデプロイメント・テンプレートに追加するには、アドバンスト・レプリケーション・インタフェースの「配置テンプレートの作成」ウィザードを使用するか、次の例に示すようにCREATE_TEMPLATE_OBJECTファンクションを使用します。
DECLARE
tempstring VARCHAR2(3000);
a NUMBER;
BEGIN
tempstring := 'CREATE MATERIALIZED VIEW hr.departments_mv
REFRESH FAST WITH PRIMARY KEY FOR UPDATE AS SELECT
department_id, department_name, manager_id, location_id
FROM hr.departments@orc1.example.com';
a := DBMS_REPCAT_RGT.CREATE_TEMPLATE_OBJECT (
refresh_template_name => 'hr_refg_dt',
object_name => 'departments_mv',
object_type => 'MATERIALIZED VIEW',
ddl_text => tempstring,
master_rollback_seg => 'rbs');
END;
/
|
注意: ddl_textパラメータの一重引用符で囲まれたDDL文の末尾には、セミコロンを付けないでください。 |
このファンクションを実行すると、dt_mviewenvという名前のデプロイメント・テンプレートにマテリアライズド・ビュー定義が追加されます。このマテリアライズド・ビューがインスタンス化されると、マテリアライズド・ビューmview_testが作成されます。マテリアライズド・ビューを作成するのみでなく、表、トリガー、プロシージャ、索引およびその他のオブジェクト定義をデプロイメント・テンプレートに追加できます。
マテリアライズド・ビューを作成するときは、マテリアライズド・ビューの問合せで表所有者のスキーマ名を必ず指定してください。前述の例では、employees表の所有者にhrが指定されています。
|
関連項目: このファンクションの使用方法については、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』の「DBMS_REPCAT_RGT.CREATE_TEMPLATE_OBJECT」を参照してください。 |
リモート・マテリアライズド・ビュー・サイトでのインスタンス化用にデプロイメント・テンプレートをパッケージ化するときは、オンライン・インスタンシエーション用とオフライン・インスタンシエーション用のテンプレートを用意します。インスタンス化プロシージャによって、リモート・マテリアライズド・ビュー環境が作成され、その環境にデータが移入されます。
オンライン・インスタンシエーション用にデプロイメント・テンプレートをパッケージ化すると、リモート・マテリアライズド・ビュー環境の作成に必要なDDLが生成され、すべてのテンプレート・パラメータが代入されます。生成されたDDLが格納される場所は、マテリアライズド・ビュー・クライアントのタイプによって異なります。
オンライン・インスタンシエーション・スクリプトは、テンプレートをパッケージ化するレプリケーション・マネージメントAPIが実行されるコンピュータのハード・ドライブ上にローカルに格納されます。このコンピュータがマテリアライズド・ビュー・サイトのコンピュータでない場合は、オンライン・インスタンシエーション・ファイルをマテリアライズド・ビュー・サイトに転送する必要があります。
オフライン・インスタンシエーション用にデプロイメント・テンプレートをパッケージ化するときに、リモート・マテリアライズド・ビュー環境の作成に必要なDDLとマテリアライズド・ビュー環境へのデータの移入に必要なDMLを、生成したファイルに格納します。また、パッケージ化の最中に、すべてのテンプレート・パラメータの代入が実行されます。
テンプレートをパッケージ化するときに、オフライン・インスタンシエーション用のスクリプトまたはバイナリ・ファイルを作成し、ハード・ディスク、CD-ROM、テープなどのストレージ・デバイスに保存します。オフライン・インスタンシエーション用のデプロイメント・テンプレートをパッケージ化するには、アドバンスト・レプリケーション・インタフェースの「配置テンプレートの作成」ウィザードまたはレプリケーション・マネージメントAPIを使用します。
オフライン・インスタンシエーション・スクリプトは、テンプレートをパッケージ化する要求が発行されるコンピュータのハード・ドライブ上にローカルに格納されます。このコンピュータがマテリアライズド・ビュー・サイトのコンピュータでない場合は、オフライン・インスタンシエーション・ファイルをマテリアライズド・ビュー・サイトに転送する必要があります。
リモート・マテリアライズド・ビュー・サイトでテンプレートをインスタンス化するときは、ストレージ・メディアまたはローカルのハード・ドライブからスクリプトまたはバイナリ・ファイルが実行されます。これにより、マテリアライズド・ビュー環境が作成され、パッケージ作成プロセスで定義したデータ・セットが環境に移入されます。前述のように、個々のサイト用のデータ・セットを定義するテンプレート・パラメータはすべて、パッケージ作成プロセスで定義します。
オンライン・インスタンシエーション・プロセスでは、マテリアライズド・ビュー・サイトの構造が作成され、指定したデータ・サブセットがマスター・サイトから取り出されて適切なマテリアライズド・ビューに格納されます。リモート・マテリアライズド・ビュー・サイトでオンライン・インスタンシエーション・プロセスを開始すると、デプロイメント・テンプレート用に定義したパラメータが評価されます。パラメータに定義した値は、テンプレートのオブジェクトDDLを実行するときに、リモート・マテリアライズド・ビュー・サイトにカスタム・データ・セットをインストールするために使用されます。同時に、マテリアライズド・ビューがマスター・サイトに登録され、マテリアライズド・ビュー・ログにマスター表への変更のロギングが開始されます。
テンプレート・パラメータの値を定義するには、デフォルト・パラメータ値とユーザー・パラメータ値という2つの方法を使用できます。Oracleはこれらのパラメータ値が存在するかどうかをチェックし、次の順に使用します。
ユーザー・パラメータ値
デフォルト・パラメータ値
ユーザー・パラメータ値が定義してあり、リストに含まれているユーザーがテンプレートをインスタンス化する場合、テンプレートをインスタンス化するときにユーザー・パラメータ値が使用されます。ユーザー・パラメータ値を定義していない場合は、デフォルト・パラメータ値が使用されます。図4-5は、パラメータのチェック・プロセスを示します。
パラメータのチェックが終わると、テンプレートによって作成されたオブジェクトが、テンプレートの作成時に指定したリフレッシュ・グループに追加されます。
大規模デプロイメントの環境では、ほとんどのマテリアライズド・ビュー環境でオフライン・インスタンシエーションを使用して、必要なマテリアライズド・ビュー環境を作成します。デプロイメント・テンプレートをパッケージ化すると、スクリプトまたはバイナリ・ファイルが作成され、マテリアライズド・ビュー環境の作成に必要なDDL、インスタンス化プロセスで使用されるパラメータ値およびマテリアライズド・ビュー環境へのデータの移入に必要なDMLが格納されます。
スクリプトまたはバイナリ・ファイルは、CD-ROMやフロッピィ・ディスクなどのストレージ・メディアにコピーしたり、WebサイトやFTPサイトに保存してリモート・マテリアライズド・ビュー・サイトにダウンロードしたりできます。また、DBMS_FILE_TRANSFERパッケージを使用して転送することもできます。このような柔軟な配布メカニズムによって、管理者とユーザーは最も効率的な方法でデプロイメント・テンプレートをインスタンス化できます。
デプロイメント・テンプレートのパッケージ化とインスタンス化には、様々なオプションがあります。表4-2では、それらのオプションおよびパッケージ化とインスタンス化のメカニズムについて説明し、操作を実行するときに使用するドキュメントを示しています。
表4-2 パッケージ化およびインスタンス化のオプション
| インスタンス化のタイプ | テンプレートのパッケージ化に使用するもの | パッケージ化に関するドキュメント | テンプレートのインスタンス化に使用するもの | インスタンス化に関するドキュメント |
|---|---|---|---|---|
|
オフライン |
アドバンスト・レプリケーション・インタフェースの「配置テンプレートの作成」ウィザード |
アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照。 |
オフライン・インスタンシエーション・スクリプトおよびSQL*Plus |
アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照。 |
|
オフライン |
レプリケーション・マネージメントAPI(PL/SQLパッケージおよびSQL*Plus) |
『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のパッケージ化に関する説明を参照。 |
オフライン・インスタンシエーション・スクリプトおよびSQL*Plus |
『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のデプロイメント・テンプレートのインスタンス化に関する説明を参照。 |
|
オンライン |
レプリケーション・マネージメントAPI(PL/SQLパッケージおよびSQL*Plus) |
『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のパッケージ化に関する説明を参照。 |
オンライン・インスタンシエーション・スクリプトおよびSQL*Plus |
『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のデプロイメント・テンプレートのインスタンス化に関する説明を参照。 |
リモート・マテリアライズド・ビュー・サイトでデプロイメント・テンプレートのインスタンス化を実行すると、マテリアライズド・ビュー・サイトでローカルにマテリアライズド・ビュー環境を作成した場合と同じ構造が作成されます。具体的には、指定した名前でマテリアライズド・ビューが作成され、制約整合性を保つために主キーに基づいて索引が作成されます。また、テンプレートのその他のオブジェクトも、マテリアライズド・ビューで手動で作成した場合と同じように作成されます。
オフライン・インスタンシエーションの場合は、サーバーでパッケージ化してからリモート・マテリアライズド・ビュー・サイトでインスタンス化するまでの時間が長くなると、インスタンス化後の最初のリフレッシュに必要な時間も長くなります。マテリアライズド・ビュー・サイトでは、マスター・サイトのマテリアライズド・ビュー・ログを使用して、テンプレートがパッケージ化された時点以降の高速リフレッシュを実行します。前述のように、マスター表に対して行った変更は、デプロイメント・テンプレートをパッケージ化するとただちにマテリアライズド・ビュー・ログに記録されます。
インスタンス化したデプロイメント・テンプレートによって作成されたオブジェクトは、オブジェクトのマスター・グループ名と同じ名前のマテリアライズド・ビュー・グループに自動的に追加されます。たとえば、マスター・グループpersonnelおよびtechnicalのオブジェクトを含むdt_mviewenvデプロイメント・テンプレートをインスタンス化した場合、テンプレート・オブジェクトはマテリアライズド・ビュー・グループpersonnelおよびtechnicalにそれぞれ追加されます。前述のように、マテリアライズド・ビュー・グループはターゲット・マスター・グループと編成上の整合性を保つのみでなく、更新可能マテリアライズド・ビューを使用するために必要です。
最初にデプロイメント・テンプレートを作成するときは、テンプレートのマテリアライズド・ビュー・オブジェクトを追加するリフレッシュ・グループの名前を定義する必要があります。インスタンス化プロセスが完了した後で、マスター・サイトに常時ネットワーク接続している場合は、リフレッシュ・グループ内のマテリアライズド・ビューを設定した間隔で自動的にリフレッシュするように指定できます。
Oracle Enterprise Manager Cloud Controlのアドバンスト・レプリケーション・インタフェースまたはDBMS_REFRESH.CHANGEプロシージャを使用して、リフレッシュ・グループのリフレッシュ間隔と次回リフレッシュするデータを変更できます。アドバンスト・レプリケーション・インタフェースでこれらの設定を変更するには、リフレッシュ・グループを選択して、「次の日付」フィールドと「間隔」フィールドを編集します。DBMS_REFRESH.CHANGEプロシージャを使用してこれらの設定を変更する場合は、intervalパラメータとnext_dateパラメータを適切に設定します。マテリアライズド・ビュー・サイトからマスター・サイトに常時ネットワーク接続していない場合は、必要に応じてリフレッシュ・グループをリフレッシュできます。
next_dateとintervalの指定に使用できる簡単な日付式の例を、次に示します。
next_dateまたはintervalが1時間の指定:
SYSDATE + 1/24
next_dateまたはintervalが7日の指定:
SYSDATE + 7
|
関連項目: 日付算術の詳細は、『Oracle Database管理者ガイド』および『Oracle Database SQL言語リファレンス』を参照してください。 |
デプロイメント・テンプレートのパラメータと副問合せによるサブセット化を組み合せることで、データベース管理者は、副問合せと行がサブセット化されたデータを使用して広範囲に分散したデータベース環境を管理できます。列のサブセット化の要件およびレプリケーション環境に必要なデータ・セットについては、さらにいくつかの設計上の考慮事項があります。
マテリアライズド・ビュー・データ・セットはマテリアライズド・ビューの問合せに基づいて定義されます(つまり、ユーザーに表示されるのは、マテリアライズド・ビューの定義問合せに適合するデータのみです)。行および列のサブセット化により、カスタマイズ・データ・セットを含むマテリアライズド・ビューを作成できます。このようなマテリアライズド・ビューは、すべてのデータ・セットを必要としない地域事業所や営業担当員に役立ちます。
この項には、次の項目が含まれます。
列のサブセット化を使用すると、マスター表の列をマテリアライズド・ビューから除外できます。これを行うには、マテリアライズド・ビューの作成中に、SELECT文に該当する列を指定します。列のサブセット化は、デプロイメント・テンプレートを使用した場合にのみ可能です。デプロイメント・テンプレートを作成する前に、テンプレートの設計を行う必要があります。
たとえば、多くの軽量なクライアントを含む大規模デプロイメントの環境では、LOBデータ自体を実際にレプリケートするのではなく、LOBデータを含む表をレプリケートすることが必要な場合があります。これを行うには、列のサブセットを定義するときに、レプリケート対象として選択した列からLOB列を除外します。
読取り専用マテリアライズド・ビューでは列の任意のサブセットを選択できます。更新可能マテリアライズド・ビューでは、列のサブセットに次の列が含まれている必要があります。
主キー列
レプリケート列の競合解消に使用するすべての列(図4-6を参照してください)
|
注意: 列のサブセット化は列グループ内に構成することもできますが、これを行うとサイト間でデータの一貫性がなくなる可能性があるため、この方法はお薦めしません。列のサブセット化を使用する場合は、列グループ・レベルで列を除外するようにしてください。 |
列pk、empid、salaryおよびlevel(図4-6を参照)をレプリケートするマテリアライズド・ビューを追加する場合は、Time Stamp列も含める必要があります。この列は、列グループAに含まれる列の競合解消に使用されるためです。
|
注意:
|
行のサブセット化では、WHERE句を使用して、マスター表の行をマテリアライズド・ビューから除外できます。たとえば、次の文では、oe.orders@orc1.example.comマスター表に基づいたマテリアライズド・ビューが作成され、sales_rep_id番号が173の営業担当員の行のみが含まれます。
CREATE MATERIALIZED VIEW oe.orders REFRESH FAST FOR UPDATE AS SELECT * FROM oe.orders@orc1.example.com WHERE sales_rep_id = 173;
orders表でsales_rep_id番号が173以外の行は、このマテリアライズド・ビューからは除外されます。
行のサブセット化に割当て表を使用する方が役に立つ場合があります。割当て表を使用すると、データベース内のあるエンティティを別のエンティティに関連付けることができ、どちらのエンティティの表にも割当て情報を格納する必要がありません。このテクニックについて、例を使用してわかりやすく説明します。
oeスキーマでは、product_id列がproduct_information表の主キーで、warehouse_id列がwarehouses表の主キーです。このスキーマではinventories表は、product_id列およびwarehouse_id列を使用して製品を倉庫に割り当てるため、割当て表として機能します。これら2つの列は、inventories表の主キーを形成します。
oeスキーマ内のこの3つの表(inventories、product_informationおよびwarehouses)を使用すると、どの製品がどの倉庫にあるかを追跡するために、product_id情報をwarehouses表に格納する必要も、warehouse_id情報をproduct_information表に格納する必要もありません。これがいかに重要かを理解するために、inventories表が存在せず、warehouse_id列がproduct_information表の外部キーである場合の例について考えてみます。
この場合、営業担当員が最寄の倉庫の製品情報を格納するには、CREATE MATERIALIZED VIEW文のWHERE句にその倉庫のwarehouse_idを指定する必要があります。たとえば、営業担当員は、次の文を使用してマテリアライズド・ビューを作成します。
CREATE MATERIALIZED VIEW oe.product_information REFRESH FAST FOR UPDATE AS SELECT * FROM oe.product_information@orc1.example.com WHERE warehouse_id = 1;
この構成のデメリットは、warehouse_idがマテリアライズド・ビュー定義にハードコードされているということです。会社が倉庫1を閉鎖するか、この営業担当員により近い場所に新しい倉庫を開設した場合、このマテリアライズド・ビュー定義は変更または再作成する必要があります。これと比べて、副問合せでの行のサブセット化と割当て表を使用する場合は、マテリアライズド・ビュー環境に対する変更を容易に制御できます。
oeスキーマでは、warehouse_id列はproduct_information表の一部ではありません。そのかわり、製品はinventories表を介して倉庫に割り当てられます。製品と倉庫間のこの関係を図4-7に示します。
新しい倉庫が建てられたり他の倉庫が閉鎖された場合は、inventories表を使用して製品を別の倉庫に割り当てられます。inventories表のような割当て表は、単一の管理点を作成するのみでなく、副問合せでの行のサブセット化とともに使用して、セキュリティを確保することもできます。たとえば、必要な場合は、特定の営業担当員が特定の倉庫のデータは見られるがその他の倉庫のデータは見られないように制限できます。
各営業担当員に特定の地域の担当責任があり、その地域の倉庫に格納されている製品の情報のみを必要とすると想定します。この場合、inventories表を割当て表として使用し、それとともに副問合せでの行のサブセット化を使用して、特定の営業担当員に関係する情報のみを含むproduct_informationマテリアライズド・ビューを作成できます。次の文により、適切なデータが営業担当員に提供されます。
CREATE MATERIALIZED VIEW oe.product_information REFRESH FAST FOR UPDATE AS
SELECT * FROM oe.product_information@orc1.example.com pi
WHERE EXISTS
(SELECT * FROM oe.inventories@orc1.example.com inv
WHERE pi.product_id = inv.product_id
AND EXISTS
(SELECT * FROM oe.warehouses@orc1.example.com w
WHERE inv.warehouse_id = w.warehouse_id
AND EXISTS
(SELECT * FROM hr.locations@orc1.example.com loc
WHERE w.location_id = loc.location_id
AND loc.postal_code = :p_code)));
|
注意: このoe.product_informationマテリアライズド・ビューを作成するには、postal_codeをhr.locations表のマテリアライズド・ビュー・ログにロギングする必要があります。詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。 |
product_informationマテリアライズド・ビューは、p_code変数により指定された郵便番号が示す倉庫に格納されている製品の製品情報が移入されます。CREATE MATERIALIZED VIEW文の最後の行にあるp_code変数に注意してください。
この柔軟な機能により、管理者はinventories表に簡単な変更を加えるだけで、マテリアライズド・ビューのデータ・セットを容易に制御でき、マテリアライズド・ビュー作成のためにSQL文を変更する必要はありません。たとえば、新製品が特定の倉庫に追加された場合、管理者はこの製品を倉庫に割り当てる行をinventories表に追加するのみです。マテリアライズド・ビューの次のリフレッシュの後、倉庫の製品情報を追跡するマテリアライズド・ビュー・サイトに製品のデータが追加されます。
デプロイメント・テンプレートを設計するときは、ターゲット・データにアクセスする様々なユーザーのタイプを考慮します。たとえば、営業担当員と技術者はいずれも顧客情報を必要としますが、両方が販売情報を必要とするわけではありません。ユーザーが自分に無関係なデータを含むデプロイメント・テンプレートをインスタンス化すると、余分な記憶領域が必要になり、リフレッシュ時間が長くなるため、このようなインスタンス化は避けてください。
逆に、販売情報と顧客情報の両方を必要とするユーザーが、重複したデータを共有する複数のデプロイメント・テンプレートをインスタンス化する必要があることも不都合です。複数のテンプレートをインスタンス化すると、データ整合性の問題が発生することがあります。つまり、各デプロイメント・テンプレートが異なるリフレッシュ・グループを使用するため、2つのデプロイメント・テンプレートのデータが別々のタイミングでリフレッシュされてデータ整合性の問題が発生する可能性があります。
この場合は、営業担当員、顧客サービス技術者、および両方のデータ・セットを必要とするユーザー向けに、それぞれ1つずつデプロイメント・テンプレートを作成するのが最善のソリューションです。
時間と手間をかけずに3種類のデプロイメント・テンプレートを作成するには、まず両方のデータ・セットを含むテンプレートを作成し、それを2つコピーして、それぞれ不要な項目を削除して2つのテンプレートを作成するのが最善の方法です。
設計上のもう1つの考慮点は、パラメータの使用です。図4-8に示されている表の多くでcustomer_idフィールドが使用される場合、テンプレート・オブジェクトのそれぞれに同じパラメータを定義できます。同じパラメータを使用すると、必要なデフォルト・パラメータ値の定義は1回のみで、インスタンス化プロセス時にその定義がすべてのオブジェクトに使用されます。
副問合せに基づくサブセット化を行うマテリアライズド・ビューで使用する場合は、1つのテンプレート・パラメータを使用するとさらに便利です。パラメータを1つにすることによって、ユーザーは必要な顧客に関するデータのみを受け取ることができます。たとえば、次のCREATE MATERIALIZED VIEW文について考えます。
CREATE MATERIALIZED VIEW sales.orders AS
SELECT * FROM sales.orders@orc1.example.com o
-- conditions for customers
WHERE EXISTS
( SELECT c_id FROM sales.customer@orc1.example.com c
WHERE o.c_id = c.c_id
AND EXISTS
( SELECT * FROM sales.assignment@orc1.example.com a
WHERE a.c_id = c.c_id
AND EXISTS
( SELECT * FROM sales.salesperson@orc1.example.com s
WHERE s.s_id = :salesperson_id)));
CREATE MATERIALIZED VIEW sales.customer AS
SELECT c_id FROM sales.customer@orc1.example.com c
-- conditions for customers
WHERE EXISTS
( SELECT * FROM sales.assignment@orc1.example.com a
WHERE a.c_id = c.c_id
AND EXISTS
( SELECT * FROM sales.salesperson@orc1.example.com s
WHERE s.s_id = :salesperson_id)));
作成する2つのマテリアライズド・ビューには明示的なsalesperson_idフィールドが含まれていませんが、副問合せに基づくサブセット化を行うことによって、パラメータを使用して必要なデータ・セットのみをインスタンス化できるので、非常に効率的です。1つのパラメータ(:salesperson_id)を使用すると、マテリアライズド・ビューの管理およびインスタンス化が、DBAおよびデプロイメント・テンプレートを使用するユーザーの両方にとって容易になります。
最後に、リモート・マテリアライズド・ビュー・サイトで他にどのようなオブジェクトを作成する必要があるかを考えます。具体的には、次の点を検討してください。
マテリアライズド・ビュー・サイトとマスター・サイト間に必要なデータベース・リンクを作成するDDLを含める必要があるかどうか
マテリアライズド・ビュー環境で必要となるトリガーまたはプロシージャの種類
非レプリケート・データを格納する表を作成する必要があるかどうか
索引を追加する必要があるかどうか
デプロイメント・テンプレートは、マテリアライズド・ビュー環境を作成および配布するための最も効率的な方法です。配布先が2つまたは3つのサイトのみの場合でも、デプロイメント・テンプレートを使用することによって、個々のサイトにマテリアライズド・ビュー環境を作成するよりもはるかに少ない手順でマテリアライズド・ビュー環境を作成できます。デプロイメント・テンプレートを使用すると、1度マテリアライズド・ビュー環境を作成して、必要な数のサイトにそれを配布できます。
ただし、マテリアライズド・ビュー環境を作成して配布するのにデプロイメント・テンプレートを使用することが最も効率的な方法ならば、どのような場合にリモート・マテリアライズド・ビュー・サイトでローカルにマテリアライズド・ビュー環境を作成するのかという疑問が1つ残っています。通常、マテリアライズド・ビュー・サイトでローカル制御を維持する必要がある場合は、「マテリアライズド・ビュー・グループ・ウィザード」を使用してマテリアライズド・ビュー環境を作成するか、マテリアライズド・ビュー・サイトでローカルにマテリアライズド・ビュー環境を作成します。
マテリアライズド・ビュー作成のローカル制御が便利なのは、マテリアライズド・ビュー・サイトで、受け取るデータを制御することが望ましい場合などです。たとえば、通常は読取り専用マテリアライズド・ビュー・サイトである意思決定支援サイト(DSS)の場合、特に便利です。DSSサイトでは複雑な問合せを実行することがありますが、OLTPサイトの速度を低下させないようにしたり、OLTPサイトのDBAの負担を軽減するにはローカル制御が必要です。
デプロイメント・テンプレートの主な利点の1つに、DBAがデプロイメント・テンプレートの作成を集中して管理できる点があります。ただし、マテリアライズド・ビュー・サイトでなんらかの制御が必要になる場合があります。
次の場合はローカル制御が必要です。
マテリアライズド・ビュー・サイトに熟練したDBAがいる場合
マテリアライズド・ビュー・サイトが信頼できるサイトである場合
マテリアライズド・ビュー・サイトで行のサブセット化を実行する場合
マテリアライズド・ビュー・グループは、マテリアライズド・ビュー・サイトのDBAまたはSQLの知識を持ったシステム・アナリストがアドバンスト・レプリケーション・インタフェースの「マテリアライズド・ビュー・グループの作成」ウィザードを使用してマテリアライズド・ビュー・サイトでローカルに作成するため、マテリアライズド・ビュー・サイトでも制御できます。
ローカル制御を行う最適な例として、次の例を考えます。マルチマスター・レプリケーションでは行および列のサブセット化ができないため、主にデータのサブセット化のみの目的で更新可能マテリアライズド・ビュー・サイトが作成されることがあります。これらのサイトは通常は安全で、熟練したDBAが存在し、ユーザーやアプリケーションの要件を満たすためにローカル制御を行う必要があります。「マテリアライズド・ビュー・グループ・ウィザード」またはレプリケーション・マネージメントAPIを使用して作成したマテリアライズド・ビュー・グループでは、安全性の高い更新可能マテリアライズド・ビュー・サイトの要件を満たすために必要なローカル制御を実行できます。
また、前述のように、デプロイメント・テンプレートを使用してマテリアライズド・ビュー環境を作成すると、マテリアライズド・ビュー環境のすべてのオブジェクトが同じリフレッシュ・グループに追加されます。このことはほとんどのインストレーションでは問題ありませんが、場合によってはマテリアライズド・ビュー・グループ内のオブジェクトをいくつかの異なるリフレッシュ・グループに割り当てる必要があります。
