| Oracle® Database 2日でデータ・レプリケーションおよび統合ガイド 11g リリース2(11.2) B56305-03 |
|
 前 |
 次 |
この章では、Oracle Streamsレプリケーションに関する概念を示し、データベース間のデータの連続的なレプリケート方法を説明します。
この章は次の項で構成されています。
|
関連項目:
|
レプリケーションは、複数のデータベースでデータベース・オブジェクトとデータを共有するプロセスです。データベース・オブジェクトとデータを複数のデータベースでメンテナンスするために、あるデータベースでのこれらのデータベース・オブジェクトの1つに対する変更が他のデータベースと共有されます。このようにして、レプリケーション環境内のすべてのデータベースでデータベース・オブジェクトとデータの同期が維持されます。
一部のレプリケーション環境は、共有データベース・オブジェクトに対して行われた変更を絶えずレプリケートする必要があります。 Oracle Streamsは、連続レプリケーションのためのOracle Database機能です。通常、このような環境では、共有データベース・オブジェクトを含むデータベースがほぼ常にネットワークに接続され、これらのネットワーク接続上でデータベース変更を絶えずプッシュします。
1つの共有データベース・オブジェクトに対して変更が行われると、Oracle Streamsは次のアクションを実行して、同じ変更が他の各データベースの対応する共有データベース・オブジェクトに対して行われるようにします。
Oracle Streamsは、変更を自動的に取得し、それをキューにステージングします。
Oracle Streamsは、共有データベース・オブジェクトを含む他の各データベース内のキューに変更を自動的にプッシュします。
Oracle Streamsは、他の各データベースでの変更を自動的に処理します。処理中に、Oracle Streamsはキューから変更をデキューし、変更を共有データベース・オブジェクトに適用します。
図4-1に、Oracle Streamsの情報フローを示します。
Oracle Streamsレプリケーションを使用して、複数のデータベースでデータを共有し、これらのデータベースでデータを効率よく最新に保つことができます。たとえば、全世界にいくつかのコール・センターを持つ会社は、顧客情報を各コール・センターのローカル・データベースに格納できます。このような環境では、Oracle Streamsでの連続レプリケーションにより、ある場所の顧客データに対して行った変更が、できるだけ早く他のすべての場所にプッシュされるようにすることができます。
Oracle Streamsを使用してデータベース・オブジェクトに対する変更を取得する場合、変更は論理変更レコード(LCR)に書式設定されます。LCRは、データベース変更を説明する特定の形式のメッセージです。変更がデータ操作言語(DML)操作だった場合は、行LCRにより、DML操作の結果として発生した行変更がそれぞれカプセル化されます。1つのDML操作によって複数の行変更が発生する場合があるため、1つのDML操作によって複数の行LCRが発生することがあります。変更がデータ定義言語(DDL)操作だった場合、1つのDDL LCRがDDL変更をカプセル化します。
次の各項で、Oracle Streamsレプリケーションを詳細に説明します。
Oracle Streamsは、データベース変更を自動的に取得する2つの方法を提供します。
取得プロセスは、比較的大量の表、スキーマ全体またはデータベースに対するデータ操作言語(DML)変更の取得に使用します。また、取得プロセスは、表およびその他のデータベース・オブジェクトに対するデータ定義言語(DDL)変更の取得に使用する必要があります。詳細は、「取得プロセスでの変更の取得の概要」を参照してください。
同期取得は、比較的少数の表に対するDML変更の取得に使用します。詳細は、「同期取得での変更の取得の概要」を参照してください。
単一の取得プロセスまたは単一の同期取得は、1つのデータベースのみに対して行われた変更を取得できます。変更が発生したデータベースは、変更のソース・データベースと呼ばれます。
|
注意: このマニュアルの例ではDMLの変更のみをレプリケートします。DMLを変更する前に、DDL変更のレプリケートを理解する必要があります。DDL変更のレプリケートの詳細は、『Oracle Streamsレプリケーション管理者ガイド』および『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 |
取得プロセスは、REDOログに記録された変更を非同期に取得するOracle Databaseのオプションのバックグラウンド処理です。取得プロセスは、データベース変更を取得すると、それを論理変更レコード(LCR)に変換し、LCRをエンキューします。エンキューは、メッセージをキューに置くプロセスです。
取得プロセスには常に1つのキューが関連付けられており、このキューのみにLCRをエンキューします。パフォーマンスを向上させるために、取得されたLCRは常にバッファ・キューに格納されます(バッファ・キューは、キューに関連付けられているシステム・グローバル領域(SGA)メモリーです)。
図4-2では、取得プロセスがどのように動作するかを示します。
取得プロセスは、ソース・データベースまたはリモート・データベース上で実行できます。ソース・データベース上で実行する場合、取得プロセスはローカル取得プロセスと呼ばれます。リモート・データベース上で実行する場合、取得プロセスはダウンストリーム取得プロセスと呼ばれます。
ダウンストリーム取得では、REDO転送サービスは、ソース・データベースのログ・ライター・プロセス(LGWR)を使用して、ダウンストリーム取得を実行するデータベースにREDOデータを送信します。異なるデータベースが変更を取得するため、ダウンストリーム取得プロセスではソース・データベースのリソースが少なくてすみます。一方、ローカル取得プロセスは、ダウンストリーム取得よりも構成と管理が簡単です。ローカル取得プロセスによって、プラットフォームまたはOracle Databaseのバージョンが異なるレプリケーション環境にも柔軟性が提供されます。
|
関連項目:
|
REDOログの非同期マイニングのかわりに、同期取得は内部メカニズムを使用して、データ操作言語(DML)の変更が表に対して行われたときにその変更を取得します。単一のDML変更によって、表の1つ以上の行が変更されることがあります。同期取得はそれぞれの行変更を取得し、それを行の論理変更レコード(LCR)に変換してエンキューします。
同期取得は常に単一のキューに関連付けられ、行LCRをこのキューにのみエンキューします。同期取得は常に行LCRを永続キューにエンキューします。永続キューは、メモリーではなくハード・ディスク上のキュー表にメッセージを格納するキューの部分です。
通常、同期取得は、比較的少数の表に対する変更を取得するレプリケーション環境で使用するのが最適です。多くの表、スキーマ全体またはデータベース全体に対する変更を取得する必要がある場合は、同期取得のかわりに取得プロセスを使用する必要があります。
図4-3では、同期取得がどのように動作するかを示します。
|
注意: Oracle Database 11g Standard Editionを使用している場合、同期取得はデータベース変更を自動的に取得できる唯一のOracle Streamsコンポーネントです。取得プロセスを使用するには、Oracle Database 11g Enterprise Editionが必要です。 |
伝播は1つのキューから他のキューにメッセージを送信します。Oracle Streamsを使用して、同じデータベース内、または異なるデータベース内の2つのキュー間のメッセージ伝播を構成できます。Oracle Streamsは、データベース・リンクとOracle Schedulerジョブを使用してメッセージを送信します。伝播は常に「ソース・キュー」と「宛先キュー」の間で行われます。Oracle Streamsレプリケーション環境では、伝播は通常、ローカル・データベース内のソース・キューからリモート・データベース内の宛先キューにデータベース変更を記述するメッセージを(LCRの形式で)送信します。
図4-4では、伝播を示します。
|
関連項目:
|
データベース変更が取得されて伝播された後、これらの変更はキューに存在し、レプリケーション・プロセスを完了するために適用する準備ができます。 適用プロセスは、論理変更レコード(LCR)およびその他のタイプのメッセージを特定のキューからデキューするオプションのOracle Databaseバックグラウンド・プロセスです。デキューは、メッセージをキューから取得するプロセスです。単純なOracle Streamsレプリケーション環境では、通常、適用プロセスはデキューするLCR内の変更をローカル・データベースのデータベース・オブジェクトに直接適用します。
適用プロセスは、常に単一のキューに関連付けられ、このキューからのみメッセージをデキューします。単一の適用プロセスは、バッファ・キューまたは永続キューからメッセージをデキューできますが、両方からデキューすることはできません。したがって、適用プロセスが、取得プロセスによって取得された変更を適用する場合は、バッファ・キューからLCRをデキューするように適用プロセスを構成する必要があります。一方、適用プロセスが、同期取得によって取得された変更を適用する場合は、永続キューからLCRをデキューするように適用プロセスを構成する必要があります。
図4-5では、適用プロセスがどのように動作するかを示します。
適用プロセスは、LCRを正常に適用できない場合に、LCR、およびトランザクション内の他のすべてのLCRをエラー・キューという特別なキューに移動します。エラー・キューには、データベースの現在の適用エラーがすべて含まれます。データベースに複数の適用プロセスがある場合、エラー・キューには各適用プロセスの適用エラーが含まれます。エラーの原因となった条件を修正してから、エラー・キュー内の対応するトランザクションを再実行して変更を適用します。たとえば、表の行を変更してトランザクション・エラーの原因となった条件を修正し、トランザクションを再実行できます。
適用プロセスが変更をデータベース・オブジェクトに適用するためには、インスタンス化システム変更番号(SCN)をデータベース・オブジェクトに対して設定する必要があります。インスタンス化SCNは、ソース・データベースのSCNの後にコミットされた変更のみが適用プロセスによって適用されることを指定するデータベース・オブジェクトのSCNです。表のインスタンス化SCNでは、ソース・データベースと宛先データベースで指定されたSCNに一貫性があることを前提としています。通常、インスタンス化SCNは、Oracle Streamsレプリケーション環境を構成するときに自動的に設定されます。
Oracle Streamsレプリケーション構成では、レプリケート対象を指定する必要があります。取得プロセス、同期取得、伝播および適用プロセスは、Oracle Streamsクライアントと呼ばれます。Oracle Streamsクライアントがレプリケートする対象は、ルールによって決まります。ルールはOracle Streamsクライアントごとに個別に設定でき、異なるOracle Streamsクライアント間でルールが一致している必要はありません。
ルールはルール・セットに編成でき、各Oracle Streamsクライアントの動作は、Oracle Streamsクライアントに関連付けられているルール・セット内のルールによって決まります。 ポジティブ・ルール・セットとネガティブ・ルール・セットを取得プロセス、伝播および適用プロセスに関連付けることができますが、同期取得に関連付けることができるのはポジティブ・ルール・セットのみです。
レプリケーション環境では、データベース変更がルール・セットを満たす場合にOracle Streamsクライアントがそのタスクを実行します。一般に、変更がOracle Streamsクライアントのルール・セットを満たすのは、変更についてネガティブ・ルール・セットのどのルールもTRUEと評価されず、ポジティブ・ルール・セットの1つ以上のルールが変更についてTRUEと評価される場合です。ネガティブ・ルール・セットが常に最初に評価されます。
Oracle Streamsレプリケーション環境でルール・セットを使用すると、具体的には次のことができます。
取得プロセスがREDOログから取得する変更または破棄する変更を指定します。REDOログ内で検出された変更が取得プロセスのルール・セットを満たしている場合、取得プロセスはその変更を取得します。REDOログ内で検出された変更が取得プロセスのルール・セットを満たしていない場合、取得プロセスはその変更を破棄します。
同期取得が取得する変更を指定します。データ操作言語(DML)の変更が同期取得のルール・セットを満たす場合、同期取得は変更がコミットされた直後に変更を取得します。表に対して行われたDML変更が同期取得のルール・セットを満たさない場合、同期取得は変更を取得しません。
伝播があるキューから別のキューに送信する変更、または破棄する変更を指定します(LCRにカプセル化されています)。キュー内のLCRが伝播のルール・セットを満たしている場合、伝播はそのLCRを送信します。キュー内のLCRが伝播のルール・セットを満たしていない場合、伝播はそのLCRを破棄します。
適用プロセスがデキューするLCR、または破棄するLCRを指定します。キュー内のLCRが適用プロセスのルール・セットを満たしている場合、適用プロセスはそのLCRをデキューして処理します。キュー内のLCRが適用プロセスのルール・セットを満たしていない場合、適用プロセスはLCRを破棄します。
|
関連項目:
|
ルールベース変換は、複数のデータベースでデータベース・オブジェクトが同一でない場合に柔軟性を提供する追加の構成オプションです。ルールベース変換では、各データベースで正常に適用できるように、データベース・オブジェクトに対する変更を修正できます。ルールベース変換は、ポジティブ・ルール・セット内のルールがTRUEと評価された場合のメッセージに対する修正を示します。
たとえば、変更が発生したデータベースで表に5つの列があり、別のデータベースの共有表には5つの列のうちの4つしかないとします。データ操作言語(DML)操作がソース・データベースの表に対して実行されると、行変更が取得され、行LCRとして書式設定されます。ルールベース変換は、他のデータベースに正常に適用できるようにこれらの行LCR内の余分な列を削除できます。行LCRが変換されない場合、行LCRには余分な列があるため他のデータベースでの適用プロセスでエラーが発生します。
ルールベース変換には、宣言とカスタムの2種類があります。宣言ルールベース変換には、DML変更(行LCR)の結果として発生した行変更の一般的な変換シナリオのセットが含まれます。カスタム・ルールベース変換には、変換を実行するためのユーザー定義PL/SQLファンクションが必要です。このマニュアルでは、宣言ルールベース変換についてのみ説明します。
次の宣言ルールベース変換を使用できます。
追加列変換は、列を行LCRに追加します。
削除列変換は、行LCRから列を削除します。
保存列変換は、行LCRに列のリストを保存しますが、リストにない列は削除します。
名前変更列変換は、行LCR内の列の名前を変更します。
名前変更スキーマ変換は、行LCR内のスキーマの名前を変更します。
名前変更表変換は、行LCR内の表の名前を変更します。
これらの宣言ルールベース変換の1つを追加するときに、変換に関連付けるルールを指定します。指定したルールが行LCRについてTRUEと評価される場合、Oracle Streamsは行LCRで宣言変換を内部的に実行します。通常、ルールとルール・セットはOracle Streamsレプリケーション環境を構成するときに自動的に作成されます。
1つのルールに対して複数の宣言ルールベース変換を構成できますが、カスタム・ルールベース変換は、1つのルールに対して1つのみ構成できます。また、1つのルールに対して宣言ルールベース変換とカスタム・ルールベース変換の両方を構成することもできます。
変換は、Oracle Streams情報フローの任意のステージ(取得中、伝播中または適用中)で発生します。変換がいつ発生するかは、変換が関連付けられているルールによって決まります。たとえば、伝播中に変換を実行するには、変換を伝播のポジティブ・ルール・セットのルールに関連付けます。
|
関連項目:
|
サプリメンタル・ロギングは、操作(行の更新など)が実行されるたびにREDOログに配置される追加の列データのプロセスです。取得プロセスは、この追加情報を取得し、論理変更レコード(LCR)に配置します。これらのLCRを適用する適用プロセスは、データベース変更を正しく適用するためにこの追加情報を必要とします。
|
関連項目:
|
競合は、表のデータを共有している2つの異なるデータベースが表の同じ行をほぼ同時に変更した場合に発生します。これらの変更がこれらのデータベースの一方で取得され、もう一方のデータベースに送信されると、適用プロセスは、行LCRを表に適用しようとしたときに競合を検出します。デフォルトでは、適用エラーがエラー・キューに入れられ、そこで手動で解消できます。適用エラーを回避するには、適用プロセスが環境に最適な方法で競合を処理するように競合解消を構成する必要があります。
Oracle Databaseには、行のUPDATEが原因で競合が発生した場合に競合を解消する競合ハンドラが組み込まれています。これらのハンドラは、組込み更新競合ハンドラと呼ばれています。
適用プロセスで、デキューされた行LCRに対する更新競合が発生した場合、2つのデータベースのデータの一貫性を維持するために行LCRを適用するか破棄する必要があります。更新競合を解消する最も一般的な方法は、最新のタイムスタンプを持つ変更を保持し、古い変更を破棄することです。表に最新の時刻競合解消を構成する方法については、「チュートリアル: 表の最新時刻競合解消の構成」を参照してください。
次の各項で、特定のタイプのレプリケーション環境で競合解消を構成する方法を説明します。
|
注意: 競合は、単一のデータベースに対する変更のみが取得されるレプリケーション環境では発生しません。このようなレプリケーション環境では、通常、他のデータベースのレプリカは読取り専用になります。 |
|
関連項目:
|
変更循環は、発生元のデータベースに変更を再び送信することを意味します。通常は、変更循環によって各データベース変更の結果が発生元のデータベースに無限にループするため、変更循環を回避する必要があります。このようなループによって、データベース内に意図しないデータが生成され、ネットワーキングと環境のコンピュータ・リソースに負荷がかかります。デフォルトでは、Oracle Streamsは変更循環を回避するように設計されています。
タグは、変更レコード内の追加情報です。データベース変更を記録する各REDOエントリと、データベース変更をカプセル化する各論理変更レコード(LCR)には、タグが含まれます。タグのデータ型はRAWです。
デフォルトでは、変更レコードには次のタグ値があります。
ユーザーまたはアプリケーションがデータベース変更を生成する場合、各変更のタグ値はNULLです。特定のデータベース・セッションに対してこのデフォルトを変更できます。
適用プロセスがデータベース・オブジェクトにデータベース変更を適用することによってその変更を生成する場合、各変更のタグ値は'00''(ゼロが2つ)と等価の16進数になります。特定の適用プロセスのデフォルトは変更可能です。
LCRのタグ値は、LCRがどのように取得されたかによって決まります。
取得プロセスによって取得されたLCRには、取得されたREDOレコードのタグ値があります。
同期取得によって取得されたLCRには、変更を行ったデータベース・セッションのタグ値があります。
Oracle Streamsクライアントのルールには、タグ値の条件を含めることができます。たとえば、取得プロセスのルールは、REDOレコードのタグ値に基づいてREDOログ内の変更が取得されるかどうかを決定できます。Oracle Streamsレプリケーション環境では、Oracle Streamsクライアントはタグとルールを使用して変更循環を回避します。
次の各項で、特定のタイプのレプリケーション環境で変更循環が回避される方法を説明します。
|
注意:
|
Oracle Streamsにより、多くの異なるタイプのカスタム・レプリケーション環境を構成できます。ただし、最も一般的なのは、2データベース、ハブアンドスポークおよびn-wayの3つのタイプのレプリケーション環境です。
次の各項で、これらの一般的なレプリケーション環境タイプについて説明し、どのタイプを使用するのが最適かの決定を支援します。
2データベース・レプリケーション環境は、レプリケートされたデータベース・オブジェクトを2つのデータベースのみで共有するレプリケーション環境です。一方のデータベースでレプリケートされたデータベース・オブジェクトに対して行われた変更は、取得された後、もう一方のデータベースに直接送信されて適用されます。2データベース・レプリケーション環境では、一方のデータベースのみでデータベース・オブジェクトに対する変更が許可される場合も、両方のデータベースでデータベース・オブジェクトに対する変更が許可される場合もあります。
レプリケートされたデータベース・オブジェクトに対する変更が一方のデータベースのみで許可されている場合、もう一方のデータベースには、これらのデータベース・オブジェクトの読取り専用レプリカが含まれます。これを単方向レプリケーション環境と呼び、通常は次の基本コンポーネントが含まれます。
1つ目のデータベースには、レプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスまたは同期取得があります。
1つ目のデータベースには、取得した変更を2つ目のデータベースに送信する伝播があります。
2つ目のデータベースには、1つ目のデータベースから変更を適用する適用プロセスがあります。
パフォーマンスを最適化するために、各取得プロセスと適用プロセスには固有のキューがあります。
図4-6に、単方向レプリケーション用に構成された2データベース・レプリケーション環境を示します。
2データベース・レプリケーション環境では、両方のデータベースで、レプリケートされたデータベース・オブジェクトを変更できます。この場合、データベース・オブジェクトに対する変更は、両方のデータベースで取得され、他方のデータベースに送信されて取得されます。これを双方向レプリケーション環境と呼び、通常は次の基本コンポーネントが含まれます。
各データベースには、レプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスまたは同期取得があります。
各データベースには、取得した変更をもう一方のデータベースに送信する伝播があります。
各データベースには、もう一方のデータベースから変更を適用する適用プロセスがあります。
パフォーマンスを最適化するために、各取得プロセスと適用プロセスには固有のキューがあります。
図4-7に、双方向レプリケーション用に構成された2データベース・レプリケーション環境を示します。
通常、双方向レプリケーション環境では、レプリケートされたデータベース・オブジェクトの同期化を維持するために競合解消を構成する必要があります。Oracle Enterprise Managerの「Streamsレプリケーションの設定」ウィザードを使用するか、またはDBMS_STREAMS_ADMパッケージの構成プロシージャを使用して、2データベース・レプリケーション環境を構成できます。
ハブアンドスポーク・レプリケーション環境は、集中データベース(ハブ)がセカンダリ・データベース(スポーク)と通信する環境です。スポークは相互に直接通信しません。ハブアンドスポーク・レプリケーション環境では、スポークはレプリケートされたデータベース・オブジェクトに対する変更を許可する場合と許可しない場合があります。
スポークが変更を許可しない場合、スポークにはハブのデータベース・オブジェクトの読取り専用レプリカが含まれます。このタイプのハブアンドスポーク・レプリケーション環境には、通常は次の基本コンポーネントがあります。
ハブには、レプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスまたは同期取得があります。
ハブには、取得された変更を各スポークに送信する伝播があります。
各スポークには、ハブから変更を適用する適用プロセスがあります。
パフォーマンスを最適化するために、各取得プロセスと適用プロセスには固有のキューがあります。
図4-8に、読取り専用スポークのあるハブアンドスポーク・レプリケーション環境を示します。
スポークがデータベース・オブジェクトに対する変更を許可する場合、通常は変更が取得されてハブに送信され、ハブが他のスポークに変更をレプリケートします。このタイプのハブアンドスポーク・レプリケーション環境には、通常は次の基本コンポーネントがあります。
ハブには、レプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスまたは同期取得があります。
ハブには、取得された変更を各スポークに送信する伝播があります。
各スポークには、レプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスまたは同期取得があります。
各スポークには、スポークで行われた変更をハブに送信する伝播があります。
各スポークには、ハブからの変更と他のスポークからの変更を適用する適用プロセスがあります。
ハブには、各スポークからの変更を適用する個別の適用プロセスがあります。各適用プロセスは、それぞれのスポークから変更を適用する必要があります。
パフォーマンスを最適化するために、各取得プロセスと適用プロセスには固有のキューがあります。
図4-9に、読取り/書込みスポークのあるハブアンドスポーク・レプリケーション環境を示します。
通常、スポーク・データベースでの変更が許可されるハブアンドスポーク・レプリケーション環境では、レプリケートされたデータベース・オブジェクトの同期化を維持するために競合解消を構成する必要があります。ハブアンドスポーク・レプリケーション環境では、レプリケートされたデータベース・オブジェクトに対する変更が一部のスポークでは許可されますが、残りのスポークでは許可されない場合があります。
Oracle Enterprise Managerの「Streamsレプリケーションの設定」ウィザードを使用するか、またはDBMS_STREAMS_ADMパッケージの構成プロシージャを使用して、ハブアンドスポーク・レプリケーション環境を構成できます。
ハブアンドスポーク・レプリケーションが有効な場合については、「Oracle Streamsでのデータのレプリケート時期」を参照してください。
n-wayレプリケーション環境は、各データベースが環境内の他のデータベースと相互に直接通信する環境です。あるデータベースでのレプリケートされたデータベース・オブジェクトに対する変更は、取得されて環境内の他の各データベースに直接送信され、そこで適用されます。
n-wayレプリケーション環境には、通常は次の基本コンポーネントがあります。
各データベースには、レプリケートされたデータベース・オブジェクトに対する変更を取得する1つ以上の取得プロセスまたは同期取得があります。
各データベースには、取得された変更を他のデータベースに相互に送信する伝播があります。
各データベースには、他の各データベースからの変更を適用する適用プロセスがあります。別の適用プロセスが、各ソース・データベースから変更を適用する必要があります。
パフォーマンスを最適化するために、各取得プロセスと適用プロセスには固有のキューがあります。
図4-10に、n-wayレプリケーション環境を示します。
オラクル社が提供する次のパッケージを使用して、n-wayレプリケーション環境を構成できます。
DBMS_STREAMS_ADMでは、キューの設定、取得プロセスまたは同期取得の作成、伝播の作成、適用プロセスおよびレプリケーション環境でのルールおよびルール・セットの構成などの、ほとんどの構成アクションを実行できます。
DBMS_CAPTURE_ADMでは、レプリケーション環境で構成した取得プロセスを開始できます。
DBMS_APPLY_ADMでは、競合解消を構成し、その他の構成タスクと同様に適用プロセスを開始できます。
n-wayレプリケーションが有効な場合については、「Oracle Streamsでのデータのレプリケート時期」を参照してください。
通常、n-wayレプリケーション環境では、レプリケートされたデータベース・オブジェクトの同期化を維持するために競合解消を構成する必要があります。
n-wayレプリケーション環境の構成は、このマニュアルの対象外です。n-wayレプリケーション環境を構成する例の詳細は、「Oracle Streamsの拡張例」を参照してください。
Oracle Enterprise Manager以外にも、Oracle Streamsレプリケーション環境を構成および管理するためのPL/SQLパッケージが提供されています。また、Oracle Streamsレプリケーション環境を監視するためのデータ・ディクショナリ・ビューも提供されています。
次の各項で、Oracle Streamsが提供する主要なPL/SQLパッケージおよびデータ・ディクショナリ・ビューについて説明します。
表4-1に、Oracle Streamsレプリケーション環境の構成および管理に重要なPL/SQLパッケージを示します。
表4-1 Oracle Streamsが提供する主要なPL/SQLパッケージ
| パッケージ | 説明 |
|---|---|
|
このパッケージを使用すると、Oracle Streams環境で一般的なタスクを簡単に実行できます。このパッケージには、Oracle Streamsレプリケーション環境を構成および維持するためのプロシージャが含まれます。また、表、スキーマおよびデータベース・レベルで、取得プロセス、同期取得、伝播および適用プロセスのための単純なルールを追加および削除するための管理インタフェースも備わっています。さらに、キューの作成や、Oracle Streamsメタデータ(データ・ディクショナリ情報など)の管理のためのプロシージャが含まれます。 |
|
|
このパッケージには、取得プロセスを起動、停止および構成するための管理インタフェースが用意されています。また、同期取得を構成するための管理インタフェースも用意されています。このパッケージには、宛先データベースでインスタンス化するために、ソース・データベースでデータベース・オブジェクトを準備するための管理プロシージャもあります。 |
|
|
このパッケージでは、伝播の起動、停止および構成のための管理インタフェースが提供されます。 |
|
|
このパッケージでは、適用プロセスの起動、停止および構成のための管理インタフェースが提供されます。また、競合の検出と解消の構成および適用エラーの管理のためのサブプログラムも含まれます。さらに、このパッケージには、適用ハンドラを構成できるプロシージャも含まれます。このパッケージには、宛先データベースでオブジェクトのインスタンス化SCNを設定する管理プロシージャが用意されています。 |
|
|
|
このパッケージでは、Oracle Streams管理者に対する権限の付与および取消しのためのサブプログラムが提供されます。 |
|
|
このパッケージでは、Oracle Streams環境についての情報の収集および収集した情報に基づくデータベース管理者へのアドバイスを行うためのインタフェースが提供されます。このパッケージは、Oracle Streamsパフォーマンス・アドバイザの一部です。 |
|
関連項目:
|
表4-2に、Oracle Streamsレプリケーション環境の監視に重要なデータ・ディクショナリ・ビューを示します。
表4-2 Oracle Streamsの主要なデータ・ディクショナリ・ビュー
| データ・ディクショナリ・ビュー | 説明 |
|---|---|
|
適用プロセスに関する情報を表示します。 |
|
|
競合ハンドラに関する情報を表示します。 |
|
|
適用プロセスが生成するエラー・トランザクションに関する情報を表示します。 |
|
|
取得プロセスに関する情報を表示します。 |
|
|
伝播に関する情報を表示します。 |
|
|
同期取得および適用プロセスでサポートされていない列に関する情報を表示します。 |
|
|
取得プロセス、同期取得、伝播および適用プロセスで使用されるルールに関する情報を表示します。 |
|
|
取得プロセスでサポートされていないデータベース・オブジェクトに関する情報を表示します。 |
|
|
同期取得に関する情報を表示します。 |
|
|
バッファ・キューおよびバッファ・キュー内のメッセージに関する情報を表示します。 |
|
|
伝播によってバッファ・キュー内に受信されるメッセージに関する情報を表示します。 |
|
|
伝播によってバッファ・キューから送信されるメッセージに関する情報を表示します。 |
|
|
有効化されている適用プロセスのコーディネータに関する情報を表示します。 |
|
|
有効化されている適用プロセスのリーダー・サーバーに関する情報を表示します。 |
|
|
有効化されている適用プロセスの適用サーバーに関する情報を表示します。 |
|
|
有効化されている取得プロセスに関する情報を表示します。 |
|
|
取得プロセスまたは適用プロセスによって処理されているトランザクションに関する情報を表示します。このビューでは、長時間実行トランザクションを識別し、各トランザクションで処理されている論理変更レコード(LCR)の数を判断できます。このビューには、取得プロセスで取得されたLCRに関する情報のみが表示されます。 |
|
関連項目:
|
Oracle Streamsレプリケーションを構成する前に、レプリケーション環境に参加するデータベースを準備します。
Oracle Streamsレプリケーションを準備するには:
Oracle Streamsでレプリケーション環境を構成する前に、初期化パラメータを正しく設定します。
グローバル名: Oracle Streamsレプリケーション環境に参加する各データベースでGLOBAL_NAMES初期化パラメータをTRUEに設定します。詳細は、「GLOBAL_NAMES初期化パラメータをTRUEに設定」を参照してください。
互換性: Oracle Streamsの最新の機能を使用するには、COMPATIBLE初期化パラメータをできるだけ高く設定することをお薦めします。可能な場合は、このパラメータを11.2.0以上に設定します。
システム・グローバル領域(SGA)およびOracle Streamsプール: Oracle Streamsプールが、レプリケーション環境に対して作成されるOracle Streamsコンポーネントを十分に収容できる大きさであることを確認します。Oracle Streamsプールは、システム・グローバル領域(SGA)の一部です。MEMORY_TARGET初期化パラメータ(自動メモリー管理)、SGA_TARGET初期化パラメータ(自動共有メモリー管理)またはSTREAMS_POOL_SIZE初期化パラメータを設定することでOracle Streamプールを管理できます。Oracle Streamsプールの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
Oracle Streamsコンポーネントのメモリー要件は次のとおりです。
各キューには、少なくとも250MBのメモリーが必要です。各キューには、取得した変更を格納するための十分なメモリーが必要です。
各取得プロセスの並列処理には、少なくとも15MBのメモリーが必要です。取得プロセスが変更を取得する際に使用する処理の数は、取得プロセス・パラメータparallelismで制御されます。取得プロセスのパフォーマンスは、取得プロセスの並行性を調整すると改善される場合があります。
各伝播には少なくとも1MBのメモリーが必要です。
各適用プロセスの並列処理には、少なくとも1MBのメモリーが必要です。適用プロセスが変更を適用する際に使用する処理の数は、適用プロセス・パラメータparallelismで制御されます。適用プロセスのパフォーマンスは、適用プロセスの並行性を調整すると改善される場合があります。
処理とセッション: Oracle Streams取得プロセス、伝播および適用プロセスは、バックグラウンドで実行されるプロセスを使用します。これらのプロセスに適応するにはPROCESSESおよびSESSIONS初期化パラメータの値を増やすことが必要な場合があります。
Oracle Streamsレプリケーション環境のベスト・プラクティスを確認し、環境を構成する際にはそれに従います。ベスト・プラクティスの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
ベスト・プラクティスに従えば、パフォーマンスの最適な環境を構成して問題を回避することができます。Oracle Enterprise Managerの「Streamsレプリケーションの設定」ウィザードおよびDBMS_STREAMS_ADMパッケージの構成プロシージャを使用すれば、自動的にベスト・プラクティスに従います。ウィザードや構成プロシージャを使用せずにOracle Streamsレプリケーション環境を構成する場合は、ベスト・プラクティスをよく確認し、可能なかぎりそれに従ってください。
次に、Oracle Streamsの構成時に従う必要のある重要なベスト・プラクティスを示します。
Oracle Streams管理者に個別の表領域を構成します。「チュートリアル: Oracle Streams管理者の構成」 の手順がこのベスト・プラクティスに従っています。
取得プロセス、同期取得および適用プロセスに個別のキューを使用します。最適なパフォーマンスを得るには、通常、これらのコンポーネントがキューを共有しないようにする必要があります。
キュー・ツー・キュー伝播を使用します。
Oracle Streams環境を構成した後は、Oracle Streams環境での操作時に次の重要なベスト・プラクティスに従う必要があります。
パフォーマンスを監視し、必要に応じて調整します。
キューのサイズを監視します。
バックアップに関するOracle Streamsのベスト・プラクティスに従います。
Oracle Streamsの情報に関するアラート・ログを確認します。
最適なパフォーマンスを得るために、取得プロセスの並列性を設定します。
最適なパフォーマンスを得るために、適用プロセスの並列性を設定します。
適用エラーを確認し、発生する場合は管理します。
これらのベスト・プラクティスと、その他のOracle Streamsのベスト・プラクティスの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
|
関連項目:
|
この項では、Oracle Streamsレプリケーション環境の構成方法について、例を使用して説明します。例では、最も一般的なタイプのOracle Streamレプリケーション環境を構成します。
次に、例について説明します。
チュートリアル: ローカル取得プロセスを使用した2データベース・レプリケーションの構成
この例では、2つのデータベースでhrスキーマにあるすべての表にデータ操作言語(DML)の変更をレプリケートするOracle Streamsレプリケーション環境を構成します。構成では、レプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスを使用します。
例は、単方向レプリケーションまたは双方向レプリケーション用に環境を構成する方法を示しています。単方向レプリケーションでは、1つのデータベースのみがデータベース・オブジェクトを変更できます。双方向レプリケーションでは、両方のデータベースがデータベース・オブジェクトを変更できます。
この構成は、2つのデータベースのみを含む比較的単純なレプリケーション環境を構成する際に有効です。2つ目のデータベースをレポートまたはデータ分析に使用するには、単方向レプリケーション環境を構成します。両方のデータベースでデータの読取り/書込みが必要な場合は、双方向レプリケーション環境を構成します。たとえば、双方向レプリケーションは、スケーラビリティやデータの可用性を向上させることができます。
2データベース・レプリケーション環境の詳細は、「2データベース・レプリケーション環境の概要」を参照してください。
チュートリアル: ダウンストリーム取得プロセスを使用した2データベース・レプリケーションの構成
この例では、2つのデータベースでhrスキーマにあるすべての表にDML変更をレプリケートするOracle Streamsレプリケーション環境を構成します。例は、単方向レプリケーションの構成方法を示していて、レプリケートされたデータベース・オブジェクトに対する変更は、1つのソース・データベースでのみ許可されます。構成では、ソース・データベースでデータベース・オブジェクトに対して行った変更を取得するために、宛先データベースでダウンストリーム取得プロセスを使用しています。宛先データベースでは、データベース・オブジェクトは読取り専用です。
この構成は、プライマリ・データベースから別のデータベースにレポートまたはデータ分析をオフロードする際に使用します。この例では、2つ目のデータベースで取得プロセスを実行し、プライマリ・データベースの負荷を削減しています。
2データベース・レプリケーション環境の詳細は、「2データベース・レプリケーション環境の概要」を参照してください。
チュートリアル: ローカル取得プロセスでのハブアンドスポーク・レプリケーションの構成
この例では、3つのデータベースでhrスキーマにあるすべての表にDML変更をレプリケートするOracle Streamsレプリケーション環境を構成します。この例では、1つのハブと2つのスポークを持つハブアンドスポーク・レプリケーション環境を構成します。ハブアンドスポーク・レプリケーション環境は、1つの中央データベース(ハブ)がセカンダリ・データベース(スポーク)と通信する環境です。この例では、スポーク・データベースによって、レプリケートされたデータベース・オブジェクトに対する変更が可能になります。構成では、レプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスを使用します。
この構成は、複数のセカンダリ・データベースにデータをレプリケートする必要のある中央データベースが存在する場合に使用します。たとえば、本社に中央データベースがあり、販売代理店に複数のセカンダリ・データベースがある企業にこの構成が有効です。
ハブアンドスポーク・レプリケーション環境の詳細は、「ハブアンドスポーク・レプリケーション環境の概要」を参照してください。
チュートリアル: 同期取得を使用した2データベース・レプリケーションの構成
この例では、2つのデータベースでhrスキーマにあるemployees表およびdepartments表にDML変更をレプリケートするOracle Streamsレプリケーション環境を構成します。この例では、2つのデータベース間での双方向レプリケーションを構成しています。このため、データベース・オブジェクトに対する変更は両方のデータベースで許可されています。構成では、レプリケートされたデータベース・オブジェクトに対する変更を取得する同期取得を使用します。
この構成は、2つのデータベースと少数の表のみを使用する比較的単純なレプリケーション環境を構成する際に使用します。Oracle Database 11g Standard Editionをインストールしている場合は、同期取得を使用することもできます。取得プロセスを使用するには、Oracle Database 11g Enterprise Editionが必要です。
2データベース・レプリケーション環境の詳細は、「2データベース・レプリケーション環境の概要」を参照してください。
この項では、表の競合解消を構成する例も示します。詳細は、「チュートリアル: 表の最新時刻競合解消の構成」を参照してください。競合解消は、レプリケートされた表に対するDML変更の実行を複数のデータベースに対して許可するレプリケーション環境で使用します。この例は、最新時刻の競合解消を構成しています。このため、表に対する行変更によって競合が発生すると、最新の変更は保持され、古い変更は破棄されます。競合解消の詳細は、「競合と競合解消の概要」を参照してください。
この例では、hrスキーマにあるすべての表に、データ操作言語(DML)変更をレプリケートするOracle Streamsレプリケーション環境を構成します。この例では、変更を取得するローカル取得プロセスを使用して2データベース・レプリケーション環境を構成します。この例では、グローバル・データベース名db1.example.comおよびdb2.example.comを使用します。ただし、例を完了するために、ご使用の環境のデータベースに置き換えることもできます。2データベース・レプリケーション環境の詳細は、「2データベース・レプリケーション環境の概要」を参照してください。
この例では、Oracle Enterprise Managerの「Streamsレプリケーションの設定」ウィザードを使用して2データベース・レプリケーション環境を構成します。このウィザードは、1つ以上のスキーマをレプリケートするOracle Streams環境を構成する最速で最も単純な方法です。また、ウィザードはOracle Streamsレプリケーション環境に対して確立されたベスト・プラクティスに従います。
レプリケーション用に構成されているデータベース・オブジェクトは、ウィザードの実行時に、宛先データベースに存在する場合としない場合があります。宛先データベースにデータベース・オブジェクトが存在しない場合、ウィザードはデータ・ポンプ・エクスポート/インポートを使用して、宛先データベースでデータベース・オブジェクトをインスタンス化します。インスタンス化の際に、これらのデータベース・オブジェクトにインスタンス化SCNが設定されます。宛先データベースにデータベース・オブジェクトが存在する場合、ウィザードは既存のデータベース・オブジェクトを保持して、インスタンス化SCNを設定します。この例では、ウィザードを実行する前に、db1.example.comデータベースとdb2.example.comデータベースの両方にhrスキーマが存在しています。
この例では、単方向レプリケーションまたは双方向レプリケーションの構成方法を示しています。双方向レプリケーションを構成するには、追加の手順を実行して、ウィザードの適切なページで「双方向レプリケーションの設定」を選択する必要があります。
図4-11に、この例で作成する環境の概要を示します。双方向レプリケーションに必要な追加のコンポーネントはグレーで表示され、そのアクションは破線で示されています。
2データベース・レプリケーション環境を構成するには:
2データベース・レプリケーション環境を準備するには、次のタスクを完了します。
db1.example.comデータベースがdb2.example.comデータベースと通信できるように、ネットワーク接続を構成します。
データベース間のネットワーク接続の構成の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
レプリケーション環境に参加する各データベースでOracle Streams管理者を構成します。方法については、「チュートリアル: Oracle Streams管理者の構成」を参照してください。この例では、Oracle Streams管理者がstrmadminであると想定します。
Oracle Streamsレプリケーション環境に参加する各データベースで初期化パラメータを正しく設定します。方法については、「Oracle Streamsレプリケーションの準備」を参照してください。
ARCHIVELOGモードで実行するようにdb1.example.comデータベースを構成します。取得プロセスがソース・データベースで生成された変更を取得するには、ソース・データベースをARCHIVELOGモードで実行する必要があります。ARCHIVELOGモードで実行するためのデータベースの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。
双方向レプリケーション環境を構成する場合は、ARCHIVELOGモードで実行するようにdb2.example.comデータベースを構成します。単方向レプリケーション環境を構成する場合、この手順は不要なため、手順2に進みます。
Enterprise Managerで、Oracle Streams管理者としてソース・データベースにログインします。
この例では、ソース・データベースはdb1.example.comです。
データベース・インスタンスの「データベース」ホームページに移動します。
「データ移動」をクリックして「データ移動」サブページを開きます。
「Streams」セクションの「設定」をクリックします。
「Streams」ページが表示され、「設定」オプションが表示されます。
「Streamsレプリケーションの設定」で、「スキーマのレプリケート」を選択します。
「ホスト資格証明」セクションで、ホスト・コンピュータ・システムの管理ユーザーのユーザー名とパスワードを入力します。
「続行」をクリックします。
「オブジェクト選択」ページで、「HR」を選択して、「次へ」をクリックします。
「宛先オプション」ページで、ホスト名、ポート、SIDまたはサービス名およびOracle Streams管理者資格証明を指定して、宛先データベースを指定します。
「次へ」をクリックします。
「レプリケーション・オプション」ページが表示されます。
「レプリケーション・オプション」ページを完了します。
「ディレクトリ・パス」セクションで、手順7で指定したホスト・ユーザーがディレクトリに対して読取りおよび書込みを行うことができ、データ・ポンプ・エクスポート・ダンプ・ファイルに対する十分な領域がある場合、ソース・データベースと宛先データベースのディレクトリ・パスをそのままにしておきます。変更する場合は、別のディレクトリ・パスを指定するか、またはこれらの要件を満たすディレクトリ・オブジェクトを作成して指定します。
「拡張オプション」を拡張します。
「オプション」セクションで「データ操作言語(DML)の変更を取得、伝播および適用」が選択されていることを確認します。
DDL変更をレプリケートしない場合は、「データ定義言語(DDL)の変更を取得、伝播および適用」を選択解除します。
双方向レプリケーションを構成するには、「双方向レプリケーションの設定」を選択します。
「次へ」をクリックします。
「ジョブのスケジュール」ページで、「即時」を選択するか、後でジョブを実行する時刻を指定します。
「次へ」をクリックします。
「確認」ページで、構成情報を確認して、「発行」をクリックします。
確認ページで、オプションとして、ジョブ・リンクをクリックしてジョブを監視します。
ジョブを実行すると、進捗情報がDBA_RECOVERABLE_SCRIPT、DBA_RECOVERABLE_SCRIPT_PARAMS、DBA_RECOVERABLE_SCRIPT_BLOCKSおよびDBA_RECOVERABLE_SCRIPT_ERRORSデータ・ディクショナリ・ビューに記録されます。ジョブがエラーによって停止した場合は、DBMS_STREAMS_ADMパッケージ内のRECOVER_OPERATIONプロシージャの使用方法について、『Oracle Streamsレプリケーション管理者ガイド』を参照してエラーからリカバリしてください。
ジョブが正常に完了すると、次の特性を持つ2データベース・レプリケーション環境が構成されます。
db1.example.comでは、サプリメンタル・ロギングがhrスキーマの表に対して構成されています。
db1.example.comデータベースには次のコンポーネントがあります。
システムで生成された名前を持つ取得プロセス。取得プロセスはhrスキーマへのDML変更を取得します。
システムで生成された名前を持つキュー。このキューは、データベースの取得プロセスに対するものです。
システムで生成された名前を持つ、変更をdb1.example.comデータベースにあるキューからdb2.example.comデータベースにあるキューに送信する伝播。
db2.example.comデータベースには次のコンポーネントがあります。
システムで生成された名前を持つ、db1.example.comデータベースから送信された変更を受信するキュー。このキューは、ローカル・データベースの適用プロセスに対するものです。
システムで生成された名前を持つ適用プロセス。適用プロセスはキューから変更をデキューし、それをhrスキーマに適用します。
双方向レプリケーション環境の場合は、次のものも構成されます。
db2.example.comでは、hrスキーマの表に対するサプリメンタル・ロギング。
db2.example.comでは、システムで生成された名前を持つ取得プロセス。取得プロセスはhrスキーマへのDML変更を取得します。
db2.example.comでは、システムで生成された名前を持つキュー。このキューは、データベースの取得プロセスに対するものです。
db1.example.comでは、システムで生成された名前を持つ、db2.example.comデータベースから送信された変更を受信するキュー。このキューは、ローカル・データベースの適用プロセスに対するものです。
db1.example.comでは、システムで生成された名前を持つ適用プロセス。適用プロセスはキューから変更をデキューし、それをhrスキーマに適用します。
双方向レプリケーション環境の場合は、変更の循環を回避するため、次のようにタグが使用されています。
各適用プロセスは適用タグを使用し、適用プロセスによって適用される変更のREDOレコードにはタグが含まれます。各適用プロセスは、レプリケーション環境で一意な適用タグを使用します。
各取得プロセスは、REDOレコード内のタグに関係なく、レプリケートされたデータベース・オブジェクトの変更すべてを取得します。したがって、各取得プロセスは、そのソース・データベースで適用プロセスによって適用された変更を取得します。
各伝播は、レプリケートされたデータベース・オブジェクトに対する変更すべてを、レプリケーション環境のもう一方のデータベースに送信しますが、他のデータベースで発生した変更は除きます。伝播ルールでは、伝播がこれらの変更を破棄するよう指示します。
レプリケーション環境で変更の循環を回避する方法の詳細は、「変更の循環を回避するためのタグの概要」を参照してください。単方向レプリケーションを構成した場合は、変更は単一のロケーションでのみ取得されるため、変更の循環は発生しません。
Oracle Streamsレプリケーション構成を確認するには:
db1.example.comデータベースで、取得プロセスが有効化され、取得タイプがローカルであることを確認します。確認には、「取得プロセスの情報の表示」の手順に従って、「取得」サブページで「ステータス」および「取得タイプ」フィールドを確認します。
db1.example.comデータベースで、伝播が有効化されていることを確認します。確認には、「伝播の情報の表示」の手順に従って、「伝播」サブページで「ステータス」フィールドを確認します。
db2.example.comデータベースで、適用プロセスが有効化されていることを確認します。確認には、「適用プロセスの情報の表示」の手順に従って、「適用」サブページで「ステータス」フィールドを確認します。
双方向レプリケーションを構成した場合は、次の追加の手順を実行します。
db2.example.comデータベースで、取得プロセスが有効化され、取得タイプがローカルであることを確認します。
db2.example.comデータベースで、伝播が有効化されていることを確認します。
db1.example.comデータベースで、適用プロセスが有効化されていることを確認します。
変更をレプリケートするには:
hrスキーマに対する変更を取得するデータベースで、hrスキーマの任意の表に対してDML変更を行います。この例では、db1.example.comデータベースがhrスキーマに対する変更を取得し、双方向レプリケーションに構成した場合、db2.example.comもhrスキーマに対する変更を取得します。
変更のレプリケーションが完了するまで待ってから、SQL*Plusを使用して他のデータベースで変更された表を問い合せてDML変更を表示します。
|
注意: ウィザードは、宛先データベースで読取り専用になるレプリケート表を構成しません。単方向レプリケーションでこれらの表を読取り専用にする必要がある場合、宛先データベースで権限を構成します。ただし、適用プロセスの適用ユーザーは、レプリケートされたデータベース・オブジェクトに対するDML変更が可能である必要があります。この例では、適用ユーザーはOracle Streams管理者です。権限の構成の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
|
関連項目:
|
この例では、hrスキーマにあるすべての表に、データ操作言語(DML)変更をレプリケートするOracle Streamsレプリケーション環境を構成します。この例では、宛先データベースでダウンストリーム取得プロセスを使用して2データベース・レプリケーション環境を構成します。この例では、グローバル・データベース名src.example.comおよびdest.example.comを使用します。ただし、例を完了するために、ご使用の環境のデータベースに置き換えることもできます。2データベース・レプリケーション環境の詳細は、「2データベース・レプリケーション環境の概要」を参照してください。
この例では、ダウンストリーム取得プロセスは宛先データベースdest.example.comで実行されます。したがって、変更の取得に必要なリソースはソース・データベースsrc.example.comで解放されます。この例では、アーカイブ・ログ・ダウンストリーム取得プロセスではなく、リアルタイム・ダウンストリーム取得プロセスを構成します。リアルタイム・ダウンストリーム取得は、ソース・データベースでの変更の取得に必要な時間を短縮できるという利点があります。時間を短縮できるのは、データを取得する前にREDOログ・ファイルがアーカイブされるまで待つ必要がないためです。
この例では、レプリケートされたデータベース・オブジェクトが宛先データベースでレポートおよび分析に使用されると想定しています。このため、これらのデータベース・オブジェクトは、dest.example.comデータベースでは読取り専用であると想定しています。
この例では、Oracle Enterprise Managerの「Streamsレプリケーションの設定」ウィザードを使用して2データベース・レプリケーション環境を構成します。このウィザードは、1つ以上のスキーマをレプリケートするOracle Streams環境を構成する最速で最も単純な方法です。また、ウィザードはOracle Streamsレプリケーション環境に対して確立されたベスト・プラクティスに従います。
レプリケーション用に構成されているデータベース・オブジェクトは、ウィザードの実行時に、宛先データベースに存在する場合としない場合があります。宛先データベースにデータベース・オブジェクトが存在しない場合、ウィザードはデータ・ポンプ・エクスポート/インポートを使用して、宛先データベースでデータベース・オブジェクトをインスタンス化します。インスタンス化の際に、これらのデータベース・オブジェクトにインスタンス化SCNが設定されます。宛先データベースにデータベース・オブジェクトが存在する場合、ウィザードは既存のデータベース・オブジェクトを保持して、インスタンス化SCNを設定します。この例では、ウィザードを実行する前に、src.example.comデータベースとdest.example.comデータベースの両方にhrスキーマが存在しています。
図4-12に、この例で作成する環境の概要を示します。
|
注意: ローカル取得プロセスでは、ダウンストリーム取得プロセスに比べ、プラットフォームまたはOracle Databaseのバージョンが異なるレプリケーション環境においてより高い柔軟性が提供されます。詳細は、『Oracle Streams概要および管理』を参照してください。 |
2データベース・レプリケーション環境を構成するには:
2データベース・レプリケーション環境を準備するには、次のタスクを完了します。
src.example.comデータベースとdest.example.comデータベースが相互に通信できるように、ネットワーク接続を構成します。
データベース間のネットワーク接続の構成の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
レプリケーション環境に参加する各データベースでOracle Streams管理者を構成します。方法については、「チュートリアル: Oracle Streams管理者の構成」を参照してください。この例では、Oracle Streams管理者がstrmadminであると想定します。
Oracle Streamsレプリケーション環境に参加する各データベースで初期化パラメータを正しく設定します。方法については、「Oracle Streamsレプリケーションの準備」を参照してください。
ARCHIVELOGモードで実行するように両方のデータベースを構成します。ダウンストリーム取得プロセスがソース・データベースで生成された変更を取得するには、ソース・データベースとダウンストリーム取得データベースをARCHIVELOGモードで実行する必要があります。この例では、src.example.comおよびdest.example.comデータベースをARCHIVELOGモードで実行する必要があります。ARCHIVELOGモードで実行するためのデータベースの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。
REDOデータの転送をサポートするために、両方のデータベースで認証を構成します。
REDO転送セッションは、Secure Sockets Layer(SSL)プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。ソース・データベースにリモート・ログイン・パスワード・ファイルがある場合は、それをダウンストリーム取得データベース・システムの適切なディレクトリにコピーします。パスワード・ファイルは、ソース・データベースおよびダウンストリーム取得データベースで同じである必要があります。
この例で、ソース・データベースはsrc.example.comで、ダウンストリーム取得データベースはdest.example.comです。REDO転送の認証要件の詳細は、『Oracle Data Guard概要および管理』を参照してください。
ソース・データベースとダウンストリーム・データベースの両方で初期化パラメータを構成して、ダウンストリーム取得をサポートします。
ソース・データベースsrc.example.comのオンラインREDOログからダウンストリーム・データベースdest.example.comのスタンバイREDOログにREDOデータが転送されるように、REDO転送サービスに対して両方のデータベースで、初期化パラメータを適切に設定する必要があります。
ダウンストリーム取得をサポートするように初期化パラメータを構成するには:
Enterprise Managerで、Oracle Streams管理者としてソース・データベースにログインします。
この例では、ソース・データベースはsrc.example.comです。
データベース・インスタンスの「データベース」ホームページに移動します。
「データ移動」をクリックして「データ移動」サブページを開きます。
「Streams」セクションの「設定」をクリックします。
「Streams」ページが表示され、「設定」オプションが表示されます。
「ダウンストリーム取得の設定」を選択します。
「ホスト資格証明」セクションで、ホスト・コンピュータ・システムの管理ユーザーのユーザー名とパスワードを入力します。
「続行」をクリックします。
「ダウンストリーム取得の設定」ページが表示されます。
「ダウンストリーム・データベースの詳細」セクションで、ダウンストリーム取得データベースのホスト名、ポートおよびSIDまたはサービス名を指定し、ダウンストリーム・データベースのOracle Streams管理者の資格証明を入力します。
この例では、ダウンストリーム取得データベースはdest.example.comです。
「取得プロセスの詳細」セクションで、「取得プロセス名」フィールドにcaptureと入力し、「リアルタイムのダウンストリーム取得」が選択されていることを確認します。
「ログの詳細」セクションで、「スタンバイREDOログ・ファイルの場所」フィールドに、ダウンストリーム・データベースを実行しているコンピュータ・システム上のアーカイブREDOログ・ファイルの場所を入力します。
ディスク・ディレクトリへの有効なパス名を指定するか、または高速リカバリ領域を使用する場合はUSE_DB_RECOVERY_FILE_DESTを指定します。これは、スタンバイREDOログから書き込まれたアーカイブREDOログ・ファイルのローカルの宛先です。リモート・ソース・データベースからのログ・ファイルは、ローカル・データベースのログ・ファイルとは別に保持する必要があります。高速リカバリ領域の構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
「ログの詳細」セクションで、「ダウンストリーム取得に対するログ・パラメータの構成」が選択されていること、および「ログ・パラメータ」のLOG_ARCHIVE_DEST_nパラメータがソース・データベースで使用されていないことを確認します。
「OK」をクリックします。
「ジョブのスケジュール」ページで、「即時」を選択するか、後でジョブを実行する時刻を指定します。
「OK」をクリックします。
確認ページで、オプションとして、ジョブ・リンクをクリックしてジョブを監視します。
ジョブが正常に完了すると、ダウンストリーム取得が構成されます。ジョブが正常に完了するまで先に進まないでください。
Oracle Streams管理者としてEnterprise Managerのソース・データベースにログインしている状態で、データベース・インスタンスの「データベース」ホームページに移動します。
「データ移動」をクリックして「データ移動」サブページを開きます。
「Streams」セクションの「設定」をクリックします。
「Streams」ページが表示され、「設定」オプションが表示されます。
「Streamsレプリケーションの設定」で、「スキーマのレプリケート」を選択します。
「ホスト資格証明」セクションで、ホスト・コンピュータ・システムの管理ユーザーのユーザー名とパスワードを入力します。
「続行」をクリックします。
「オブジェクト選択」ページで、「HR」を選択して、「次へ」をクリックします。
HRユーザーを表示するには、「次へ」リンクのクリックが必要な場合があります。
「宛先オプション」ページで、ホスト名、ポート、SIDまたはサービス名およびOracle Streams管理者資格証明を指定して、宛先データベースを指定します。
この例では、宛先データベースはdest.example.comです。
「次へ」をクリックします。
「レプリケーション・オプション」ページが表示されます。
「レプリケーション・オプション」ページを完了します。
「ディレクトリ・パス」セクションで、手順7で指定したホスト・ユーザーがディレクトリに対して読取りおよび書込みを行うことができ、データ・ポンプ・エクスポート・ダンプ・ファイルに対する十分な領域がある場合、ソース・データベースと宛先データベースのディレクトリ・パスをそのままにしておきます。変更する場合は、別のディレクトリ・パスを指定するか、またはこれらの要件を満たすディレクトリ・オブジェクトを作成して指定します。
「拡張オプション」を拡張します。
「オプション」セクションで「データ操作言語(DML)の変更を取得、伝播および適用」が選択されていることを確認します。
「オプション」セクションで「データ定義言語(DDL)の変更を取得、伝播および適用」を選択解除し、「双方向レプリケーションの設定」が選択されていないことを確認します。
「取得プロセス」セクションで、「ダウンストリーム取得」を選択します。
「取得プロセス」セクションで、ダウンストリーム取得データベースのホスト名、ポートおよびSIDまたはサービス名を入力し、ダウンストリーム・データベースのOracle Streams管理者の資格証明を入力します。
「取得名」フィールドにcaptureと入力します。このダウンストリーム取得プロセスは、手順2で構成しました。
「適用名」フィールドにapplyと入力します。
「次へ」をクリックします。
「ジョブのスケジュール」ページで、「即時」を選択するか、後でジョブを実行する時刻を指定します。
「次へ」をクリックします。
「確認」ページで、構成情報を確認して、「発行」をクリックします。
確認ページで、ジョブ・リンクをクリックしてジョブを監視します。ジョブが正常に完了するまで次の手順に進まないでください。
ジョブを実行すると、進捗情報がDBA_RECOVERABLE_SCRIPT、DBA_RECOVERABLE_SCRIPT_PARAMS、DBA_RECOVERABLE_SCRIPT_BLOCKSおよびDBA_RECOVERABLE_SCRIPT_ERRORSデータ・ディクショナリ・ビューに記録されます。ジョブがエラーによって停止した場合は、DBMS_STREAMS_ADMパッケージ内のRECOVER_OPERATIONプロシージャの使用方法について、『Oracle Streamsレプリケーション管理者ガイド』を参照してエラーからリカバリしてください。
SQL*Plusで、管理ユーザーとしてソース・データベースsrc.example.comに接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
ソース・データベースで現行のログ・ファイルを次のようにアーカイブします。
ALTER SYSTEM ARCHIVE LOG CURRENT;
ソース・データベースで現行のログ・ファイルをアーカイブすると、ソース・データベースのREDOログのリアルタイム・マイニングが開始されます。
例を完了すると、次の特性を持つ2データベース・レプリケーション環境が構成されます。
src.example.comデータベースでは、サプリメンタル・ロギングがhrスキーマの表に対して構成されています。
dest.example.comデータベースには次のコンポーネントがあります。
captureという名前のダウンストリーム取得プロセス。この取得プロセスは、ソース・データベースsrc.example.comから送信されるREDOログ情報で、hrスキーマに対する変更を取得します。
システムで生成された名前を持つキュー。このキューは、データベースの取得プロセスおよび適用プロセスに対するものです。
applyという名前の適用プロセス。この適用プロセスは、変更をhrスキーマに適用します。
Oracle Streamsレプリケーション構成を確認するには:
dest.example.comデータベースで、取得プロセスが有効化され、取得タイプがダウンストリームであることを確認します。確認には、「取得プロセスの情報の表示」の手順に従って、「取得」サブページで「ステータス」および「取得タイプ」フィールドを確認します。
取得プロセスが、異常なほど長い時間、REDOデータを待機していると思われる場合は、アラート・ログでエラーを確認します。詳細は、『Oracle Streams概要および管理』を参照してください。
dest.example.comデータベースで、適用プロセスが有効化されていることを確認します。確認には、「適用プロセスの情報の表示」の手順に従って、「適用」サブページで「ステータス」フィールドを確認します。
変更をレプリケートするには:
src.example.comデータベースで、hrスキーマの任意の表に対してDML変更を行った後、変更をコミットします。
変更のレプリケーションが完了するまで待ってから、SQL*Plusを使用してdest.example.comデータベースで変更された表を問い合せてDML変更を表示します。
|
注意: ウィザードは、宛先データベースで読取り専用になるレプリケート表を構成しません。これらの表を読取り専用にする必要がある場合、宛先データベースで権限を構成します。ただし、適用プロセスの適用ユーザーは、レプリケートされたデータベース・オブジェクトに対するDML変更が可能である必要があります。この例では、適用ユーザーはOracle Streams管理者です。権限の構成の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
|
関連項目:
|
この例では、hrスキーマにあるすべての表に、データ操作言語(DML)変更をレプリケートするOracle Streamsハブアンドスポーク・レプリケーション環境を構成します。この例では、各データベースで取得プロセスを使用してこれらの変更を取得します。ハブアンドスポーク・レプリケーションとは、中央のハブ・データベースが1つ以上のスポーク・データベースでの変更をレプリケートすることを意味します。スポーク・データベースは、相互に直接通信しません。このサンプル構成では、ハブ・データベースが、1つのスポーク・データベースで生成された変更を他のスポーク・データベースに送信します。ハブアンドスポーク・レプリケーション環境の詳細は、「ハブアンドスポーク・レプリケーション環境の概要」を参照してください。
この例では、Oracle Enterprise Managerの「Streamsレプリケーションの設定」ウィザードを使用して、ハブアンドスポーク・レプリケーション環境を構成します。このウィザードは、1つ以上のスキーマをレプリケートするOracle Streams環境を構成する最速で最も単純な方法です。また、ウィザードはOracle Streamsレプリケーション環境に対して確立されたベスト・プラクティスに従います。
この例では、ハブ・データベースのグローバル名はhub.example.com、スポーク・データベースのグローバル名はspoke1.example.comおよびspoke2.example.comです。ただし、例を完了するために、ご使用の環境のデータベースに置き換えることもできます。
レプリケーション用に構成されているデータベース・オブジェクトは、ウィザードの実行時に、宛先データベースに存在する場合としない場合があります。宛先データベースにデータベース・オブジェクトが存在しない場合、ウィザードはデータ・ポンプ・エクスポート/インポートを使用して、宛先データベースでデータベース・オブジェクトをインスタンス化します。インスタンス化の際に、これらのデータベース・オブジェクトにインスタンス化SCNが設定されます。宛先データベースにデータベース・オブジェクトが存在する場合、ウィザードは既存のデータベース・オブジェクトを保持して、インスタンス化SCNを設定します。この例では、ウィザードを実行する前に、各データベースにhrスキーマが存在しています。
図4-13に、この例で作成する環境の概要を示します。
読取り/書込みスポークのあるこのハブアンドスポーク・レプリケーション環境を構成するには:
ハブアンドスポーク・レプリケーション環境を準備するには、次のタスクを完了します。
次のデータベースが相互に通信できるように、ネットワーク接続を構成します。
hub.example.comデータベースとspoke1.example.comデータベース
hub.example.comデータベースとspoke2.example.comデータベース
データベース間のネットワーク接続の構成の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
レプリケーション環境に参加する各データベースでOracle Streams管理者を構成します。方法については、「チュートリアル: Oracle Streams管理者の構成」を参照してください。この例では、Oracle Streams管理者がstrmadminであると想定します。
Oracle Streamsレプリケーション環境に参加する各データベースで初期化パラメータを正しく設定します。方法については、「Oracle Streamsレプリケーションの準備」を参照してください。
ARCHIVELOGモードで実行するように各ソース・データベースを構成します。取得プロセスがソース・データベースで生成された変更を取得するには、ソース・データベースをARCHIVELOGモードで実行する必要があります。この例では、すべてのデータベースをARCHIVELOGモードで実行する必要があります。ARCHIVELOGモードで実行するためのデータベースの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。
Enterprise Managerで、Oracle Streams管理者としてハブ・データベースhub.example.comにログインします。
データベース・インスタンスの「データベース」ホームページに移動します。
「データ移動」をクリックして「データ移動」サブページを開きます。
「Streams」セクションの「設定」をクリックします。
「Streams」ページが表示され、「設定」オプションが表示されます。
「Streamsレプリケーションの設定」で、「スキーマのレプリケート」を選択します。
「ホスト資格証明」セクションで、ホスト・コンピュータ・システムの管理ユーザーのユーザー名とパスワードを入力します。
「続行」をクリックします。
「オブジェクト選択」ページで、「HR」を選択して、「次へ」をクリックします。
「宛先オプション」ページで、ホスト名、ポート、SIDまたはサービス名およびOracle Streams管理者資格証明を指定して、スポーク・データベースspoke1.example.comを指定します。
(レプリケーションをspoke2.example.comデータベースで構成する場合は、spoke2.example.comを指定します。)
「次へ」をクリックします。
「レプリケーション・オプション」ページが表示されます。
「レプリケーション・オプション」ページを完了します。
「ディレクトリ・パス」セクションで、手順7で指定したホスト・ユーザーがディレクトリに対して読取りおよび書込みを行うことができ、データ・ポンプ・エクスポート・ダンプ・ファイルに対する十分な領域がある場合、ソース・データベースと宛先データベースのディレクトリ・パスをそのままにしておきます。変更する場合は、別のディレクトリ・パスを指定するか、またはこれらの要件を満たすディレクトリ・オブジェクトを作成して指定します。
「拡張オプション」を拡張します。
「オプション」セクションで「データ操作言語(DML)の変更を取得、伝播および適用」が選択されていることを確認します。
DDL変更をレプリケートしない場合は、「データ定義言語(DDL)の変更を取得、伝播および適用」を選択解除します。
「双方向レプリケーションの設定」を選択します。
「取得プロセス」セクションで、「取得名」にcapture_hnsと入力します。
「伝播プロセス」セクションで、「伝播名」にpropagation_spoke1と入力します。(レプリケーションをspoke2.example.comデータベースで構成する場合は、propagation_spoke2と入力します。)
「適用プロセス」セクションで、「適用名」にapply_spoke1と入力します。(レプリケーションをspoke2.example.comデータベースで構成する場合は、apply_spoke2と入力します。)
「次へ」をクリックします。
「ジョブのスケジュール」ページで、「即時」を選択するか、後でジョブを実行する時刻を指定します。
「次へ」をクリックします。
「確認」ページで、構成情報を確認して、「発行」をクリックします。
確認ページで、オプションとして、ジョブ・リンクをクリックしてジョブを監視します。
ジョブを実行すると、進捗情報がDBA_RECOVERABLE_SCRIPT、DBA_RECOVERABLE_SCRIPT_PARAMS、DBA_RECOVERABLE_SCRIPT_BLOCKSおよびDBA_RECOVERABLE_SCRIPT_ERRORSデータ・ディクショナリ・ビューに記録されます。ジョブがエラーによって停止した場合は、DBMS_STREAMS_ADMパッケージ内のRECOVER_OPERATIONプロシージャの使用方法について、『Oracle Streamsレプリケーション管理者ガイド』を参照してエラーからリカバリしてください。
Oracle Streams管理者としてhub.example.comデータベースに接続している状態で、手順3から17をもう一度完了します。ただし、手順10では、「宛先オプション」ページで、ホスト名、ポート、SIDまたはサービス名およびOracle Streams管理者資格証明を指定して、スポーク・データベースspoke2.example.comを指定します。
また、手順12gでは「伝播名」にpropagation_spoke2を入力し、手順12hでは「適用名」にapply_spoke2を入力します。
例を完了すると、次の特性を持つハブアンドスポーク・レプリケーション環境が構成されます。
各データベースで、サプリメンタル・ロギングがhrスキーマの表に対して構成されています。
各データベースには、capture_hnsという名前の取得プロセスがあります。取得プロセスは、データベースのhrスキーマに対する変更を取得します。
各データベースには、システムで生成された名前を持つキューがあります。各キューは、データベースの取得プロセスに対するものです。
ハブ・データベースhub.example.comには、次の追加コンポーネントがあります。
apply_spoke1という名前の適用プロセス。この適用プロセスは、spoke1.example.comデータベースから送信されたhrスキーマに対する変更を適用します。
システムで生成された名前を持つキュー。このキューは、データベースのapply_spoke1適用プロセスに対するものです。
apply_spoke2という名前の適用プロセス。この適用プロセスは、spoke2.example.comデータベースから送信されたhrスキーマに対する変更を適用します。
システムで生成された名前を持つキュー。このキューは、データベースのapply_spoke2適用プロセスに対するものです。
propagation_spoke1という名前の伝播。この伝播は、hrスキーマに対する変更をローカル・キューからspoke1.example.comデータベースのキューに送信します。
propagation_spoke2という名前の伝播。この伝播は、hrスキーマに対する変更をローカル・キューからspoke2.example.comデータベースのキューに送信します。
スポーク・データベースspoke1.example.comには、次の追加コンポーネントがあります。
apply_spoke1という名前の適用プロセス。この適用プロセスは、hub.example.comデータベースから送信されたhrスキーマに対する変更を適用します。
システムで生成された名前を持つキュー。このキューは、データベースのapply_spoke1適用プロセスに対するものです。
propagation_spoke1という名前の伝播。この伝播は、hrスキーマに対する変更をローカル・キューからhub.example.comデータベースのキューに送信します。
スポーク・データベースspoke2.example.comには、次の追加コンポーネントがあります。
apply_spoke2という名前の適用プロセス。この適用プロセスは、hub.example.comデータベースから送信されたhrスキーマに対する変更を適用します。
システムで生成された名前を持つキュー。このキューは、データベースのapply_spoke2適用プロセスに対するものです。
propagation_spoke2という名前の伝播。この伝播は、hrスキーマに対する変更をローカル・キューからhub.example.comデータベースのキューに送信します。
変更の循環を回避するため、次のようにタグが使用されています。
各適用プロセスは適用タグを使用し、適用プロセスによって適用される変更のREDOレコードにはタグが含まれます。各適用プロセスは、レプリケーション環境で一意な適用タグを使用します。
各取得プロセスは、REDOレコード内のタグに関係なく、レプリケートされたデータベース・オブジェクトの変更すべてを取得します。したがって、各取得プロセスは、そのソース・データベースで適用プロセスによって適用された変更を取得します。
各伝播は、レプリケートされたデータベース・オブジェクトに対する変更すべてを、レプリケーション環境の他のデータベースに送信しますが、他のデータベースで発生した変更は除きます。伝播ルールでは、伝播がこれらの変更を破棄するよう指示します。
レプリケーション環境で変更の循環を回避する方法の詳細は、「変更の循環を回避するためのタグの概要」および『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
Oracle Streamsレプリケーション構成を確認するには:
各データベースで、取得プロセスが有効化され、取得タイプがローカルであることを確認します。確認には、「取得プロセスの情報の表示」の手順に従って、「取得」サブページで「ステータス」および「取得タイプ」フィールドを確認します。
各データベースで、伝播が有効化されていることを確認します。確認には、「伝播の情報の表示」の手順に従って、「伝播」サブページで「ステータス」フィールドを確認します。ハブ・データベースには2つの伝播が必要で、両方の伝播が有効化されている必要があります。各スポーク・データベースには、有効化されている1つの伝播が必要です。
各データベースで、適用プロセスが有効化されていることを確認します。確認には、「適用プロセスの情報の表示」の手順に従って、「適用」サブページで「ステータス」フィールドを確認します。ハブ・データベースには2つの適用プロセスが必要で、両方の適用プロセスが有効化されている必要があります。各スポーク・データベースには、有効化されている1つの適用プロセスが必要です。
変更をレプリケートするには:
データベースの1つで、DML変更をhrスキーマの任意の表に対して行います。
変更のレプリケーションが完了するまで待ってから、SQL*Plusを使用して他のデータベースで変更された表を問い合せてDML変更を表示します。
|
関連項目:
|
この項の例では、hrスキーマにある2つの表に、データ操作言語(DML)変更をレプリケートするOracle Streamsレプリケーション環境を構成します。この例では、各データベースで同期取得を使用して変更を取得します。この例では、Oracle Streamsレプリケーション環境で、データベースのグローバル名にsync1.example.comおよびsync2.example.comを使用します。ただし、例を完了するために、ご使用の環境の2つのデータベースに置き換えることもできます。2データベース・レプリケーション環境の詳細は、「2データベース・レプリケーション環境の概要」を参照してください。
具体的に、この例では、sync1.example.comおよびsync2.example.comデータベースでhr.employeesおよびhr.departments表を共有するOracle Streamsの2データベース・レプリケーション環境を構成します。2つのデータベースは、すべてのDML変更をこれらの表にレプリケートします。 hrサンプル・スキーマは、Oracle Databaseとともにデフォルトでインストールされます。
|
注意: 同期取得は、表レベルの変更のみ取得できます。スキーマ・レベルまたはデータベース・レベルの変更は取得できません。同期取得を構成するには、DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESおよびADD_SUBSET_RULESプロシージャを使用します。 |
図4-14に、この例で作成する環境の概要を示します。
このレプリケーション環境を同期取得で構成するには:
2データベース・レプリケーション環境を準備するには、次のタスクを完了します。
ネットワーク接続を構成して、2つのデータベースが相互に通信できるようにします。データベース間のネットワーク接続の構成の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
レプリケーション環境に参加する各データベースでOracle Streams管理者を構成します。方法については、「チュートリアル: Oracle Streams管理者の構成」を参照してください。この例では、Oracle Streams管理者がstrmadminであると想定します。
Oracle Streamsレプリケーション環境に参加する各データベースで初期化パラメータを正しく設定します。方法については、「Oracle Streamsレプリケーションの準備」を参照してください。
hr.employeesおよびhr.departments表が2つのデータベースに存在し、これらのデータベースで一貫していることを確認します。データベース・オブジェクトが1つのデータベースにのみ存在する場合は、エクスポート/インポートを使用してこれらを他のデータベースで作成および移入できます。エクスポート/インポートの詳細は、『Oracle Databaseユーティリティ』を参照してください。
各データベースに2つのANYDATAキューを作成します。この例では、各データベースに次の2つのキューを作成します。
Oracle Streams管理者strmadminが所有する、capture_queueという名前のキュー。このキューはデータベースでの同期取得によって使用されます。
Streams管理者strmadminが所有する、apply_queueという名前のキュー。このキューはデータベースでの適用プロセスによって使用されます。
方法については、「ANYDATAキューの作成」を参照してください。
各データベースから他のデータベースへのデータベース・リンクを作成します。
sync1.example.comデータベースからsync2.example.comデータベースに、データベース・リンクを作成します。データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。また、データベース・リンクはsync2.example.comデータベースでOracle Streams管理者に接続する必要があります。データベース・リンクの名前およびサービス名は、どちらもsync2.example.comである必要があります。
sync2.example.comデータベースからsync1.example.comデータベースに、データベース・リンクを作成します。データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。また、データベース・リンクはsync1.example.comデータベースでOracle Streams管理者に接続する必要があります。データベース・リンクの名前およびサービス名は、どちらもsync1.example.comである必要があります。
詳細は、「チュートリアル: データベース・リンクの作成」を参照してください。
sync1.example.comデータベースで適用プロセスを構成します。この適用プロセスは、sync2.example.comデータベースで取得され、sync1.example.comデータベースに伝播された共有表への変更を適用します。
SQL*Plusを開き、sync1.example.comデータベースにOracle Streams管理者として接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
適用プロセスを作成します。
BEGIN
DBMS_APPLY_ADM.CREATE_APPLY(
queue_name => 'strmadmin.apply_queue',
apply_name => 'apply_emp_dep',
apply_captured => FALSE);
END;
/
適用プロセスは永続キュー内の変更を適用するため、apply_capturedパラメータがFALSEに設定されます。これらは、同期取得によって取得された変更です。 apply_capturedパラメータは、適用プロセスが取得プロセスによって取得された変更を適用する場合にのみTRUEに設定する必要があります。
適用プロセスは起動しないでください。
適用プロセス・ルール・セットにルールを追加します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'hr.employees',
streams_type => 'apply',
streams_name => 'apply_emp_dep',
queue_name => 'strmadmin.apply_queue',
source_database => 'sync2.example.com');
END;
/
このルールは、apply_queueキューに出現するhr.employees表に対するすべてのDML変更を適用するよう適用プロセスapply_emp_depに指示します。ルールは、適用プロセスがsync2.example.comソース・データベースで取得された変更のみ適用することも指定します。
適用プロセス・ルール・セットにルールを追加します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'hr.departments',
streams_type => 'apply',
streams_name => 'apply_emp_dep',
queue_name => 'strmadmin.apply_queue',
source_database => 'sync2.example.com');
END;
/
このルールは、apply_queueキューに出現するhr.departments表に対するすべてのDML変更を適用するよう適用プロセスapply_emp_depに指示します。ルールは、適用プロセスがsync2.example.comソース・データベースで取得された変更のみ適用することも指定します。
sync2.example.comデータベースで適用プロセスを構成します。この適用プロセスは、sync1.example.comデータベースで取得され、sync2.example.comデータベースに伝播された変更を適用します。
SQL*Plusで、sync2.example.comデータベースにOracle Streams管理者として接続します。
SQL*Plusでのデータベースへの接続の詳細は、『Oracle Database管理者ガイド』を参照してください。
適用プロセスを作成します。
BEGIN
DBMS_APPLY_ADM.CREATE_APPLY(
queue_name => 'strmadmin.apply_queue',
apply_name => 'apply_emp_dep',
apply_captured => FALSE);
END;
/
適用プロセスは永続キュー内の変更を適用するため、apply_capturedパラメータがFALSEに設定されます。これらの変更は、同期取得によって取得されました。 apply_capturedパラメータは、適用プロセスが取得プロセスによって取得された変更を適用する場合にのみTRUEに設定する必要があります。
適用プロセスは起動しないでください。
適用プロセス・ルール・セットにルールを追加します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'hr.employees',
streams_type => 'apply',
streams_name => 'apply_emp_dep',
queue_name => 'strmadmin.apply_queue',
source_database => 'sync1.example.com');
END;
/
このルールは、apply_queueキューに出現するすべてのDML変更をhr.employees表に適用するよう適用プロセスapply_emp_depに指示します。ルールは、適用プロセスがsync1.example.comソース・データベースで取得された変更のみ適用することも指定します。
適用プロセス・ルール・セットにルールを追加します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'hr.departments',
streams_type => 'apply',
streams_name => 'apply_emp_dep',
queue_name => 'strmadmin.apply_queue',
source_database => 'sync1.example.com');
END;
/
このルールは、apply_queueキューに出現するすべてのDML変更をhr.departments表に適用するよう適用プロセスapply_emp_depに指示します。ルールは、適用プロセスがsync1.example.comソース・データベースで取得された変更のみ適用することも指定します。
sync1.example.comデータベースのキューからsync2.example.comデータベースのキューに変更を送信する伝播を作成します。
SQL*Plusで、sync1.example.comデータベースにOracle Streams管理者として接続します。
sync2.example.comデータベースに対する変更を送信する伝播の作成を作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES(
table_name => 'hr.employees',
streams_name => 'send_emp_dep',
source_queue_name => 'strmadmin.capture_queue',
destination_queue_name => 'strmadmin.apply_queue@sync2.example.com',
source_database => 'sync1.example.com',
queue_to_queue => TRUE);
END;
/
ADD_TABLE_PROPAGATION_RULESプロシージャは、伝播およびポジティブ・ルール・セットを作成します。このプロシージャは、sync2.example.comデータベース内のapply_queueキューのhr.employees表にDML変更を送信するよう指示する伝播ルール・セットにルールの追加もします。
伝播ルール・セットにルールを追加します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES(
table_name => 'hr.departments',
streams_name => 'send_emp_dep',
source_queue_name => 'strmadmin.capture_queue',
destination_queue_name => 'strmadmin.apply_queue@sync2.example.com',
source_database => 'sync1.example.com',
queue_to_queue => TRUE);
END;
/
ADD_TABLE_PROPAGATION_RULESプロシージャは、sync2.example.comデータベース内のapply_queueキューのhr.departments表にDML変更を送信するよう指示する伝播ルール・セットにルールを追加します。
sync2.example.comデータベースのキューからsync1.example.comデータベースのキューに変更を送信する伝播を作成します。
SQL*Plusで、sync2.example.comデータベースにOracle Streams管理者として接続します。
sync1.example.comデータベースに対する変更を送信する伝播の作成を作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES(
table_name => 'hr.employees',
streams_name => 'send_emp_dep',
source_queue_name => 'strmadmin.capture_queue',
destination_queue_name => 'strmadmin.apply_queue@sync1.example.com',
source_database => 'sync2.example.com',
queue_to_queue => TRUE);
END;
/
ADD_TABLE_PROPAGATION_RULESプロシージャは、伝播およびポジティブ・ルール・セットを作成します。このプロシージャでは、sync1.example.comデータベース内のapply_queueキューのhr.employees表にDML変更を送信するよう指示する伝播ルール・セットにルールを追加します。
伝播ルール・セットにルールを追加します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES(
table_name => 'hr.departments',
streams_name => 'send_emp_dep',
source_queue_name => 'strmadmin.capture_queue',
destination_queue_name => 'strmadmin.apply_queue@sync1.example.com',
source_database => 'sync2.example.com',
queue_to_queue => TRUE);
END;
/
ADD_TABLE_PROPAGATION_RULESプロシージャは、sync1.example.comデータベース内のapply_queueキューのhr.departments表にDML変更を送信するよう指示する伝播ルール・セットにルールを追加します。
sync1.example.comデータベースで同期取得を構成します。
SQL*Plusで、sync1.example.comデータベースにOracle Streams管理者として接続します。
ADD_TABLE_RULESプロシージャを実行して、同期取得を作成し、hr.employees表に対する変更を取得するよう指示するルールを追加します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'hr.employees',
streams_type => 'sync_capture',
streams_name => 'sync_capture',
queue_name => 'strmadmin.capture_queue');
END;
/
同期取得ルール・セットにルールを追加します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'hr.departments',
streams_type => 'sync_capture',
streams_name => 'sync_capture',
queue_name => 'strmadmin.capture_queue');
END;
/
これらのプロシージャを実行して次のアクションを実行します。
現在のデータベースでsync_captureという名前の同期取得を作成します。同じ名前の同期取得は存在できません。
同期取得を有効にします。同期取得は無効にできません。
strmadminが所有するcapture_queueという名前の既存のキューで同期取得を関連付けます。
同期取得sync_captureのポジティブ・ルール・セットを作成します。ルール・セットにはシステムで作成された名前があります。
hr.employees表に対するDML変更を取得するルールを作成し、同期取得のポジティブ・ルール・セットにルールを追加します。ルールにはシステムで生成された名前があります。
表に対してDBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATIONファンクションを自動的に実行することで、インスタンス化用にhr.employees表を準備します。
hr.departments表に対するDML変更を取得するルールを取得するルールを作成し、同期取得のポジティブ・ルール・セットにルールを追加します。ルールにはシステムで生成された名前があります。
表に対してDBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATIONファンクションを自動的に実行することで、インスタンス化用にhr.departments表を準備します。
sync2.example.comデータベースで同期取得を構成します。
SQL*Plusで、sync2.example.comデータベースにOracle Streams管理者として接続します。
ADD_TABLE_RULESプロシージャを実行して、同期取得を作成し、hr.employees表に対する変更を取得するよう指示するルールを追加します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'hr.employees',
streams_type => 'sync_capture',
streams_name => 'sync_capture',
queue_name => 'strmadmin.capture_queue');
END;
/
同期取得ルール・セットにルールを追加します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'hr.departments',
streams_type => 'sync_capture',
streams_name => 'sync_capture',
queue_name => 'strmadmin.capture_queue');
END;
/
手順8では、これらのプロシージャによって現在のデータベースで実行されるアクションについて説明します。
sync2.example.comデータベースで表のインスタンス化SCNを設定します。
SQL*Plusで、sync1.example.comデータベースにOracle Streams管理者として接続します。
sync2.example.comデータベースでhr.employees表のインスタンス化SCNを設定します。
DECLARE
iscn NUMBER; -- Variable to hold instantiation SCN value
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@sync2.example.com(
source_object_name => 'hr.employees',
source_database_name => 'sync1.example.com',
instantiation_scn => iscn);
END;
/
sync2.example.comデータベースでhr.departments表のインスタンス化SCNを設定します。
DECLARE
iscn NUMBER; -- Variable to hold instantiation SCN value
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@sync2.example.com(
source_object_name => 'hr.departments',
source_database_name => 'sync1.example.com',
instantiation_scn => iscn);
END;
/
インスタンス化SCNは、適用プロセスが表に変更を適用できる最小のSCNです。適用プロセスがsync2.example.comデータベースの共有表への変更を適用する前に、インスタンス化SCNを各表に対して設定する必要があります。
sync1.example.comデータベースで表のインスタンス化SCNを設定します。
SQL*Plusで、sync2.example.comデータベースにOracle Streams管理者として接続します。
sync1.example.comデータベースでhr.employees表のインスタンス化SCNを設定します。
DECLARE
iscn NUMBER; -- Variable to hold instantiation SCN value
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@sync1.example.com(
source_object_name => 'hr.employees',
source_database_name => 'sync2.example.com',
instantiation_scn => iscn);
END;
/
sync2.example.comデータベースでhr.departments表のインスタンス化SCNを設定します。
DECLARE
iscn NUMBER; -- Variable to hold instantiation SCN value
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@sync1.example.com(
source_object_name => 'hr.departments',
source_database_name => 'sync2.example.com',
instantiation_scn => iscn);
END;
/
SQL*Plusで、sync1.example.comデータベースにOracle Streams管理者として接続します。
適用プロセスを開始します。
BEGIN
DBMS_APPLY_ADM.START_APPLY(
apply_name => 'apply_emp_dep');
END;
/
SQL*Plusで、sync2.example.comデータベースにOracle Streams管理者として接続します。
適用プロセスを開始します。
BEGIN
DBMS_APPLY_ADM.START_APPLY(
apply_name => 'apply_emp_dep');
END;
/
適用プロセスの開始にEnterprise Managerを使用する方法については、「適用プロセスの起動と停止」を参照してください。
sync1.example.comおよびsync2.example.comの各データベースのhr.departmentsおよびhr.employeesの各表に対して、最新時刻競合解消を構成します。方法については、「チュートリアル: 表の最新時刻競合解消の構成」を参照してください。
次のような特性を持つ2データベース・レプリケーション環境が構成されます。
各データベースには、sync_captureという名前の同期取得があります。この同期取得は、hr.employees表およびhr.departments表に対するすべてのDML変更を取得します。
各データベースには、capture_queueという名前のキューがあります。このキューは、データベースでの同期取得用です。
各データベースには、apply_emp_depという名前の適用プロセスがあります。この適用プロセスは、hr.employees表およびhr.departments表に対するすべてのDML変更を適用します。
各データベースには、apply_queueという名前のキューがあります。このキューは、データベースでの適用プロセス用です。
各データベースには、send_emp_depという名前の伝播があります。この伝播は、ローカル・データベース内のcapture_queueから、他のデータベース内のapply_queueに変更を送信します。この伝播では、hr.employees表およびhr.departments表に対するすべてのDML変更が送信されます。
変更の循環を回避するため、次のようにタグが使用されています。
各適用プロセスでは、デフォルトの適用タグを使用します。デフォルトの適用タグは、'00'(ゼロが2つ)と等価の16進数になります。
各同期取得は、NULLタグを含むセッションの変更のみを取得します。したがって、同期取得は、ローカル適用プロセスによって適用される変更は取得しません。同期取得のルールは、これらの変更を取得しないよう同期取得に指示します。
レプリケーション環境で変更の循環を回避する方法の詳細は、「変更の循環を回避するためのタグの概要」を参照してください。
Oracle Streamsレプリケーション構成を確認するには:
各データベースで、次の手順を実行して同期取得が構成されることを確認します。
SQL*Plusを起動して、データベースにOracle Streams管理者として接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
次のようにALL_SYNC_CAPTUREデータ・ディクショナリ・ビューを問い合せます。
SELECT CAPTURE_NAME FROM ALL_SYNC_CAPTURE;
各データベースにsync_captureという名前の同期取得が存在していることを確認します。
各データベースで、伝播が有効化されていることを確認します。確認には、「伝播の情報の表示」の手順に従って、「伝播」サブページで「ステータス」を確認します。
各データベースで、適用プロセスが有効化されていることを確認します。確認には、「適用プロセスの情報の表示」の手順に従って、「適用」サブページで「ステータス」を確認します。
変更をレプリケートするには:
データベースの1つで、hr.employees表またはhr.departments表に対してDML変更を行います。
変更のレプリケーションが完了するまで待ってから、SQL*Plusを使用して他のデータベースのhr.employees表またはhr.departments表を問い合せて変更を表示します。
レプリケーション環境では、競合解消によって競合が自動的に解消されます。競合解消の詳細は、「競合と競合解消の概要」を参照してください。
更新競合を解消する最も一般的な方法は、最新のタイムスタンプを持つ変更を保持し、古い変更を破棄することです。この方法では、適用中に競合が検出された場合、適用プロセスは、変更のタイムスタンプ列が表の対応する行よりも新しい場合に変更を適用します。表のタイムスタンプ列が最新の場合、適用プロセスは変更を破棄します。
この項の例では、次のアクションを完了することにより、hr.departments表の最新時刻競合解消を構成します。
TIMESTAMP WITH TIME ZONEデータ型のtime列を表に追加する
行が変更されたときに最新の時刻を持つ行の時間列を更新するようにトリガーを構成する
表の列にサプリメンタル・ロギングを追加する
DBMS_APPLY_ADMパッケージのSET_UPDATE_CONFLICT_HANDLERプロシージャを実行して、表の競合解消を構成する
この項の手順を使用して、任意の表の競合解消を構成できます。これを構成するには、hrをスキーマ名で置換し、departmentsを表名で置換します。また、SET_UPDATE_CONFLICT_HANDLERプロシージャを実行するときに、hr.departments表の列を、使用する表の列で置換します。
hr.departments表の最新時刻競合解消を構成するには:
SQL*Plusで、Oracle Streams管理者やSYSTEMなどの管理ユーザーとしてデータベースに接続します。別の方法として、時間列が追加される表を所有しているユーザーとして接続することもできます。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
SQL文ALTER TABLEを使用して、表にtime列を追加します。この例では、次の文を実行してtime列をhr.departments表に追加します。
ALTER TABLE hr.departments ADD (time TIMESTAMP WITH TIME ZONE);
トリガーを作成して変更が発生した時刻で各マスター表のtime列を更新します。
|
ヒント: トリガーを使用してtime列を更新するかわりに、アプリケーションで表に対して列を修正または挿入するたびに、time列を移入できます。 |
Oracle Enterprise Managerで、SYSTEMまたはOracle Streams管理者などの管理者ユーザーとしてデータベースにログインします。
「データベース」ホームページに移動します。
「スキーマ」をクリックして「スキーマ」サブページを開きます。
「プログラム」セクションで「トリガー」をクリックします。
「トリガー」ページで、「作成」をクリックします。
「トリガーの作成」ページが表示され、「一般」サブページが表示されます。
「名前」フィールドにトリガーの名前を入力します。この例では、insert_departments_timeを入力します。
表を所有しているスキーマを「スキーマ」フィールドに入力します。この例では、「スキーマ」フィールドにはhrと入力します。
「トリガー本体」フィールドに次のように入力します。
BEGIN
-- Consider time synchronization problems. The previous update to this
-- row might have originated from a site with a clock time ahead of
-- the local clock time.
IF :OLD.TIME IS NULL OR :OLD.TIME < SYSTIMESTAMP THEN
:NEW.TIME := SYSTIMESTAMP;
ELSE
:NEW.TIME := :OLD.TIME + 1 / 86400;
END IF;
END;
「イベント」をクリックして「イベント」サブページを開きます。
「対象オブジェクト」リストで「表」が選択されていることを確認します。
「表(Schema.Table)」フィールドにschema.tableの形式で表名を入力するか、懐中電灯アイコンを使用してデータベース・オブジェクトを検索します。この例では、hr.departmentsを入力します。
「起動タイミング」に「前」が選択されていることを確認してください。
「イベント」に「選択」および「列の更新」を選択します。
表内の列が表示されます。
新規のtime列を除く表のすべての列を選択します。
「拡張」をクリックして、「拡張」サブページを開きます。
「行レベル・トリガー」を選択します。
「OK」をクリックしてトリガーを作成します。
|
注意: SQL文CREATE TRIGGERを使用して、トリガーを作成することもできます。 |
SQL*Plusで、データベースにOracle Streams管理者として接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
表の列にサプリメンタル・ロギングを追加します。
ALTER TABLE hr.departments ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
サプリメンタル・ロギングは、適用中の競合解消に必要です。
SET_UPDATE_CONFLICT_HANDLERプロシージャを実行して、表の最新時刻競合解消を構成します。
たとえば、次のプロシージャを実行して、hr.departments表の最新時刻競合解消を構成します。
DECLARE
cols DBMS_UTILITY.NAME_ARRAY;
BEGIN
cols(1) := 'department_id';
cols(2) := 'department_name';
cols(3) := 'manager_id';
cols(4) := 'location_id';
cols(5) := 'time';
DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(
object_name => 'hr.departments',
method_name => 'MAXIMUM',
resolution_column => 'time',
column_list => cols);
END;
/
cols列リストの表内のすべての列を含みます。
レプリケーション環境で競合解消が必要な表について、これらの手順を繰り返します。複数のデータベースで表の競合解消を構成することが必要な場合があります。
レプリケーション環境を構成または拡張する例を実行している場合は、適切な表に対して最新時刻競合解消を構成します。
「チュートリアル: ローカル取得プロセスを使用した2データベース・レプリケーションの構成」では、db1.example.comおよびdb2.example.comデータベースでhrスキーマのすべての表に対して競合解消を構成します。このスキーマには、countries、departments、employees、jobs、job_history、locationsおよびregionsの各表が含まれます。
「チュートリアル: ローカル取得プロセスでのハブアンドスポーク・レプリケーションの構成」では、hub1.example.com、spoke1.example.com、spoke2.example.comの各データベースでhrスキーマ内のすべての表に対して競合解消を構成します。このスキーマには、countries、departments、employees、jobs、job_history、locationsおよびregionsの各表が含まれます。
「チュートリアル: 同期取得を使用した2データベース・レプリケーションの構成」では、sync1.example.comおよびsync2.example.comデータベースでhr.departmentsおよびhr.employees表に対して競合解消を構成します。
「チュートリアル: レプリケーション環境へのデータベース・オブジェクトの追加」では、hub.example.com、spoke1.example.comおよびspoke2.example.comデータベースでoe.ordersおよびoe.order_items表に対して競合解消を構成します。
「チュートリアル: レプリケーション環境へのデータベースの追加」では、spoke3.example.comデータベースでhrスキーマのすべての表に対して競合解消を構成します。このスキーマには、countries、departments、employees、jobs、job_history、locationsおよびregionsの各表が含まれます。
例からこの項に移動した場合は、ここでその例に戻ります。
