| Oracle® Databaseアドバンスト・レプリケーション 11g リリース2 (11.2) B72089-02 |
|
 前 |
 次 |
この章では、アドバンスト・レプリケーションに関する基本的な概念および用語について説明します。
この章には、次の項が含まれます。
|
注意: Trusted Oracleを使用している環境でレプリケーションを使用する方法は、Oracleセキュリティ関連製品のドキュメントを参照してください。 |
レプリケーションとは、分散データベース・システムを構成する複数のデータベースのデータベース・オブジェクト(表など)をコピーおよびメンテナンスするプロセスです。1つのサイトに適用された変更は、ローカルで取得および格納された後、リモートの各場所に転送され、適用されます。アドバンスト・レプリケーションは、Oracleサーバーの完全に統合された機能で、別の独立したサーバーではありません。
レプリケーションは、分散データベース・テクノロジを使用して複数サイト間でデータを共有する機能ですが、レプリケート・データベースと分散データベースは異なります。分散データベースの場合は、多くの場所からデータを使用できますが、特定の表が存在するのは1つの場所のみです。たとえば、employees表は分散データベース・システム内のny.example.comデータベースのみに含まれますが、この分散データベース・システムにはhk.example.comデータベースとla.example.comデータベースも含まれています。レプリケーションでは、複数の場所で同一のデータを使用できます。たとえば、employees表は、ny.example.com、hk.example.comおよびla.example.comで使用できます。
レプリケーションを使用するのは、次の理由によります。
可用性
レプリケーションを行うと、複数サイト間でアクティビティを均衡化できるので、共有データに高速にローカル・アクセスできます。各ユーザーは同時に別々のサーバーにアクセスでき、その結果全サーバーの負荷が軽減されます。また、ユーザーはアクセス・コストが最も低いレプリケーション・サイト(通常、ユーザーから地理的に最も近いサーバー)のデータを利用できます。
パフォーマンス
レプリケーションを行うと、複数サイト間でアクティビティを均衡化できるので、共有データに高速にローカル・アクセスできます。各ユーザーは同時に別々のサーバーにアクセスでき、その結果全サーバーの負荷が軽減されます。
モバイル・コンピューティング
マテリアライズド・ビューとは、ある一時点におけるターゲット表の完全または部分的なコピー(レプリカ)です。マテリアライズド・ビューを使用すると、ユーザーは中央のデータベース・サーバーに接続せずにデータベースのサブセットを操作できます。その後、中央のデータベース・サーバーとの接続が確立された時点で、必要に応じてマテリアライズド・ビューを同期化(リフレッシュ)できます。ユーザーがマテリアライズド・ビューをリフレッシュすると、マテリアライズド・ビュー・サイトのすべての変更が中央のデータベースに反映され、ユーザーが接続されていない間に中央のデータベースで発生した変更が、マテリアライズド・ビューに反映されます。
ネットワーク負荷の軽減および大規模デプロイメント
レプリケーションを使用すると、複数の場所にデータを分散できます。したがって、アプリケーションは中央の1つのサーバーではなく様々な地域サーバーにアクセスできます。このように構成することで、ネットワーク負荷は大幅に軽減されます。
レプリケーションの使用方法の詳細は、以降の章で説明します。
|
注意: アドバンスト・レプリケーション機能は、すべてのOracle Databaseのインストール時に自動的にインストールおよびアップグレードされます。 |
|
関連項目: 分散データベースの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
レプリケーションは、要件が異なる様々なアプリケーションをサポートしています。アプリケーションの中には、比較的自律的な個別のマテリアライズド・ビュー・サイトに適しているものもあります。たとえば、営業支援システム、フィールド・サービス、小売りなどの大規模デプロイメントアプリケーションでは、通常、中央のデータベース・システムと、中央のデータベースと非接続状態にあることが多い多数の小規模リモート・サイトとの間で定期的にデータを同期化する必要があります。営業担当員は、中央のデータベースに接続されているかどうかに関係なく、トランザクションを完了できる必要があります。この場合、リモート・サイトは自律的である必要があります。
これに対し、コール・センターやインターネット・システムなどのアプリケーションでは、複数のサーバー上のデータを継続的かつほぼ即時に同期化し、常に同じ内容のサービスを利用できる必要があります。たとえば、インターネット上の小売りWebサイトでは、顧客が閲覧する情報がどのサイトのオンライン・カタログでも同じであることが必要です。この場合、サイトの自律性よりもデータ整合性が重要です。
アドバンスト・レプリケーションは、前述の2種類のアプリケーションでそれぞれに使用することも、2種類のアプリケーションを組み合せたシステムで使用することもできます。実際、1つのアドバンスト・レプリケーション環境で、大規模デプロイメントレプリケーションとサーバー/サーバー・レプリケーションの両方をサポートできるので、一貫した環境に統合することが可能です。このような環境では、たとえば、営業支援システムと顧客サービスのコール・センターの間でデータを共有できます。
アドバンスト・レプリケーションは、異なるリリースのOracleを使用する環境や別々のオペレーティング・システムでOracleを実行する環境でデータをレプリケートできます。したがって、このような環境でデータを使用するアプリケーションは、アドバンスト・レプリケーションを使用できます。
次の項では、レプリケーション・オブジェクト、レプリケーション・グループ、レプリケーション・サイトなど、レプリケーション・システムの基本構成要素について説明します。
レプリケーション・オブジェクトは、分散データベース・システム内の複数のサーバーに存在するデータベース・オブジェクトです。レプリケーション環境では、1つのサイトのレプリケーション・オブジェクトに加えられた更新がすべて、その他の各サイトにあるコピーに適用されます。アドバンスト・レプリケーションを使用すると、次のタイプのオブジェクトをレプリケートできます。
表
索引
ビューおよびオブジェクト・ビュー
パッケージおよびその本体
プロシージャおよびファンクション
ユーザー定義型および型の本体
トリガー
シノニム
索引タイプ
ユーザー定義演算子
表に関しては、レプリケーションでは高度な機能(パーティション表、索引構成表、ユーザー定義型を基にした列を含む表、オブジェクト表など)をサポートしています。
レプリケーション環境では、レプリケーション・グループを使用してレプリケーション・オブジェクトを管理します。レプリケーション・グループは、論理的に関連付けられたレプリケーション・オブジェクトの集合です。
レプリケーション・グループ内に関連するデータベース・オブジェクトを編成すると、多数のオブジェクトをまとめて簡単に管理できます。通常、レプリケーション・グループを作成および使用して、特定のデータベース・アプリケーションのサポートに必要なスキーマ・オブジェクトを編成します。ただし、レプリケーション・グループおよびスキーマは、相互に対応している必要はありません。レプリケーション・グループには、複数のスキーマのオブジェクトを含めることができ、1つのスキーマには、複数のレプリケーション・グループ内のオブジェクトを含めることができます。ただし、各レプリケーション・オブジェクトは、1つのレプリケーション・グループのメンバーにしかなれません。
レプリケーション・グループは、複数のレプリケーション・サイトに存在できます。レプリケーション環境では、マスター・サイトとマテリアライズド・ビュー・サイトという2つの基本的なタイプのサイトがサポートされます。1つのサイトは、1つのレプリケーション・グループのマスター・サイトであり、同時に別のレプリケーション・グループのマテリアライズド・ビュー・サイトにもなることができます。ただし、同一レプリケーション・グループ内のマスター・サイトとマテリアライズド・ビュー・サイトになることはできません。
マスター・サイトとマテリアライズド・ビュー・サイトの違いは次のとおりです。
マスター・サイトのレプリケーション・グループは、マスター・グループと呼ばれます。マテリアライズド・ビュー・サイトのレプリケーション・グループはマスター・グループを基にしており、マテリアライズド・ビュー・グループと呼ばれます。また、すべてのマスター・グループには、マスター定義サイトが1つずつ存在します。レプリケーション・グループのマスター定義サイトは、レプリケーション・グループおよびグループ内のオブジェクトを管理する制御センターとして機能するマスター・サイトです。
マスター・サイトでは、レプリケーション・グループ内のすべてのオブジェクトの完全なコピーが保持されますが、マテリアライズド・ビュー・サイトのマテリアライズド・ビューには、マスター・グループ内の表データのすべてが含まれる場合と一部が含まれる場合があります。たとえば、hr_repgマスター・グループに表employeesおよびdepartmentsが含まれている場合、マスター・グループに含まれているすべてのマスター・サイトでは、employeesおよびdepartmentsの完全なコピーを保持する必要があります。一方、あるマテリアライズド・ビュー・サイトにはemployees表のマテリアライズド・ビューのみを含め、別のマテリアライズド・ビュー・サイトにはemployees表とdepartments表を両方とも含めることができます。
マルチマスター・レプリケーション環境のすべてのマスター・サイトは、相互に直接通信を行って、レプリケーション・グループのデータの変更を絶えず伝播します。マテリアライズド・ビュー・サイトには、ある一時点における表データのイメージ、すなわちマテリアライズド・ビューが含まれています。通常、マテリアライズド・ビューは、定期的にリフレッシュされてマスター・サイトと同期化されます。マテリアライズド・ビューはリフレッシュ・グループに編成できます。リフレッシュ・グループ内のマテリアライズド・ビューは、1つ以上のマテリアライズド・ビュー・グループに含めることができ、各マテリアライズド・ビューは、リフレッシュ・グループ内のすべてのマテリアライズド・ビューのデータがトランザクションの一貫性を保つ特定の時点と一致するように、同時にリフレッシュされます。
アドバンスト・レプリケーションは、次のタイプのレプリケーション環境をサポートしています。
マルチマスター・レプリケーション(peer-to-peerレプリケーションまたはn-wayレプリケーションとも呼ばれます)を使用すると、同等ピアとして機能する複数サイトでレプリケート・データベース・オブジェクトのグループを管理できます。マルチマスター・レプリケーション環境では各サイトがマスター・サイトで、各サイトが他のマスター・サイトと通信します。
アプリケーションは、マルチマスター構成のサイトにある任意のレプリケート表を更新できます。マルチマスター環境でマスター・サイトとして機能しているOracle Databaseサーバーで、すべての表レプリカのデータが自動的に収集され、グローバルなトランザクション一貫性およびデータ整合性が保証されます。
マルチマスター・レプリケーションを実装する最も一般的な方法は非同期レプリケーションです。他の方法として、同期レプリケーションとプロシージャ・レプリケーションがあります。同期レプリケーションを使用する場合には、表のデータ操作言語(DML)の変更についての情報が、変更が行われたマスター・サイトの遅延トランザクション・キューに格納されます。この変更は、遅延トランザクションと呼ばれます。遅延トランザクションは、他の関連するマスター・サイトに定期的に送信(または伝播)されます。これらの間隔で時間の量を制御できます。
非同期レプリケーションを使用すると、同じ行の値が2つの別のマスター・サイトでほぼ同時に更新される場合があるため、データ競合が発生する可能性があります。ただし、競合は技術によって回避することができ、競合が発生した場合は、Oracleが提供する組込みメカニズムにより問題を解決できます。解消されない競合に関する情報は、エラー・ログに格納されます。
マスター・グループで管理作業を実行するために、マスター・グループのレプリケーション・アクティビティをすべて停止することが必要な場合があります。たとえば、新しいマスター・グループ・オブジェクトを追加するには、マスター・グループのレプリケーション・アクティビティをすべて停止する必要があります。マスター・グループのレプリケーション・アクティビティをすべて停止することを、グループの静止といいます。マスター・グループの静止中は、マスター・グループ内のオブジェクトに対してDML文を発行できません。また、マスター・グループを静止する前に、遅延トランザクションをすべて伝播しておく必要があります。ユーザーは静止中のマスター・グループ内の表に対して、問合せを引き続き実行できます。
マテリアライズド・ビューには、ある一時点におけるターゲット・マスターの完全コピーまたは部分的なコピーが含まれます。ターゲット・マスターは、マスター・サイトのマスター表またはマテリアライズド・ビュー・サイトのマスター・マテリアライズド・ビューのいずれかです。マスター・マテリアライズド・ビューは、別のマテリアライズド・ビューのマスターとして機能するマテリアライズド・ビューです。多重化マテリアライズド・ビューは、マスター表ではなく他のマテリアライズド・ビューを基にしたマテリアライズド・ビューです。
マテリアライズド・ビューには、次の利点があります。
ローカル・アクセスが可能なため、応答時間を短縮し、可用性を向上できます。
ユーザーはローカルなマテリアライズド・ビューに問合せを実行できるため、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに対する問合せ負荷が軽減されます。
ターゲット・マスターのデータ・セットのうち、選択したサブセットのみをレプリケート可能にすることにより、データ・セキュリティを高めることができます。
マテリアライズド・ビューは、読取り専用、更新可能または書込み可能のいずれかで、このようなマテリアライズド・ビューには前述したリストにない他の利点があります。
基本的な構成では、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのデータを基に作成された表データに対して、マテリアライズド・ビューは読取り専用アクセスを提供します。アプリケーションでは読取り専用マテリアライズド・ビューからデータを問い合せることにより、ネットワークが使用できるかどうかに関係なくマスター・サイトへのネットワーク・アクセスを回避できます。ただし、アプリケーションでデータ操作言語(DML)による変更を実行する場合は、システムのあらゆる場所からマスター・サイトのデータにアクセスする必要があります。図1-2は、基本的な読取り専用レプリケーションを示します。読取り専用マテリアライズド・ビューのマスター表およびマスター・マテリアライズド・ビューは、レプリケーション・グループに属する必要はありません。
読取り専用マテリアライズド・ビューには、次の利点があります。
更新できないため、競合の可能性がありません。
複合マテリアライズド・ビューをサポートします。複合マテリアライズド・ビューの例として、集合演算またはCONNECT BY句を含むマテリアライズド・ビューがあります。
より高度な構成では、更新可能マテリアライズド・ビューを作成でき、これを使用すると、ユーザーはマテリアライズド・ビューに対して行の挿入、更新および削除の操作を実行することで、ターゲット・マスター表またはマスター・マテリアライズド・ビューの行を挿入、更新および削除できます。更新可能マテリアライズド・ビューには、ターゲット・マスター内のデータのサブセットも含められます。図1-3は、更新可能マテリアライズド・ビューを使用したレプリケーション環境を示します。
更新可能マテリアライズド・ビューは、レプリケーションをサポートするように設定されている表やその他のマテリアライズド・ビューに基づいています。実際、更新可能マテリアライズド・ビューは、別のレプリケーション・グループに基づいたマテリアライズド・ビュー・グループに含まれている必要があります。更新可能マテリアライズド・ビューへの変更をリフレッシュ中にマスターにプッシュするには、更新可能マテリアライズド・ビューがマテリアライズド・ビュー・グループに属する必要があります。
更新可能マテリアライズド・ビューには、次の特性があります。
常に1つの表に基づいています。ただし、副問合せで複数の表を参照できます。
増分リフレッシュ(または高速リフレッシュ)を実行できます。
更新可能マテリアライズド・ビューに加えられた変更は、マテリアライズド・ビューのリモートのマスター表またはマスター・マテリアライズド・ビューに伝播されます。次に、マスターへの更新が他のすべてのレプリケーション・サイトにカスケードして伝播されます。
更新可能マテリアライズド・ビューには、次の利点があります。
マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに接続されていない状態でも、ローカルのレプリケート・データ・セットに対して問合せおよび更新ができます。
データの更新をサポートしていますが、リソースはマルチマスター・レプリケーションの場合よりも少なくて済みます。マルチマスター・レプリケーションでは定期的な間隔で変更が伝播されますが、マテリアライズド・ビューは必要に応じてリフレッシュできるため、ネットワーク・リソースにかかる負荷を軽減できます。さらに、マテリアライズド・ビューは非常に少ないデータしか含まないデータベース内にも常駐させることが可能なため、マテリアライズド・ビュー・クライアントのためのディスク領域とメモリー要件は、マスター・サイトを含むOracleサーバーに対する要件より少なくて済みます。
FOR UPDATE句を使用してマテリアライズド・ビューを作成し、このマテリアライズド・ビューをマテリアライズド・ビュー・グループに追加しないことが可能です。この場合、ユーザーはこのマテリアライズド・ビューに対してデータ操作言語(DML)による変更を実行できますが、この変更はマスターにプッシュされず、マテリアライズド・ビューがリフレッシュされた場合は変更が失われます。このようなマテリアライズド・ビューは、書込み可能マテリアライズド・ビューと呼ばれます。
行と列のサブセット化により、マスター表またはマスター・マテリアライズド・ビューのデータの部分的なコピーを含むマテリアライズド・ビューを作成できます。このようなマテリアライズド・ビューは、すべてのデータ・セットを必要としない地域事業所や営業担当員に役立ちます。
行のサブセットでは、WHERE句を使用して、マスター内の必要な行のみをマテリアライズド・ビューに含めることができます。列のサブセットでは、マスター内の必要な列のみをマテリアライズド・ビューに含めることができます。マテリアライズド・ビューを作成する際に、SELECT文で特定の列を指定してこれらを実行します。
|
注意: 更新可能マテリアライズド・ビューの列のサブセット化は、デプロイメント・テンプレートおよびOracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用する場合にのみサポートされます。この制限は、読取り専用マテリアライズド・ビューの列のサブセット化にはあてはまりません。 |
マテリアライズド・ビューとマスター表またはマスター・マテリアライズド・ビューとの間で一貫性を保つには、マテリアライズド・ビューを定期的にリフレッシュする必要があります。マテリアライズド・ビューをリフレッシュするには、次の3つの方法があります。
マテリアライズド・ビュー間のトランザクションの一貫性を保つことが重要なときは、マテリアライズド・ビューをリフレッシュ・グループに編成できます。リフレッシュ・グループをリフレッシュすることで、リフレッシュ・グループ内のすべてのマテリアライズド・ビューのデータが、トランザクションの一貫性を保つ特定の時点のデータと確実に一致します。読取り専用マテリアライズド・ビューと更新可能マテリアライズド・ビューは、どちらもリフレッシュ・グループに含められます。リフレッシュ・グループ内のマテリアライズド・ビューを個別にリフレッシュすることも可能ですが、リフレッシュ・グループ内のその他のマテリアライズド・ビューはリフレッシュされないため、リフレッシュ・グループを編成する意味がなくなります。
マテリアライズド・ビュー・ログは、マテリアライズド・ビューのマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトにある表で、DMLによってマスター表またはマスター・マテリアライズド・ビューに加えられたすべての変更を記録します。マテリアライズド・ビュー・ログは1つのマスター表またはマスター・マテリアライズド・ビューと対応付けられ、それぞれのマスター表またはマスター・マテリアライズド・ビューには、マスターからリフレッシュされるマテリアライズド・ビューの数に関係なく、1つのマテリアライズド・ビュー・ログがあります。マテリアライズド・ビューの高速リフレッシュは、マテリアライズド・ビューのマスターにマテリアライズド・ビュー・ログがある場合にのみ可能です。マテリアライズド・ビューを高速リフレッシュすると、マテリアライズド・ビューと対応付けられたマテリアライズド・ビュー・ログのエントリで、最後のリフレッシュ以降に追加されたエントリがマテリアライズド・ビューに適用されます。
デプロイメント・テンプレートを使用すると、多くのリモート・マテリアライズド・ビュー・サイトの配置およびメンテナンス作業が簡単になります。また、デプロイメント・テンプレートを使用すると、マスター・サイトでマテリアライズド・ビュー定義の集合を定義でき、その定義中のパラメータを使用してマテリアライズド・ビューを個々のユーザーまたはユーザーのタイプにあわせてカスタマイズできます。
たとえば、営業用に1つのテンプレートを作成し、サービス技術員用に別のテンプレートを作成する場合などです。この場合、販売地域や顧客サポート・レベルなどのパラメータ値を使用できます。リモート・ユーザーは、マスター・サイトに接続するときに、使用可能なテンプレートのリストを問い合せることができます。ユーザーがテンプレートをインスタンス化すると、リモート・サイトで適切なマテリアライズド・ビューが作成され、データが移入されます。パラメータ値は、リモート・ユーザーが指定するか、マスター・サイトに保持されている表の値を利用します。
ユーザーがマテリアライズド・ビュー・サイトでテンプレートをインスタンス化すると、オブジェクトDDL(たとえば、CREATE MATERIALIZED VIEW文やCREATE TABLE文)が実行されて、マテリアライズド・ビュー・サイトに適切なスキーマ・オブジェクトが作成され、そのオブジェクトに適切なデータが移入されます。テンプレートのインスタンス化は、マスター・サイトに接続した状態でネットワークを介して行うことも(オンライン・インスタンシエーション)、あるいはマスター・サイトから切断された状態で行うこともできます(オフライン・インスタンシエーション)。
オフライン・インスタンシエーションは、ピーク期間中のサーバー負荷を軽減したり、リモート接続時間を短縮するために使用されます。テンプレートをオフラインでインスタンス化するには、テンプレートおよび必要なデータをテープやCD-ROMなどのストレージ・メディアにパッケージ化します。そして、マスター・サイトではなく、テンプレートとデータが入ったストレージ・メディアからデータをプルします。
マルチマスター・レプリケーションとマテリアライズド・ビューは、様々なアプリケーションの要件を満たすようにハイブリッド(複合)構成として組み合せられます。ハイブリッド構成では、マスター・サイトの数に制限がなく、各マスターに複数のマテリアライズド・ビュー・サイトを対応付けられます。
たとえば、図1-4に示すように、2つのマスター間のマルチマスター(またはn-way)レプリケーションでは、2つの地域をサポートするデータベース間の全表レプリケーションをサポートできます。マテリアライズド・ビューをマスター上に定義すると、全表または表のサブセットを各地域内のサイトにレプリケートできます。
マテリアライズド・ビューとレプリケート・マスター表との主な違いは次のとおりです。
レプリケート・マスター表にはレプリケートされている表全体のデータが含まれている必要がありますが、マテリアライズド・ビューはマスター表のデータのサブセットをレプリケートできます。
マルチマスター・レプリケーションを使用すると、変更が発生するたびに各トランザクションの変更内容をレプリケートできます。マテリアライズド・ビューのリフレッシュを使用すると、一定の間隔でバッチ処理されるため、マルチマスター・レプリケーションより少ない頻度で複数のトランザクションの内容をより効率的に伝播できます。
同一データの複数のコピーに変更が加えられることにより競合が発生する場合は、競合の検出と解消は常にマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトで発生します。
マスター・サイトとマテリアライズド・ビュー・サイトは、スケジュール・リンクを使用して他のサイトにデータの変更を伝播します。スケジュール・リンクは、ユーザー定義スケジュールを使用して遅延トランザクションをプッシュするデータベース・リンクです。スケジュール・リンクによって、あるマスター・サイトから別のマスター・サイトへの遅延トランザクション・キューの伝播方法、あるいは、あるマテリアライズド・ビュー・サイトからそのマスター・サイトへの遅延トランザクション・キューの伝播方法が決定されます。スケジュール・リンクを作成すると、遅延トランザクション・キューをシステムの別のサイトにプッシュするジョブがローカル・ジョブ・キューに作成されます。
レプリケーション環境を構成、管理および監視するために、いくつかのツールを使用できます。Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースでは、レプリケーション環境の管理に役立つ強力なGraphical User Interface(GUI)を利用でき、レプリケーション・マネージメントApplication Program Interface(API)では、使い慣れたAPIを使用してレプリケーション管理のためのカスタマイズ・スクリプトを作成できます。レプリケーション・カタログを使用して、レプリケーション環境に関する情報を管理することもできます。
レプリケーション環境の構成と管理に利用できるように、Oracle Enterprise Managerには洗練されたアドバンスト・レプリケーション・インタフェースが用意されています。アドバンスト・レプリケーション・インタフェースを使用するには、Enterprise Managerの「データ移動」サブページへ移動します。アドバンスト・レプリケーション・インタフェースの詳細は、主にこのツールのオンライン・ヘルプを参照してください。図1-5は、Enterprise Managerのアドバンスト・レプリケーション・インタフェースを示しています。
|
関連項目: Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースのオンライン・ヘルプ |
レプリケーション・マネージメントAPIは、アドバンスト・レプリケーション環境を構成する際に使用するプロシージャおよびファンクションをカプセル化したPL/SQLパッケージのセットです。レプリケーション・マネージメントAPIは、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースの機能をコマンドラインで実行します。つまり、アドバンスト・レプリケーション・インタフェースは、レプリケーション・マネージメントAPIのプロシージャとファンクションを使用して処理を実行します。たとえば、アドバンスト・レプリケーション・インタフェースを使用してマスター・グループを作成するときに、このインタフェースでは、DBMS_REPCATパッケージ内のCREATE_MASTER_REPGROUPプロシージャをコールして作業を完了させます。レプリケーション・マネージメントAPIを使用すると、レプリケーション環境を管理するカスタム・スクリプトを簡単に作成できます。
|
関連項目: レプリケーション・マネージメントAPIの使用方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。 |
レプリケーション環境の各マスター・サイトおよびマテリアライズド・ビュー・サイトには、それぞれレプリケーション・カタログがあります。サイトのレプリケーション・カタログは、そのサイトのレプリケーション・オブジェクトとレプリケーション・グループに関する管理情報をメンテナンスしている、データ・ディクショナリの表およびビューの固有のセットです。レプリケーション環境に関係する各サーバーでは、そのレプリケーション・カタログの情報を使用して、レプリケーション・グループのオブジェクトのレプリケーションを自動化できます。
|
関連項目: レプリケーション・カタログの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。 |
レプリケーション環境では、すべてのDDL文は、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースまたはレプリケーション・マネージメントAPIのDBMS_REPCATパッケージを使用して発行する必要があります。具体的には、DBMS_REPCATパッケージを使用する場合、マスター・グループにオブジェクトを追加するためにCREATE_MASTER_REPOBJECTプロシージャ、レプリケート・オブジェクトを変更するためにALTER_MASTER_REPOBJECTプロシージャを使用します。EXECUTE_DDLプロシージャを使用することもできます。
アドバンスト・レプリケーション・インタフェースまたはDBMS_REPCATパッケージのいずれかを使用すると、レプリケーション環境に属するすべてのサイトにすべてのDDL文がレプリケートされます。レプリケート・オブジェクトの作成にエクスポート/インポートを使用できる場合もあります。
|
注意: SQL*Plusなどのツールを使用して直接DDL文を発行すると、他のサイトにはレプリケートされません。 |
非同期のマルチマスター・レプリケーション環境および更新可能マテリアライズド・ビュー・レプリケーション環境では、たとえば異なるサイトから発行された2つのトランザクションがほぼ同時に同じ行を更新する場合などに発生するレプリケーション競合に対処する必要があります。データ競合が発生した場合は、ビジネス・ルールに従って競合を解消し、すべてのサイトを適正に収束するためのメカニズムが必要です。
アドバンスト・レプリケーションでは、レプリケート環境で発生したすべての競合がログに記録されるのみでなく、様々なビルトインの競合解消方法が用意されており、これらの方法を使用してデータベースの競合解消システムを定義すると、ビジネス・ルールに従って競合を解消できます。ビルトインの競合解消方法によって競合を解消できない場合は、独自の競合解消方法を作成して使用することもできます。
|
関連項目:
|
マルチマスター・レプリケーションを実装する最も一般的な方法は非同期レプリケーションです。ただし、他にも同期レプリケーションとプロシージャ・レプリケーションの2つのオプションがあります。
マルチマスター・レプリケーション環境では、非同期レプリケーションまたは同期レプリケーションを使用してデータをコピーできます。非同期レプリケーションを使用する場合、1つのマスター・サイトに加えられた変更は、一定時間後に関係するすべてのマスター・サイトに反映されます。同期レプリケーションの場合は、1つのマスター・サイトに加えられた変更は即時に、関係するすべてのマスター・サイトに反映されます。
同期レプリケーションを使用して表を更新すると、関係するすべてのマスター・サイトで更新内容が即時にレプリケートされます。つまり、それぞれのトランザクションはすべてのマスター・サイトと関連があります。したがって、なんらかの理由から1つのマスター・サイトでトランザクションを処理できなかった場合、そのトランザクションはすべてのマスター・サイトでロールバックされます。
同期レプリケーションを使用して競合の発生を回避できますが、処理を円滑に行うには非常に安定した環境が必要です。たとえば、ネットワーク上の問題により1つのマスター・サイトと通信できない場合、ユーザーがレプリケート表を問い合せることはできますが、通信が再び確立されるまではどのトランザクションも完了しません。また、同期レプリケーションをシミュレートするように非同期レプリケーションを構成することもできます。
バッチ処理アプリケーションでは、1つのトランザクション内で大量のデータを変更できます。この場合、通常の行レベル・レプリケーションを実行すると、大量のデータ変更のためにネットワークの負荷が増大する可能性があります。このような問題を回避するために、レプリケーション環境で動作するバッチ処理アプリケーションでは、プロシージャ・レプリケーションを使用して、データ・レプリカを収集する簡単なストアド・プロシージャ・コールをレプリケートできます。プロシージャ・レプリケーションでは、アプリケーションが表の更新に使用するストアド・プロシージャのコールのみがレプリケートされます。データの変更自体はレプリケートされません。
プロシージャ・レプリケーションを使用するには、システムのデータを変更するパッケージをすべてのサイトにレプリケートする必要があります。パッケージをレプリケートした後に、各サイトでこのパッケージ用のラッパーを生成する必要があります。アプリケーションがデータを変更するパッケージ・プロシージャをローカル・サイトでコールすると、ラッパーにより、最終的にレプリケーション環境内の他のすべてのサイトで同じパッケージ・プロシージャがコールされます。プロシージャ・レプリケーションは、非同期または同期で実行できます。
プロシージャ・レプリケーションを使用してデータをレプリケートする場合、データをレプリケートするプロシージャにより、レプリケート・データの整合性が保証される必要があります。つまり、このようなプロシージャは、レプリケーションの競合を回避または検出し、競合を適切に解消するように設計する必要があります。したがって、プロシージャ・レプリケーションは、主に大規模バッチ操作によってのみデータベースを変更する場合に使用されます。このような状況では、多数のトランザクションが同じデータで競合することはないため、レプリケーションの競合はほとんど発生しません。
|
関連項目: プロシージャ・レプリケーションの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。 |
