ヘッダーをスキップ
Oracle Databaseアドバンスト・レプリケーション
10gリリース2(10.2)
B19219-02
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

2 マスター・レプリケーションの概要とアーキテクチャ

この章では、シングル・マスター・レプリケーション環境およびマルチマスター・レプリケーション環境での、Oracleのマスター・レプリケーション・サイトの概念およびアーキテクチャについて説明します。

この章の内容は、次のとおりです。

マスター・レプリケーションの概念

マスター・レプリケーションのアーキテクチャの詳細を理解するには、マスター・レプリケーションの概念について知っておく必要があります。マスター・レプリケーションの使用方法と目的がわかると、アーキテクチャの個々の要素がどのように相互に作用してマルチマスター・レプリケーション環境が作成されるのか理解が深まります。

マスター・レプリケーションについて

Oracleには、シングル・マスター・レプリケーションとマルチマスター・レプリケーションという、2つのタイプのマスター・レプリケーションがあります。マルチマスター・レプリケーションは、複数のマスター・サイトを含んでおり、各マスター・サイトが同等ピアとして機能します。シングル・マスター・レプリケーションでは、マテリアライズド・ビュー・レプリケーションをサポートする1つのマスター・サイトが、数百、数千のマテリアライズド・ビュー・サイトをサポートします。また、1つ以上のマテリアライズド・ビュー・サイトをサポートする1つのマスター・サイトが、複数マスター・サイト環境の一部として含まれるハイブリッド・レプリケーション環境(マルチマスター・レプリケーションとマテリアライズド・ビュー・レプリケーションの組合せ)を構成することも可能です。

マテリアライズド・ビューは、マスター・サイトのマスター表またはマテリアライズド・ビュー・サイトのマテリアライズド・ビューのいずれかに基づきます。マテリアライズド・ビューがマテリアライズド・ビューに基づいている場合は、多重化マテリアライズド・ビュー環境が作成されます。このような環境では、他のマテリアライズド・ビューの基になるマテリアライズド・ビューがマスター・マテリアライズド・ビューと呼ばれます。


関連項目:

多重化マテリアライズド・ビューの詳細は、第3章「マテリアライズド・ビューの概要とアーキテクチャ」を参照してください。

マルチマスター・レプリケーション

マルチマスター・レプリケーション(peer-to-peerレプリケーションまたはn-wayレプリケーションとも呼ばれます)は、同等な複数のマスター・サイトから構成されており、どのマスター・サイトでも更新が可能です。個々のマスター・サイトに対する更新処理は、関係するすべてのマスター・サイトに伝播されます。図2-1は、マルチマスター・レプリケーション・システムを示します。

マルチマスター・レプリケーション環境でマスター・サイトとして機能しているOracleデータベース・サーバーで、すべての表レプリカのデータが自動的に収束され、グローバルなトランザクション一貫性とデータ整合性が保証されます。競合解消は、各マスター・サイトで独自に行われます。マルチマスター・レプリケーションでは、各マスター・サイトのレプリケート表の完全なレプリカが提供されます。

ハイブリッド・レプリケーション環境(複数のマスター・サイトと各マスター・サイトがサポートする1つ以上のマテリアライズド・ビュー・サイトから構成される環境)の場合、ターゲット・マスター・サイトからマルチマスター・レプリケーション環境の他のすべてのマスター・サイトにマテリアライズド・ビューのすべての更新内容が伝播されます。次に、各マスター・サイトが、マテリアライズド・ビューのリフレッシュ時に変更をマテリアライズド・ビューに伝播します。

図2-1 マルチマスター・レプリケーション

図2-1の説明が続きます。
「図2-1 マルチマスター・レプリケーション」の説明

シングル・マスター・レプリケーション

1つのマスター・サイトを、1つ以上のマテリアライズド・ビュー・サイトのターゲット・マスター・サイトとして機能させることもできます。マルチマスター・レプリケーションでは、1つのサイトに対して行った更新処理はその他のすべてのマスター・サイトに伝播されましたが、シングル・マスター・レプリケーションでは、マテリアライズド・ビューにより、更新がそのターゲット・マスター・サイトにのみ反映されます。

競合解消は、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでのみ処理されます。マテリアライズド・ビュー・レプリケーションには、レプリケート表の全部または一部のレプリカを含めることができます。


関連項目:

1つのマスター・サイトを使用するマテリアライズド・ビュー・レプリケーションの詳細は、第3章「マテリアライズド・ビューの概要とアーキテクチャ」を参照してください。

マスター・サイト

マスター・サイトは、マルチマスター・レプリケーション環境のノード、あるいはシングル・マスター・レプリケーション環境またはマルチマスター・レプリケーション環境の1つ以上のマテリアライズド・ビュー・サイトのマスター(あるいはその両方)として設定できます。レプリケート・オブジェクトはマスター・サイトに格納され、ユーザーがアクセスできます。

マスター定義サイト

マルチマスター・レプリケーション環境では、1つのマスター・サイトがマスター・グループのマスター定義サイトとして機能します。この特定のサイトで、マルチマスター・レプリケーション環境の管理作業やメンテナンス作業の多くが実行されます。

マスター定義サイトはマルチマスター環境のどのマスター・サイトでもかまいませんが、各マスター・グループ内に設定できるのは1つのみです。また、必要に応じて、マスター定義サイトを別のマスター・サイトに変更することもできます。

マテリアライズド・ビュー・レプリケーションをサポートするシングル・マスター・サイトは、デフォルトでマスター定義サイトになります。

マルチマスター・レプリケーションの使用目的

基本的に、レプリケーションを使用するのは、必要なときに必要な場所でデータを確実に使用するためです。次の項では、情報の配布要件が異なるいくつかの環境について説明します。使用するレプリケーション環境には、次のような要件が1つ以上ある可能性があります。

フェイルオーバー

マルチマスター・レプリケーションは、ミッション・クリティカルなデータベースの可用性を保護するのに役立ちます。たとえば、マルチマスター・レプリケーション環境では、システムまたはネットワーク障害が発生してプライマリ・サイトが使用できなくなった場合に備え、データベース内のデータをレプリケートしてフェイルオーバー・サイトを確立できます。このようなフェイルオーバー・サイトは、プライマリ・サイトが同時に稼働しているときでも、アプリケーションからアクセスできる完全に機能したデータベースとして機能します。

Oracle Netを使用すると、接続時に自動的に起動されるフェイルオーバーを構成できます。この機能により、最初のマスター・サイトに障害が発生した場合、Oracle Netは別のマスター・サイトに接続を切り替えることができます。 自動的な接続時フェイルオーバーを構成するには、tnsnames.oraファイルでFAILOVER_MODEパラメータをonに設定し、複数の接続記述子を指定します。


関連項目:

接続時フェイルオーバーの構成方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

ロード・バランシング

マルチマスター・レプリケーションは、次のような目的で複数ポイントのデータベース情報にアクセスすることが必要なトランザクション処理アプリケーションに役立ちます。

  • 過度のアプリケーション負荷の分散

  • 連続的な可用性の保証

  • よりローカライズされたデータ・アクセスの提供

アプリケーション負荷を分散することが必要なアプリケーションとして一般的なものに、サービス指向のアプリケーションがあります。

図2-2 複数ポイントの更新アクセスをサポートするマルチマスター・レプリケーション

図2-2の説明が続きます。
「図2-2 複数ポイントの更新アクセスをサポートするマルチマスター・レプリケーション」の説明

非接続マテリアライズド・ビュー環境のサポート

マテリアライズド・ビュー・レプリケーションを使用すると、ユーザーは、マスター・サイトに接続せずに、マスター・サイトからのレプリケート・データの全部またはサブセットをリモートで格納できます。たとえば、営業支援システムでは、個人のラップトップ(非接続デバイス)に個々の営業担当員に関連するデータのサブセットを格納します。

マスター・サイトは、マテリアライズド・ビュー環境のターゲットとして機能します。マスター・サイトのサポートには、次のものがあります。

  • すべてのマテリアライズド・ビュー・サイトをサポートするシングル・マスター・サイト。競合解消がマスター・サイトまたは(多重化マテリアライズド・ビュー環境の)マスター・マテリアライズド・ビュー・サイトでのみ実行されるため、データの不一致が発生する確率が低下します。

  • マルチマスター・レプリケーションとマテリアライズド・ビュー・レプリケーションの組合せ。この組合せでは、マルチマスター構成の様々なマスターがマテリアライズド・ビュー・グループのターゲットになります。この構成を使用すると、ネットワーク負荷が複数のマスター・ノードに分散され、いずれかのマスター・ノードが使用できなくなった場合に備えてスケーラビリティと可用性を向上できます。

Oracle Real Application ClustersとAdvanced Replicationとの比較

Advanced ReplicationとOracle Real Application Clusters(RAC)のどちらを使用するかを検討する必要があるのは、ロード・バランシングと耐障害性の分野です。

  • ロード・バランシング: Advanced Replicationは複数のデータベースに対する読取りロード・バランシングを提供し、RACは複数のインスタンスに対する読取りおよび書込みロード・バランシングを提供します。書込みはそれぞれ各レプリケーション・サイトで実行する必要があるため、レプリケーションでは書込みロード・バランシングは提供されていません。

  • 耐障害性: Advanced Replicationの場合、各レプリケーション・サイトが地理的に異なる地域に置かれている可能性があるため、自然災害、停電またはサボタージュに対する耐障害性は高くなります。RACは、物理的に同一の環境にあるクラスタまたはその他の大規模パラレル・システム上で動作するため、Advanced Replicationでは対処できる物理的問題に対する耐障害性はありません。

  • 相互運用性: Advanced Replicationは、Oracleが稼働している様々なプラットフォームおよびオペレーティング・システム間でデータをレプリケートできます。RAC環境内のインスタンスは、同一プラットフォーム上で実行する必要があります。

マルチマスター・レプリケーション・プロセス

マルチマスター・レプリケーションには、非同期と同期という2つのタイプがあります。

非同期レプリケーション(ストア/フォワード・レプリケーションとも呼ばれます)では、ローカルで加えられたすべての変更を取得してキューに格納し、一定の間隔でリモート・サイトに伝播して変更を適用します。この形式のレプリケーションでは、すべてのサイトでデータが収束するまでに一定の時間がかかります。

同期レプリケーション(リアルタイム・レプリケーションとも呼ばれます)では、1つのトランザクションの一部として、レプリケーション環境に関係するすべてのサイトで変更を適用し、レプリケート・プロシージャを実行します。いずれかのサイトでデータ操作言語(DML)文またはプロシージャが失敗すると、トランザクション全体がロールバックされます。同期レプリケーションを使用すると、各サイトのデータ整合性がリアルタイムで保証されます。

マスター・サイトの伝播モードは、非同期から同期に、または同期から非同期に変更できます。マスター・グループ内のマスター・サイトの伝播モードを変更した場合、すべてのマスター・グループ・オブジェクトに対してレプリケーション・サポートを再度生成する必要があります。レプリケーション・サポートを再生成すると、内部トリガーがアクティブ化され、内部パッケージが再生成されて、すべてのマスター・サイトにあるオブジェクトのレプリケーションがサポートされます。また、マルチマスター・レプリケーション環境では、同期レプリケーションおよび非同期レプリケーションの両方を混在させることも可能です。


関連項目:

詳細は、「複合モードのマルチマスター・システムについて」を参照してください。

非同期レプリケーション

非同期レプリケーションでは、DMLまたはレプリケート・プロシージャを実行すると、マルチマスター・レプリケーション環境のすべてのマスター・サイトに個別に伝播されます。各トランザクションにおいてデータが伝播されるのは、DMLまたはレプリケーション・プロシージャをローカルで実行した後です。

非同期レプリケーションがデフォルトのレプリケーション・モードです。非同期レプリケーションでは、同期レプリケーションの場合よりもネットワーク・リソースやハードウェア・リソースの使用を抑えることができるため、可用性およびパフォーマンスが高くなります。

ただし、非同期レプリケーションを使用すると、変更内容が伝播されるまでの一定時間、レプリケーション環境にある別のマスター・サイトのデータ・セットと一致しません。また、非同期レプリケーションでは、データの競合が発生する可能性もあります。

非同期レプリケーション・プロセスは次のとおりです。

  1. DML文を発行または、レプリケート・プロシージャのラッパーを実行します。

    表がレプリケーション用に設定された後、ユーザーがこの表に対してコミットしたDMLは、他のすべてのマスター・サイトへのレプリケーション用に取得されます。

    挿入、更新または削除の対象となる各行に対して、内部トリガーによって遅延リモート・プロシージャ・コール(RPC)が作成され、遅延トランザクション・キューに入れられます。遅延トランザクション・キューには、すべての遅延RPCが入っています。

    プロシージャがレプリケートされており、そのラッパーがマスター・サイトで実行されると、プロシージャ・コールが遅延トランザクション・キューに入れられます。

  2. 遅延RPCを遅延トランザクション・キューに格納します。

    遅延トランザクション・キュー内の各トランザクションには接続先リストがあり、遅延トランザクションの伝播先が定義されています。このリストには、発行元サイト以外の全マスター・サイトが記載されています。各サイトには遅延トランザクション・キューが1つあり、この1つのキューが複数のレプリケーション・グループにより使用されます。

  3. 接続先へ遅延トランザクション・キューのエントリを送信します。

    スケジュールした間隔で、または必要に応じて、遅延トランザクション・キュー内の遅延トランザクションがターゲットの接続先に伝播されます。接続先ごとにスケジュール間隔を変えられます。

  4. 遅延トランザクション・キューのエントリがリモートの接続先で適用されます。

    遅延トランザクションがターゲットの接続先へ伝播されると、接続先サイトで内部パッケージがコールされて各遅延RPCが適用されます。接続先サイトで遅延トランザクションの適用に失敗した場合、遅延トランザクションは再送されて、接続先サイトのエラー・キューに入れられます。DBAは、このエラー・キューを使用してエラー条件を修正し、遅延トランザクションを再び適用できます。

    遅延トランザクション・キューのエントリがリモートの接続先で適用されるときに、データ競合がないかがチェックされます。データ競合が検出された場合、その競合はリモートの接続先でログに記録され、オプションで競合解消方法が起動します。

  5. 遅延トランザクションがすべてのリモート・マスター・サイトに正常にプッシュされた後、元のサイトではこのトランザクションが遅延トランザクション・キューからすぐにはパージされません。ユーザーが定義した間隔で実行されるパージ・ジョブにより、後でパージできます。


    関連項目:

    詳細は、第5章「競合解消の概念およびアーキテクチャ」を参照してください。

同期レプリケーション

同期レプリケーションでは、1つのトランザクションが終了するまでの間に、ローカル・サイトで加えられた変更をレプリケーション環境内の同期リンクしたマスター・サイトに伝播します。いずれかのマスター・サイトで伝播に失敗した場合、ローカルのマスター・サイトで最初に加えられた変更を含め、トランザクション全体がロールバックされます。この厳しい規則により、レプリケーション環境全体のデータ整合性を保つことができます。非同期レプリケーションとは異なり、マスター・サイト間のデータが一致しない時間はありません。


関連項目:

1つの環境で同期レプリケーションと非同期レプリケーションを混在させる方法の詳細は、「複合モードのマルチマスター・システムについて」を参照してください。

同期レプリケーションでは、レプリケーション環境でデータ競合が発生しないことも保証されています。このようなメリットがある一方で、停止時間に関する制限が多いハードウェア・リソースやネットワーク・リソースを必要とするというデメリットもあります。たとえば、ノードが6つあるマルチマスター環境で、1つのマスター・サイトが使用できなくなった場合、どのマスター・サイトでもトランザクションは完了しません。

ただし、非同期レプリケーションでは、ダウンしたサイトが使用可能になるまで元のサイトで遅延トランザクションが保持されます。その間に、他のレプリケーション・サイトにはトランザクションが正常に伝播され適用されます。

また、同期レプリケーションを使用すると、問合せがローカルで実行されるため高パフォーマンスを維持できるのに対して、更新処理には時間がかかります。これは、すべての更新内容が正しく伝播され、リモートの接続先サイトへ正しく適用できるように、2フェーズ・コミット・プロトコルを使用しているためです。


関連項目:

2フェーズ・コミットの詳細は、『Oracle Database管理者ガイド』を参照してください。

同期レプリケーション・プロセスは次のとおりです。

  1. DML文を発行または、レプリケート・プロシージャのラッパーを実行します。

    表がレプリケーション用に設定された後、ターゲット表に対してユーザーがコミットしたDMLが、他のすべてのマスター・レプリケーション・サイトへのレプリケーション用に取得されます。

    プロシージャがレプリケートされており、そのラッパーがマスター・サイトで実行されると、プロシージャ・コールがレプリケーション用に取得されます。

  2. DMLまたはラッパーを実行すると即時に接続先のサイトに伝播されます。

    内部トリガーは、DMLを取得し、これらのアクションを即時にレプリケーション環境の各マスター・サイトに伝播します。そして、これらのアクションをプロパゲータのデータベース・リンクのセキュリティ・コンテキストで適用し、内部RPCを使用して接続先サイトにこれらのアクションを適用します。

    内部トリガーと同様に、レプリケート・プロシージャのラッパーは、レプリケーション環境の各マスター・サイトにプロシージャ・コールを即時に伝播します。

    いずれかのマスター・レプリケーション・サイトでトランザクションが失敗した場合、すべてのマスター・サイトでトランザクションがロールバックされます。この方法により、すべてのマスター・サイト間でのデータ整合性が保証されます。トランザクションがいずれかのサイトで失敗するとロールバックを実行する必要があるので、同期レプリケーションは、可用性の高いネットワーク、データベースおよびそれに関連するハードウェアに大きく依存します。

競合解消の概念

表がレプリケートされるときに、任意のレプリケーション・サイト(マスター・サイトまたはマテリアライズド・ビュー・サイトのいずれか)のレプリケート表に適用されるDMLのうち、接続先サイトでデータ競合を発生させるDMLは、接続先サイトのOracleサーバーによって自動的に検出されます。マテリアライズド・ビュー・サイトで発生したデータ競合は、マテリアライズド・ビューのターゲット・マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトで検出され、解消されます。

たとえば、次のマスター・グループが1時間に1回変更を伝播するようにスケジュールされていると仮定します。

時間 マスター・サイトA マスター・サイトB 状態
午前8:00 マスター・サイトBに変更を伝播 マスター・サイトAに変更を伝播 データの収束
午前8:15 行1を更新 - -
午前8:30 - 行1を更新 -
午前9:00 マスター・サイトBに変更を伝播 マスター・サイトAに変更を伝播 行1で競合検出

2つのデータ伝播の間の時間を伝播間隔とみなした場合、1つの間隔中に複数のサイトが同じ行を更新すると競合が発生します。

前述した更新の競合のみでなく、挿入および削除時にも競合が発生します。次のようなタイプの競合について考えてみます。各競合は、同じ間隔内に競合するアクションが起こると発生します。

競合タイプ 要約
更新の競合 DML文が他のサイトに伝播される前に、複数のDML文が複数のレプリケーション・サイトで同一行に適用される場合。
一意性競合 複数のサイトで挿入を実行した結果、各挿入の主キー(またはその他の一意の列のセット)に同じ値が存在する場合、またはあるサイトで更新を実行した結果、主キー(またはその他の一意の列のセット)が変更され、その主キーに別のサイトで挿入した値と同じ値が存在する場合。
削除の競合 あるサイトで行が削除され、別のサイトで同じ行に対して更新が行われる場合。この結果、存在しない行を更新しようとする可能性や、または複数のサイトで同じ間隔で同じ行を削除しようとする可能性があります。


関連項目:

その他のタイプのデータ競合の詳細は、第5章「競合解消の概念およびアーキテクチャ」を参照してください。

データ競合が検出されると、次のアクションが発生します。

  1. 競合解消方法によって、データ競合の解消が試みられます。

  2. 競合が解消されない場合は、接続先サイトのエラー・キューでデータ競合がログに記録されます。

エラー・キューにデータ競合がログされた場合、データベース管理者はデータ競合を手動で解消する必要があります。

オラクル社が提供する競合解消方法またはユーザー定義の競合解消方法を使用する場合、Oracleサーバーはデータ競合の自動的な解消を試みます。ユーザーが実装する競合解消方法は、レプリケーション環境で定義されているビジネス・ルールに準拠し、データ収束を保証する必要があります。実装する競合解消方法の要件に合うように、表の変更が必要になる可能性があります。たとえば、最新のタイムスタンプによる競合の解消方法では、実装対象の表にタイムスタンプ列が必要になります。

オブジェクト型およびコレクションでのレプリケーションの動作方法

Oracleのオブジェクトはユーザー定義データ型で、これを使用すると現実の複雑なエンティティ(顧客や注文など)をデータベース内に単一エンティティ(オブジェクト)としてモデル化できます。オブジェクト型は、CREATE TYPE ...AS OBJECT文を使用して作成します。オブジェクト型とオブジェクトは、マルチマスター・レプリケーション環境のマスター・サイト間でレプリケートできます。

表の1列を占有するOracleオブジェクトを、列オブジェクトと呼びます。一般に、列オブジェクトが含まれている表にはその他の列も含まれており、このような列のデータ型は組込みデータ型(VARCHAR2NUMBERなど)の場合があります。オブジェクト表とは、各行がオブジェクトを表す特殊な表です。オブジェクト表の各行は行オブジェクトです。

コレクションをレプリケートすることもできます。コレクションとは、VARRAYデータ型およびネストした表のデータ型に基づいたユーザー定義データ型です。VARRAYはCREATE TYPE ...AS VARRAY文を、ネストした表はCREATE TYPE ...AS TABLE文を使用して作成します。


注意:

  • ユーザー定義型とユーザー定義型に基づいたオブジェクトをレプリケートするには、マスター・サイト間の互換性のレベルが9.0.1以上の必要があります。互換性のレベルは、COMPATIBLE初期化パラメータによって制御されます。

  • Advanced Replicationでは、型継承または型進化をサポートしていません。また、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_addressVARCHAR2(40)、2番目の属性はpostal_codeVARCHAR2(10)、3番目の属性はcityVARCHAR2(30)というように続いている必要があります。

  • 全レプリケーション・サイトで、ユーザー定義型のハッシュコードが一致する必要があります。Oracleでは、ユーザー定義型が検査され、ハッシュコードが割り当てられます。この検査では、型の属性、属性の順序および型の名前が調べられます。複数の型についてこれらの項目がすべて同じである場合、型のハッシュコードは同じです。 型のハッシュコードは、DBA_TYPE_VERSIONSデータ・ディクショナリ・ビューを問い合せて表示できます。

全レプリケーション・サイトでユーザー定義型を同一にするには、次のいずれかの方法でユーザー定義型を作成する必要があります。

レプリケーション・マネージメントAPIの使用

オラクル社では、ユーザー定義型を含むレプリケート・オブジェクトの作成、変更または削除には、レプリケーション・マネージメントAPIの使用をお薦めします。レプリケーション・マネージメントAPIを使用しない場合、レプリケーション・エラーが発生することがあります。 たとえば、前述の条件を満たすユーザー定義型をマスター・グループの全レプリケーション・サイトに追加する場合は、マスター定義サイトでその型を作成した後、DBMS_REPCATパッケージ内のCREATE_MASTER_REPOBJECTプロシージャを使用してマスター・グループにその型を追加します。


関連項目:

『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』

CREATE TYPE文の使用

型を作成するには、レプリケーション・サイトで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を認識した後、次の手順を実行して、型が存在していないレプリケーション・サイトで型を作成します。

  1. 型を所有するユーザーとしてレプリケーション・サイトにログインします。レプリケーション・サイトにこのユーザーがない場合は、ユーザーを作成します。

  2. 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を指定する方法があります。このオプションを使用する場合は、次の手順を実行します。

  1. DUALビューに対する問合せを実行し、グローバルに一意のOIDを求めます。

    SELECT SYS_GUID() OID FROM DUAL;
    
    OID
    --------------------------------
    81D98C325D4A45D0E03408002074B239
    
  2. 各レプリケーション・サイトで、手順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列を含む表

REFとはOracleの組込みデータ型で、オブジェクト表内の行オブジェクトを指す論理的なポインタです。有効範囲付きREFは、指定されたオブジェクト表に対する参照のみを含むREFで、有効範囲なしREFにはデータベース内のすべてのオブジェクト表に対する参照を含められます。有効範囲付きREFは、有効範囲なしREFと比べて必要とする記憶領域が少なく、より効率的なアクセスを提供します。Oracleでは、REF型の表のレプリケーションをサポートします。

有効範囲付きREF

有効範囲付きREFを含む表がレプリケートされ、REFにより参照されているオブジェクト表がレプリケートされない場合は、有効範囲付きREFを含む表をレプリケートする前に、参照されているオブジェクト表のないサイトに表を作成する必要があります。そうしないと、有効範囲付きREFにより、参照されているオブジェクト表が検出できないときに、この表のレプリケートによりエラーが発生します。このような場合は、通常、参照されているオブジェクト表もレプリケートすることが最善の方法です。レプリケートしないと、様々なレプリケーション・サイトでこの表の同期がなくなる可能性があるためです。

有効範囲なしREF

有効範囲なしREFを含む表がレプリケートされ、REFにより参照されているオブジェクト表がレプリケートされない場合、REFで参照オブジェクトが検出できない場合に、レプリケート・サイトで参照先がないREFが発生する可能性があります。レプリケートされたREFが有効になるには、参照されているオブジェクト表が各レプリケーション・サイトに存在する必要があります。

WITH ROWIDオプションを使用して作成された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 Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』で説明している手順や例に従えば作成できますが、レプリケーションのアーキテクチャを理解すると、レプリケーションをサポートするデータベース環境の設定、レプリケーション環境のチューニングやトラブルシューティングを、必要に応じて実施するための重要な情報が得られます。この項では、メカニズムとプロセスの観点からレプリケーションのアーキテクチャについて説明します。

マスター・サイトのメカニズム

Oracleでは、レプリケーション環境をサポートするために、マルチマスター・レプリケーション環境またはシングル・マスター・レプリケーション環境のいずれかに関係する各マスター・サイトで次のメカニズムを使用しています。これらのマスター・サイト・メカニズムの一部は、特定の環境でのみ必要となります。

マスター・サイトのロールおよびユーザー

セキュリティ要件によっては、管理、伝播および受信の3つのロールが1人のレプリケーション管理者に統合されている場合があります。実際、ほとんどのマルチマスター・レプリケーション環境では、1人のユーザーがレプリケーションの管理、伝播および受信のロールを実行します。セキュリティ要件がより厳格な場合は、次のロールを別々のユーザーに割り当てることができます。


注意:

このコンテキストのロールという用語は、SQL用語のロールとは関連がありません。レプリケーションにおけるロールは、PL/SQLのストアド・プロシージャまたは個々の権限(あるいはその両方)を使用して付与されます。

レプリケーション管理者

レプリケーション管理者は、レプリケーション環境のマスター・サイトに関連するすべての管理機能を実行します。一般的に、1つのレプリケーション環境に対して1人のレプリケーション管理者を置くことをお薦めします。レプリケーション管理者は、レプリケーションをサポートするようにデータベースを準備することに加えて次の作業を実行します。

  • 個々のマスター・レプリケーション・グループの作成とメンテナンス

  • 各マスター・サイトの追加と削除

  • キューの管理

  • レプリケーション環境の状態(通常および静止中)の制御

レプリケーション管理者のデフォルトのユーザー名はREPADMINですが、別のユーザー名を使用することもできます。

プロパゲータ

プロパゲータは、遅延トランザクション・キューに含まれる各トランザクションを接続先に伝播する作業を実行します。プロパゲータは、各データベースに1つ存在します。つまり、異なるスキーマを管理するために複数のレプリケーション管理者を置くことはできますが、それぞれのデータベースには1つのプロパゲータしか配置できません。

受信者

受信者は、プロパゲータから遅延トランザクションを受信し、それを適用します。受信者に遅延トランザクション内のコールを適用する適切な権限が付与されていない場合、遅延トランザクション全体が接続先のエラー・キューに入れられます。 受信者を登録するには、DBMS_REPCAT_ADMINパッケージ内のREGISTER_USER_REPGROUPプロシージャを使用します。

データベース・リンクとレプリケーション

データベース・リンクは、マスター・サイトとマテリアライズド・ビュー・サイト間でデータをレプリケートするためのパイプを提供します。マルチマスター環境では、各マスター・サイトからその他の各マスター・サイトに対してデータベース・リンクが存在します。つまり、各マスター・サイトにつきN - 1個(Nはマスター・サイトの合計数)のデータベース・リンクが存在します。

図2-3 データベース・リンクを表す矢印

図2-3の説明が続きます。
「図2-3 データベース・リンクを表す矢印」の説明

図2-3では、各マスター・サイトから他のマスター・サイトに対して2つ(N-1、すなわちこの例では3-1=2)のデータベース・リンクが存在します。この構成では、マルチマスター・レプリケーションに必要な両方向通信チャネルがマスター・サイト間で保証されます。マテリアライズド・ビュー・サイトの場合は、マテリアライズド・ビュー・サイトからマスター・サイトへのリンクのみが必要な点に注意してください。マスター・サイトからマテリアライズド・ビュー・サイトへのデータベース・リンクは不要です。

最も基本的なデータベース・リンクは、個々のマスター・サイトのレプリケーション管理者と、関係する他のマスター・サイトのレプリケーション管理者とを結ぶデータベース・リンクです。

ただし、通常はレプリケーション環境にデータベース・リンクのセットを追加します。レプリケーション管理者のデータベース・リンクを作成する前に、CONNECT TO句を指定せずに各マスター・サイト間にパブリック・データベース・リンクを作成します。パブリック・データベース・リンクは、リモート・データベースのサービス名を指定するUSING句を使用して各データベース・リンクのターゲットを指定します。

パブリック・データベース・リンクを作成した後で、レプリケーション管理者のプライベート・データベース・リンクを作成できます。プライベート・データベース・リンクの作成時はCONNECT TO句を指定しますが、対応付けられたパブリック・データベース・リンクにより、USING句の指定が不要になります。

パブリック・データベース・リンクとプライベート・データベース・リンクの両方を使用すると、データベース・リンクの管理に必要な労力が軽減されます。次の利点もあります。

  • 複数のセットのプライベート・データベース・リンクで同じパブリック・データベース・リンクを共有でき、しかもデータベース・リンクの管理が簡単になります。

  • データベース・リンクのターゲット・データベースを変更した一方で、ターゲット・データベースのサービス名がそのままの場合、変更する必要があるのはtnsnames.oraファイルのターゲット・データベースのエントリのみです。USING句により指定されるのはリモート・ターゲット・データベースのサービス名であることを覚えておいてください。ターゲットが同じプライベート・データベース・リンクはすべて、パブリック・データベース・リンクのUSING句で定義した接続先にリンクされます。

    たとえば、データベースを別のサーバーに移動しても同じサービス名をそのまま使用する場合は、各レプリケーション・サイトでtnsnames.oraファイルのリモート・データベースのエントリを更新すれば、データベース・リンクを再作成する必要はありません。

前述のように、レプリケーション管理者は、通常、マルチマスター環境の管理作業および伝播作業を実行します。これらの作業を実行するのは1人のユーザーであるため、レプリケーション管理者用にプライベート・データベース・リンクを1セットのみ作成する必要があります。

ただし、レプリケーション管理者以外のユーザーが伝播を実行するマルチマスター・レプリケーション環境では、これらのユーザーのそれぞれに対して適切なプライベート・データベース・リンク・セットを作成する必要があります。


関連項目:

  • データベース・リンクおよびその作成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

  • サービス名とtnsnames.oraファイルの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。


レプリケーション・マネージメント・ツールにより作成されたデータベース・リンク

Oracle Enterprise Manager Consoleのレプリケーション・マネージメント・ツールの「設定ウィザード」を使用してレプリケーション・サイトを設定する場合、デフォルトでは、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.worldという名前の2つのパブリック・データベース・リンクに異なるパスを指定して、リモート・データベースに接続できます。

  • ny.world@ethernet: イーサネット・リンクを使用してnyに接続するリンクです。

  • ny.world@modem: モデム・リンクを使用してnyに接続する別のリンクです。

レプリケーションでは、接続修飾子の使用により、複数のマスター・グループの伝播特性をより厳密に制御できます。たとえば、各マスター・サイトに3つの別のマスター・グループがあり、接続修飾子を指定していないと想定します。この場合、遅延トランザクション・キューの伝播のスケジューリング特性はどのマスター・グループも同じです。この3つのマスター・グループのうち、1つのマスター・グループが遅延トランザクションを1時間に1回伝播し、残りの2つのマスター・グループが1日に1回伝播したとすると、コストが高くなる可能性があります。

接続修飾子をマスター・グループと対応付けると、遅延トランザクション・キューの伝播のスケジューリング特性を、前述のようなデータベース・レベルではなくマスター・グループ・レベルで個別に定義できます。


関連項目:

データベース・リンク用の接続修飾子の定義の詳細は、『Oracle Database管理者ガイド』を参照してください。

新規マスター・グループを作成するときに、そのグループに対応するすべてのスケジュール・リンクに1つの接続修飾子を使用するよう指定できます。ただし、マスター・グループに接続修飾子を使用すると、各マスター・サイトで接続修飾子を使用してデータベース・リンクを作成しないと情報が伝播されません。マスター・グループを作成した後は、グループの接続修飾子の削除、追加または変更はできません。


注意:

接続修飾されたリンクと複数のマスター・グループを使用するマルチマスター環境でのトランザクションの一貫性を保持するため、接続修飾子が異なる複数グループのレプリケーション・オブジェクトを1つのトランザクションで操作できません。


注意:

接続修飾子を使用する場合は、すべてのマスター・サイトの OPEN_LINKS初期化パラメータの値を大きくすることが必要な場合があります。デフォルトでは、プロセスごとのオープン・リンク数は4つです。用途に応じて、必要な値を見積もります。 詳細は、「初期化パラメータ」を参照してください。OPEN_LINKSの詳細は、『Oracle Databaseリファレンス』を参照してください。

レプリケーション・オブジェクト

レプリケーション環境の中で最も理解しやすいのは、レプリケート・オブジェクト自体です。レプリケート・オブジェクトの中では、レプリケート表がレプリケーション環境の基盤です。次の項では、関連するデータベース・オブジェクトのレプリケーションについて説明します。特に、次のタイプのデータベース・オブジェクトをレプリケートする場合の利点および制限事項を中心に説明します。

ほとんどの場合、レプリケート表がレプリケーション環境の基盤です。レプリケーション用の表を選択し、レプリケーション・サポートを生成すると、表に対してDMLが適用されているかどうかを検出するために、内部トリガーによって監視が行われます。 


関連項目:

「内部トリガー」

表をレプリケートするときは、表構造と表データをリモート・データ・サイトにレプリケートすることも、表構造のみをレプリケートすることもできます。また、同じ名前と構造の表がターゲットのレプリケーション・サイトにすでに存在する場合は、レプリケーション環境内の既存のオブジェクトを使用することもできます。


注意:

  • 自己参照型整合性制約がある表では、正しい順序で削除が実行される保証はありません。このような表で削除を実行する場合は、プロシージャ・レプリケーションを使用します。 詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

  • 循環依存性を持つ表または自己参照型制約のある表を含むマスター・グループに新規マスター・サイトを追加する場合は、新規マスター・サイトで表定義を再作成し、データを手動でロードする必要があります。循環依存性の例としては、「表Aには表Bに対する外部キー制約があり、表Bには表Aに対する外部キー制約がある」などがあります。

  • レプリケート表からファンクション索引を削除する場合、またはレプリケート表にファンクション索引を追加する場合、表のレプリケーション・サポートを再生成する必要があります。

  • Advanced Replicationでは、透過的なデータ暗号化を使用して暗号化された列を含む表はサポートされていません。


表のレプリケーションは、表データに加えられたすべての変更をレプリケーション環境に関係するすべてのサイトにレプリケートすることを目的としていますが、これ以外の用途もあります。

  • オブジェクトおよびデータのトランスポート: オブジェクトがターゲットの接続先サイトにレプリケートされると、それ以降レプリケーション・サポートは自動的には生成されません。オブジェクトとデータのトランスポートにより、オブジェクトとデータをリモートの接続先に簡単に配布できます。レプリケーション・オブジェクトの削除およびレプリケーション・サポートの生成を行っていない場合は、表(またはその他のオブジェクト)およびデータはリモートの接続先サイトに残り、リモートの接続先サイトの変更は一切レプリケートされません。この方法により、標準のデータベース環境とデータ・セットを新しいデータベース環境に配布できます。

  • オブジェクトのトランスポート: 同様に、データをコピーせずにターゲットの接続先サイトに表をレプリケートできます。この方法により、接続先サイトにオブジェクトが作成されますが、データは移入されません。したがって、空のデータベース環境を即時に配布できます。

索引

レプリケーション用の表が選択され、リモート接続先サイトで作成されると、表内での制約の施行に使用する索引がリモート・サイトで自動的に作成されます。ただし、パフォーマンス上の理由から索引を使用する場合は、レプリケーション用の索引を明示的に選択して、レプリケーション環境に関係する他のマスター・サイトに作成する必要があります。索引が別のサイトにレプリケートされると、ローカルで作成されたかのように動作します。索引のレプリケーション・サポートを生成する必要はありません。

Oracleではドメイン索引のレプリケーションをサポートしています。ドメイン索引の記憶表の定義はレプリケートできますが、記憶表には通常はROWID情報が含まれているため、記憶表自体はレプリケートできません。


関連項目:

  • 外部キー列に対する索引のレプリケーションの詳細は、「外部キーとレプリケート表」を参照してください。

  • 拡張索引の詳細は、『Oracle Databaseデータ・カートリッジ開発者ガイド』を参照してください。


パッケージおよびその本体

レプリケーション用のパッケージとパッケージ本体を選択し、必要なレプリケーション・サポートを生成すると、プロシージャ・レプリケーションを実行できます。プロシージャ・レプリケーションを使用すると、レプリケーション環境でシリアルに実行されて大量の行を処理する、大規模なバッチ指向操作のパフォーマンスが向上します。

レプリケーション・サポートを使用するプロシージャのパラメータはすべて、INパラメータであることが必要です。OUTモードおよびIN/OUTモードはサポートされていません。これらのパラメータには次のデータ型がサポートされています。

  • VARCHAR2

  • NVARCHAR2

  • NUMBER

  • DATE

  • RAW

  • ROWID

  • CHAR

  • NCHAR

  • バイナリ・ラージ・オブジェクト(Binary Large Object: BLOB

  • キャラクタ・ラージ・オブジェクト(Character Large Object: CLOB

  • 各国語キャラクタ・ラージ・オブジェクト(National Character Large Object: NCLOB

  • ユーザー定義データ型

レプリケート・プロシージャは、パッケージ内で宣言する必要があります。スタンドアロン・プロシージャにはレプリケーション・サポートはありません。


関連項目:

プロシージャ・レプリケーションの使用方法の詳細は、『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リファレンス』を参照してください。

ビュー、オブジェクト・ビューおよびシノニム

ビュー、オブジェクト・ビューまたはシノニムをレプリケーション環境に関係する他のマスター・サイトに配布するには、レプリケーションを使用します。オブジェクトが他のサイトにレプリケートされると、そのオブジェクトはローカルで作成されたかのように動作します。変更を取得するためにオブジェクトを監視する内部トリガーまたはパッケージはありません。ただし、オブジェクトはレプリケート・オブジェクトなので、レプリケーション・マネージメント・ツールまたはレプリケーション・マネージメントAPIを使用して削除または変更できます。

索引タイプ

Oracleでは索引タイプのレプリケーションをサポートしています。 レプリケーション・マネージメント・ツールまたはDBMS_REPCATパッケージ内のCREATE_MASTER_REPOBJECTプロシージャを使用して、索引タイプの実装に使用するタイプとタイプ本体のファンクションを明示的にレプリケートする必要があります。


関連項目:

拡張索引の詳細は、『Oracle Databaseデータ・カートリッジ開発者ガイド』を参照してください。

ユーザー定義演算子

オブジェクト指向アプリケーションの開発者は、ユーザー定義演算子と呼ばれるドメイン固有の演算子(ContainsWithin_DistanceSimilarなど)を使用して、組込みのリレーショナル演算子(+-/*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 WITHMAXVALUEを指定することにより、マスター・サイトごとに異なる範囲を定義できます。

内部トリガー

内部トリガーは、レプリケート・データの更新に関する情報の取得および格納に使用します。内部トリガーによって、ローカル・サイトで加えられたデータ変更をリモート・サイトで再生成するリモート・プロシージャ・コール(RPC)が作成されます。遅延RPCは、遅延トランザクション・キューに格納され、レプリケーション環境に関係する他のマスター・サイトに伝播されます。データ・レプリケーションをサポートする内部トリガーは、Oracleサーバー実行モジュール内の必須コンポーネントです。したがって、システム・リソースを最小限に使用して、レプリケート・データへの更新内容を高速に取得し、格納できます。

遅延トランザクション

前述の内部トリガーによって生成されるRPCを伝播(送信および実行)することにより、データ・レプリケーション情報が転送されます。このRPCは、遅延トランザクション・キューに格納されます。各RPCには、接続先サイトでの内部プロシージャの実行コマンドのみでなく、ターゲット・サイトにレプリケートされるデータも含まれています。Oracleでは分散トランザクション・プロトコルを使用しているため、グローバルなデータベース整合性が自動的に保護され、データの耐障害性が保証されます。

内部プロシージャ

内部トリガーによって作成された遅延RPCがレプリケーション環境に関係する他のマスター・サイトに伝播されると、遅延RPCは接続先サイトの内部プロシージャによってリモート・サイトで適用されます。この内部プロシージャは、表のレプリケーション・サポートを生成するときに自動的にアクティブ化されます。また、この内部プロシージャは、発行元サイトの遅延トランザクション・キューから受信されるRPCに基づいて実行されます。

キュー

次のキューは、Advanced Replicationによって生成されるトランザクションを管理します。

遅延トランザクション・キュー

このキューには、マスター・グループ内の別の接続先に伝播されるトランザクション(たとえば、DML)が格納されます。遅延伝播用に、サイトの遅延トランザクション・キューの内部トリガーによって生成されるRPCが格納されます。また、トランザクションを構成するすべてのRPCがトランザクションとして伝播されてリモートで適用されるように、開始トランザクションに関する情報も記録されます。Oracleのレプリケーション機能では、Oracle Advanced Queuingのメカニズムを使用して遅延トランザクション・キューが実装されます。


注意:

ENABLE RESTRICTED SESSION句を指定したSQL文ALTER SYSTEMで制限付きセッションを使用可能にすると、遅延トランザクションは伝播されません。制限付きセッションが使用禁止になっている場合は、伝播されます。

エラー・キュー

このキューには、ローカル・サイトでの適用に失敗した遅延トランザクションに関する情報が格納されます。エラー・キューにはレプリケーション環境のその他の各マスター・サイトのエラー情報は表示されません。エラー状態が解消されると、トランザクションを再度実行するか、エラー・キューからトランザクションを削除できます。

ジョブ・キュー

伝播プロセスは、ジョブ・キュー・メカニズムおよび遅延トランザクションを使用して管理されます。各サーバーには、ローカル・ジョブ・キューがあります。サーバーのジョブ・キューは、ジョブの実行を要求するPL/SQLコールやジョブの実行時期など、ローカル・ジョブに関する情報を格納するデータベース表です。レプリケーション環境の一般的なジョブには、遅延トランザクションをリモートのマスター・サイトにプッシュするジョブ、遅延トランザクション・キューから適用済のトランザクションをパージするジョブおよびマテリアライズド・ビューのリフレッシュ・グループをリフレッシュするジョブがあります。

管理メカニズム

通常はレプリケーション環境をサポートする管理作業を処理するために、いくつかのメカニズムが必要です。このメカニズムを使用すると、レプリケーション環境をオンまたはオフにしたり、レプリケーション環境の作成時または変更時に生成される管理作業を監視できます。

レプリケーションの操作モード

レプリケーション環境の操作モードは3つあります。

通常

通常モードのレプリケーション環境では、レプリケーションを使用できます。レプリケーション環境はこのモードで実行されます。レプリケート・オブジェクトに対してトランザクションを実行でき、トランザクションは適切に伝播されます。

静止

静止モードは、レプリケーション環境が通常モードから静止中モードに移行する段階のモードです。レプリケーション環境の静止中は、ユーザーは、レプリケート・オブジェクトに対してトランザクションを実行できませんが、既存の遅延トランザクションは伝播されます。静止表に対する問合せはできます。各接続先へのすべての遅延トランザクションが正しく伝播終了すると、レプリケーション環境は静止中モードに変わります。

静止中

静止中モードのレプリケーション環境は、通常のレプリケーションが使用禁止になっており、主に管理目的(レプリケート・オブジェクトの追加や削除など)に使用されている状態と考えられます。このモードでは、レプリケーションが停止されます。静止中状態では、レプリケーションをオフにしないかぎり、ユーザーは静止中のマスター・グループのレプリケート・オブジェクトに対してトランザクションを実行できません。レプリケーションをオフにすると、レプリケーションが再開されたときにデータの不一致が発生することがあります。トランザクションには、レプリケート表に対するDMLまたはレプリケート・プロシージャのラッパーの実行が含まれます。マスター表が静止中の場合は、そのマスター表に基づくマテリアライズド・ビューからターゲットのマスター表に変更内容を伝播できませんが、マテリアライズド・ビューをローカルで変更することはできます。

レプリケーション環境は、マスター・グループ・レベルで静止します。マスター・グループに含まれているすべてのマスター・サイトが影響を受けます。マスター・グループが静止中状態になると、遅延トランザクション・キューのトランザクションが他のマスター・サイトに正常に伝播されたか、エラー・キューに入れられたことを確認できます。ユーザーは静止中のマスター・グループに属する表に対しては、引き続き問合せを実行できます。

1つのマスター・グループを静止しても、その他のマスター・グループには影響しません。通常モードのマスター・グループでは、その他のマスター・グループの静止中も更新処理を継続できます。

レプリケーション・モードの制御

レプリケーションの3つの操作モードは、中断および再開の2つのメカニズムで制御されます(静止モードは通常モードから静止中モードへの移行段階のモードです)。

中断

中断メカニズムを実行すると、マスター・グループのレプリケーション操作モードが、通常から静止中への移行モードである静止モードになります。遅延トランザクション・キューに、マスター・グループへ未伝播の遅延トランザクションがないときは、レプリケーション環境は静止中モードに変わります。

中断メカニズムを実行できるのは、レプリケーション環境が通常モードの場合のみです。レプリケーション環境を変更する必要がある場合は、中断メカニズムを実行します。

再開

再開メカニズムを実行すると、マスター・グループのレプリケーション操作モードが静止中モードから通常モードに変わります。 レプリケーション環境で管理作業(たとえば、レプリケート・オブジェクトの追加)を実行していた場合は、再開メカニズムを実行する前に管理要求キュー(DBA_REPCATLOG)が空であることを確認する必要があります。

管理要求

レプリケーション環境を構成および管理するために、関係する各サーバーはOracleのレプリケーション・マネージメントAPIを使用します。サーバーのレプリケーション・マネージメントAPIは、レプリケーション機能を構成するために管理者が使用できるプロシージャおよびファンクションをカプセル化したPL/SQLパッケージのセットです。また、レプリケーション・マネージメント・ツールでは、各サイトのレプリケーション・マネージメントAPIのプロシージャおよびファンクションを使用して作業を実行します。

管理要求とは、Oracleのレプリケーション・マネージメントAPIのプロシージャまたはファンクションをコールすることです。 たとえば、レプリケーション・マネージメント・ツールを使用して新しいマスター・グループを作成するときに、このツールは、DBMS_REPCAT.CREATE_MASTER_REPGROUPプロシージャをコールして作業を完了させます。管理要求には、追加のレプリケーション・マネージメントAPIコールを生成して要求を処理するものもあります。

管理要求のメカニズム

レプリケーション・マネージメント・ツールを使用するか、DBMS_REPCATパッケージのプロシージャをコールしてレプリケーション・システムを管理する場合、内部メカニズムによって要求は同期ブロードキャストされます。なんらかの理由で同期でのブロードキャストが失敗した場合は、エラー・メッセージが戻され、それを含むトランザクションがロールバックされます。

Oracleサーバーが管理要求を受信すると、 DBA_REPCATLOGビューに要求が記録され、対応するDDL文がDBA_REPCATLOGビューの子表に記録されます。マスター・サイトのマスター・グループの管理要求を表示すると、別のマスター・サイトからのコールバックを待機している要求が含まれる場合があります。 このような要求は、AWAIT_CALLBACK要求と呼ばれます。 DBA_REPCATLOGビュー内の管理要求がすべて適用され、エラーがすべて解決されるまで、マスター・レプリケーション・アクティビティは再開できません。

レプリケーション・マネージメント・ツールを使用してレプリケーション・グループの管理要求を作成するたびに、そのグループに対してジョブが存在しない場合はローカル・ジョブ・キューにジョブが自動的に挿入されます。 このジョブは定期的にDBMS_REPCAT.DO_DEFERRED_REPCAT_ADMINプロシージャを実行します。要求を同期ブロードキャストすると、レプリケートされた変更を各マスター・サイトに適用するためにこのジョブが即時に開始されます。

エラーがない場合、バックグラウンド・プロセスがジョブ実行用に使用可能なときはDO_DEFERRED_REPCAT_ADMINが実行されます。バックグラウンド・プロセスの実行頻度は自動的に判断されます。未処理ジョブを実行するために十分な数のバックグラウンド・プロセスを使用できない場合、処理が遅れることがあります。


注意:

サイトでJOB_QUEUE_PROCESSESがゼロに設定されている場合は、そのサイトのすべてのグループに対して管理要求を手動で適用する必要があります。


関連項目:

JOB_QUEUE_PROCESSESの詳細は、「初期化パラメータ」および『Oracle Databaseリファレンス』を参照してください。

マスター・サイトで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ビューに記述されます。マスター・グループごとに、各管理要求に対応する状態がレプリケーション・マネージメント・ツールに表示されます。最後に、各マスター・サイトは、その管理要求の状態をマスター定義サイトに伝播します。 マスター・サイトで要求が正常に完了した場合、マスター定義サイトのDBA_REPCATLOGビューからサイトのコールバックが削除されます。

すべてのサイトで要求が正常に完了した場合は、マスター定義サイトを含むすべてのサイトのDBA_REPCATLOGビューのエントリがすべて削除されます。 マスター定義サイト以外のサイトで要求が失敗した場合は、マスター・サイトの要求が削除され、マスター定義サイト内の対応するAWAIT_CALLBACK要求がERRORステータスと失敗の理由で更新されます。

変更を同期でブロードキャストすることで、すべてのサイトで変更を確実に認識し、同期が取れた状態に保持できます。後の特定の時点でサイトに変更を適用でき、変更の適用に最も適した時点を自由に選択できます。

オブジェクトにレプリケーション・サポートが必要な場合、オブジェクトの変更後にレプリケーション・サポートを再生成する必要があります。Oracleでは、内部トリガーをアクティブ化し、パッケージを再生成して、すべてのマスター・サイトにある変更後のオブジェクトのレプリケーションをサポートしています。


注意:

エラーなしにこれらのプロシージャを完了させるにはDDLをマスター定義サイトで正常に適用する必要がありますが、これによって、DDLが各マスター・サイトで正常に適用されることが保証されるわけではありません。レプリケーション・マネージメント・ツールにより、すべての管理要求の状態が表示されます。 また、DBA_REPCATLOGビューには、一時的な状態および要求によって生成される非同期のエラー・メッセージが含まれます。

DDL変更によって影響を受けるマテリアライズド・ビュー・サイトは、そのマテリアライズド・ビュー・サイトのリフレッシュを次に実行するときに更新されます。すべてのマスター・サイトが他のマスター・サイトと通信できるのに対して、マテリアライズド・ビュー・サイトが通信できるのは、対応付けられたマスター・サイトのみです。

マテリアライズド・ビューのマスターに変更を加えた結果、マテリアライズド・ビューの形式を変更する必要がある場合は、マテリアライズド・ビューを削除してから再作成します。

管理要求キュー

DBA_REPCATLOGビュー(通常、管理要求キューと呼ばれます)には、レプリケーション環境を管理および変更する管理要求が格納されます。 一部のDBMS_REPCATプロシージャは、実行すると管理要求キューにリストされます。 たとえば、既存のマスター・グループにレプリケート表を追加すると、DBMS_REPCAT.CREATE_MASTER_REPOBJECTプロシージャという要求が表示されます。

管理要求キューを表示するには、DBA_REPCATLOGビューを問い合せるか、レプリケーション・マネージメント・ツールの「管理要求」ダイアログ・ボックスを表示します。

各要求には、要求の状態を表すステータスがあります。状態は、次のとおりです。

  • READY: READY状態は、要求を実行する準備が整っている状態を示します。管理要求キューを監視しているときに、ある要求がしばらくの間READY状態である場合、その要求の前にコールバック待機中の要求が存在している可能性があります。通常、READY状態の管理要求は、ジョブが要求を実行するのを待機しています。 このような要求は、DBMS_REPCATパッケージ内のDO_DEFERRED_REPCAT_ADMINプロシージャを使用して手動で実行できます。

  • AWAIT_CALLBACK: AWAIT_CALLBACK状態は、ある要求が別のサイトで実行され、その実行が確認されるまで待機している状態を示します。要求がコールバックを受信すると、その要求は削除されるか、状態が変更されます。要求が正常に適用された場合はその要求キューから削除され、失敗した場合はそのステータスがERRORに変更されます。この状態は、マスター定義サイトでのみ発生します。

  • ERROR: 要求を正常に実行できない場合、ERROR状態になります。エラー番号がERRNUM列に表示され、エラー・メッセージが管理要求キューのMESSAGE列(レプリケーション・マネージメント・ツールを使用している場合はError列)に表示されます。


    注意:

    要求がERROR状態にある場合は、エラー番号による説明に従ってエラー状態を解消し、要求を再送信してください。

  • DO_CALLBACK: マスター・サイトの要求がDO_CALLBACK状態にある場合、要求が成功したか失敗したかどうかをマスター・サイトからマスター定義サイトに通知する必要があります。この状態は、マスター定義サイト以外のマスター・サイトでのみ発生します。

各マスター・サイトの管理要求キューには、そのマスター・サイトで実行される管理要求のみがリストされています。ただし、マスター・グループのマスター定義サイトには、各マスター・サイトで実行される管理要求がリストされています。DBAは、マスター定義サイトの管理要求キューを使用すると、レプリケーション環境のすべてのマスター・サイトの管理要求を監視できます。


注意:

ENABLE RESTRICTED SESSION句を指定したSQL文ALTER SYSTEMで制限付きセッションを使用可能にすると、管理要求は実行されません。制限付きセッションが使用禁止になっている場合は、実行されます。

編成メカニズム

Oracleでは、編成メカニズムを使用して前述のマスター・サイトを編成し、管理メカニズムを使用して個別のレプリケーション・グループを作成します。編成メカニズムの中で最も重要なのは、マスター・グループです。追加の編成メカニズムは、レプリケート表の競合解消に使用する列をグループ化するのに役立ちます。

マスター・グループ

レプリケーション環境では、レプリケーション・グループを使用してレプリケーション・オブジェクトを管理します。レプリケーション・グループは、常にトランザクションの一貫性を保つように更新されるレプリケーション・オブジェクトの集合です。

レプリケーション・グループ内に関連するデータベース・オブジェクトを編成すると、多数のオブジェクトをまとめて簡単に管理できます。通常、レプリケーション・グループを作成および使用して、特定のデータベース・アプリケーションのサポートに必要なスキーマ・オブジェクトを編成します。ただし、レプリケーション・グループとスキーマが相互に対応している必要はありません。レプリケーション・グループのオブジェクトは、複数のデータベース・スキーマから作成でき、スキーマには異なるレプリケーション・グループのメンバーであるオブジェクトを入れることができます。制限は、レプリケーション・オブジェクトが1つのグループのメンバーにしかなれないことです。

マルチマスター・レプリケーション環境では、レプリケーション・グループはマスター・グループと呼ばれます。異なるサイトの対応するマスター・グループには、レプリケーション・オブジェクトの同一のセットが含まれている必要があります(「レプリケーション・オブジェクト」を参照してください)。 図2-4は、各マスター・サイトにレプリケート・オブジェクトの同一のレプリカが含まれているマスター・グループhr_mgを示します。

図2-4 すべてのサイトで同じレプリケーション・オブジェクトを含むマスター・グループhr_mg

図2-4の説明が続きます。
「図2-4 すべてのサイトで同じレプリケーション・オブジェクトを含むマスター・グループhr_mg」の説明

マスター・サイトのマスター・グループ編成は、マテリアライズド・ビュー・サイトでのレプリケーション・オブジェクトの編成に不可欠です。


関連項目:

マテリアライズド・ビュー・サイトでの編成メカニズムの詳細は、「編成メカニズム」を参照してください。

また、各マスター・サイトに複数のレプリケーション・グループが含まれている例を図2-5に示します。各マスター・サイトの各グループに含まれているオブジェクトのセットは、同一であることが必要です。

図2-5 各マスター・サイトで同一のマスター・グループ

図2-5の説明が続きます。
「図2-5 各マスター・サイトで同一のマスター・グループ」の説明

列グループ

列グループは、競合解消ルーチンと関係するすべての列をグループ化する編成メカニズムを提供します。グループのいずれかの列で競合が発生した場合、残りの列を使用して競合を解消できます。 たとえば、表の列グループにmin_pricelist_pricecost_priceおよびtimestampというフィールドが含まれており、list_priceフィールドで競合が発生した場合、タイムスタンプによる競合解消ルーチンを使用していたと想定すると、timestampフィールドを使用して競合を解消できます。

表のすべての列を1つの列グループにまとめる必要はありません。すべての列を1つの列グループにまとめれば設定や管理は簡単になりますが、レプリケート表のパフォーマンスが低下し、データ競合が発生する可能性が高くなることがあります。「パフォーマンス・メカニズム」で説明しているように、表の1つの列グループで競合が発生した場合、最小限の通信機能によって、表のその他の列グループからはデータが送信されません。 したがって、すべての列を1つの列グループにまとめると、DBMS_REPCATパッケージ内のSEND_OLD_VALUESプロシージャおよびCOMPARE_OLD_VALUESプロシージャを使用しないかぎり、最小限の通信機能の利点がなくなってしまう可能性があります。


関連項目:

列グループの詳細は、第5章「競合解消の概念およびアーキテクチャ」を参照してください。

伝播メカニズム

伝播は、レプリケーション環境のすべてのマスター・サイトにすべてのアクションを送信または配布するメカニズムであり、レプリケーションにおいて不可欠な要素です。

伝播のタイプ

内部トリガーはレプリケート表に適用されるすべてのDMLを取得するため、レプリケーション環境の他のマスター・サイトにDMLを伝播(送信)する必要があります。内部トリガーの詳細は、「内部トリガー」を参照してください。

Advanced Replicationでは、非同期レプリケーションおよび同期レプリケーションの両方をサポートしています。

非同期

一般的なレプリケーション構成では、非同期データ・レプリケーションを使用します。非同期データ・レプリケーションは、アプリケーションで表のローカル・レプリカを更新し、レプリケーション情報をローカル・キューに格納し、その後で他のレプリケーション・サイトにレプリケーション情報を転送する場合に発生します。このため、非同期データ・レプリケーションはストア/フォワード・レプリケーションとも呼ばれます。

図2-6に示すように、Oracleでは内部トリガー、遅延トランザクション、遅延トランザクション・キューおよびジョブ・キューを使用して、更新可能マテリアライズド・ビューからマスター表に対する伝播の他、レプリケーション環境のマスター・サイト間でも、データレベルの変更を非同期に伝播します。

図2-6 非同期データ・レプリケーションのメカニズム

図2-6の説明が続きます。
「図2-6 非同期データ・レプリケーションのメカニズム」の説明

同期

Oracleでは、特定の要件を持つアプリケーションに対しては同期データ伝播もサポートしています。同期データ伝播は、アプリケーションによって表のローカル・レプリカが更新され、同じトランザクション内で同じ表の少なくとも1つの他のレプリカも更新されたときに発生します。したがって、同期データ・レプリケーションはリアルタイム・データ・レプリケーションとも呼ばれます。アプリケーションでレプリケート・サイトを継続的に同期化する必要があるとき以外は、同期レプリケーションを使用しないでください。

図2-7 同期データ・レプリケーションのメカニズム

図2-7の説明が続きます。
「図2-7 同期データ・レプリケーションのメカニズム」の説明

図2-7に示すように、同じ内部トリガーを使用して、データレベルの変更をその他のレプリケーション・サイトに非同期にレプリケートして、行レベルの同期データ・レプリケーションをサポートするリモート・プロシージャ・コール(RPC)を生成します。ただし、このRPCの実行は延期されません。かわりに、データ・レプリケーションRPCは、ローカル・レプリカを変更する同一のトランザクションの境界内で実行されます。したがって、レプリケート表を管理する同期リンクされたすべてのサイトで、データレベルの変更が可能な必要があります。可能でない場合は、トランザクションはロールバックされます。

同期データ伝播

図2-8に示すように、アプリケーションによってローカルのレプリケート表にDMLによる変更が加えられ、レプリケーション・グループで行レベルの同期レプリケーションを使用しているときは常に、変更内容は内部トリガーによってレプリケーション環境の他のマスター・サイトに同期伝播されます。アプリケーションでローカルな変更が適用されると、内部トリガーからリモート・マスター・サイトで生成されたプロシージャに対して、レプリケーション・プロパゲータのセキュリティ・コンテキストでコールが発行されます。障害が発生した場合は、すべての分散トランザクションがコミットまたはロールバックされます。


関連項目:

分散トランザクションの詳細は、『Oracle Database管理者ガイド』を参照してください。

図2-8 行レベルの同期レプリケーションを使用した変更の伝播

図2-8の説明が続きます。
「図2-8 行レベルの同期レプリケーションを使用した変更の伝播」の説明

制限事項

2つの異なるサイトで同じ行が同時に更新されるときは、同期レプリケーションで使用されるロック・メカニズムにより、デッドロックが発生することがあります。アプリケーションでレプリケート表への同期更新が実行されると、まずローカル行がロックされ、次にAFTER ROWトリガーを使用して対応するリモート行がロックされます。各サイトでトランザクションがコミットされると、ロックは解放されます。


注意:

レプリケーション・データのリアルタイム伝播を使用するレプリケーション・システムは、システム内のすべてのサイトが同時に使用可能な場合にのみ機能するため、システムとネットワークの可用性に大きく依存します。

同期を取ってレプリケートされるトランザクションの接続先

同期レプリケーションのサポートに必要なリモート・プロシージャ・コールは、各オブジェクトの内部トリガーに組み込まれています。レプリケート・オブジェクトのレプリケーション・サポートを生成すると、すべてのマスター・サイトでトリガーがアクティブ化され、新しいサイトに必要なリモート・プロシージャ・コールが追加されます。反対に、マスター・グループからマスター・サイトを削除すると、内部トリガーからコールが削除されます。

競合の検出

マスター・グループのすべてのサイトが互いに同期通信している場合は、アプリケーションでレプリケーションの競合が発生することはありません。ただし、別のサイトに非同期で変更を送信するサイトが1つでもあると、レプリケーション環境のいずれかのサイトで競合が発生する可能性があります。

変更が同期伝播されている場合は、エラーが発生し、ロールバックが必要になります。変更内容が非同期で伝播されている場合は、競合が自動的に検出されてエラー・キューでログに記録されるか、適切な解消方法を指定している場合にはその競合が解消されます。

複合モードのマルチマスター・システムについて

状況によっては、一部のマスター・サイトでマスター・グループの変更内容を非同期で伝播し、他のマスター・サイトでは同期伝播するような複合モード環境の設定が必要な場合があります。新規マスター・サイトをデータ伝播モードが異なるグループに追加するときは、その順番が重要となることがあります。

たとえば、A、BおよびCの3つのマスター・サイトがあると想定します。まずマスター定義サイトとしてサイトAを作成し、次に同期伝播モードでサイトBを追加した場合、サイトAからサイトBへも、サイトBからサイトAへも変更は同期を取って送信されます。どのサイトでも遅延トランザクションは作成されないため、どちらかのサイトでリンクをスケジュールする必要はありません。

次に、非同期伝播モードでマスター・サイトCを作成するとします。伝播モードは、図2-9に示すようになります。

図2-9 伝播モードの選択

図2-9の説明が続きます。
「図2-9 伝播モードの選択」の説明

次に、サイトAからサイトC、サイトBからサイトC、サイトCからサイトAおよびサイトBへの遅延トランザクション・キューの伝播をスケジュールする必要があります。

別の例として、サイトAをマスター定義サイトとして作成し、サイトCを非同期伝播モードで追加した後、サイトBを同期伝播モードで追加する場合を考えてみます。伝播モードは、図2-10に示すようになります。

図2-10 順序に関する考慮事項

図2-10の説明が続きます。
「図2-10 順序に関する考慮事項」の説明

複合モードのマルチマスター・システムに新規マスター・サイトを追加するときは、その追加が既存のサイトとのデータ伝播モードに与える影響を考慮してください。

伝播の開始

同期伝播を使用する場合、DMLが即時に伝播され、自動的に開始されます。非同期伝播を使用する場合は、2つの方法で遅延トランザクションを伝播できます。

  • スケジュール・ジョブ: 通常、設定したスケジュール間隔に従って遅延トランザクションを自動的に伝播するには、スケジュール・ジョブを使用します。

  • 手動による伝播: ストアド・プロシージャを実行したり、レプリケーション・マネージメント・ツールを使用して、変更を手動で伝播することもできます。遅延トランザクションがジョブ・キューによって自動的に伝播されるまで待機しない場合は、遅延トランザクションを手動で伝播する必要があります。

パフォーマンス・メカニズム

他のエンタープライズ・データベース・ソリューションと同様に、データベース管理者にとってパフォーマンスは常に重要な課題です。Advanced Replicationには、レプリケーション環境のパフォーマンスを高めるいくつかのメカニズムがあります。

パラレル伝播

パラレル伝播では、スループットを向上させるため、複数のパラレル伝送ストリームを使用してレプリケート・トランザクションを非同期で伝播します。必要に応じて依存トランザクションの実行が命令され、グローバルなデータベースの整合性が保証されます。

パラレル伝播では、使用可能なパラレル処理のプールが使用されます。これは、パラレル問合せ、パラレル・ロード、パラレル・リカバリなどの他のパラレル操作に使用されるプールと同じです。各サーバー・プロセスでは、シングル・ストリームを介してトランザクションが伝播されます。これらのサーバー・プロセスは、パラレル・コーディネータ・プロセスにより制御されます。コーディネータでは、トランザクション依存性を追跡しサーバー・プロセスに作業を割り当て、その進行状況を追跡します。

操作の実行中は、パラレル処理がサーバーのパラレル操作に対応付けられた状態になります。操作が完了すると、サーバー・プロセスは他のパラレル操作の処理に使用できます。たとえば、接続先への遅延トランザクション・キューのパラレル・プッシュが実行されるときは、キューのプッシュに使用されるすべてのパラレル処理は、プッシュが完了するまで占有されます。

サーバー用のパラレル処理のプールを正しく構成するには、レプリケーション・システムの構成に関する問題を考慮する必要があります。

  • シリアル伝播を使用するようにすべてのスケジュール・リンクを構成すると、レプリケーション・システムではパラレル処理は使用されません。したがって、レプリケーションを考慮して、パラレル処理のプールのサイズを調整する必要はありません。シリアル伝播は、通常、下位互換性が必要な場合にのみ使用します。

  • 1つ以上のスケジュール・リンクをパラレル伝播を使用するように構成する場合、それぞれのリンクが変更を接続先にプッシュするために使用するパラレル処理の数を考慮する必要があります。さらに、別の操作によって使用されないように、各プッシュでパラレル・サーバーを保持する時間を考慮する必要があります。たとえば、遅延秒数値を大きくして連続的な伝播用にスケジュール・リンクを構成すると、接続先にトランザクションをプッシュするために使用するパラレル処理が保持されます。したがって、サーバーの他のパラレル操作で使用するプロセスを十分に確保するために、対応するデータベース・サーバーのパラレル処理の数を増やす必要があります。

パラレル問合せプロセスのデータベース・サーバーのプールを構成するには、次の初期化パラメータを使用します。

パラレル伝播の実装

ほとんどのユーザーの場合、パラレル伝播パラメータ値を1に設定すると、十分なパフォーマンスが得られます。1に設定すると、シリアル伝播ではなく、前項で説明した最適化されたデータの交換方式が使用されます。ただし、一部のユーザーは、パラレル伝播値をさらにチューニングすることが必要な場合があります。

パラレル伝播値をさらにチューニングする場合、次の手順の実行をお薦めします。

  1. パラレル伝播値を1に設定します。

  2. 使用しているデータベース環境をテストし、伝播スループットを慎重に測定します。

    パラレル伝播値が1でパフォーマンス目標が達成される場合は、パラレル伝播が実装されたことになるため、残りの手順を実行する必要はありません。


    注意:

    パラレル伝播値を大きくすると、パラレル伝播のパフォーマンスが向上する一方で、追加のパラレル・スレーブのサポートに必要なリソースが増大します。

  3. パラレル伝播値を1に設定した場合よりもスループットを向上させたい場合は、パラレル伝播値を2に設定します。

  4. 使用しているデータベース環境をテストし、伝播スループットを慎重に測定します。

    通常、伝播値を2に設定すると、伝播スループットは低下します。これは、依存トランザクションを使用可能なスレーブに割り当て、追加トランザクションを割り当てる前に必要なコミットを待機しているコーディネータに関連したラウンドトリップ遅延によるものです。

    パラレル伝播値を4に設定して手順34を繰り返し、さらに、パラレル伝播値を8に設定して同じ手順を繰り返します。それでもスループットが改善されない場合は、使用している環境のトランザクションの相互依存性が非常に高いことが考えられます。パラレル伝播値を1に下げ、手順5に進んでください。


    関連項目:

    トランザクション依存性を下げるテクニックの詳細は、「パラレル伝播のチューニング」を参照してください。

    パラレル伝播値を2、4または8のいずれかに設定することでパフォーマンスが向上した場合は、トランザクションの相互依存性は低いといえます。パラレル伝播値は9以上の値に設定してもかまいません。必ず使用している環境を完全にテストしてください。パラレル化が増大すれば、追加のパラレル・スレーブのサポートに必要なリソースも増大することに注意してください。

  5. テスト結果に基づき、使用している環境でパフォーマンスが最善になる値にパラレル伝播を設定します。

パラレル伝播のチューニング

パラレル伝播のパフォーマンス上の利点を最大限に活用するには、作成する依存トランザクションの数を減らします。トランザクションは、依存関係にあるすべてのトランザクションがコミットされるまで開始できません。

依存トランザクションの数を減らすには、次のようにします。

  • 可能であれば、トランザクションを小さくします(つまり、自律性を損なわない範囲で、コミットの回数を増やします)。

  • 挿入を受け取る各表の空きリスト数を増やします。

  • ホットスポット(頻繁に変更される行。同じ行に対して操作が行われる場合、そのトランザクションはシリアライズされます)を回避します。たとえば、行のカウンタを使用して手動で増分するのではなく、Oracleの順序を使用します。

  • 行レベルの依存性の追跡を行うようにします。

最小限の通信

行の更新の競合を検出および解消するには、伝播サイトから受信サイトに新旧の行に関するデータを送信する必要があります。デフォルトでは、レプリケート表内の変更された各行の競合を検出するために通信する必要があるデータの量を最小化します。具体的には、次の値が伝播されます。

  • 主キー値および変更された各列グループの各列の古い値(変更前の値)

  • それぞれの更新された列の新しい値


    注意:

    • 挿入された行には古い値はありません。また、削除された行には新しい値はありません。

    • DBMS_REPCATパッケージのCREATE_MVIEW_REPOBJECTおよびGENERATE_REPLICATION_SUPPORTプロシージャを実行するときに、min_communicationパラメータにデフォルト値のtrueが設定されていることを確認して、レプリケーション環境が最小限の通信を使用するようにします。


遅延秒数

パフォーマンスに直接かかわるメカニズムではありませんが、delay_secondsパラメータ値を適切に設定すると、遅延トランザクションの伝播のタイミングをより詳細に制御できます。

遅延トランザクションをプッシュする場合は、SCHEDULE_PUSHプロシージャまたはPUSHファンクションにdelay_secondsパラメータを設定します。 遅延トランザクションをパージする場合は、SCHEDULE_PURGEプロシージャまたはPURGEファンクションにdelay_secondsパラメータを設定します。 これらのプロシージャとファンクションは、DBMS_DEFER_SYSパッケージにあります。

delay_secondsパラメータは、ジョブが遅延トランザクション・キューを認識し続ける時間を制御します。 delay_secondsパラメータ値を最大限に活用した2つの例を次に示します。

delay_seconds = 0(デフォルト)

間隔を60分に設定したスケジュール・ジョブが午後2時30分に起動され、遅延トランザクション・キューをチェックする場合、既存の遅延トランザクションはすべて伝播されます。伝播には2分かかるので、ジョブが完了するのは午後2時32分です。

遅延トランザクションが午後2時34分にキューに入れられた場合、ジョブが完了しているためこの遅延トランザクションは伝播されません。このシナリオでは、遅延トランザクションは午後3時30分に伝播されます。

delay_seconds = 300

間隔を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は、レプリケート・トランザクションがリモート・サイトに伝播されたときの依存性の順序を維持します。たとえば、次のようなトランザクションがあったとします。

  1. トランザクションAが受注を取り消します。

  2. トランザクションBが取消しを検出して返金を処理します。

トランザクションBは、ローカル・システムでの受注の取消し(トランザクションA)のコミット済の更新を参照するので、トランザクションBはトランザクションAに依存しています。

トランザクションA(受注の取消し)が正常に伝播された後で、トランザクションB(返金)が伝播されます。取消しの適用後に返金を処理する更新が適用されます。

パラレル伝播の依存性の追跡

ローカル・システムで新規トランザクションが実行されるときは、次の処理が実行されます。

  1. データを更新した最新トランザクションのシステム変更番号(SCN)が記録されます。新規トランザクションはこれを依存SCNとして認識します。SCNはデータ・ブロック・レベルまたは行レベルで記録できます。これについてはこの章で後述します。

  2. 依存SCN以下のSCNを持つトランザクションが、リモート・システムに正常に伝播されるようにします。

  3. 待機中の依存トランザクションが伝播されます。


    注意:

    トランザクション間で依存関係の可能性がないときは、トランザクションはパラレルで伝播されます。

パラレル伝播は、シリアル伝播とは異なる方法でデータ整合性を保持します。シリアル伝播では、依存性を維持するために、ローカル・システム上でコミットするときと同じ順序ですべてのトランザクションが適用されます。パラレル伝播では、依存性を追跡し、依存性があるときはコミットされた順に実行し、依存性がないときはパラレルで実行します。シリアル伝播でもパラレル伝播でも、トランザクション内の実行順序は保持されます。遅延トランザクションは、各サイトで、ローカル・トランザクション内で実行された順序と同じ順序で、リモート・プロシージャ・コールを実行します。


注意:

シングル・コーディネータ・プロセスは、リモート・サイトに対する各データベース・リンクに存在しています。同じリモート・サイトに対する各データベース・リンクには、異なる接続修飾子が必要です。


関連項目:

「接続修飾子」

パラレル化を改善するための行レベルでの依存性の追跡の使用

表を作成するときは、システム変更番号(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句を使用するには、レプリケーション・サイト間の互換性のレベルがリリース9.0.1以上である必要があります。互換性のレベルは、COMPATIBLE初期化パラメータによって制御されます。


関連項目:

ROWDEPENDENCIES句を使用した表の作成方法の詳細は、「行レベルでの依存性の追跡」を参照してください。

パラレル化を改善するためのトランザクション依存性の最小化

レプリケート表のいくつかでROWDEPENDENCIES句を使用していない場合は、トランザクション依存性を最小化することで、これらの表のパラレル伝播のパフォーマンスを改善できます。

この場合、アプリケーション条件によっては、トランザクション間に依存関係を確立して、遅延トランザクションの伝播を強制的にシリアライズできます。複数の非関連トランザクションによってレプリケート表内の同じデータ・ブロックが変更される場合、対応するトランザクションはリモート接続先へシリアル伝播されます。

データ・ブロック・レベルで作成されたトランザクション依存性を最小化するには、データ・ブロックの変更が1つまたは少数のデータ・ブロックに集中することを回避します。たとえば、レプリケート表にINSERTアクティビティが頻繁に発生する場合は、表の空きリストを複数作成することで、新しい行の記憶域を複数のデータ・ブロックに分散できます。

多数のトランザクションすべてが同一の小さい表を更新する状態は、できるだけ避けてください。たとえば、複数のトランザクションが1つの小さい表に読取りと更新を行い、主キーの順序番号生成をシミュレートするのは、望ましいアプリケーション設計とはいえません。このように設計すると、すべてのトランザクションが同じデータ・ブロックを更新します。より優れたソリューションは、順序を作成し順序番号をキャッシュに格納することで、主キーの生成を最適化し、パラレル伝播のパフォーマンスを改善できます。

競合解消メカニズム

レプリケーション環境の受信マスター・サイトでは、次のような更新の競合、一意性競合および削除の競合が検出されます。

  • 主キー列または更新された列グループの列のいずれかで、レプリケート行の古い値(変更前の値)と受信サイトの同じ行の現在の値が異なる場合、受信サイトで更新の競合が検出されます。

  • レプリケート行のINSERTまたはUPDATEの実行中に一意制約違反が発生した場合、受信サイトで一意性競合が検出されます。

  • 行の主キーが存在しないために受信サイトでUPDATE文またはDELETE文の対象の行が見つからない場合、受信サイトで削除の競合が検出されます。


    注意:

    行の更新の競合を検出および解消するには、伝播サイトから受信サイトに新旧の行に関するデータを送信する必要があります。パフォーマンスを最大にするには、更新の競合の検出および解消サポートに使用するデータの量をチューニングします。詳細は、「古い値の送信および比較」を参照してください。

競合検出時の行の識別

レプリケーションの競合を正確に検出するには、データ・レプリケーション時に別々のサイトの対応する行を一意に識別し、一致させる必要があります。通常、Oracleのレプリケーション機能では、表の主キーを使用して表内の行を一意に識別します。 表に主キーがない場合は、代替キーを指定する必要があります。代替キーとは、データ・レプリケーション時に表内の行を一意に識別するために使用する列または列のセットです。


注意:

アプリケーションで表の主キーまたは代替キーを更新しないようにしてください。これにより、行を識別し、レプリケート・データの整合性を保つことができます。

上書きによる競合解消方法

Oracleには、データ競合が検出されたときに競合解消方法を定義するメカニズムがあります。ビルトインの競合解消方法は次のとおりです。

  • 最新のタイムスタンプおよび最も古いタイムスタンプ

  • 上書きおよび廃棄

  • 最大値および最小値

  • 加算および平均

  • タイムスタンプ

  • 優先グループ

  • サイト優先順位

ビルトインの競合解消方法ではレプリケーション環境のニーズが満たされない場合、PL/SQLを使用して独自の競合解消方法を作成し、ユーザー定義の競合解消方法として実装できます。競合解消の仕組みの詳細は、第5章「競合解消の概念およびアーキテクチャ」を参照してください。


関連項目:

レプリケーション・マネージメント・ツールを使用した競合解消の実装方法の詳細は、レプリケーション・マネージメント・ツールのオンライン・ヘルプを参照してください。レプリケーション・マネージメントAPIを使用した競合解消の実装方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。