| Oracle® Databaseアドバンスト・レプリケーション 11g リリース2 (11.2) B72089-02 |
|
 前 |
 次 |
この章では、シングル・マスター・レプリケーション環境およびマルチマスター・レプリケーション環境での、Oracleのマスター・レプリケーション・サイトの概念およびアーキテクチャについて説明します。
この章には、次の項が含まれます。
マスター・レプリケーションのアーキテクチャの詳細を理解するには、マスター・レプリケーションの概念について知っておく必要があります。マスター・レプリケーションの使用方法と目的がわかると、アーキテクチャの個々の要素がどのように相互に作用してマルチマスター・レプリケーション環境が作成されるのか理解が深まります。
この項には、次の項目が含まれます。
Oracleには、シングル・マスター・レプリケーションとマルチマスター・レプリケーションという、2つのタイプのマスター・レプリケーションがあります。マルチマスター・レプリケーションは、複数のマスター・サイトを含んでおり、各マスター・サイトが同等ピアとして機能します。シングル・マスター・レプリケーションでは、マテリアライズド・ビュー・レプリケーションをサポートする1つのマスター・サイトが、数百、数千のマテリアライズド・ビュー・サイトをサポートします。また、1つ以上のマテリアライズド・ビュー・サイトをサポートする1つのマスター・サイトが、複数マスター・サイト環境の一部として含まれるハイブリッド・レプリケーション環境(マルチマスター・レプリケーションとマテリアライズド・ビュー・レプリケーションの組合せ)を構成することも可能です。
マテリアライズド・ビューは、マスター・サイトのマスター表またはマテリアライズド・ビュー・サイトのマテリアライズド・ビューのいずれかに基づきます。マテリアライズド・ビューがマテリアライズド・ビューに基づいている場合は、多重化マテリアライズド・ビュー環境が作成されます。このような環境では、他のマテリアライズド・ビューの基になるマテリアライズド・ビューがマスター・マテリアライズド・ビューと呼ばれます。
マルチマスター・レプリケーション(peer-to-peerレプリケーションまたはn-wayレプリケーションとも呼ばれます)は、同等な複数のマスター・サイトから構成されており、どのマスター・サイトでも更新が可能です。個々のマスター・サイトに対する更新処理は、関係するすべてのマスター・サイトに伝播されます。図2-1は、マルチマスター・レプリケーション・システムを示します。
マルチマスター・レプリケーション環境でマスター・サイトとして機能しているOracle Databaseサーバーで、すべての表レプリカのデータが自動的に収束され、グローバルなトランザクション一貫性とデータ整合性が保証されます。競合解消は、各マスター・サイトで独自に行われます。マルチマスター・レプリケーションでは、各マスター・サイトのレプリケート表の完全なレプリカが提供されます。
ハイブリッド・レプリケーション環境(複数のマスター・サイトと各マスター・サイトがサポートする1つ以上のマテリアライズド・ビュー・サイトから構成される環境)の場合、ターゲット・マスター・サイトからマルチマスター・レプリケーション環境の他のすべてのマスター・サイトにマテリアライズド・ビューのすべての更新内容が伝播されます。次に、各マスター・サイトが、マテリアライズド・ビューのリフレッシュ時に変更をマテリアライズド・ビューに伝播します。
1つのマスター・サイトを、1つ以上のマテリアライズド・ビュー・サイトのターゲット・マスター・サイトとして機能させることもできます。マルチマスター・レプリケーションでは、1つのサイトに対して行った更新処理はその他のすべてのマスター・サイトに伝播されましたが、シングル・マスター・レプリケーションでは、マテリアライズド・ビューにより、更新がそのターゲット・マスター・サイトにのみ反映されます。
競合解消は、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでのみ処理されます。マテリアライズド・ビュー・レプリケーションには、レプリケート表の全部または一部のレプリカを含めることができます。
基本的に、レプリケーションを使用するのは、必要なときに必要な場所でデータを確実に使用するためです。次の項では、情報の配布要件が異なるいくつかの環境について説明します。使用するレプリケーション環境には、次のような要件が1つ以上ある可能性があります。
マルチマスター・レプリケーションは、ミッション・クリティカルなデータベースの可用性を保護できます。たとえば、マルチマスター・レプリケーション環境では、システムまたはネットワーク障害が発生してプライマリ・サイトが使用できなくなった場合に備え、データベース内のデータをレプリケートしてフェイルオーバー・サイトを確立できます。このようなフェイルオーバー・サイトは、プライマリ・サイトが同時に稼働しているときでも、アプリケーションからアクセスできる完全に機能したデータベースとして機能します。
Oracle Netを使用すると、接続時に自動的に起動されるフェイルオーバーを構成でき、この機能により、最初のマスター・サイトに障害が発生した場合、Oracle Netは別のマスター・サイトに接続を切り替えることができます。自動的な接続時フェイルオーバーを構成するには、tnsnames.oraファイルでFAILOVER_MODEパラメータをonに設定し、複数の接続記述子を指定します。
|
関連項目: 接続時フェイルオーバーの構成方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
マルチマスター・レプリケーションは、次のような目的で複数ポイントのデータベース情報にアクセスすることが必要なトランザクション処理アプリケーションに役立ちます。
過度のアプリケーション負荷の分散
連続的な可用性の保証
よりローカライズされたデータ・アクセスの提供
アプリケーション負荷を分散することが必要なアプリケーションとして一般的なものに、サービス指向のアプリケーションがあります。
マテリアライズド・ビュー・レプリケーションを使用すると、ユーザーは、マスター・サイトに接続せずに、マスター・サイトからのレプリケート・データの全部またはサブセットをリモートで格納できます。たとえば、営業支援システムでは、個人のラップトップ(非接続デバイス)に個々の営業担当員に関連するデータのサブセットを格納します。
マスター・サイトは、マテリアライズド・ビュー環境のターゲットとして機能します。マスター・サイトのサポートには、次のものがあります。
すべてのマテリアライズド・ビュー・サイトをサポートするシングル・マスター・サイト。競合解消がマスター・サイトまたは(多重化マテリアライズド・ビュー環境の)マスター・マテリアライズド・ビュー・サイトでのみ実行されるため、データの不一致が発生する確率が低下します。
マルチマスター・レプリケーションとマテリアライズド・ビュー・レプリケーションの組合せで、マテリアライズド・ビューのグループがマルチマスター構成の様々なマスターをターゲットとします。この構成は、複数のマスター・ノードにまたがってネットワーク負荷を分散し、マスター・ノードのいずれかが使用不可になった場合に、スケーラビリティや可用性を向上させます。
アドバンスト・レプリケーションとOracle Real Application Clusters (Oracle RAC)のどちらを使用するかを検討する必要があるのは、ロード・バランシングと耐障害性の面です。
ロード・バランシング: アドバンスト・レプリケーションでは、複数のデータベースに対する読取りロード・バランシングが可能であり、Oracle RACでは、複数のインスタンスに対する読取りおよび書込みロード・バランシングが可能です。書込みはそれぞれ各レプリケーション・サイトで実行する必要があるため、レプリケーションでは書込みロード・バランシングは行われません。
耐障害性: アドバンスト・レプリケーションでは、各レプリケーション・サイトが地理的に異なる地域に置かれている可能性があるため、自然災害、停電またはサボタージュに対する耐障害性が高くなります。Oracle RACは、物理的に同一の環境にあるクラスタまたはその他の大規模パラレル・システム上で動作するため、アドバンスト・レプリケーションでは対処できる物理的問題に対する耐障害性はありません。
相互運用性: アドバンスト・レプリケーションは、Oracleが稼働している様々なプラットフォームおよびオペレーティング・システム間でデータをレプリケートできます。Oracle RAC環境内のインスタンスは、同一プラットフォーム上で実行する必要があります。
マルチマスター・レプリケーションには、非同期と同期という2つのタイプがあります。
非同期レプリケーション(ストア/フォワード・レプリケーションとも呼ばれます)では、ローカルで加えられたすべての変更を取得してキューに格納し、一定の間隔でリモート・サイトに伝播して変更を適用します。この形式のレプリケーションでは、すべてのサイトでデータが収束するまでに一定の時間がかかります。
同期レプリケーション(リアルタイム・レプリケーションとも呼ばれます)では、1つのトランザクションの一部として、レプリケーション環境に関係するすべてのサイトで変更を適用し、レプリケート・プロシージャを実行します。いずれかのサイトでデータ操作言語(DML)文またはプロシージャが失敗すると、トランザクション全体がロールバックされます。同期レプリケーションを使用すると、各サイトのデータ整合性がリアルタイムで保証されます。
マスター・サイトの伝播モードは、非同期から同期に、または同期から非同期に変更できます。マスター・グループ内のマスター・サイトの伝播モードを変更した場合、すべてのマスター・グループ・オブジェクトに対してレプリケーション・サポートを再度生成する必要があります。レプリケーション・サポートを再生成すると、内部トリガーがアクティブ化され、内部パッケージが再生成されて、すべてのマスター・サイトにあるオブジェクトのレプリケーションがサポートされます。また、マルチマスター・レプリケーション環境では、同期レプリケーションおよび非同期レプリケーションの両方を混在させることも可能です。
非同期レプリケーションでは、DMLまたはレプリケート・プロシージャを実行すると、マルチマスター・レプリケーション環境のすべてのマスター・サイトに個別に伝播されます。各トランザクションにおいてデータが伝播されるのは、DMLまたはレプリケーション・プロシージャをローカルで実行した後です。
非同期レプリケーションがデフォルトのレプリケーション・モードです。非同期レプリケーションでは、同期レプリケーションの場合よりもネットワーク・リソースやハードウェア・リソースの使用を抑えることができるため、可用性およびパフォーマンスが高くなります。
ただし、非同期レプリケーションを使用すると、変更内容が伝播されるまでの一定時間、レプリケーション環境にある別のマスター・サイトのデータ・セットと一致しません。また、非同期レプリケーションでは、データの競合が発生する可能性もあります。
非同期レプリケーション・プロセスは次のとおりです。
DML文を発行または、レプリケート・プロシージャのラッパーを実行します。
表がレプリケーション用に設定された後、ユーザーがこの表に対してコミットしたDMLは、他のすべてのマスター・サイトへのレプリケーション用に取得されます。
挿入、更新または削除の対象となる各行に対して、内部トリガーによって遅延リモート・プロシージャ・コール(RPC)が作成され、遅延トランザクション・キューに入れられます。遅延トランザクション・キューには、すべての遅延RPCが入っています。
プロシージャがレプリケートされており、そのラッパーがマスター・サイトで実行されると、プロシージャ・コールが遅延トランザクション・キューに入れられます。
遅延RPCを遅延トランザクション・キューに格納します。
遅延トランザクション・キュー内の各トランザクションには、遅延トランザクションの伝播先が定義されている接続先リストがあり、このリストには、発行元サイト以外の全マスター・サイトが記載されています。各サイトには遅延トランザクション・キューが1つあり、この1つのキューが複数のレプリケーション・グループにより使用されます。
接続先へ遅延トランザクション・キューのエントリを送信します。
スケジュールした間隔で、または必要に応じて、遅延トランザクション・キュー内の遅延トランザクションがターゲットの接続先に伝播されます。接続先ごとにスケジュール間隔を変えられます。
遅延トランザクション・キューのエントリがリモートの接続先で適用されます。
遅延トランザクションがターゲット宛先に伝播されているため、内部パッケージをコールすることによって各遅延RPCが宛先サイトで適用されます。遅延トランザクションを宛先サイトで正しく適用できない場合、宛先サイトのエラー・キューに再送および配置されます。ここでは、DBAがエラーの状態を修正し、遅延トランザクションを再度適用します。
遅延トランザクション・キューのエントリがリモートの接続先で適用されるときに、データ競合がないかがチェックされます。データ競合が検出された場合、その競合はリモートの接続先でログに記録され、オプションで競合解消方法が起動します。
遅延トランザクションがすべてのリモート・マスター・サイトに正常にプッシュされた後、元のサイトではこのトランザクションが遅延トランザクション・キューからすぐにはパージされません。ユーザーが定義した間隔で実行されるパージ・ジョブにより、後でパージできます。
同期レプリケーションでは、1つのトランザクションが終了するまでの間に、ローカル・サイトで加えられた変更をレプリケーション環境内の同期リンクしたマスター・サイトに伝播します。いずれかのマスター・サイトで伝播に失敗した場合、ローカルのマスター・サイトで最初に加えられた変更を含め、トランザクション全体がロールバックされます。この厳しい規則により、レプリケーション環境全体のデータ整合性を保つことができます。非同期レプリケーションとは異なり、マスター・サイト間のデータが一致しない時間はありません。
同期レプリケーションでは、レプリケーション環境でデータ競合が発生しないことも保証されています。このようなメリットがある一方で、停止時間に関する制限が多いハードウェア・リソースやネットワーク・リソースを必要とするというデメリットもあります。たとえば、ノードが6つあるマルチマスター環境で、1つのマスター・サイトが使用できなくなった場合、どのマスター・サイトでもトランザクションは完了しません。
ただし、非同期レプリケーションでは、ダウンしたサイトが使用可能になるまで元のサイトで遅延トランザクションが保持されます。その間に、他のレプリケーション・サイトにはトランザクションが正常に伝播され適用されます。
また、同期レプリケーションを使用すると、問合せがローカルで実行されるため高パフォーマンスを維持できるのに対して、更新処理には時間がかかります。これは、すべての更新内容が正しく伝播され、リモートの接続先サイトへ正しく適用できるように、2フェーズ・コミット・プロトコルを使用しているためです。
|
関連項目: 2フェーズ・コミットの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
同期レプリケーションは、次のように行われます。
DML文を発行または、レプリケート・プロシージャのラッパーを実行します。
表がレプリケーション用に設定された後、ターゲット表に対してユーザーがコミットしたDMLが、他のすべてのマスター・レプリケーション・サイトへのレプリケーション用に取得されます。
プロシージャがレプリケートされており、そのラッパーがマスター・サイトで実行されると、プロシージャ・コールがレプリケーション用に取得されます。
DMLまたはラッパーを実行すると即時に接続先のサイトに伝播されます。
内部トリガーは、DMLを取得し、これらのアクションを即時にレプリケーション環境の各マスター・サイトに伝播します。そして、これらのアクションをプロパゲータのデータベース・リンクのセキュリティ・コンテキストで適用し、内部RPCを使用して接続先サイトにこれらのアクションを適用します。
内部トリガーと同様に、レプリケート・プロシージャのラッパーは、レプリケーション環境の各マスター・サイトにプロシージャ・コールを即時に伝播します。
いずれかのマスター・レプリケーション・サイトでトランザクションが失敗した場合、すべてのマスター・サイトでトランザクションがロールバックされます。この方法により、すべてのマスター・サイト間でのデータ整合性が保証されます。トランザクションがいずれかのサイトで失敗するとロールバックを実行する必要があるので、同期レプリケーションは、可用性の高いネットワーク、データベースおよびそれに関連するハードウェアに大きく依存します。
表がレプリケートされるときに、任意のレプリケーション・サイト(マスター・サイトまたはマテリアライズド・ビュー・サイトのいずれか)のレプリケート表に適用されるDMLのうち、接続先サイトでデータ競合を発生させるDMLは、接続先サイトのOracleサーバーによって自動的に検出されます。マテリアライズド・ビュー・サイトで発生したデータ競合は、マテリアライズド・ビューのターゲット・マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトで検出され、解消されます。
たとえば、次のマスター・グループが1時間に1回変更を伝播するようにスケジュールされていると仮定します。
| 時間 | マスター・サイトA | マスター・サイトB | 状態 |
|---|---|---|---|
| 8:00 AM | マスター・サイトBに変更を伝播 | マスター・サイトAに変更を伝播 | データの収束 |
| 8:15 AM | 行1を更新 | - | - |
| 8:30 AM | - | 行1を更新 | - |
| 9:00 AM | マスター・サイトBに変更を伝播 | マスター・サイトAに変更を伝播 | 行1で競合検出 |
2つのデータ伝播の間の時間を伝播間隔とみなした場合、1つの間隔中に複数のサイトが同じ行を更新すると競合が発生します。
前述した更新の競合のみでなく、挿入および削除時にも競合が発生します。次のようなタイプの競合について考えてみます。各競合は、同じ間隔内に競合するアクションが起こると発生します。
| 競合タイプ | 要約 |
|---|---|
| 更新の競合 | DML文が他のサイトに伝播される前に、複数のDML文が複数のレプリケーション・サイトで同一行に適用される場合。 |
| 一意性競合 | 複数のサイトで挿入を実行した結果、各挿入の主キー(またはその他の一意の列のセット)に同じ値が存在する場合、またはあるサイトで更新を実行した結果、主キー(またはその他の一意の列のセット)が変更され、その主キーに別のサイトで挿入した値と同じ値が存在する場合。 |
| 削除の競合 | あるサイトで行が削除され、別のサイトで同じ行に対して更新が行われる場合(この結果、存在しない行を更新しようとする可能性や、または複数のサイトで同じ間隔で同じ行を削除しようとする可能性があります)。 |
データ競合が検出されると、次のアクションが発生します。
競合解消方法によって、データ競合の解消が試みられます。
競合が解消されない場合は、接続先サイトのエラー・キューでデータ競合がログに記録されます。
エラー・キューにデータ競合がログされた場合、データベース管理者はデータ競合を手動で解消する必要があります。
オラクル社が提供する競合解消方法またはユーザー定義の競合解消方法を使用する場合、Oracleサーバーはデータ競合の自動的な解消を試みます。ユーザーが実装する競合解消方法は、レプリケーション環境で定義されているビジネス・ルールに準拠し、データ収束を保証する必要があります。実装する競合解消方法の要件に合うように、表の変更が必要になる可能性があります。たとえば、最新のタイムスタンプによる競合の解消方法では、実装対象の表にタイムスタンプ列が必要になります。
Oracleのオブジェクト型はユーザー定義データ型で、これを使用すると現実の複雑なエンティティ(顧客や注文など)をデータベース内に単一エンティティ(オブジェクト)としてモデル化できます。オブジェクト型は、CREATE TYPE ... AS OBJECT文を使用して作成します。オブジェクト型とオブジェクトは、マルチマスター・レプリケーション環境のマスター・サイト間でレプリケートできます。
表の1列を占有するOracleオブジェクトを、列オブジェクトと呼びます。一般に、列オブジェクトが含まれている表にはその他の列も含まれており、このような列のデータ型は組込みデータ型(VARCHAR2やNUMBERなど)の場合があります。オブジェクト表とは、各行がオブジェクトを表す特殊な表です。オブジェクト表の各行は行オブジェクトです。
コレクションをレプリケートすることもできます。コレクションとは、VARRAYデータ型およびネストした表のデータ型に基づいたユーザー定義データ型です。VARRAYはCREATE TYPE ... AS VARRAY文を、ネストした表はCREATE TYPE ... AS TABLE文を使用して作成します。
|
注意: アドバンスト・レプリケーションでは、型継承や型進化をサポートしていません。また、NOT FINAL句で作成された型はサポートしていません。レプリケート表またはレプリケートされたオブジェクト表の列がユーザー定義型に基づいている場合、ユーザー定義型を変更することはできません。 |
|
関連項目: ユーザー定義型、列オブジェクト、オブジェクト表およびコレクションの詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください。この項では、このマニュアルに記載されている基本的な情報を理解していることを前提としています。 |
ユーザー定義型には、オブジェクト、ネストした表および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_MASTER_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を指定できます。この場合、次の問合せを実行すると、グローバルに一意のOIDを識別できます。
SELECT SYS_GUID() OID FROM DUAL;
型の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));
/
これで、レプリケーション・サイトで型を使用できます。
|
関連項目: 『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』 |
エクスポート・ユーティリティおよびインポート・ユーティリティを使用すると、レプリケーション・サイト間の型の一致を維持できます。ユーザー定義型に基づいたオブジェクト表またはユーザー定義型に基づいた列オブジェクトを含む表をエクスポートするとき、エクスポートを実行するユーザーにこれらの型に対するアクセス権がある場合は、ユーザー定義型も自動的にエクスポートされます。このような表を別のレプリケーション・サイトでインポートしたときのユーザー定義型は、エクスポートを実行したサイトと同一の型になります。
したがって、エクスポート/インポートを使用して新規レプリケーション・サイトで事前にレプリケーション表を作成しておき、これらの表をレプリケーション・グループに追加するときに「既存オブジェクトの使用」オプションを指定できます。この方法を使用すれば、レプリケーション・サイトで型が一致するようになります。
|
関連項目: エクスポート/インポートの詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
オブジェクト表をレプリケートする場合は、次の条件が適用されます。
全レプリケーション・サイトでオブジェクト表のOIDを同じにする必要があります。
全レプリケーション・サイトでオブジェクト表の各行オブジェクトのOIDを同じにする必要があります。
この条件を満たすには、レプリケーション・マネージメントAPIを使用して、オブジェクト表をレプリケーション・グループに追加し、オブジェクト表を変更し、さらにレプリケーション・グループからオブジェクト表を削除します。たとえば、オブジェクト表をマスター・グループに追加するときにDBMS_REPCATパッケージ内のCREATE_MASTER_REPOBJECTプロシージャを使用すると、この条件が満たされます。この条件を満たすために、エクスポート/インポートを使用してレプリケーション・サイトでオブジェクト表を事前に作成することもできます。
もう1つのオプションとしては、複数のレプリケーション・サイトでオブジェクト表を作成するときにオブジェクト表のOIDを指定する方法があります。このオプションを使用する場合は、次の手順を実行します。
DUALビューに対する問合せを実行し、グローバルに一意のOIDを求めます。
SELECT SYS_GUID() OID FROM DUAL; OID -------------------------------- 81D98C325D4A45D0E03408002074B239
各レプリケーション・サイトで、手順1で戻されたOIDを使用してcategories_tabオブジェクト表を作成します。
CREATE TABLE oe.categories_tab5 OF oe.category_typ OID '81D98C325D4A45D0E03408002074B239' (category_id PRIMARY KEY);
コレクション列とは、VARRAYデータ型およびネストした表のデータ型に基づいた列です。Oracleではコレクション列のレプリケーションをサポートしています。コレクション列を含む表をレプリケーション・グループに追加すると、コレクション列内のデータは自動的にレプリケートされます。コレクション列がVARRAYの場合、4KBより大きいVARRAYはBLOBとして格納されます。
コレクション列がネストした表の場合は、ネストした表の記憶表内の各行に対して行レベルのレプリケーションが実行されます。たとえば、記憶表の5つの行での変更により、5つの別々のリモート・プロシージャ・コール(RPC)が発生し、競合検出およびオプションの競合解消のフェーズが5つになります。記憶表は索引構成表として格納できます。
さらに、ネストした表を含む行に対するDMLにより、親表に対するRPCと、ネストした表の記憶表で影響を受ける各行に対するRPCがそれぞれ別々に発生します。Oracleでは、親表の作成中に整合性制約を明示的に指定しないかぎり、親表の行と記憶表の行との間の参照整合性検査は実行しません。競合をすべて検出するために、レプリケート表にはこのような制約を指定することをお薦めします。
ネストした表とその記憶表との間の競合が検出されるように、この2つの間には遅延可能な外部キー制約を定義することをお薦めします。遅延可能な外部キー制約がないと、競合により記憶表に行が挿入されアクセスできなくなることがあります。遅延可能な外部キー制約が定義してあると、このような場合はエラーが発生して競合が検出されます。制約を遅延させるには、SET CONSTRAINTS文のDEFERRED句を使用します。
次のアクションは、レプリケート表内のネストした表の記憶表に対して直接実行することはできません。
レプリケーション・グループへの記憶表の追加
記憶表の変更
記憶表の削除
記憶表に対するレプリケーション・サポートの生成
これらのアクションは、記憶表の親表に対して実行するときに間接的に発生します。さらに、記憶表内の列のサブセットはレプリケートできません。
REFとはOracleの組込みデータ型で、オブジェクト表内の行オブジェクトを指す論理的なポインタです。有効範囲付きREFは、指定されたオブジェクト表に対する参照のみを含むREFで、有効範囲なしREFにはデータベース内のすべてのオブジェクト表に対する参照を含められます。有効範囲付きREFは、有効範囲なしREFと比べて必要とする記憶領域が少なく、より効率的なアクセスを提供します。Oracleでは、REF型の表のレプリケーションをサポートします。
有効範囲付きREFを含む表がレプリケートされ、REFにより参照されているオブジェクト表がレプリケートされない場合は、有効範囲付きREFを含む表をレプリケートする前に、参照されているオブジェクト表のないサイトに表を作成する必要があります。そうしないと、有効範囲付きREFにより、参照されているオブジェクト表が検出できないときに、この表のレプリケートによりエラーが発生します。このような場合は、通常、参照されているオブジェクト表もレプリケートすることが最善の方法で、レプリケートしないと、様々なレプリケーション・サイトでこの表の同期がなくなる可能性があります。
有効範囲なしREFを含む表がレプリケートされ、REFにより参照されているオブジェクト表がレプリケートされない場合、REFで参照オブジェクトが検出できない場合に、レプリケート・サイトで参照先がないREFが発生する可能性があります。レプリケートされたREFが有効になるには、参照されているオブジェクト表が各レプリケーション・サイトに存在する必要があります。
REF列にWITH ROWIDオプションを指定すると、REFで参照されている行オブジェクトの行IDのヒントがメンテナンスされます。REFに含まれている行IDを使用して、参照されているオブジェクトを直接検出できます(OID索引から行IDをフェッチする必要はありません)。WITH ROWIDオプションは、有効範囲付きREFに対してはサポートされていません。
WITH ROWIDオプションを使用して作成されたREFをレプリケートすると、REFが最初に作成または変更されたサイトを除き、各レプリケーション・サイトで行IDヒントが正しくなくなります。他のサイトではREFに含まれているROWID情報が無意味になります(行IDヒントは自動的には修正されません)。無効な行IDヒントは、パフォーマンス上の問題の原因になります。この場合は、ANALYZE TABLE文のVALIDATE STRUCTUREオプションを使用して、各レプリケーション・サイトの正しくない行IDヒントを判断できます。
|
関連項目: ANALYZE TABLE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
レプリケーション環境は、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースのオンライン・ヘルプおよび『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』で説明している手順や例に従えば作成できますが、レプリケーションのアーキテクチャを理解すると、レプリケーションをサポートするデータベース環境の設定、レプリケーション環境のチューニングやトラブルシューティングを、必要に応じて実施するための重要な情報が得られます。この項では、メカニズムとプロセスの観点からレプリケーションのアーキテクチャについて説明します。
この項には、次の項目が含まれます。
Oracleでは、レプリケーション環境をサポートするために、マルチマスター・レプリケーション環境またはシングル・マスター・レプリケーション環境のいずれかに関係する各マスター・サイトで次のメカニズムを使用しています。これらのマスター・サイト・メカニズムの一部は、特定の環境でのみ必要となります。
セキュリティ要件によっては、管理、伝播および受信の3つのロールが1人のレプリケーション管理者に統合されている場合があります。実際、ほとんどのマルチマスター・レプリケーション環境では、1人のユーザーがレプリケーションの管理、伝播および受信のロールを実行します。セキュリティ要件がより厳格な場合は、次のロールを別々のユーザーに割り当てることができます。
|
注意: このコンテキストのロールという用語は、SQL用語のロールとは関連がありません。レプリケーションにおけるロールは、PL/SQLのストアド・プロシージャまたは個々の権限(あるいはその両方)を使用して付与されます。 |
レプリケーション管理者は、レプリケーション環境のマスター・サイトに関連するすべての管理機能を実行します。一般的に、1つのレプリケーション環境に対して1人のレプリケーション管理者を置くことをお薦めします。レプリケーション管理者は、レプリケーションをサポートするようにデータベースを準備することに加えて次の作業を実行します。
個々のマスター・レプリケーション・グループの作成とメンテナンス
各マスター・サイトの追加と削除
キューの管理
レプリケーション環境の状態(通常および静止中)の制御
レプリケーション管理者のデフォルトのユーザー名はREPADMINですが、別のユーザー名を使用することもできます。
プロパゲータは、遅延トランザクション・キューに含まれる各トランザクションを接続先に伝播する作業を実行します。プロパゲータは、各データベースに1つ存在します。つまり、異なるスキーマを管理するために複数のレプリケーション管理者を置くことはできますが、それぞれのデータベースには1つのプロパゲータしか配置できません。
データベース・リンクは、マスター・サイトとマテリアライズド・ビュー・サイト間でデータをレプリケートするためのパイプ役になります。マルチマスター環境では、各マスター・サイトからその他の各マスター・サイトに対してデータベース・リンクが存在します。つまり、各マスター・サイトにつきN - 1個(Nはマスター・サイトの合計数)のデータベース・リンクが存在します。
図2-3では、各マスター・サイトから他のマスター・サイトに対して2つ(N-1、すなわちこの例では3-1 = 2)のデータベース・リンクが存在します。この構成では、マルチマスター・レプリケーションに必要な両方向通信チャネルがマスター・サイト間で保証されます。マテリアライズド・ビュー・サイトの場合は、マテリアライズド・ビュー・サイトからマスター・サイトへのリンクのみが必要な点に注意してください。マスター・サイトからマテリアライズド・ビュー・サイトへのデータベース・リンクは不要です。
最も基本的なデータベース・リンクは、個々のマスター・サイトのレプリケーション管理者と、関係する他のマスター・サイトのレプリケーション管理者とを結ぶデータベース・リンクです。
ただし、通常はレプリケーション環境にデータベース・リンクのセットを追加します。レプリケーション管理者のデータベース・リンクを作成する前に、CONNECT TO句を指定せずに各マスター・サイト間にパブリック・データベース・リンクを作成します。パブリック・データベース・リンクは、リモート・データベースのサービス名を指定するUSING句を使用して各データベース・リンクのターゲットを指定します。
パブリック・データベース・リンクを作成した後で、レプリケーション管理者のプライベート・データベース・リンクを作成できます。プライベート・データベース・リンクの作成時はCONNECT TO句を指定しますが、対応付けられたパブリック・データベース・リンクにより、USING句の指定が不要になります。
パブリック・データベース・リンクとプライベート・データベース・リンクの両方を使用すると、データベース・リンクの管理に必要な労力が軽減されます。次の利点もあります。
複数のセットのプライベート・データベース・リンクで同じパブリック・データベース・リンクを共有でき、しかもデータベース・リンクの管理が簡単になります。
データベース・リンクのターゲット・データベースを変更した一方で、ターゲット・データベースのサービス名がそのままの場合、変更する必要があるのはtnsnames.oraファイルのターゲット・データベースのエントリのみです。USING句により指定されるのはリモート・ターゲット・データベースのサービス名であることを覚えておいてください。ターゲットが同じプライベート・データベース・リンクはすべて、パブリック・データベース・リンクのUSING句で定義した接続先にリンクされます。
たとえば、データベースを別のサーバーに移動しても同じサービス名をそのまま使用する場合は、各レプリケーション・サイトでtnsnames.oraファイルのリモート・データベースのエントリを更新すれば、データベース・リンクを再作成する必要はありません。
前述のように、レプリケーション管理者は、通常、マルチマスター環境の管理作業および伝播作業を実行します。これらの作業を実行するのは1人のユーザーであるため、レプリケーション管理者用にプライベート・データベース・リンクを1セットのみ作成する必要があります。
ただし、レプリケーション管理者以外のユーザーが伝播を実行するマルチマスター・レプリケーション環境では、これらのユーザーのそれぞれに対して適切なプライベート・データベース・リンク・セットを作成する必要があります。
|
関連項目:
|
Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースのウィザードを使用してレプリケーション・サイトを設定すると、デフォルトでは、tnsnames.oraファイルまたはOracle Management Serverのサービス名の説明を含むUSING句を使用して、データベース・リンクが作成されます。
たとえば、tnsnames.oraファイルでサイトのエントリが次のように指定されているとします。
HQ.MYCOMPANY.COM = (DESCRIPTION= (ADDRESS=(PROTOCOL=TCP)(HOST=server1)(PORT=1521)) (CONNECT_DATA=(SID=hqdb)(SERVER=DEDICATED)))
この場合、サービス名はHQ.MYCOMPANY.COMで、その説明は最初の等号の後に続くテキストです。次の文は、ウィザードにより作成されたHQ.MYCOMPANY.COMサイトへのデータベース・リンクの例を示します。
CREATE PUBLIC DATABASE LINK "HQ.MYCOMPANY.COM" USING '(DESCRIPTION= (ADDRESS=(PROTOCOL=TCP)(HOST=server1)(PORT=1521)) (CONNECT_DATA=(SID=hqdb)(SERVER=DEDICATED)))';
ウィザードはサービス名自体ではなくサービス名の説明を使用しますが、これは、tnsnames.oraファイル内の情報がサイトごとに異なる可能性があるためです。たとえば、ウィザードがサービス名のみを使用し、サービス名の説明を使用しなかった場合は、全サイトに同一サービス名が存在し、全サイトのtnsnames.oraファイル内の情報が同じであることをユーザーが確認する必要があります(アドバンスト・レプリケーション・インタフェースではこの要件をチェックできません)。
ウィザードは、サービス名の説明を使用することで、データベース・リンクが全レプリケーション・サイトで有効なことを保証します。このタイプのデータベース・リンクの弱点は、まれにデータベースのサービス名の説明が変更された場合に、データベース・リンクを削除して再作成が必要になることです。説明ではなくサービス名のみを使用してデータベース・リンクを作成した場合は、全サイトでtnsnames.oraファイルを変更してもデータベース・リンクをそのまま使用できます。
|
注意: ウィザードのデフォルトの動作は、このウィザードのカスタマイズ画面を編集して上書きできます。 |
接続修飾子を使用すると、同じリモート・データベースにリンクされている複数のデータベース・リンクに異なるパスを指定して接続を確立できます。たとえば、データベースnyでは、ny.example.comという名前の2つのパブリック・データベース・リンクに異なるパスを指定して、リモート・データベースに接続できます。
ny.example.com@ethernet: イーサネット・リンクを使用してnyに接続するリンクです。
ny.example.com@modem: モデム・リンクを使用してnyに接続する別のリンクです。
レプリケーションでは、接続修飾子の使用により、複数のマスター・グループの伝播特性をより厳密に制御できます。たとえば、各マスター・サイトに3つの別のマスター・グループがあり、接続修飾子を指定していないと想定した場合、遅延トランザクション・キューの伝播のスケジューリング特性はどのマスター・グループも同じです。この3つのマスター・グループのうち、1つのマスター・グループが遅延トランザクションを1時間に1回伝播し、残りの2つのマスター・グループが1日に1回伝播したとすると、コストが高くなる可能性があります。
接続修飾子をマスター・グループと対応付けると、遅延トランザクション・キューの伝播のスケジューリング特性を、前述のようなデータベース・レベルではなくマスター・グループ・レベルで個別に定義できます。
|
関連項目: データベース・リンク用の接続修飾子の定義の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
マスター・グループを作成するときに、そのグループに対応するすべてのスケジュール・リンクに1つの接続修飾子を使用するよう指定できます。ただし、マスター・グループに接続修飾子を使用すると、各マスター・サイトで接続修飾子を使用してデータベース・リンクを作成しないと情報が伝播されません。マスター・グループを作成した後は、グループの接続修飾子の削除、追加または変更はできません。
|
注意: 接続修飾されたリンクと複数のマスター・グループを使用するマルチマスター環境でのトランザクションの一貫性を保持するため、接続修飾子が異なる複数グループのレプリケーション・オブジェクトを、単一のトランザクションで操作することはできません。 |
|
注意: 接続修飾子を使用する場合は、すべてのマスター・サイトのOPEN_LINKS初期化パラメータの値を大きくすることが必要な場合があります。デフォルトでは、プロセスごとのオープン・リンク数は4つです。用途に応じて、必要な値を見積もります。OPEN_LINKSの詳細は、「初期化パラメータ」および『Oracle Databaseリファレンス』を参照してください。 |
レプリケーション環境の中で最も理解しやすいのは、レプリケート・オブジェクト自体です。レプリケート・オブジェクトの中では、レプリケート表がレプリケーション環境の基盤です。次の項では、関連するデータベース・オブジェクトのレプリケーションについて説明します。特に、次のタイプのデータベース・オブジェクトをレプリケートする場合の利点および制限事項を中心に説明します。
ほとんどの場合、レプリケート表がレプリケーション環境の基盤です。レプリケーション用の表を選択し、レプリケーション・サポートを生成すると、表に対してDMLが適用されているかどうかを検出するために、内部トリガーによって監視が行われます。
表をレプリケートするときは、表構造と表データをリモート・データ・サイトにレプリケートすることも、表構造のみをレプリケートすることもできます。また、同じ名前と構造の表がターゲットのレプリケーション・サイトにすでに存在する場合は、レプリケーション環境内の既存のオブジェクトを使用することもできます。
表のレプリケーションは、表データに加えられたすべての変更をレプリケーション環境に関係するすべてのサイトにレプリケートすることを目的としていますが、これ以外の用途もあります。
オブジェクトおよびデータのトランスポート: オブジェクトがターゲットの接続先サイトにレプリケートされると、それ以降レプリケーション・サポートは自動的には生成されません。オブジェクトとデータのトランスポートにより、オブジェクトとデータをリモートの接続先に簡単に配布できます。レプリケーション・オブジェクトの削除およびレプリケーション・サポートの生成を行っていない場合は、表(またはその他のオブジェクト)およびデータはリモートの接続先サイトに残り、リモートの接続先サイトの変更は一切レプリケートされません。この方法により、標準のデータベース環境とデータ・セットを新しいデータベース環境に配布できます。
オブジェクトのトランスポート: 同様に、データをコピーせずにターゲットの接続先サイトに表をレプリケートできます。この方法により、接続先サイトにオブジェクトが作成されますが、データは移入されません。したがって、空のデータベース環境を即時に配布できます。
レプリケーション用の表が選択され、リモート接続先サイトで作成されると、表内での制約の施行に使用する索引がリモート・サイトで自動的に作成されます。ただし、パフォーマンス上の理由から索引を使用する場合は、レプリケーション用の索引を明示的に選択して、レプリケーション環境に関係する他のマスター・サイトに作成する必要があります。索引が別のサイトにレプリケートされると、ローカルで作成されたかのように動作します。索引のレプリケーション・サポートを生成する必要はありません。
Oracleではドメイン索引のレプリケーションをサポートしています。ドメイン索引の記憶表の定義はレプリケートできますが、記憶表には通常はROWID情報が含まれているため、記憶表自体はレプリケートできません。
|
関連項目:
|
レプリケーション用のパッケージとパッケージ本体を選択し、必要なレプリケーション・サポートを生成すると、プロシージャ・レプリケーションを実行できます。プロシージャ・レプリケーションを使用すると、レプリケーション環境でシリアルに実行されて大量の行を処理する、大規模なバッチ指向操作のパフォーマンスが向上します。
レプリケーション・サポートを使用するプロシージャのパラメータはすべて、INパラメータである必要があり、「レプリケート表のデータ型に関する考慮事項」で説明されているデータ型の要件を満たす必要があります。OUTモードおよびIN/OUTモードはサポートされていません。
レプリケート・プロシージャは、パッケージ内で宣言する必要があります。スタンドアロン・プロシージャにはレプリケーション・サポートはありません。
|
関連項目: プロシージャ・レプリケーションの使用方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。 |
|
注意: 「表」で説明した概念と同様に、レプリケーション・サポートを生成せずにレプリケーション用のパッケージおよびパッケージ本体を選択すると、このオブジェクトをリモート・サイトに簡単に配布できます。ただしその場合、パッケージに対するコールはレプリケートされません。 |
パッケージの一部として宣言されていないプロシージャおよびファンクションは、レプリケーション・サポートされません。スタンドアロンのプロシージャとファンクションを使用してプロシージャ・レプリケーション環境を作成できませんが、レプリケーションを使用してこれらのスタンドアロンのプロシージャとファンクションをレプリケーション環境の各サイトに配布することはできます。スタンドアロンのプロシージャまたはファンクションがレプリケーションを使用してリモート・サイトで作成されると、作成されたオブジェクトはレプリケーション・サポートされず、ローカルで作成されたかのように動作します。
ユーザー定義型を含むスキーマ・オブジェクトをレプリケートするには、全レプリケーション・サイトに同一のユーザー定義型が存在する必要があります。
各マスター・サイトにアプリケーション・ロジックまたはデータベース・ロジックがあることを確認するために、レプリケーション用のトリガーを選択できます。トリガーのレプリケーションの重要な例として、DMLが表に適用されたときに表に自動的にタイムスタンプを挿入するトリガーのレプリケーションがあります。
トリガーが再起動されないようにするには、APIコールをトリガーに挿入して、トリガーがローカル・コールまたはリモート・コールによって起動されているかどうかを検出することが重要です。これにより、トリガーが行を更新して、その更新が別のマスターサイトに伝播されたときトリガー再起動の原因となる状況を回避できます。
次のコード例の5行目を見てください。
1) CREATE OR REPLACE TRIGGER hr.insert_time 2) BEFORE 3) INSERT OR UPDATE ON hr.employees FOR EACH ROW 4) BEGIN 5) IF DBMS_REPUTIL.FROM_REMOTE = FALSE THEN 6) :NEW.TIMESTAMP := SYSDATE; 7) END IF; 8) END; 9) /
DBMS_REPUTIL.FROM_REMOTEファンクションによって挿入または更新がローカルで開始されたと判断されると、定義されているアクション(タイムスタンプ割当て)が実行されます。挿入または更新がリモート・サイトから開始されたと判断された場合は、タイムスタンプ値は割り当てられません。この例は、timestamp列がhr.employees表に追加されたことを前提としています。
|
関連項目: レプリケート・トリガーの作成方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。 |
ビュー、オブジェクト・ビューまたはシノニムをレプリケーション環境に関係する他のマスター・サイトに配布するには、レプリケーションを使用します。オブジェクトが他のサイトにレプリケートされると、そのオブジェクトはローカルで作成されたかのように動作します。変更を取得するためにオブジェクトを監視する内部トリガーまたはパッケージはありません。ただし、オブジェクトはレプリケート・オブジェクトであるため、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースまたはレプリケーション・マネージメントAPIを使用して削除または変更できます。
Oracleでは索引タイプのレプリケーションをサポートしています。Enterprise Managerのアドバンスト・レプリケーション・インタフェースまたはDBMS_REPCATパッケージ内のCREATE_MASTER_REPOBJECTプロシージャを使用して、索引タイプの実装に使用するタイプとタイプ本体のファンクションを明示的にレプリケートする必要があります。
|
関連項目: 拡張索引の詳細は、『Oracle Databaseデータ・カートリッジ開発者ガイド』を参照してください。 |
オブジェクト指向アプリケーションの開発者は、ユーザー定義演算子と呼ばれるドメイン固有の演算子(Contains、Within_Distance、Similarなど)を使用して、組込みのリレーショナル演算子(+、-、/、*、LIKEなど)のリストを拡張できます。ユーザー定義演算子をレプリケーション環境に関係する他のマスター・サイトに配布するには、レプリケーションを使用します。オブジェクトが他のサイトにレプリケートされると、演算子はローカルで作成されたかのように動作します。変更を取得するためにオブジェクトを監視する内部トリガーまたはパッケージはありません。ただし、レプリケート・オブジェクトであるため、レプリケーション・マネージメントAPIを使用して削除または変更できます。
|
関連項目: 『Oracle Databaseデータ・カートリッジ開発者ガイド』 |
異なるデータベースの2つの順序で同じ値が生成されることがあるため、順序のレプリケーションはサポートしていません。
順序のレプリケーションの代替方法が3つあり、これらの方法を使用すると、一意の値の生成と一意性のデータ競合が確実に回避されます。次のSELECT文を実行すれば、一意識別子を取り出せます。
SELECT SYS_GUID() OID FROM DUAL;
このSQL文は、グローバルに一意な16バイトの識別子を返します。この値は、タイムスタンプと日付スタンプおよびマシン識別子を使用してグローバルに一意な識別子を生成するアルゴリズムに基づいています。グローバルに一意な識別子は、次の形式で表示されます。
4595EF13AB785E73E03400400B40F58B
SYS_GUID()ファンクションを使用する第2の方法として、各マスター・サイトに順序を作成し、サイト名(またはその他のグローバルに一意な値)とローカルの順序を連結する方法があります。この方法は、順序の値の重複や、「競合解消の概念」で説明している挿入競合の発生を回避するのに役立ちます。
さらに、レプリケーション環境内で一意の値を生成するように各マスター・サイトで順序を作成する方法があります。これを実現するには、CREATE SEQUENCE文で開始値、増分値および最大値の組合せを使用します。たとえば、次のように設定すると想定します。
| パラメータ | マスター・サイトA | マスター・サイトB | マスター・サイトC |
|---|---|---|---|
START WITH |
1 |
3 | 5 |
INCREMENT BY |
10 | 10 | 10 |
| 範囲の例 | 1, 11, 21, 31, 41,... | 3, 13, 23, 33, 43,... | 5, 15, 25, 35, 45,... |
同様の方法を使用して、各サイトに対して一意の範囲を生成するSTART WITHとMAXVALUEを指定することにより、各マスター・サイトごとに異なる範囲を定義できます。
内部トリガーは、レプリケート・データの更新に関する情報の取得および格納に使用します。内部トリガーによって、ローカル・サイトで加えられたデータ変更をリモート・サイトで再生成するリモート・プロシージャ・コール(RPC)が作成されます。遅延RPCは、遅延トランザクション・キューに格納され、レプリケーション環境に関係する他のマスター・サイトに伝播されます。データ・レプリケーションをサポートする内部トリガーは、Oracleサーバー実行モジュール内の必須コンポーネントです。したがって、システム・リソースを最小限に使用して、レプリケート・データへの更新内容を高速に取得し、格納できます。
前述の内部トリガーによって生成されるRPCを伝播(送信および実行)することにより、データ・レプリケーション情報が転送されます。このRPCは、遅延トランザクション・キューに格納されます。各RPCには、接続先サイトでの内部プロシージャの実行コマンドのみでなく、ターゲット・サイトにレプリケートされるデータも含まれています。Oracleでは分散トランザクション・プロトコルを使用しているため、グローバルなデータベース整合性が自動的に保護され、データの耐障害性が保証されます。
内部トリガーによって作成された遅延RPCがレプリケーション環境に関係する他のマスター・サイトに伝播されると、遅延RPCは接続先サイトの内部プロシージャによってリモート・サイトで適用されます。この内部プロシージャは、表のレプリケーション・サポートを生成するときに自動的にアクティブ化されます。また、この内部プロシージャは、発行元サイトの遅延トランザクション・キューから受信されるRPCに基づいて実行されます。
次のキューは、アドバンスト・レプリケーションによって生成されるトランザクションを管理します。
このキューには、マスター・グループ内の別の接続先に伝播されるトランザクション(たとえば、DML)が格納されます。遅延伝播用に、サイトの遅延トランザクション・キューの内部トリガーによって生成されるRPCが格納されます。また、トランザクションを構成するすべてのRPCがトランザクションとして伝播されてリモートで適用されるように、開始トランザクションに関する情報も記録されます。Oracleのレプリケーション機能では、Oracle Advanced Queuingのメカニズムを使用して遅延トランザクション・キューが実装されます。
|
注意: ENABLE RESTRICTED SESSION句を指定したSQL文ALTER SYSTEMで制限付きセッションを使用可能にすると、遅延トランザクションは伝播されません。制限付きセッションが使用禁止になっている場合は、伝播されます。 |
通常はレプリケーション環境をサポートする管理作業を処理するために、いくつかのメカニズムが必要です。このメカニズムを使用すると、レプリケーション環境をオンまたはオフにしたり、レプリケーション環境の作成時または変更時に生成される管理作業を監視できます。
レプリケーション環境の操作モードは3つあります。
通常モードのレプリケーション環境では、レプリケーションを使用できます。レプリケーション環境はこのモードで実行されます。レプリケート・オブジェクトに対してトランザクションを実行でき、トランザクションは適切に伝播されます。
静止モードは、レプリケーション環境が通常モードから静止中モードに移行する段階のモードです。レプリケーション環境の静止中は、ユーザーは、レプリケート・オブジェクトに対してトランザクションを実行できませんが、既存の遅延トランザクションは伝播されます。静止表に対する問合せはできます。各接続先へのすべての遅延トランザクションが正しく伝播終了すると、レプリケーション環境は静止中モードに変わります。
静止中レプリケーション環境は通常のレプリケーションの使用では無効とみなすことができ、主に(レプリケート・オブジェクトの追加や削除などの)管理目的で使用されます。このモードではレプリケーションは「停止」されます。静止状態では、ユーザーはレプリケーションをオフにしないかぎり、静止マスター・グループのレプリケート・オブジェクトに対するトランザクションの実行はできません。これによりレプリケーションの再開後にデータの不一致が発生する場合があります。トランザクションには、レプリケート表に対するDMLやレプリケート・プロシージャ用のラッパーの実行などがあります。マスター表が静止中の場合、これらのマスター表に基づくマテリアライズド・ビューは自身の変更をターゲット・マスター表に伝播できませんが、マテリアライズド・ビューへのローカルな変更は継続できます。
レプリケーション環境は、マスター・グループ・レベルで静止します。マスター・グループに含まれているすべてのマスター・サイトが影響を受けます。マスター・グループが静止中状態になると、遅延トランザクション・キューのトランザクションが他のマスター・サイトに正常に伝播されたか、エラー・キューに入れられたことを確認できます。ユーザーは静止中のマスター・グループに属する表に対しては、引き続き問合せを実行できます。
1つのマスター・グループを静止しても、その他のマスター・グループには影響しません。通常モードのマスター・グループでは、その他のマスター・グループの静止中も更新処理を継続できます。
レプリケーションの3つの操作モードは、中断および再開の2つのメカニズムで制御されます(静止モードは通常モードから静止中モードへの移行段階のモードです)。
レプリケーション環境を構成および管理するために、関係する各サーバーはOracleのレプリケーション・マネージメントAPIを使用します。サーバーのレプリケーション・マネージメントAPIは、レプリケーション機能を構成するために管理者が使用できるプロシージャおよびファンクションをカプセル化したPL/SQLパッケージのセットです。また、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースでは、各サイトのレプリケーション・マネージメントAPIのプロシージャおよびファンクションを使用して作業を実行します。
管理要求とは、Oracleのレプリケーション・マネージメントAPIのプロシージャまたはファンクションをコールすることです。たとえば、Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用してマスター・グループを作成するときに、このインタフェースは、DBMS_REPCAT.CREATE_MASTER_REPGROUPプロシージャをコールして作業を実行します。管理要求には、追加のレプリケーション・マネージメントAPIコールを生成して要求を処理するものもあります。
Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用するか、DBMS_REPCATパッケージのプロシージャをコールしてレプリケーション・システムを管理すると、内部メカニズムによって要求は同期ブロードキャストされます。なんらかの理由で同期でのブロードキャストが失敗した場合は、エラー・メッセージが戻され、それを含むトランザクションがロールバックされます。
Oracleサーバーが管理要求を受信すると、 DBA_REPCATLOGビューに要求が記録され、対応するDDL文がDBA_REPCATLOGビューの子表に記録されます。マスター・サイトのマスター・グループの管理要求を表示すると、別のマスター・サイトからのコールバックを待機している要求が含まれる場合があります。このような要求は、AWAIT_CALLBACK要求と呼ばれます。DBA_REPCATLOGビュー内の管理要求がすべて適用され、エラーがすべて解決されるまで、マスター・レプリケーション・アクティビティは再開できません。
Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用してレプリケーション・グループの管理要求を作成する際、そのグループに対してジョブが存在しない場合は、ローカル・ジョブ・キューにジョブが自動的に挿入されます。このジョブは定期的にDBMS_REPCAT.DO_DEFERRED_REPCAT_ADMINプロシージャを実行します。要求を同期ブロードキャストすると、レプリケートされた変更を各マスター・サイトに適用するためにこのジョブが即時に開始されます。
エラーがない場合、バックグラウンド・プロセスがジョブ実行用に使用可能なときはDO_DEFERRED_REPCAT_ADMINが実行されます。バックグラウンド・プロセスの実行頻度は自動的に判断されます。未処理ジョブを実行するために十分な数のバックグラウンド・プロセスを使用できない場合、処理が遅れることがあります。
マスター・サイトでDO_DEFERRED_REPCAT_ADMINをコールするたびに、DBA_REPCATLOGビューがチェックされ、実行する必要のある要求があるかどうかが確認されます。管理要求が1つでも存在すると、要求が適用され、ローカル・ビューが適切に更新されます。このイベントは、各マスター・サイトで非同期に発生します。
DO_DEFERRED_REPCAT_ADMINは、所定の順序でローカルの管理要求を実行します。DO_DEFERRED_REPCAT_ADMINがマスター定義サイトではないマスター・サイトで実行される場合、可能な範囲で処理が実行されます。ただし、レプリケート表へのデータの移入などのいくつかの非同期アクティビティでは、マスター定義サイトとの通信が必要になります。通信が不可能な場合は、DO_DEFERRED_REPCAT_ADMINによって管理要求の実行が停止され、管理要求が順序を無視して実行されるのを防ぎます。マスター定義サイトで管理要求を更新または削除する最終ステップなど、マスター定義サイトとの通信の中には遅延可能なものもありますが、そのような通信によってDO_DEFERRED_REPCAT_ADMINによる追加の要求の実行が妨げられることはありません。
各マスター・サイトで管理要求が成功または失敗したことが、各サイトのDBA_REPCATLOGビューに記述されます。マスター・グループごとに、各管理要求に対応する状態がEnterprise Managerのアドバンスト・レプリケーション・インタフェースに表示されます。最後に、各マスター・サイトは、その管理要求の状態をマスター定義サイトに伝播します。マスター・サイトで要求が正常に完了した場合、マスター定義サイトのDBA_REPCATLOGビューからサイトのコールバックが削除されます。
すべてのサイトで要求が正常に完了した場合は、マスター定義サイトを含むすべてのサイトのDBA_REPCATLOGビューのエントリがすべて削除されます。マスター定義サイト以外のサイトで要求が失敗した場合は、マスター・サイトの要求が削除され、マスター定義サイト内の対応するAWAIT_CALLBACK要求がERRORステータスと失敗の理由で更新されます。
変更を同期でブロードキャストすることで、すべてのサイトで変更を確実に認識し、同期が取れた状態に保持できます。後の特定の時点でサイトに変更を適用でき、変更の適用に最も適した時点を自由に選択できます。
オブジェクトにレプリケーション・サポートが必要な場合、オブジェクトの変更後にレプリケーション・サポートを再生成する必要があります。Oracleでは、内部トリガーをアクティブ化し、パッケージを再生成して、すべてのマスター・サイトにある変更後のオブジェクトのレプリケーションをサポートしています。
|
注意: エラーなしにこれらのプロシージャを完了させるにはDDLをマスター定義サイトで正常に適用する必要がありますが、これによって、DDLが各マスター・サイトで正常に適用されることが保証されるわけではありません。Enterprise Managerのアドバンスト・レプリケーション・インタフェースにより、すべての管理要求の状態が表示されます。また、DBA_REPCATLOGビューには、一時的な状態および要求によって生成される非同期のエラー・メッセージが含まれます。 |
DDL変更によって影響を受けるマテリアライズド・ビュー・サイトは、そのマテリアライズド・ビュー・サイトのリフレッシュを次に実行するときに更新されます。すべてのマスター・サイトが他のマスター・サイトと通信できるのに対して、マテリアライズド・ビュー・サイトが通信できるのは、対応付けられたマスター・サイトのみです。
マテリアライズド・ビューのマスターに変更を加えた結果、マテリアライズド・ビューの形式を変更する必要がある場合は、マテリアライズド・ビューを削除してから再作成します。
DBA_REPCATLOGビュー(通常、管理要求キューと呼ばれます)には、レプリケーション環境を管理および変更する管理要求が格納されます。一部のDBMS_REPCATプロシージャは、実行すると管理要求キューにリストされます。たとえば、既存のマスター・グループにレプリケート表を追加すると、DBMS_REPCAT.CREATE_MASTER_REPOBJECTプロシージャという要求が表示されます。
管理要求キューを表示するには、DBA_REPCATLOGビューを問い合せるか、Enterprise Managerのアドバンスト・レプリケーション・インタフェースの「管理要求」ページを表示します。
各要求には、要求の状態を表すステータスがあります。状態は、次のとおりです。
READY: READY状態は、要求を実行する準備が整っている状態を示します。管理要求キューを監視しているときに、ある要求がしばらくの間READY状態である場合、その要求の前にコールバック待機中の要求が存在している可能性があります。通常、READY状態の管理要求は、ジョブが要求を実行するのを待機しています。このような要求は、DBMS_REPCATパッケージ内のDO_DEFERRED_REPCAT_ADMINプロシージャを使用して手動で実行できます。
AWAIT_CALLBACK: AWAIT_CALLBACK状態は、ある要求が別のサイトでの実行を待機中であり、かつその実行の確認を待機している状態を示します。要求がコールバックを受信すると、その要求は削除されるか、状態が変更されます。要求が正常に適用された場合はその要求キューから削除され、失敗した場合はそのステータスがERRORに変更されます。この状態は、マスター定義サイトでのみ発生します。
ERROR: 要求を正常に実行できない場合、ERROR状態になります。エラー番号がERRNUM列に表示され、エラー・メッセージが管理要求キューの「メッセージ」列(Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用している場合は「管理要求」ページの「ステータス」フィールドの「エラー」)に表示されます。
|
注意: 要求がERROR状態にある場合は、エラー番号による説明に従ってエラー状態を解消し、要求を再送信してください。 |
DO_CALLBACK: マスター・サイトの要求がDO_CALLBACK状態にある場合、要求が成功したか失敗したかどうかをマスター・サイトからマスター定義サイトに通知する必要があります。この状態は、マスター定義サイト以外のマスター・サイトでのみ発生します。
各マスター・サイトの管理要求キューには、そのマスター・サイトで実行される管理要求のみがリストされています。ただし、マスター・グループのマスター定義サイトには、各マスター・サイトで実行される管理要求がリストされています。DBAは、マスター定義サイトの管理要求キューを使用すると、レプリケーション環境のすべてのマスター・サイトの管理要求を監視できます。
|
注意: ENABLE RESTRICTED SESSION句を指定したSQL文ALTER SYSTEMで制限付きセッションを使用可能にすると、管理要求は実行されません。制限付きセッションが使用禁止になっている場合は、実行されます。 |
Oracleでは、編成メカニズムを使用して前述のマスター・サイトを編成し、管理メカニズムを使用して個別のレプリケーション・グループを作成します。編成メカニズムの中で最も重要なのは、マスター・グループです。追加の編成メカニズムは、レプリケート表の競合解消に使用する列をグループ化するのに役立ちます。
レプリケーション環境では、レプリケーション・グループを使用してレプリケーション・オブジェクトを管理します。レプリケーション・グループは、常にトランザクションの一貫性を保つように更新されるレプリケーション・オブジェクトの集合です。
レプリケーション・グループ内に関連するデータベース・オブジェクトを編成すると、多数のオブジェクトをまとめて簡単に管理できます。通常、レプリケーション・グループを作成および使用して、特定のデータベース・アプリケーションのサポートに必要なスキーマ・オブジェクトを編成します。ただし、レプリケーション・グループとスキーマが相互に対応している必要はありません。レプリケーション・グループのオブジェクトは、複数のデータベース・スキーマから作成でき、スキーマには異なるレプリケーション・グループのメンバーであるオブジェクトを入れることができます。制限は、レプリケーション・オブジェクトが1つのグループのメンバーにしかなれないことです。
マルチマスター・レプリケーション環境では、レプリケーション・グループはマスター・グループと呼ばれます。異なるサイトの対応するマスター・グループには、レプリケーション・オブジェクトの同一のセットが含まれている必要があります(「レプリケーション・オブジェクト」を参照してください)。図2-4は、各マスター・サイトにレプリケート・オブジェクトの同一のレプリカが含まれているマスター・グループhr_mgを示します。
マスター・サイトのマスター・グループ編成は、マテリアライズド・ビュー・サイトでのレプリケーション・オブジェクトの編成に不可欠です。
また、各マスター・サイトに複数のレプリケーション・グループが含まれている例を図2-5に示します。各マスター・サイトの各グループに含まれているオブジェクトのセットは、同一であることが必要です。
列グループは、競合解消ルーチンと関係するすべての列をグループ化する編成メカニズムを提供します。グループのいずれかの列で競合が発生した場合、残りの列を使用して競合を解消できます。たとえば、表の列グループにmin_price、list_price、cost_priceおよびtimestampというフィールドが含まれており、list_priceフィールドで競合が発生した場合、タイムスタンプによる競合解消ルーチンを使用していたと想定すると、timestampフィールドを使用して競合を解消できます。
表のすべての列を1つの列グループにまとめる必要はありません。すべての列を1つの列グループにまとめれば設定や管理は簡単になりますが、レプリケート表のパフォーマンスが低下し、データ競合が発生する可能性が高くなることがあります。「パフォーマンス・メカニズム」で説明しているように、表の1つの列グループで競合が発生した場合、最小限の通信機能によって、表のその他の列グループからはデータが送信されません。したがって、すべての列を1つの列グループにまとめると、DBMS_REPCATパッケージ内のSEND_OLD_VALUESプロシージャおよびCOMPARE_OLD_VALUESプロシージャを使用しないかぎり、最小限の通信機能の利点がなくなってしまう可能性があります。
伝播は、レプリケーション環境のすべてのマスター・サイトにすべてのアクションを送信または配布するメカニズムであり、レプリケーションにおいて不可欠な要素です。
内部トリガーはレプリケート表に適用されるすべてのDMLを取得するため、レプリケーション環境の他のマスター・サイトにDMLを伝播(送信)する必要があります。内部トリガーの詳細は、「内部トリガー」を参照してください。
アドバンスト・レプリケーションでは、非同期レプリケーションおよび同期レプリケーションの両方をサポートしています。
一般的なレプリケーション構成では、非同期データ・レプリケーションを使用します。非同期データ・レプリケーションは、アプリケーションで表のローカル・レプリカを更新し、レプリケーション情報をローカル・キューに格納し、その後で他のレプリケーション・サイトにレプリケーション情報を転送する場合に発生します。このため、非同期データ・レプリケーションはストア/フォワード・レプリケーションとも呼ばれます。
図2-6に示すように、Oracleでは内部トリガー、遅延トランザクション、遅延トランザクション・キューおよびジョブ・キューを使用して、更新可能マテリアライズド・ビューからマスター表に対する伝播の他、レプリケーション環境のマスター・サイト間でも、データレベルの変更を非同期に伝播します。
Oracleでは、特定の要件を持つアプリケーションに対しては同期データ伝播もサポートしています。同期データ伝播は、アプリケーションによって表のローカル・レプリカが更新され、同じトランザクション内で同じ表の少なくとも1つの他のレプリカも更新されたときに発生します。したがって、同期データ・レプリケーションはリアルタイム・データ・レプリケーションとも呼ばれます。アプリケーションでレプリケート・サイトを継続的に同期化する必要があるとき以外は、同期レプリケーションを使用しないでください。
図2-7に示すように、同じ内部トリガーを使用して、データレベルの変更をその他のレプリケーション・サイトに非同期にレプリケートして、行レベルの同期データ・レプリケーションをサポートするリモート・プロシージャ・コール(RPC)を生成します。ただし、このRPCの実行は延期されません。かわりに、データ・レプリケーションRPCは、ローカル・レプリカを変更する同一のトランザクションの境界内で実行されます。したがって、レプリケート表を管理する同期リンクされたすべてのサイトで、データレベルの変更が可能な必要があり、可能でない場合、トランザクションはロールバックされます。
図2-8に示すように、アプリケーションによってローカルのレプリケート表にDMLによる変更が加えられ、レプリケーション・グループで行レベルの同期レプリケーションを使用しているときは常に、変更内容は内部トリガーによってレプリケーション環境の他のマスター・サイトに同期伝播されます。アプリケーションでローカルな変更が適用されると、内部トリガーからリモート・マスター・サイトで生成されたプロシージャに対して、レプリケーション・プロパゲータのセキュリティ・コンテキストでコールが発行されます。障害が発生した場合は、すべての分散トランザクションがコミットまたはロールバックされます。
|
関連項目: 分散トランザクションの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
2つの異なるサイトで同じ行が同時に更新されるときは、同期レプリケーションで使用されるロック・メカニズムにより、デッドロックが発生することがあります。アプリケーションでレプリケート表への同期更新が実行されると、まずローカル行がロックされ、次にAFTER ROWトリガーを使用して対応するリモート行がロックされます。各サイトでトランザクションがコミットされると、ロックは解放されます。
|
注意: レプリケーション・データのリアルタイム伝播を使用するレプリケーション・システムは、システム内のすべてのサイトが同時に使用可能な場合にのみ機能するため、システムとネットワークの可用性に大きく依存します。 |
同期レプリケーションのサポートに必要なリモート・プロシージャ・コールは、各オブジェクトの内部トリガーに組み込まれています。レプリケート・オブジェクトのレプリケーション・サポートを生成すると、すべてのマスター・サイトでトリガーがアクティブ化され、新しいサイトに必要なリモート・プロシージャ・コールが追加されます。反対に、マスター・グループからマスター・サイトを削除すると、内部トリガーからコールが削除されます。
状況によっては、一部のマスター・サイトでマスター・グループの変更内容を非同期で伝播し、他のマスター・サイトでは同期伝播するような複合モード環境の設定が必要な場合があります。新規マスター・サイトをデータ伝播モードが異なるグループに追加するときは、その順番が重要となることがあります。
たとえば、A、BおよびCの3つのマスター・サイトがあると想定します。まずマスター定義サイトとしてサイトAを作成し、次に同期伝播モードでサイトBを追加した場合、サイトAからサイトBへも、サイトBからサイトAへも変更は同期を取って送信されます。どのサイトでも遅延トランザクションは作成されないため、どちらかのサイトでリンクをスケジュールする必要はありません。
次に、非同期伝播モードでマスター・サイトCを作成するとします。伝播モードは、図2-9に示すようになります。
次に、サイトAからサイトC、サイトBからサイトC、サイトCからサイトAおよびサイトBへの遅延トランザクション・キューの伝播をスケジュールする必要があります。
別の例として、サイトAをマスター定義サイトとして作成し、サイトCを非同期伝播モードで追加した後、サイトBを同期伝播モードで追加する場合を考えてみます。伝播モードは、図2-10に示すようになります。
複合モードのマルチマスター・システムに新規マスター・サイトを追加するときは、その追加が既存のサイトとのデータ伝播モードに与える影響を考慮してください。
同期伝播を使用する場合、DMLが即時に伝播され、自動的に開始されます。非同期伝播を使用する場合は、2つの方法で遅延トランザクションを伝播できます。
スケジュール・ジョブ: 通常、設定したスケジュール間隔に従って遅延トランザクションを自動的に伝播するには、スケジュール・ジョブを使用します。
手動による伝播: ストアド・プロシージャを実行したり、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して、変更を手動で伝播することもできます。遅延トランザクションがジョブ・キューによって自動的に伝播されるまで待機しない場合は、遅延トランザクションを手動で伝播する必要があります。
他のエンタープライズ・データベース・ソリューションと同様に、データベース管理者にとってパフォーマンスは常に重要な課題です。アドバンスト・レプリケーションには、レプリケーション環境のパフォーマンスを高めるいくつかのメカニズムがあります。
パラレル伝播では、スループットを向上させるため、複数のパラレル伝送ストリームを使用してレプリケート・トランザクションを非同期で伝播します。必要に応じて依存トランザクションの実行が命令され、グローバルなデータベースの整合性が保証されます。
パラレル伝播では、使用可能なパラレル処理のプールが使用されます。これは、パラレル問合せ、パラレル・ロード、パラレル・リカバリなどの他のパラレル操作に使用されるプールと同じです。各サーバー・プロセスでは、シングル・ストリームを介してトランザクションが伝播されます。これらのサーバー・プロセスは、パラレル・コーディネータ・プロセスにより制御されます。コーディネータでは、トランザクション依存性を追跡しサーバー・プロセスに作業を割り当て、その進行状況を追跡します。
操作の実行中は、パラレル処理がサーバーのパラレル操作に対応付けられた状態になります。操作が完了すると、サーバー・プロセスは他のパラレル操作の処理に使用できます。たとえば、Oracle Databaseで接続先への遅延トランザクション・キューのパラレル・プッシュが実行されるときは、キューのプッシュに使用されるすべてのパラレル処理は、プッシュが完了するまで占有されます。
サーバー用のパラレル処理のプールを正しく構成するには、レプリケーション・システムの構成に関する問題を考慮する必要があります。
シリアル伝播を使用するようにすべてのスケジュール・リンクを構成すると、レプリケーション・システムではパラレル処理は使用されません。したがって、レプリケーションを考慮して、パラレル処理のプールのサイズを調整する必要はありません。シリアル伝播は、通常、下位互換性が必要な場合にのみ使用します。
1つ以上のスケジュール・リンクをパラレル伝播を使用するように構成する場合、それぞれのリンクが変更を接続先にプッシュするために使用するパラレル処理の数を考慮する必要があります。さらに、別の操作によって使用されないように、各プッシュでパラレル・サーバーを保持する時間を考慮する必要があります。たとえば、遅延秒数値を大きくして連続的な伝播用にスケジュール・リンクを構成すると、接続先にトランザクションをプッシュするために使用するパラレル処理が保持されます。したがって、サーバーの他のパラレル操作で使用するプロセスを十分に確保するために、対応するデータベース・サーバーのパラレル処理の数を増やす必要があります。
パラレル問合せプロセスのデータベース・サーバーのプールを構成するには、次の初期化パラメータを使用します。
ほとんどのユーザーの場合、パラレル伝播パラメータ値を1に設定すると、十分なパフォーマンスが得られます。1に設定すると、シリアル伝播ではなく、前項で説明した最適化されたデータの交換方式が使用されます。ただし、一部のユーザーは、パラレル伝播値をさらにチューニングすることが必要な場合があります。
パラレル伝播値をさらにチューニングする場合、次の手順の実行をお薦めします。
パラレル伝播値を1に設定します。
使用しているデータベース環境をテストし、伝播スループットを慎重に測定します。
パラレル伝播値が1でパフォーマンス目標が達成される場合は、パラレル伝播が実装されたことになるため、残りの手順を実行する必要はありません。
|
注意: パラレル伝播値を大きくすると、パラレル伝播のパフォーマンスが向上する一方で、追加のパラレル処理のサポートに必要なリソースが増大します。 |
パラレル伝播値を1に設定した場合よりもスループットを向上させたい場合は、パラレル伝播値を2に設定します。
使用しているデータベース環境をテストし、伝播スループットを慎重に測定します。
通常、伝播値を2に設定すると、伝播スループットは低下します。これは、依存トランザクションを使用可能なパラレル処理に割り当て、追加トランザクションを割り当てる前に必要なコミットを待機しているコーディネータに関連したラウンドトリップ遅延によるものです。
パラレル伝播値を4に設定して手順3と4を繰り返し、さらに、パラレル伝播値を8に設定して同じ手順を繰り返します。それでもスループットが改善されない場合は、使用している環境のトランザクションの相互依存性が非常に高いことが考えられます。パラレル伝播値を1に下げ、手順5に進んでください。
パラレル伝播値を2、4または8のいずれかに設定することでパフォーマンスが向上した場合は、トランザクションの相互依存性は低いといえます。パラレル伝播値は9以上の値に設定してもかまいません。必ず使用している環境を完全にテストし、パラレル化が増大すれば、追加のパラレル処理のサポートに必要なリソースも増大することに注意してください。
テスト結果に基づき、使用している環境でパフォーマンスが最善になる値にパラレル伝播を設定します。
パラレル伝播のパフォーマンス上の利点を最大限に活用するには、作成する依存トランザクションの数を減らします。トランザクションは、依存関係にあるすべてのトランザクションがコミットされるまで開始できません。
依存トランザクションの数を減らすには、次のようにします。
可能であれば、トランザクションを小さくします(つまり、自律性を損なわない範囲で、コミットの回数を増やします)。
挿入を受け取る各表の空きリスト数を増やします。
ホットスポット(頻繁に修正される行。同じ行がアクセスされると、それらのトランザクションはシリアライズされます)は避けるようにします。たとえば、行のカウンタを使用するかわりにOracle順序を使用して、それを「手動で」インクリメントします。
行レベルの依存性の追跡を行うようにします。
行の更新の競合を検出および解消するには、伝播サイトから受信サイトに新旧の行に関するデータを送信する必要があります。デフォルトでは、レプリケート表内の変更された各行の競合を検出するために通信する必要があるデータの量を最小化します。具体的には、次の値が伝播されます。
主キー値および変更された各列グループの各列の古い値(変更前の値)
それぞれの更新された列の新しい値
|
注意:
|
パフォーマンスに直接かかわるメカニズムではありませんが、delay_secondsパラメータ値を適切に設定すると、遅延トランザクションの伝播のタイミングをより詳細に制御できます。
遅延トランザクションをプッシュする場合は、SCHEDULE_PUSHプロシージャまたはPUSHファンクションにdelay_secondsパラメータを設定します。遅延トランザクションをパージする場合は、SCHEDULE_PURGEプロシージャまたはPURGEファンクションにdelay_secondsパラメータを設定します。これらのプロシージャとファンクションは、DBMS_DEFER_SYSパッケージにあります。
delay_secondsパラメータは、ジョブが遅延トランザクション・キューを認識し続ける時間を制御します。delay_secondsパラメータ値を最大限に活用した2つの例を次に示します。
間隔を60分に設定したスケジュール・ジョブが午後2時30分に起動され、遅延トランザクション・キューをチェックする場合、既存の遅延トランザクションはすべて伝播されます。伝播には2分かかるので、ジョブが完了するのは午後2時32分です。
遅延トランザクションが午後2時34分にキューに入れられた場合、ジョブが完了しているためこの遅延トランザクションは伝播されません。このシナリオでは、遅延トランザクションは午後3時30分に伝播されます。
間隔を60分に設定したスケジュール・ジョブが午後2時30分に起動され、遅延トランザクション・キューをチェックする場合、既存の遅延トランザクションはすべて伝播されます。伝播には2分かかるので、ジョブが完了するのは午後2時32分です。
遅延トランザクションが午後2時34分にキューに入れられた場合、既存の遅延トランザクションの伝播完了後も300秒間(5分間)はジョブによって遅延トランザクション・キューが認識されるので、この遅延トランザクションは伝播されます。このシナリオでは、この遅延トランザクションは午後2時34分に伝播されます。
さらに頻繁にジョブが実行されるように設定できないかという疑問が生じます。ジョブを開始および停止すると、ジョブを開始して一定時間認識し続けるよりもはるかに大きいオーバーヘッドが発生します。delay_secondsパラメータ値を使用すると、ジョブの開始および停止に伴うオーバーヘッドを削減できるだけでなく、スケジュール・ジョブのサポートに必要なREDOロギングの量を減らすことができます。
パフォーマンスにかかわるほとんどの機能と同様に、デメリットもあります。次の理由により、delay_secondsパラメータの長さは常にチェックするようにします。
パラレル伝播: 遅延トランザクション・キューをプッシュするときに使用する各パラレル処理は、その伝播ジョブが完了するまでその他のパラレル・アクティビティでは使用できません。長いdelay_seconds値を定義すると、他の操作がパラレル処理を使用できなくなる可能性があります。パラレル伝播を使用するには、SCHEDULE_PUSHプロシージャまたはPUSHファンクションのparallelismパラメータを1以上に設定します。
シリアル伝播: (パラレル伝播ではなく)シリアル伝播しか使用しない場合、delay_seconds値を設定するとオープン・セッションが遅延時間中スリープするため、この値を設定しても前述のようなメリットはありません。シリアル伝播を使用するには、SCHEDULE_PUSHプロシージャまたはPUSHファンクションのparallelismパラメータを0(ゼロ)に設定します。
精度パージ: DBMS_DEFER_SYS.PURGEプロシージャを使用しているときにpurge_method_preciseメソッドを指定し、delay_seconds値に大きい値を定義した場合、指定したパージの実行時にパフォーマンスが低下する可能性があります。purge_method_preciseは別の選択肢(purge_method_quick)よりもコストがかかりますが、遅延トランザクションとプロシージャ・コールは、正常にプッシュされた後で確実にパージされます。
delay_secondsパラメータに20分(パラメータ設定では1200秒)を超える値を設定しても、通常はメリットはありません。
さらに、parallelismパラメータを0に設定してシリアル伝播を使用している場合は、delay_seconds値はあまり大きくは設定しません。パラレル伝播と異なり、シリアル伝播ではdelay_seconds値の時間が経過した後にのみキューがチェックされます。シリアル伝播を使用し、delay_secondsを20分に設定した場合は、スケジュール・ジョブが20分間すべてスリープし、その間に遅延トランザクション・キューに入れられた遅延トランザクションは、20分経過するまでプッシュされません。したがって、シリアル伝播を使用する場合は、delay_seconds値を60秒以下に設定するようにします。
パラレル伝播値を20分に設定する場合、パラレル・プッシュによって1分に1回チェックされます。リソースを20分間ロックしておいてもかまわない場合は、20分間という比較的長いdelay_seconds値が使用環境で最も効率的といえます。リソースを20分間ロックできない場合は、delay_seconds値を10秒または20秒に設定することを考えます。1200秒に設定した場合よりもジョブの実行回数を多くする必要がありますが、delay_seconds機能を利用するメリットは残ります(デフォルトの0秒に設定した場合と比較した場合)。
マルチマスター・レプリケーション環境では、障害の発生時でも、リモート・サイトに伝播されたトランザクションは消失されず、再伝播されないことが保証されています。トランザクションは次の方法で保護されます。
1つのローカル・トランザクション内で発行された複数のプロシージャ・コールは、1つのトランザクションとしてリモートで実行されます。
伝播の実行中にネットワークまたはリモート・データベースに障害が発生した場合、トランザクションはリモート・サイトでロールバックされ、リモート・データベースが再度アクセス可能になって伝播が正常に完了するまで、レプリケーション元のサイトのローカル・キューに残ります。
トランザクションがローカル・サイトのキューから削除されるのは、すべての接続先サイトへの伝播および適用が正常に完了してからです。トランザクションがすべての接続先サイトに正常に伝播された後でも、パージ・ジョブによって削除されるまで、トランザクションはキューに残ります。
パラレル伝播の場合は、パラレル操作用に最適化された特殊な分散トランザクション・プロトコルが使用されます。リモート・サイトは、正常に伝播されたトランザクションを記録し、この情報が要求されたときに情報をローカル・サイトに戻します。ローカル・サイトは、この情報を記録し、すべての接続先サイトに伝播されたエントリをローカル・キューからパージします。障害が発生した場合、ローカル・サイトは、適切な時点から伝播を続行できるように、正常に伝播されたトランザクションに関する情報をリモート・サイトに要求します。
|
注意: 伝播が正常に完了しても、必ずしもトランザクションがリモート・サイトで正常に適用されるとはかぎりません。解消不能な競合や記憶領域不足などのエラーが発生すると、トランザクションでエラーが発生することがあり、そのエラーはエラー・トランザクションとしてリモート・サイトのログに記録されます。 |
|
関連項目:
|
Oracleは、レプリケート・トランザクションがリモート・サイトに伝播されたときの依存性の順序を維持します。たとえば、次のようなトランザクションがあったとします。
トランザクションAが受注を取り消します。
トランザクションBが取消しを検出して返金を処理します。
トランザクションBは、ローカル・システムでの受注の取消し(トランザクションA)のコミット済の更新を参照するので、トランザクションBはトランザクションAに依存しています。
トランザクションA(受注の取消し)が正常に伝播された後で、トランザクションB(返金)が伝播されます。取消しの適用後に返金を処理する更新が適用されます。
ローカル・システムで新規トランザクションが実行されるときは、次の処理が実行されます。
Oracleは、新しいトランザクションにより見られるデータを依存SCNとして更新する最新のトランザクションのシステム変更番号(SCN)を記録します。SCNは、この章の後半で説明するように、データ・ブロック・レベルまたは行レベルで記録できます。
依存SCN以下のSCNを持つトランザクションが、リモート・システムに正常に伝播されるようにします。
待機中の依存トランザクションが伝播されます。
|
注意: トランザクション間で依存関係の可能性がないときは、トランザクションはパラレルで伝播されます。 |
パラレル伝播は、シリアル伝播とは異なる方法でデータ整合性を保持します。シリアル伝播では、依存性を維持するために、ローカル・システム上でコミットするときと同じ順序ですべてのトランザクションが適用されます。パラレル伝播では、依存性を追跡し、依存性があるときはコミットされた順に実行し、依存性がないときはパラレルで実行します。シリアル伝播でもパラレル伝播でも、トランザクション内の実行順序は保持されます。遅延トランザクションは、各サイトで、ローカル・トランザクション内で実行された順序と同じ順序で、リモート・プロシージャ・コールを実行します。
|
注意: シングル・コーディネータ・プロセスは、リモート・サイトに対する各データベース・リンクに存在しています。同じリモート・サイトに対する各データベース・リンクには、異なる接続修飾子が必要です。 |
表を作成するときは、システム変更番号(SCN)を追跡するために次のオプションを指定できます。
NOROWDEPENDENCIES。SCNがデータ・ブロック・レベルで追跡されることを指定します(デフォルト)。
ROWDEPENDENCIES。SCNが表の各行に対して追跡されることを指定します。
表にNOROWDEPENDENCIES句を使用すると、データ・ブロックSCNはデータ・ブロックに格納されている行の最新の更新を追跡します。その前に更新されている他の行は、同じデータ・ブロックに格納されている可能性がありますが、これらの行がいつ更新されたかを示す情報は、新規SCNがデータ・ブロック・レベルで適用されたときに失われます。
表にROWDEPENDENCIES句を使用すると、1つのデータ・ブロックに複数のSCNを格納できます。つまり、1つのSCNがデータ・ブロック内に格納されている行のそれぞれに対する変更を追跡します。同一データ・ブロックに格納されている2つの行が別々のトランザクションにより変更された場合、行のそれぞれにはこの変更を追跡するSCNがあります。SCNを行レベルで追跡するには、表の各行が6バイトの記憶領域を追加使用します。
表にROWDEPENDENCIES句を使用するとパラレル伝播が使用可能になり、遅延トランザクション・キューの適用時に、より効率良く依存性を追跡して変更に順序を付けられます。効率が上がることによりパフォーマンスが向上し、レプリケーション環境でのスケーラビリティが高まります。
次の問合せを使用すると、現在ROWDEPENDENCIES句を使用している表をリストできます。
SELECT OWNER, TABLE_NAME FROM DBA_TABLES WHERE DEPENDENCIES = 'ENABLED';
レプリケート表のいくつかでROWDEPENDENCIES句を使用していない場合は、トランザクション依存性を最小化することで、これらの表のパラレル伝播のパフォーマンスを改善できます。
この場合、アプリケーション条件によっては、トランザクション間に依存関係を確立して、遅延トランザクションの伝播を強制的にシリアライズできます。複数の非関連トランザクションによってレプリケート表内の同じデータ・ブロックが変更される場合、対応するトランザクションはリモート接続先へシリアル伝播されます。
データ・ブロック・レベルで作成されたトランザクション依存性を最小化するには、データ・ブロックの変更が1つまたは少数のデータ・ブロックに集中することを回避します。たとえば、レプリケート表にINSERTアクティビティが頻繁に発生する場合は、表の空きリストを複数作成することで、新しい行の記憶域を複数のデータ・ブロックに分散できます。
多数のトランザクションすべてが同一の小さい表を更新する状態は、できるだけ避けてください。たとえば、複数のトランザクションが1つの小さい表に読取りと更新を行い、主キーの順序番号生成をシミュレートするのは、望ましいアプリケーション設計とはいえません。このように設計すると、すべてのトランザクションが同じデータ・ブロックを更新します。より優れたソリューションは、順序を作成し順序番号をキャッシュに格納することで、主キーの生成を最適化し、パラレル伝播のパフォーマンスを改善できます。
レプリケーション環境の受信マスター・サイトでは、次のような更新の競合、一意性競合および削除の競合が検出されます。
主キー列または更新された列グループの列のいずれかで、レプリケート行の古い値(変更前の値)と受信サイトの同じ行の現在の値が異なる場合、受信サイトで更新の競合が検出されます。
レプリケート行のINSERTまたはUPDATEの実行中に一意制約違反が発生した場合、受信サイトで一意性競合が検出されます。
行の主キーが存在しないために受信サイトでUPDATE文またはDELETE文の対象の行が見つからない場合、受信サイトで削除の競合が検出されます。
|
注意: 行の更新の競合を検出および解消するには、伝播サイトから受信サイトに新旧の行に関するデータを送信する必要があります。パフォーマンスを最大にするには、更新の競合の検出および解消サポートに使用するデータの量をチューニングします。詳細は、「古い値の送信および比較」を参照してください。 |
レプリケーションの競合を正確に検出するには、データ・レプリケーション時に別々のサイトの対応する行を一意に識別し、一致させる必要があります。通常、Oracleのレプリケーション機能では、表の主キーを使用して表内の行を一意に識別します。表に主キーがない場合は、(データ・レプリケーション時に表内の行を一意に識別するために使用する列または列のセットである)代替キーを指定する必要があります。
|
注意: アプリケーションで表の主キーまたは代替キーを更新しないようにしてください。これにより、行を識別し、レプリケート・データの整合性を保つことができます。 |
Oracleには、データ競合が検出されたときに競合解消方法を定義するメカニズムがあります。ビルトインの競合解消方法は次のとおりです。
最新のタイムスタンプおよび最も古いタイムスタンプ
上書きおよび廃棄
最大値および最小値
加算および平均
タイムスタンプ
優先グループ
サイト優先順位
ビルトインの競合解消方法ではレプリケーション環境のニーズが満たされない場合、PL/SQLを使用して独自の競合解消方法を作成し、ユーザー定義の競合解消方法として実装できます。競合解消の仕組みの詳細は、第5章「競合解消の概念およびアーキテクチャ」を参照してください。
|
関連項目: Oracle Enterprise Managerを使用した競合解消の実装方法の詳細は、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを、レプリケーション・マネージメントAPIを使用した競合解消の実装方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。 |
