| Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス 11g リリース1（11.1） E05779-02 |
|
 戻る |
 次へ |
事業の拡大や縮小、緊急事態などにより、データ配信を変更する場合、レプリケーション環境の構成も変更する必要があります。この章では、レプリケーション環境のマスター・サイトの管理を説明します。この項では、マスター・サイトの変更と再構成を中心に説明しています。
この章では、次の項目を説明します。
ほとんどのレプリケーション管理タスクは、マスター定義サイトのみで実行できます。マスター定義サイトを他のマスター・サイトへ移動する場合は、DBMS_REPCATパッケージのRELOCATE_MASTERDEFプロシージャを使用します。このAPIは、マスター定義サイトが利用できなくなったために、新しいマスター定義サイトを指定する必要がある場合に使用します（「オプション2 :旧マスター定義サイトが利用不可」を参照してください）。
すべてのマスター・サイトが利用可能な場合は、この項のアクションを実行して、マスター定義サイトを変更します。これらのアクションを実行するには、次の要件を満たす必要があります。
実行者: レプリケーション管理者
実行場所: いずれかのマスター・サイト
レプリケーションの状態: 実行中（静止中ではない）
次の手順に従います。
手順1 SQL*Plusで、レプリケーション管理者としてマスター・サイトに接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。
手順2 マスター定義サイトを再配置します。
BEGIN
DBMS_REPCAT.RELOCATE_MASTERDEF ( gname => 'hr_repg', old_masterdef => 'orc1.example.com', new_masterdef => 'orc2.example.com', notify_masters => TRUE, include_old_masterdef => TRUE); END; /
旧マスター・サイトが利用不可の場合は、この項のアクションを実行して、マスター定義サイトを変更します。これらのアクションを実行するには、次の要件を満たす必要があります。
実行者: レプリケーション管理者
実行場所: いずれかのマスター・サイト
レプリケーションの状態: 通常
次の手順に従います。
手順1 SQL*Plusで、レプリケーション管理者としてマスター・サイトに接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。
手順2 マスター定義サイトを再配置します。
BEGIN
DBMS_REPCAT.RELOCATE_MASTERDEF ( gname => 'hr_repg', old_masterdef => 'orc1.example.com', new_masterdef => 'orc2.example.com', notify_masters => TRUE, include_old_masterdef => FALSE); END; /
レプリケーション環境が拡張されるにつれ、新しいマスター・サイトをマスター・グループに追加することが必要な場合があります。新しいマスター・サイトは実行中のマスター・グループへも静止中のマスター・グループへも追加できます。マスター・グループが静止中ではない場合は、ユーザーは、新しいマスター・サイトが追加されるときのデータに対して、データ操作言語（DML）を操作できます。ただし、マスター・グループが静止中ではない場合は、新しいマスター・サイトを追加するときに、より管理的なアクションが要求されます。
該当する項の指示に従って、新しいマスター・サイトをマスター・グループに追加します。
この項には、新しいマスター・サイトを静止中ではない既存のマスター・グループへ追加するプロシージャが含まれています。これらの新しいサイトは、他のレプリケーション・グループのレプリケーション・サイト（マスター・サイトまたはマテリアライズド・ビュー・サイト）に存在する場合も存在しない場合もあります。
マスター・グループを静止しないで新しいマスター・サイトを追加する場合は、次のいずれかの方法が使用できます。
全データベースのエクスポートまたはインポート、あるいは変更ベースのリカバリを使用して、現在、レプリケーション・グループを保有していない新しいマスター・サイトを追加します。手順については、「全データベースのエクスポートまたはインポートの使用、あるいは変更ベースのリカバリの使用」を参照してください。
オブジェクトレベルのエクスポートまたはインポートを使用して、すでに他のレプリケーション・グループを保有する新しいマスター・サイトを追加、またはレプリケーション・グループを保有していない新しいマスター・サイトを追加します。手順については、「オブジェクトレベルのエクスポート/インポートの使用」を参照してください。
全データベースのエクスポートまたはインポート、および変更ベースのリカバリを使用して、マスター定義サイトのすべてのレプリケーション・グループを新しいマスター・サイトに追加します。この方法を使用する場合は、次の条件が適用されます。
新しいマスター・サイトは既存のレプリケーション・グループを持つことはできません。
マスター定義サイトはマテリアライズド・ビュー・グループを持つことはできません。
マスター定義サイトはすべてのマスター・グループについて同じである必要があります。これらのマスター・グループの1つ以上で、異なるマスター定義サイトを保有する場合は、全データベースのエクスポートまたはインポート、あるいは変更ベースのリカバリは使用しません。その場合、かわりにオブジェクトレベルのエクスポートまたはインポートを使用します。
新しいマスター・サイトは、拡張プロセスの完了時には、マスター定義サイトのすべてのレプリケーション・グループを含んでいる必要があります。すなわち、マスター定義サイトのマスター・グループのサブセットを新しいマスター・サイトへ追加することはできません。グループのすべてを追加する必要があります。
使用している環境がこれらの条件の一部を満たすことができない場合は、オブジェクトレベルのエクスポートまたはインポートを使用して新しいマスター・サイトを追加します。図7-1は、これらの条件をまとめたものです。
|
注意: 変更ベースのリカバリを使用するには、既存のマスター・サイトおよび新しいマスター・サイトを同じオペレーティング・システム上で実行する必要があります。ただし、オペレーティング・システムのリリースは同じでなくてもかまいません。この条件は、全データベースのエクスポートまたはインポートへは適用されません。 |
オブジェクトレベルのエクスポートまたはインポートを使用して、マスター・グループをすでに他のレプリケーション・グループを保有する新しいマスター・サイトへ追加、またはマスター・グループをレプリケーション・グループを保有していない新しいマスター・サイトへ追加します。この方法では、1つ以上のマスター・グループを新しいマスター・サイトへ一度に追加できます。また、マスター定義サイトのマスター・グループのサブセットを選択して操作実行時に新しいマスター・サイトへ追加できます。
オブジェクトレベルのエクスポートまたはインポートを使用する場合において、2つ以上のマスター・グループにまたがる整合性制約があり、これらの制約に該当する表が新しいマスター・サイトにすでに存在する場合は、新しいマスター・サイトを追加する表のこれらの整合性制約を一時的に無効にします。最初は、新しいマスター・サイトを参照するDEFSCHEDULEデータ・ディクショナリ・ビューには2つの行があります。伝播を受け取った場合は、このビューの行は1つです。また、すべてのマスター・サイトから新しいマスター・サイトへの伝播を受け取った場合は、無効化した整合性制約を再有効化できます。
マスター・グループを静止することなく新しいマスター・サイトを追加する2つの方法を再度、次に示します。
全データベースのエクスポートまたはインポート、あるいは変更ベースのリカバリ
オブジェクトレベルのエクスポートまたはインポート
いずれかの方法を使用する場合は、新しいマスター・サイトの追加時に、新しいマスター・サイトへの遅延トランザクションの伝播は、部分的または完全に無効化されます。このため、既存の各マスター・サイトには、未伝播の遅延トランザクション・キューの中で最大のものを格納するのに十分な空き領域があることを確認します。
影響を受けるマスター・グループはすべて、非同期レプリケーションを使用します。同期レプリケーションは使用できません。
すべてのスケジュール・リンクは、パラレル化を1以上に設定したパラレル伝播を使用します。
影響を受けるすべてのマスター・グループのデータベース・リンクは、接続修飾子を所有しないか、またはすべてのマスター・グループで同一の接続修飾子を所有するかのいずれかです。
新しいマスター・サイトを1つ以上のマスター・グループへ追加するプロセスを開始した後は、これらの新しいマスター・サイトが追加されてから、影響を受けるマスター・グループへの追加を開始します。マスター定義サイトのDBA_NEW_REPSITESデータ・ディクショナリ・ビュー内に、影響を受けるマスター・グループの情報がある場合、マスター・グループに対して開始した追加プロセスは完了できません。
新しいマスター・サイトを1つ以上のマスター・グループへ追加するプロセスを開始した後は、新しいマスター・サイトが追加されるまで、これらのマスター・グループのマスター定義サイトを再配置できません。DBA_NEW_REPSITESデータ・ディクショナリ・ビュー内に、影響を受けるマスター・グループの情報がある場合は、マスター・グループに対して開始した追加プロセスは完了できません。
マスター・サイトで許可されるマスター・サイトの追加要求は一度に1つのみです。 たとえば、hq1.example.comがmgroup1のマスター定義サイトで、hq2.example.comがmgroup2のマスター定義サイトである場合、hq1.example.comのmgroup2への追加およびhq2.example.comのmgroup1への追加は同時に行うことはできません。
オブジェクトレベルまたは全データベースのエクスポートまたはインポートを使用している場合は、エクスポートのロールバック・セグメントまたはUNDO表領域に十分な領域があることを確認します。
また、いずれかの方法で新しいマスター・サイトを追加する前に、新しいマスター・サイトがマルチマスター・レプリケーション用に正しく設定されていることを確認します。
|
注意: 次の項に記述された手順を続行できなくなった場合は、メッセージのトレース・ファイルおよびアラート・ログをチェックします。 |
|
関連項目:
|
図7-2では、全データベースのエクスポートまたはインポート、あるいは変更ベースのリカバリを使用して、マスター・グループを静止することなく新しいマスター・サイトをマスター・グループに追加する主な手順について説明しています。 次のスクリプト例では、新しいマスター・サイトorc4.example.comおよびorc5.example.comをhr_repgマスター・グループに追加しています。 この例では、orc4.example.comは全データベースのエクスポートまたはインポートを使用して追加され、orc5.example.comは変更ベースのリカバリを使用して追加されています。
図7-2 全データベースのエクスポートまたはインポートの使用、あるいは変更ベースのリカバリの使用
これらのアクションを実行するには、次の要件を満たす必要があります。
実行者: レプリケーション管理者（他の実行者が指定されていない場合）
実行場所:
レプリケーションの状態: 実行中（静止中ではない）
次の手順に従い、全データベースのエクスポートまたはインポート、あるいは変更ベースのリカバリを使用して、サイトをマスター・グループに追加します。
|
注意: このドキュメントをオンラインで参照している場合は、次の「BEGINNING OF SCRIPT」の行から「END OF SCRIPT」の行までのテキストをテキスト・エディタにコピーして編集し、使用している環境に適したスクリプトを作成します。 |
/************************* BEGINNING OF SCRIPT ******************************
手順1 全データベースのエクスポートまたはインポートを使用している場合は、マスター・グループへ追加するデータベースを作成します。
変更ベースのリカバリを使用している場合、この手順は必要ありません。
|
関連項目: データベース作成の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
*/ SET ECHO ON SPOOL add_masters_full.out PAUSE Press <RETURN> when the databases for the new master sites are created. /*
手順2 各新しいマスター・サイトをレプリケーション・サイトとして設定します。
次の構成を行う必要があることに注意してください。
*/ PAUSE Press <RETURN> to continue the new master sites have been setup and the required scheduled links have been created. /*
|
関連項目:
|
新しい各マスター・サイトのレプリケーション管理者
既存の各マスター・サイトから新しい各マスター・サイトへのスケジュール・リンク
新しい各マスター・サイトから既存の各マスター・サイトへのスケジュール・リンク
新しい各マスター・サイトでのスケジュール・パージ
手順3 レプリケーション管理者としてマスター定義サイトに接続します。
*/
CONNECT repadmin@orc1.example.com /*
手順4 各マスター・グループの新しいマスター・サイトを指定します。
新しいマスター・サイトを指定する前に、リンクが存在していない場合は既存のマスター・サイトと各新しいマスター・サイト間で必要なスケジュール・リンクを作成します。
|
関連項目:
|
*/ BEGIN DBMS_REPCAT.SPECIFY_NEW_MASTERS ( gname => 'HR_REPG', master_list => 'orc4.example.com,orc5.example.com'); END; / /*
他のSQL*Plusセッションで次のデータ・ディクショナリ・ビューに問い合せることで、拡張プロセスの追跡を開始できます。
DBA_REPSITES_NEW
DBA_REPEXTENSIONS
*/ PAUSE Press <RETURN> when you have completed the these steps. /*
次のプロシージャを実行する前に、新しいマスター・サイトで実行中のバックグラウンド・ジョブの数が適切であることを確認します。全データベースのエクスポートまたはインポートを使用している場合は、このプロシージャを実行する前に、エクスポートのロールバック・セグメントまたはUNDO表領域に十分な領域があることを確認します。
|
関連項目:
|
*/ VARIABLE masterdef_flashback_scn NUMBER; VARIABLE extension_id VARCHAR2(32); BEGIN DBMS_REPCAT.ADD_NEW_MASTERS ( export_required => TRUE, available_master_list => NULL, masterdef_flashback_scn => :masterdef_flashback_scn, extension_id => :extension_id, break_trans_to_masterdef => FALSE, break_trans_to_new_masters => FALSE, percentage_for_catchup_mdef => 80, cycle_seconds_mdef => 60, percentage_for_catchup_new => 80, cycle_seconds_new => 60); END; / /*
masterdef_flashback_scnおよびextension_idの値は変数に保存され、後のプロセスで使用されます。これらの値を参照する場合は、DBA_REPSITES_NEWおよびDBA_REPEXTENSIONSデータ・ディクショナリ・ビューへの問合せを行います。
*/ PAUSE Press <RETURN> when you have completed the these steps. /*
SPECIFY_NEW_MASTERSおよびADD_NEW_MASTERSプロシージャで、特定のマスター・サイトに対して行った変更を取り消す場合は、DBMS_REPCAT.UNDO_ADD_NEW_MASTERS_REQUESTプロシージャを使用します。
orc4.example.comは全データベースのエクスポートまたはインポートを使用して追加されたため、export_requiredパラメータには、TRUEが指定されます。 orc5.example.comは変更ベースのリカバリを使用していますが、TRUEの設定は誤りではありません。これは、少なくとも1つの新しいマスター・サイトが、エクスポートまたはインポートを使用しているためです。
このプロシージャを実行した後、他のSQL*PlusセッションでDBA_REPCATLOGデータ・ディクショナリ・ビューに問合せを行うことで、進行状況を監視します。このビューに新しいマスター・サイトの追加情報がなくなるまでは、手順7には進まないでください。DBA_REPCATLOGには他の操作による無関係の情報が含まれていないことを前提に、次の文を入力します。
SELECT COUNT(*) FROM DBA_REPCATLOG;
この文から0（ゼロ）が戻されれば、すべてのプロセスは完了です。
*/ PAUSE Press <RETURN> to continue when DBA_REPCATLOG is empty. /*
手順6 全データベースのエクスポートまたはインポートを実行する場合は、各データベースにディレクトリ・オブジェクトを作成します。
変更ベースのリカバリを使用して追加されたマスター・サイトでは、この手順は必要ないので、手順8に進みます。
この操作で使用する各データベースには、データ・ポンプ・ダンプ・ファイルを保存するためのディレクトリ・オブジェクトが必要です。また、エクスポートまたはインポートを実行するユーザーには、このディレクトリ・オブジェクトに対するREADおよびWRITE権限が必要です。この例では、マスター定義サイトでデータ・ポンプ・エクスポートを実行し、各新しいマスター・サイトでデータ・ポンプ・インポートを実行します。
全データベースのエクスポート/インポートを実行する場合は、SQL文CREATE DIRECTORYを使用してディレクトリ・オブジェクトを作成できる管理ユーザーとしてSQL*Plusでデータベースに接続し、データ・ポンプのダンプ・ファイルおよびログ・ファイルを保存するためのディレクトリ・オブジェクトを作成します。次に例を示します。
*/ CONNECT system@orc1.example.com CREATE DIRECTORY DPUMP_DIR AS '/usr/dpump_dir'; CONNECT system@orc4.example.com CREATE DIRECTORY DPUMP_DIR AS '/usr/dpump_dir'; CONNECT system@orc5.example.com CREATE DIRECTORY DPUMP_DIR AS '/usr/dpump_dir'; /*
この例では、SYSTEMユーザーがすべてのエクスポートおよびインポートを実行します。ディレクトリ・オブジェクトを作成したユーザー以外のユーザーがエクスポートまたはインポートを実行する場合は、このユーザーにそのディレクトリ・オブジェクトに対するREADおよびWRITE権限を付与します。
操作に使用した各データベースでこれらのアクションが完了していることを確認します。
手順7 全データベースのエクスポートまたはインポートを使用して追加されたマスター・サイトの次のサブステップを実行します。
変更ベースのリカバリを使用して追加されたマスター・サイトでは、このサブステップは必要ないので、手順8に進みます。
マスター定義データベースの全データベースのエクスポートを実行します。FLASHBACK_SCNエクスポート・パラメータの手順5のmasterdef_flashback_scnパラメータから戻されるシステム変更番号（SCN）を使用します。
DBA_REPEXTENSIONSデータ・ディクショナリ・ビューにFLASHBACK_SCN値を問い合せることができます。
SELECT FLASHBACK_SCN FROM DBA_REPEXTENSIONS;
この例では、この問合せで戻される値は124723であるとします。
この例で、orc4.example.comは全データベースのエクスポートまたはインポートを使用しています。 このため、この後の手順でorc4.example.comへインポートできるように、マスター定義データベースの全データベースのエクスポートを実行します。 一方、orc5.example.comデータベースは変更ベースのリカバリを使用しています。 このため、orc5.example.comのみの追加では、エクスポートは必要とされません。
コマンドラインで、エクスポートを実行します。この例では、SYSTEMユーザーとして接続します。データ・ポンプ・エクスポート・コマンドの例を次に示します。
expdp system FULL=y DIRECTORY=DPUMP_DIR DUMPFILE=fulldb_orc1.dmp FLASHBACK_SCN=124723
エクスポート・ユーティリティを実行する場合の考慮事項は、次のとおりです。
DBAロールまたはEXP_FULL_DATABASEロールを所有するユーザーのみが全データベース・モードでのエクスポートを実行できます。
エクスポートを実行する前に、UNDO_RETENTION初期化パラメータが正しく設定されていることを確認します。
|
関連項目:
|
*/ PAUSE Press <RETURN> to continue when the export is complete. /*
次のプロシージャを実行することで、マスター・サイトの拡張されたマスター・グループおよび影響されていないマスター・グループに対するエクスポートが正常に行われ、伝播が有効化されたことが示されます。
*/ BEGIN DBMS_REPCAT.RESUME_PROPAGATION_TO_MDEF ( extension_id => :extension_id); END; / /*
extension_idは、DBA_REPSITES_NEWデータ・ディクショナリ・ビューを問い合せることで検索できます。
エクスポート・ダンプ・ファイルを新しいマスター・サイトに転送します。
全データベースのエクスポートまたはインポートで追加された他の新しいマスター・サイトへは、DBMS_FILE_TRANSFERパッケージ、FTPなどの方法により、エクスポート・ダンプ・ファイルが転送されます。次の手順で説明するインポートを実行する場合、新しいサイトで、このエクスポート・ダンプ・ファイルが必要となります。
*/ PAUSE Press <RETURN> to continue after transferring the dump file. /*
新しいマスター・サイトのJOB_QUEUE_PROCESSES初期化パラメータを0（ゼロ）に設定します。
*/ PAUSE Press <RETURN> to continue after JOB_QUEUE_PROCESSES is set to zero at each new master site. /*
手順8 新しいマスター・サイトでインポートまたは変更ベースのリカバリを実行します。
全データベースのエクスポートまたはインポートを使用している場合は、全データベースのエクスポートまたはインポートで追加された新しいマスター・サイトの手順7でエクスポートしたデータベースの全データベースのインポートを実行します。
インポートを実行します。 この例では、SYSTEMユーザーとして接続してorc4.example.comでインポートを実行します。インポート・コマンドの例を次に示します。
impdp system FULL=y DIRECTORY=DPUMP_DIR DUMPFILE=fulldb_orc1.dmp
DBAロールまたはIMP_FULL_DATABASEロールを所有するユーザーのみが全データベース・モードでのインポートを実行できます。
|
関連項目: データ・ポンプ・インポートの実行方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
*/ PAUSE Press <RETURN> to continue when the import is complete. /*
変更ベースのリカバリを使用している場合は、手順5のmasterdef_flashback_scnパラメータから戻されたシステム変更番号（SCN）を使用して変更ベースのリカバリを実行します。DBA_REPEXTENSIONSデータ・ディクショナリ・ビューにmasterdef_flashback_scn値を問い合せることができます。
次の方法で変更ベースのリカバリを実行できます。
SQL*PlusのRECOVERコマンドを使用します。手順については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
Recovery ManagerのDUPLICATEコマンドを使用します。 手順については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
変更ベースのリカバリを実行するサイトに接続します。
*/ CONNECT repadmin@orc5.example.com PAUSE Press <RETURN> to continue when the change-based recovery is complete. You can use a separate terminal window to perform the change-based recovery. /*
手順9 次の手順に従って、新しいサイトをマルチマスター・レプリケーション用に構成します。
新しいマスター・サイトにレプリケート・スキーマとして存在するデータファイルなどの、データベース構造を確認します。この例では、レプリケート・スキーマはhrです。
新しいマスター・サイトにグローバル名を設定します。新しいマスター・サイトのグローバル名は、手順4で実行したSPECIFY_NEW_MASTERSプロシージャに指定したグローバル名と一致する必要があります。DBA_REPSITES_NEWデータ・ディクショナリ・ビューのDBLINK列への問合せを行い、新しいマスター・サイトのグローバル名を確認できます。
次の例に示すように、ALTER DATABASE文を使用してグローバル名を設定できます。
ALTER DATABASE RENAME GLOBAL_NAME TO orc4.example.com;
新しいマスター・サイトと既存のマスター・サイト間に、マスター定義サイトなどの、適切なスケジュール・リンクを作成します。
*/ PAUSE Press <RETURN> when you have completed the these steps. /*
手順10 新しいマスター・サイトで遅延トランザクションを受信します。
次のプロシージャでは、新しく準備されたマスター・サイトや既存のマスター・サイトから起動マスター・サイトへの遅延トランザクションの伝播が可能です。このプロシージャでは、起動マスター・サイトから新しく準備されたマスター・サイトや既存のマスター・サイトへの遅延トランザクションの伝播も可能です。
|
注意: 新しいマスター・サイトのインスタンス化（エクスポートまたはインポート、あるいは変更ベースのリカバリ）が完了するまでは、このプロシージャを起動しないでください。 プロシージャから完了通知が戻るまでは、データ操作言語（DML）文を新しいマスター・サイトの拡張マスター・グループのオブジェクトに適用しないでください。これは、これらのDML文が、レプリケートされないためです。 |
*/ CONNECT repadmin@orc4.example.com BEGIN DBMS_REPCAT.PREPARE_INSTANTIATED_MASTER ( extension_id => :extension_id); END; / CONNECT repadmin@orc5.example.com BEGIN DBMS_REPCAT.PREPARE_INSTANTIATED_MASTER ( extension_id => :extension_id); END; / SET ECHO OFF SPOOL OFF /*
|
注意:
|
************************** END OF SCRIPT **********************************/
図7-3では、オブジェクトレベルのエクスポートまたはインポート使用して、マスター・グループを静止することなく新しいマスター・サイトをマスター・グループに追加する主な手順について説明しています。 次のプロシージャ例では、新しいマスター・サイトorc4.example.comおよびorc5.example.comをhr_repgマスター・グループに追加しています。オブジェクトレベルのエクスポートまたはインポートには、マスター・グループの表のエクスポートとインポートが含まれます。表のエクスポートとインポートでは、索引などの、その他の依存データベース・オブジェクトも同様にエクスポート、インポートされます。
2つのマスター・グループにまたがる整合性制約がある場合は、一方のマスター・グループに子表（子マスター・グループ）、他方のマスター・グループに親表（親マスター・グループ）を用意します。この場合、新しいマスター・サイトを両方のマスター・グループに同時に追加することをお薦めします。しかし、同時に追加することができない場合は、子マスター・グループを静止してから新しいマスター・サイトを追加します。ここでは、子表には外部キーが含まれているため、子表は親表の値に依存します。子マスター・グループを静止しないで追加を行うと、マスター・サイトの追加時に競合が発生します。親マスター・グループへのマスター・サイトの追加は静止なしでも行えます。
これらのアクションを実行するには、次の要件を満たす必要があります。
実行者: レプリケーション管理者（他の実行者が指定されていない場合）
実行場所:
レプリケーションの状態: 実行中（静止中ではない）
次の手順に従って、オブジェクトレベルのエクスポートまたはインポートを使用してサイトをマスター・グループに追加します。
|
注意: このドキュメントをオンラインで参照している場合は、次の「BEGINNING OF SCRIPT」の行から「END OF SCRIPT」の行までのテキストをテキスト・エディタにコピーして編集し、使用している環境に適したスクリプトを作成します。 |
/************************* BEGINNING OF SCRIPT ******************************
手順1 新しいマスター・サイトにエクスポート・スキーマのユーザーが存在しない場合は、ここで作成します。
この例では、レプリケート・スキーマはhrです。このスキーマは、Oracleとともにインストールされるサンプル・スキーマであるため、新しいマスター・サイトに存在します。
|
関連項目: サンプル・スキーマの概要とそのインストール方法の詳細は、『Oracle Databaseサンプル・スキーマ』を参照してください。 |
*/ SET ECHO ON SPOOL add_masters_object.out PAUSE Press <RETURN> to continue when the users are created at the new master sites. /*
手順2 マスター・グループ内の表のいずれかに循環依存がある場合は、これらの表を新しいマスター・サイトで事前に作成しておきます。
循環依存を持つ表を事前に作成しないと、後でエラーが発生します。循環依存がなければ、この手順は必要ないので手順3に進みます。
hrスキーマの一部の表には、循環依存が含まれています。そのため、この例では、hrスキーマ内の表を新しい各マスター・サイトで事前に作成する必要があります。また、hrスキーマの表は、通常はOracleのインストール中に作成されるため、すでに新しいマスター・サイトに存在する可能性があります。
表の事前作成が必要な場合は、インポート前に新しいマスター・サイトで、これらの表に対する参照整合性制約を無効化します。参照整合性制約が有効化されていると、既存の表にデータをインポートするときにエラーの原因になることがあります。この例では、新しいマスター・サイトで、hrスキーマに事前作成する表に対する参照整合性制約を無効化します。
また、新しいマスター・サイトで事前作成する表には、データを含めないでください。この例では、データが含まれないように、新しいマスター・サイトでhrスキーマ内の表を切り捨てます。
|
関連項目:
|
*/ PAUSE Press <RETURN> to continue when the tables are precreated at the new master sites, if table precreation is required. After the tables are precreated, the following statements disable the referential integrity constraints related to the hr schema and truncate the tables in the hr schema at the new site. CONNECT oe@orc4.example.com ALTER TABLE oe.warehouses DISABLE CONSTRAINT warehouses_location_fk; ALTER TABLE oe.customers DISABLE CONSTRAINT customers_account_manager_fk; ALTER TABLE oe.orders DISABLE CONSTRAINT orders_sales_rep_fk; CONNECT hr@orc4.example.com ALTER TABLE hr.countries DISABLE CONSTRAINT countr_reg_fk; ALTER TABLE hr.departments DISABLE CONSTRAINT dept_mgr_fk DISABLE CONSTRAINT dept_loc_fk; ALTER TABLE hr.employees DISABLE CONSTRAINT emp_dept_fk DISABLE CONSTRAINT emp_job_fk DISABLE CONSTRAINT emp_manager_fk; ALTER TABLE hr.job_history DISABLE CONSTRAINT jhist_job_fk DISABLE CONSTRAINT jhist_emp_fk DISABLE CONSTRAINT jhist_dept_fk; ALTER TABLE hr.locations DISABLE CONSTRAINT loc_c_id_fk; TRUNCATE TABLE hr.countries; TRUNCATE TABLE hr.departments; TRUNCATE TABLE hr.employees; TRUNCATE TABLE hr.jobs; TRUNCATE TABLE hr.job_history; TRUNCATE TABLE hr.locations; TRUNCATE TABLE hr.regions; CONNECT oe@orc5.example.com ALTER TABLE oe.warehouses DISABLE CONSTRAINT warehouses_location_fk; ALTER TABLE oe.customers DISABLE CONSTRAINT customers_account_manager_fk; ALTER TABLE oe.orders DISABLE CONSTRAINT orders_sales_rep_fk; CONNECT hr@orc5.example.com ALTER TABLE hr.countries DISABLE CONSTRAINT countr_reg_fk; ALTER TABLE hr.departments DISABLE CONSTRAINT dept_mgr_fk DISABLE CONSTRAINT dept_loc_fk; ALTER TABLE hr.employees DISABLE CONSTRAINT emp_dept_fk DISABLE CONSTRAINT emp_job_fk DISABLE CONSTRAINT emp_manager_fk; ALTER TABLE hr.job_history DISABLE CONSTRAINT jhist_job_fk DISABLE CONSTRAINT jhist_emp_fk DISABLE CONSTRAINT jhist_dept_fk; ALTER TABLE hr.locations DISABLE CONSTRAINT loc_c_id_fk; TRUNCATE TABLE hr.countries; TRUNCATE TABLE hr.departments; TRUNCATE TABLE hr.employees; TRUNCATE TABLE hr.jobs; TRUNCATE TABLE hr.job_history; TRUNCATE TABLE hr.locations; TRUNCATE TABLE hr.regions; /*
手順3 新しい各マスター・サイトをレプリケーション・サイトとして設定します。
次の構成を行う必要があることに注意してください。
新しい各マスター・サイトのレプリケーション管理者
既存の各マスター・サイトから新しい各マスター・サイトへのスケジュール・リンク
新しい各マスター・サイトから既存の各マスター・サイトへのスケジュール・リンク
新しい各マスター・サイトでのスケジュール・パージ
*/ PAUSE Press <RETURN> to continue the new master sites have been setup and the required scheduled links have been created. /*
|
関連項目:
|
手順4 レプリケーション管理者としてマスター定義サイトに接続します。
*/
CONNECT repadmin@orc1.example.com /*
手順5 各マスター・グループの新しいマスター・サイトを指定します。
*/
BEGIN DBMS_REPCAT.SPECIFY_NEW_MASTERS ( gname => 'hr_repg', master_list => 'orc4.example.com,orc5.example.com'); END; / /*
他のSQL*Plusセッションで次のデータ・ディクショナリ・ビューに問い合せることで、拡張プロセスの追跡を開始できます。
DBA_REPSITES_NEW
DBA_REPEXTENSIONS
次のプロシージャを実行する前に、新しいマスター・サイトで実行中のバックグラウンド・ジョブの数が適切であることを確認します。このプロシージャを実行する前に、エクスポートのロールバック・セグメントまたはUNDO表領域に十分な領域があることも確認します。
|
関連項目:
|
*/ VARIABLE masterdef_flashback_scn NUMBER; VARIABLE extension_id VARCHAR2(32); BEGIN DBMS_REPCAT.ADD_NEW_MASTERS ( export_required => TRUE, available_master_list => 'orc4.example.com,orc5.example.com', masterdef_flashback_scn => :masterdef_flashback_scn, extension_id => :extension_id, break_trans_to_masterdef => FALSE, break_trans_to_new_masters => FALSE, percentage_for_catchup_mdef => 80, cycle_seconds_mdef => 60, percentage_for_catchup_new => 80, cycle_seconds_new => 60); END; / /*
available_master_listパラメータに指定したサイトは、手順5のSPECIFY_NEW_MASTERSプロシージャに指定したサイトと同じである必要があります。
masterdef_flashback_scnおよびextension_idの値は変数に保存され、後のプロセスで使用されます。これらの値を参照する場合は、DBA_REPSITES_NEWおよびDBA_REPEXTENSIONSデータ・ディクショナリ・ビューへの問合せを行います。
SPECIFY_NEW_MASTERSおよびADD_NEW_MASTERSプロシージャで、特定のマスター・サイトに対して行った変更を取り消す場合は、UNDO_ADD_NEW_MASTERS_REQUESTプロシージャを使用します。
このプロシージャを実行した後、他のSQL*PlusセッションでDBA_REPCATLOGデータ・ディクショナリ・ビューに問合せを行うことで、進行状況を監視します。このビューに新しいマスター・サイトの追加情報がなくなるまでは、手順8には進まないでください。DBA_REPCATLOGには他の操作による無関係の情報が含まれていないことを前提に、次の文を入力します。
SELECT COUNT(*) FROM DBA_REPCATLOG;
この文から0（ゼロ）が戻されれば、すべてのプロセスは完了です。
*/ PAUSE Press <RETURN> to continue when DBA_REPCATLOG is empty. /*
手順7 各データベースにディレクトリ・オブジェクトを作成します。
この操作で使用する各データベースには、データ・ポンプ・ダンプ・ファイルを保存するためのディレクトリ・オブジェクトが必要です。また、エクスポートまたはインポートを実行するユーザーには、このディレクトリ・オブジェクトに対するREADおよびWRITE権限が必要です。この例では、マスター定義サイトでデータ・ポンプ・エクスポートを実行し、各新しいマスター・サイトでデータ・ポンプ・インポートを実行します。
SQL文CREATE DIRECTORYを使用してディレクトリ・オブジェクトを作成できる管理ユーザーとしてSQL*Plusでデータベースに接続し、データ・ポンプのダンプ・ファイルおよびログ・ファイルを保存するためのディレクトリ・オブジェクトを作成します。次に例を示します。
*/ CONNECT system@orc1.example.com CREATE DIRECTORY DPUMP_DIR AS '/usr/dpump_dir'; CONNECT system@orc4.example.com CREATE DIRECTORY DPUMP_DIR AS '/usr/dpump_dir'; CONNECT system@orc5.example.com CREATE DIRECTORY DPUMP_DIR AS '/usr/dpump_dir'; /*
この例では、SYSTEMユーザーがすべてのエクスポートおよびインポートを実行します。ディレクトリ・オブジェクトを作成したユーザー以外のユーザーがエクスポートまたはインポートを実行する場合は、このユーザーにそのディレクトリ・オブジェクトに対するREADおよびWRITE権限を付与します。
操作に使用した各データベースでこれらのアクションが完了していることを確認します。
手順8 マスター定義データベースでオブジェクトレベルの表のエクスポートを実行します。
マスター定義データベースで、新しいマスター・サイトに作成するマスター・グループ内の各マスター表のオブジェクトレベルのエクスポートを実行します。オブジェクトレベルのエクスポートには、表モード、ユーザー・モードまたは表領域モードで実行するエクスポートがあります。
FLASHBACK_SCNエクスポート・パラメータの手順6のmasterdef_flashback_scnパラメータから戻されるシステム変更番号（SCN）を使用します。DBA_REPEXTENSIONSデータ・ディクショナリ・ビューにFLASHBACK_SCN値を問い合せることができます。
SELECT FLASHBACK_SCN FROM DBA_REPEXTENSIONS;
この例では、SCN値は3456871であるとします。
コマンドラインで、エクスポートを実行します。この例では、SYSTEMユーザーとして接続します。データ・ポンプ・エクスポート・コマンドの例を次に示します。
expdp system TABLES=HR.COUNTRIES,HR.DEPARTMENTS,HR.EMPLOYEES, HR.JOB_HISTORY,HR.JOBS,HR.LOCATIONS,HR.REGIONS DIRECTORY=DPUMP_DIR DUMPFILE=hr_tables.dmp CONTENT=data_only FLASHBACK_SCN=3456871
この例では、表がインポート・サイトにすでに存在しているため、CONTENTパラメータを使用します。このパラメータを指定する必要がない場合もあります。
エクスポートを実行する前に、UNDO_RETENTION初期化パラメータが正しく設定されていることを確認します。
|
関連項目:
|
*/ PAUSE Press <RETURN> to continue when the export is complete. /*
次のプロシージャを実行することで、マスター・サイトの拡張されたマスター・グループおよび影響されていないマスター・グループに対するエクスポートが正常に行われ、伝播が有効化されたことが示されます。
*/ CONNECT repadmin@orc1.example.com BEGIN DBMS_REPCAT.RESUME_PROPAGATION_TO_MDEF ( extension_id => :extension_id); END; / /*
extension_idは、DBA_REPSITES_NEWデータ・ディクショナリ・ビューを問い合せることで検索できます。
手順10 エクスポート・ダンプ・ファイルを新しいマスター・サイトに転送します。
オブジェクトレベルのエクスポートまたはインポートで追加された他の新しいマスター・サイトへは、DBMS_FILE_TRANSFERパッケージ、FTPなどの方法により、エクスポート・ダンプ・ファイルが転送されます。次の手順で説明するインポートを実行する場合、各新しいサイトで、これらのエクスポート・ダンプ・ファイルが必要となります。
*/ PAUSE Press <RETURN> to continue when the export dump files have been transfered to the new master sites that are being added with object-level export/import. /*
手順11 手順8でエクスポートした各オブジェクトの各新しいマスター・サイトでオブジェクトレベルのインポートを実行します。
コマンドラインで、インポートを実行します。この例では、SYSTEMユーザーとして接続します。インポート・コマンドの例を次に示します。
impdp system TABLES=HR.COUNTRIES,HR.DEPARTMENTS,HR.EMPLOYEES, HR.JOB_HISTORY,HR.JOBS,HR.LOCATIONS,HR.REGIONS DIRECTORY=DPUMP_DIR DUMPFILE=hr_tables.dmp CONTENT=data_only TABLE_EXISTS_ACTION=append
表に基づいて作成された索引など、他のオブジェクトは自動的にインポートされます。この例では、表がインポート・サイトにすでに存在しているため、CONTENTおよびTABLE_EXISTS_ACTIONパラメータを使用します。これらのパラメータを指定する必要がない場合もあります。
|
関連項目: データ・ポンプ・インポートの実行方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
各サイトでオブジェクトレベルのインポートを実行します。
*/ PAUSE Press <RETURN> to continue when the imports are complete at each site. You can use a separate terminal window to perform the object-level imports. /*
手順12 新しいマスター・サイトで遅延トランザクションを受信します。
次のプロシージャでは、新しく準備されたマスター・サイトや既存のマスター・サイトから起動マスター・サイトへの遅延トランザクションの伝播が可能です。このプロシージャでは、起動マスター・サイトから新しく準備されたマスター・サイトや既存のマスター・サイトへの遅延トランザクションの伝播も可能です。
|
注意: 新しいマスター・サイトに対するオブジェクトレベルのエクスポートまたはインポートが完了するまでは、このプロシージャは起動しないでください。 プロシージャから完了通知が戻るまでは、データ操作言語（DML）文を新しいマスター・サイトの拡張マスター・グループのオブジェクトに適用しないでください。これは、これらのDML文が、レプリケートされないためです。 |
*/ CONNECT repadmin@orc4.example.com BEGIN DBMS_REPCAT.PREPARE_INSTANTIATED_MASTER ( extension_id => :extension_id); END; / CONNECT repadmin@orc5.example.com BEGIN DBMS_REPCAT.PREPARE_INSTANTIATED_MASTER ( extension_id => :extension_id); END; / SET ECHO OFF SPOOL OFF /*
|
注意:
|
************************** END OF SCRIPT **********************************/
次に示す方法で、新しいマスター・サイトを静止中のマスター・グループに追加できます。
通常は、マスター・グループが小規模の場合または新しいマスター・サイトでレプリケーション表を事前に作成してデータをロードする場合にのみADD_MASTER_DATABASEプロシージャを使用します。これ以外の場合は、ADD_MASTER_DATABASEプロシージャは使用しません。このプロシージャでは、ネットワーク上のすべてのマスター・グループがコピーされるためです。大規模なマスター・グループでは、新しいマスター・サイトのマスター・グループにオブジェクトを事前に作成するか、オフライン・インスタンシエーションを使用します。
ADD_MASTER_DATABASEプロシージャを使用して、静止中の既存のマスター・グループにマスター・サイトを追加できます。このプロシージャを実行すると、既存のマスター・オブジェクトが新しいサイトにレプリケートされます。
これらのアクションを実行するには、次の要件を満たす必要があります。
実行者: レプリケーション管理者
実行場所: マスター定義サイト
レプリケーションの状態: 静止中
次の手順に従って、ADD_MASTER_DATABASEプロシージャを使用してサイトをマスター・グループに追加します。
|
注意: このドキュメントをオンラインで参照している場合は、次の「BEGINNING OF SCRIPT」の行から「END OF SCRIPT」の行までのテキストをテキスト・エディタにコピーして編集し、使用している環境に適したスクリプトを作成します。 |
/************************* BEGINNING OF SCRIPT ******************************
手順1 新しいマスター・サイトを設定します。
新しいマスター・サイトを追加する前に、適切なスキーマおよびデータベース・リンクが作成されていることを確認します。新しいマスター・サイトから既存の各マスター・サイトへのデータベース・リンクの作成を確認します。既存の各マスター・サイトから新しいマスター・サイトへのデータベース・リンクも作成します。データベース・リンクの作成を終えた後、新しいデータベース・リンクごとにスケジュール・リンクも定義します。
*/ SET ECHO ON SPOOL add_masters_quiesced.out PAUSE Press <RETURN> to the new master site has been set up. /*
手順2 レプリケーション管理者としてマスター定義サイトに接続します。
*/
CONNECT repadmin@orc1.example.com /*
手順3 レプリケーションの状態が通常の場合は、静止中に変更します。
*/
BEGIN DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY ( gname => 'hr_repg'); END; / /*
手順4 新しいマスター・サイトを追加します。
この例では、新しいマスター・サイトにレプリケート・オブジェクトが存在しないことを前提としています。このため、マスター定義サイトのレプリケート・オブジェクトの行を新しいマスター・サイトにコピーする場合はcopy_rowsパラメータをTRUEに設定します。また、Advanced Replicationが新しいサイトにレプリケート・オブジェクトを作成するためには、use_existing_objectsパラメータをFALSEに設定します。レプリケート・オブジェクトが新しいサイトにすでに存在して、データが含まれない場合は、use_existing_objectsをTRUEに設定します。
*/ BEGIN DBMS_REPCAT.ADD_MASTER_DATABASE ( gname => 'hr_repg', master => 'orc4.example.com', use_existing_objects => FALSE, copy_rows => TRUE, propagation_mode => 'ASYNCHRONOUS'); END; / /*
DBA_REPCATLOGビューが空になるまで待機します。このビューには、正常な実行後には消去される一時的な情報が含まれます。他のSQL*Plusセッションで次のSELECT文を実行して、DBA_REPCATLOGビューを監視します。
SELECT COUNT(*) FROM DBA_REPCATLOG WHERE GNAME = 'HR_REPG';
この文から0（ゼロ）が戻されれば、すべてのプロセスは完了です。
*/ PAUSE Press <RETURN> to continue when DBA_REPCATLOG is empty. /*
手順5 レプリケーション・アクティビティを再開します。
*/
BEGIN DBMS_REPCAT.RESUME_MASTER_ACTIVITY ( gname => 'hr_repg'); END; / SET ECHO OFF SPOOL OFF /************************* END OF SCRIPT **********************************/
確立されたレプリケーション環境が拡張されると、ADD_MASTER_DATABASEプロシージャを使用して新しいマスター・サイトをレプリケーション環境に追加した場合に、ネットワークの通信量が増大します。これは、ネットワークを通じて、表またはマテリアライズド・ビューの内容全体が新しいレプリケート・サイトに伝播されるためです。
このようなネットワークの通信量を最少にするには、レプリケーション環境を拡張する場合にオフライン・インスタンシエーション・プロシージャを使用します。オフライン・インスタンシエーションでは、Oracleのエクスポート・ユーティリティおよびインポート・ユーティリティを利用できます。これによって、エクスポート・ファイルを作成し、CD-ROMやテープなどのストレージ・メディアを使用して新しいサイトにデータを転送できます。
次のスクリプト例は、マスター・サイトのオフライン・インスタンシエーションを行う方法を示します。このスクリプトを実行すると、静止中の既存のマスター・グループに新しいマスター・サイトを追加する他の方法と比べ、ネットワークの通信量をかなり絞り込むことができます。このスクリプトは、新しいマスター・サイトにhrスキーマが存在しないことを前提とし、新しいマスター・サイトでこのスキーマをインスタンス化します。hrスキーマは、Oracleのインストール時に自動的に作成されます。この例を開始する前に、新しいマスター・サイトからhrスキーマを削除することもできます。
これらのアクションを実行するには、次の要件を満たす必要があります。
実行者: レプリケーション管理者（他の実行者が指定されていない場合）
実行場所: マスター定義サイトおよび新しいマスター・サイト
レプリケーションの状態: 静止中と部分的な再開
次の手順に従って、オフライン・インスタンシエーションを使用してサイトをマスター・グループに追加します。
|
注意: このドキュメントをオンラインで参照している場合は、次の「BEGINNING OF SCRIPT」の行から「END OF SCRIPT」の行までのテキストをテキスト・エディタにコピーして編集し、使用している環境に適したスクリプトを作成します。 |
/************************* BEGINNING OF SCRIPT ******************************
手順1 新しいマスター・サイトを設定します。
新しいマスター・サイトのオフライン・インスタンシエーションを実行する前に、適切なスキーマおよびデータベース・リンクが作成されていることを確認します。新しいマスター・サイトから既存の各マスター・サイトへのデータベース・リンクの作成を確認します。既存の各マスター・サイトから新しいマスター・サイトへのデータベース・リンクも作成します。データベース・リンクの作成を終えた後、新しいデータベース・リンクごとにスケジュール・リンクも定義します。
*/ SET ECHO ON SPOOL add_masters_instant.out PAUSE Press <RETURN> to the new master site has been set up. /*
手順2 レプリケーション管理者としてマスター定義サイトに接続します。
*/
CONNECT repadmin@orc1.example.com /*
手順3 マスター・アクティビティを一時停止します。
マスター・データのエクスポートおよびオフライン・インスタンシエーション・プロセスの開始の前に、既存のマスター・サイトのマスター・アクティビティを一時停止する必要があります。
*/ BEGIN DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY ( gname => 'hr_repg'); END; / /*
手順4 個別のSQL*Plusセッションにはペンディング・トランザクションがないことを検証します。
ここでは、未解決の遅延トランザクションのプッシュ、エラー・トランザクションの解決、および管理トランザクションのプッシュが含まれます。この手順は、既存の各マスター・サイトで実行する必要があります。
エラー・トランザクション・キューをチェックします。
SELECT * FROM DEFERROR;
遅延トランザクションがエラー・キューに入力された場合、エラーを解決するために手動で遅延トランザクションを再実行します。次に例を示します。
BEGIN DBMS_DEFER_SYS.EXECUTE_ERROR ( deferred_tran_id => '128323', destination => 'orc1.example.com'); END; /
未処理の管理要求をチェックします。
SELECT * FROM DBA_REPCATLOG;
未処理の管理要求が残っている場合は、これらの要求を手動で実行することも、自動的に実行されるまで待機することも可能です。複数の手順を含む管理操作も存在するため、DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMINプロシージャを数回実行します。次に例を示します。
BEGIN DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMIN ( gname => 'hr_repg', all_sites => TRUE); END; / */ PAUSE Press <RETURN> to continue when you have verified that there are no pending requests. /*
手順5 オフライン・インスタンシエーション・プロシージャを開始します。
*/
BEGIN DBMS_OFFLINE_OG.BEGIN_INSTANTIATION ( gname => 'hr_repg', new_site => 'orc4.example.com'); END; / /*
DBA_REPCATLOGビューが空になるまで待機します。このビューには、正常な実行後には消去される一時的な情報が含まれます。他のSQL*Plusセッションで次のSELECT文を実行して、DBA_REPCATLOGビューを監視します。
SELECT * FROM DBA_REPCATLOG WHERE GNAME = 'HR_REPG'; */ PAUSE Press <RETURN> to continue when DBA_REPCATLOG is empty. /*
手順6 各データベースにディレクトリ・オブジェクトを作成します。
この操作で使用する各データベースには、データ・ポンプ・ダンプ・ファイルを保存するためのディレクトリ・オブジェクトが必要です。また、エクスポートまたはインポートを実行するユーザーには、このディレクトリ・オブジェクトに対するREADおよびWRITE権限が必要です。この例では、マスター定義サイトでデータ・ポンプ・エクスポートを実行し、新しいマスター・サイトでデータ・ポンプ・インポートを実行します。
SQL文CREATE DIRECTORYを使用してディレクトリ・オブジェクトを作成できる管理ユーザーとしてSQL*Plusでデータベースに接続し、データ・ポンプのダンプ・ファイルおよびログ・ファイルを保存するためのディレクトリ・オブジェクトを作成します。次に例を示します。
*/ CONNECT system@orc1.example.com CREATE DIRECTORY DPUMP_DIR AS '/usr/dpump_dir'; CONNECT system@orc4.example.com CREATE DIRECTORY DPUMP_DIR AS '/usr/dpump_dir'; /*
操作に使用した両方のデータベースでこれらのアクションが完了していることを確認します。この例では、SYSTEMユーザーがディレクトリ・オブジェクトの作成およびすべてのエクスポートとインポートを実行します。ディレクトリ・オブジェクトを所有していないユーザーがエクスポートまたはインポートを実行する場合は、このユーザーにそのディレクトリ・オブジェクトに対するREADおよびWRITE権限を付与します。
手順7 個別の端末ウィンドウで、エクスポートを実行します。
コマンドラインで、エクスポートを実行します。この例では、SYSTEMユーザーとして接続します。データ・ポンプ・エクスポート・コマンドの例を次に示します。
expdp system SCHEMAS=hr DIRECTORY=DPUMP_DIR DUMPFILE=hr_schema.dmp
表のエクスポートでは、索引が自動的にエクスポートされます。
|
関連項目: データ・ポンプ・エクスポートの実行方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
*/ PAUSE Press <RETURN> to continue when the export is complete. /*
手順8 レプリケーション・アクティビティを部分的に再開します。
オフライン・インスタンシエーション・プロセスの完了には時間がかかるため、エクスポートの終了後、DBMS_OFFLINE_OGパッケージ内のRESUME_SUBSET_OF_MASTERSプロシージャを実行することにより、残りのマスター・サイト（新しいマスター・サイトは除きます）のレプリケーション・アクティビティを再開できます。 次の例では、新しいマスター・サイトのorc4.example.comを除くすべてのマスター・サイトでレプリケーション・アクティビティが再開されます。
*/ CONNECT repadmin@orc1.example.com BEGIN DBMS_OFFLINE_OG.RESUME_SUBSET_OF_MASTERS ( gname => 'hr_repg', new_site => 'orc4.example.com'); END; / /*
手順9 エクスポート・ダンプ・ファイルを新しいマスター・サイトに転送します。
新しいマスター・サイトへは、DBMS_FILE_TRANSFERパッケージ、FTPなどの方法により、エクスポート・ダンプ・ファイルが転送されます。次の手順で説明するインポートを実行する場合、新しいサイトで、このエクスポート・ダンプ・ファイルが必要となります。
*/ PAUSE Press <RETURN> to continue when the export dump file has been transfered to the new master site. /*
手順10 レプリケーション管理者として新しいマスター・サイトに接続します。
*/
CONNECT repadmin@orc4.example.com /*
手順11 新しいマスター・サイトを準備します。
エクスポート・ファイルのデータをインポートするには、新しいサイトを準備する必要があります。新しいマスター・サイトで次のプロシージャを必ず実行します。
*/ BEGIN DBMS_OFFLINE_OG.BEGIN_LOAD ( gname => 'hr_repg', new_site => 'orc4.example.com'); END; / /*
手順12 個別の端末ウィンドウで、エクスポート・ダンプ・ファイルからデータをインポートします。
コマンドラインで、インポートを実行します。この例では、SYSTEMユーザーとして接続します。インポート・コマンドの例を次に示します。
impdp system SCHEMAS=hr DIRECTORY=DPUMP_DIR DUMPFILE=hr_schema.dmp
表に基づいて作成された索引など、他のオブジェクトは自動的にインポートされます。
|
関連項目: データ・ポンプ・インポートの実行方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
*/ PAUSE Press <RETURN> to continue when the import is complete. /*
手順13 新しいマスター・サイトのロード・プロセスを完了します。
エクスポート・ファイルをインポートすれば、新しいマスター・サイトのオフライン・インスタンシエーション・プロセスを完了できます。DBMS_OFFLINE_OG.END_LOADプロシージャを実行して、通常のレプリケーション・アクティビティ用の新しいサイトを準備します。
*/ BEGIN DBMS_OFFLINE_OG.END_LOAD ( gname => 'hr_repg', new_site => 'orc4.example.com'); END; / /*
手順14 レプリケーション管理者としてマスター定義サイトに接続します。
*/
CONNECT repadmin@orc1.example.com /*
手順15 インスタンス化処理を完了します。
新しいマスター・サイトの手順を完了すれば、オフライン・インスタンシエーション・プロセスを完了できます。DBMS_OFFLINE_OGパッケージのEND_INSTANTIATIONプロシージャを実行することで、プロセスを完了して、すべてのマスター・サイトにおける通常のレプリケーション・アクティビティを再開します。マスター定義サイトで次のプロシージャを必ず実行します。
*/ BEGIN DBMS_OFFLINE_OG.END_INSTANTIATION ( gname => 'hr_repg', new_site => 'orc4.example.com'); END; / SET ECHO OFF SPOOL OFF /************************* END OF SCRIPT **********************************/
マスター・グループからマスター・サイトを削除する場合は、REMOVE_MASTER_DATABASESプロシージャを使用して1つ以上のマスター・サイトを削除します。
これらのアクションを実行するには、次の要件を満たす必要があります。
実行者: レプリケーション管理者
実行場所: マスター定義サイト
レプリケーションの状態: 静止中
次に示す手順に従って、マスター・サイトを削除します。
|
注意: このドキュメントをオンラインで参照している場合は、次の「BEGINNING OF SCRIPT」の行から「END OF SCRIPT」の行までのテキストをテキスト・エディタにコピーして編集し、使用している環境に適したスクリプトを作成します。 |
/************************* BEGINNING OF SCRIPT ******************************
手順1 レプリケーション管理者としてマスター定義サイトに接続します。
*/
SET ECHO ON SPOOL remove_masters.out CONNECT repadmin@orc1.example.com /*
手順2 マスター・グループのレプリケーションの状態が通常の場合は、静止中に変更してください。
*/
BEGIN DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY ( gname => 'hr_repg'); END; / /*
手順3 マスター・サイトを削除します。
*/
BEGIN DBMS_REPCAT.REMOVE_MASTER_DATABASES ( gname => 'hr_repg', master_list => 'orc4.example.com'); END; / /*
DBA_REPCATLOGビューが空になるまで待機します。他のSQL*Plusセッションで次のSELECT文を実行して、DBA_REPCATLOGビューを監視します。
SELECT * FROM DBA_REPCATLOG WHERE GNAME = 'HR_REPG'; */ PAUSE Press <RETURN> to continue when DBA_REPCATLOG is empty for the master group. /*
手順4 マスター・グループのマスター・アクティビティを再開します。
*/
BEGIN DBMS_REPCAT.RESUME_MASTER_ACTIVITY ( gname => 'hr_repg'); END; / SET ECHO OFF SPOOL OFF /************************* END OF SCRIPT **********************************/
マスター・グループから削除するサイトはアクセス可能である必要はありません。システムまたはネットワークの障害により、長期間、マスター・サイトが使用できない場合は、マスター・グループからマスター・サイトを削除できます。
しかし、サイトが使用不可能であるため、多くの場合、マスター・グループのレプリケーション・アクティビティを一時停止することはできません。DBMS_REPCATパッケージのREMOVE_MASTER_DATABASESプロシージャを使用すると、マスター・グループが静止中でない場合でも、マスター・グループからマスター・サイトを削除できます。
この場合の対処を次に示します。
遅延トランザクション・キューのクリーン
非一貫性データの削除
具体的には、マスター・グループのレプリケーション・アクティビティを次に一時停止するときは、使用不可能なマスター・サイトが削除された後すぐに、次の手順を完了する必要があります。
手順1 マスター・グループのレプリケーション・アクティビティを一時停止します。
詳細は、「SUSPEND_MASTER_ACTIVITYプロシージャ」を参照してください。
手順2 遅延トランザクションの接続先が削除済のマスター・サイトである場合は、そのマスター・サイトからすべての遅延トランザクションを削除します。
詳細は、「DELETE_TRANプロシージャ」を参照してください。
手順3 削除済のマスター・サイトから、すべての遅延トランザクションを削除します。
詳細は、「DELETE_TRANプロシージャ」を参照してください。
手順4 残りの各マスター・サイトで、すべてのエラー・トランザクションを再実行または削除します。
エラー・トランザクションの再実行の詳細は、「エラー・キューの管理」を、エラー・トランザクションの削除の詳細は、「DELETE_TRANプロシージャ」をそれぞれ参照してください。
手順5 遅延トランザクションまたはエラー・トランザクションが、現存の各マスターに存在しないことを確認してください。
現存のマスターから1つ以上の遅延トランザクションが削除できない場合は、マスター・サイトでDBMS_DEFER_SYS.DELETE_TRANプロシージャを実行します。
手順6 レプリケート・データがすべて一貫したデータであることを確認します。
違いの判別と訂正の詳細は、第16章「DBMS_RECTIFIER_DIFF」を参照してください。
手順7 マスター・グループのレプリケーション・アクティビティを再開します。
詳細は、「RESUME_MASTER_ACTIVITYプロシージャ」を参照してください。
|
注意: マスター・グループから使用不可能なマスター・サイトを削除した後は、削除したサイトからマスター・グループを削除してクリーン・アップを終了します。 |
DBMS_REPCATパッケージには、レプリケーションに関連する様々なデータ・ディクショナリ・ビュー内のコメント情報を更新できるプロシージャがいくつかあります。表7-1に、各ビューに対してコールするプロシージャの一覧を示します。
表7-1 アドバンスト・レプリケーション・ビュー内のコメントの更新
| ビュー | DBMS_REPCATプロシージャ | パラメータ情報の参照先 |
|---|---|---|
DBA_REPGROUP |
COMMENT_ON_REPGROUP( gname IN VARCHAR2, comment IN VARCHAR2) |
|
DBA_REPOBJECT |
COMMENT_ON_REPOBJECT( sname IN VARCHAR2, oname IN VARCHAR2, type IN VARCHAR2, comment IN VARCHAR2) |
|
DBA_REPSITES |
COMMENT_ON_REPSITES( gname IN VARCHAR2, master IN VARCHAR, comment IN VARCHAR2) |
|
DBA_REPCOLUMN_GROUP |
COMMENT_ON_COLUMN_GROUP( sname IN VARCHAR2, oname IN VARCHAR2, column_group IN VARCHAR2, comment IN VARCHAR2) |
|
DBA_REPPRIORITY_GROUP |
COMMENT_ON_PRIORITY_GROUP( gname IN VARCHAR2, pgroup IN VARCHAR2) comment IN VARCHAR2) |
|
DBA_REPPRIORITY_GROUP (site priority group) |
COMMENT_ON_SITE_PRIORITY( gname IN VARCHAR2, name IN VARCHAR2, comment IN VARCHAR2) |
|
DBA_REPRESOLUTION (uniqueness conflicts) |
COMMENT_ON_UNIQUE_RESOLUTION( sname IN VARCHAR2, oname IN VARCHAR2, constraint_name IN VARCHAR2, sequence_no IN NUMBER, comment IN VARCHAR2) |
|
DBA_REPRESOLUTION (update conflicts) |
COMMENT_ON_UPDATE_RESOLUTION( sname IN VARCHAR2, oname IN VARCHAR2, column_group IN VARCHAR2, sequence_no IN NUMBER, comment IN VARCHAR2) |
|
DBA_REPRESOLUTION (delete conflicts) |
COMMENT_ON_DELETE_RESOLUTION( sname IN VARCHAR2, oname IN VARCHAR2, sequence_no IN NUMBER, comment IN VARCHAR2) |
|
プロシージャ・レプリケーションは、レプリケーション環境内で逐次実行され、多くの行を操作する大規模なバッチ指向の操作に有効です。
これを応用したふさわしい例がパージ操作です。これは、アーカイブ操作とも呼ばれ、空き時間に不定期に実行（たとえば、四半期に1回）して、旧データまたはオンライン・データベースから論理的に削除されたデータを削除します。プロシージャ・レプリケーションを使用して削除された行をパージする例は、『Oracle Databaseアドバンスト・レプリケーション』の第5章「競合解消の概念およびアーキテクチャ」の「削除の競合解消方法」で説明しています。
レプリケート・プロシージャのパラメータはすべて、INパラメータです。OUTおよびIN/OUTモードはサポートされていません。これらのパラメータでは次のデータ型がサポートされます。
VARCHAR2
NVARCHAR2
NUMBER
DATE
RAW
ROWID
CHAR
NCHAR
バイナリ・ラージ・オブジェクト（Binary Large Object: BLOB ） （BLOB）
キャラクタ・ラージ・オブジェクト（Character Large Object: CLOB ） （CLOB）
各国語キャラクタ・ラージ・オブジェクト（National Character Large Object: NCLOB）（NCLOB）
ユーザー定義データ型
Oracleでは、レプリケート・プロシージャが生成した更新の競合が検出されません。レプリケート・プロシージャ自らが、競合の検出と解消を行う必要があります。独自の競合解消ルーチンの表現は困難なため、競合の可能性を単純に回避することが最良です。
次のガイドラインに従うことで、プロシージャ・レプリケーションを使用するすべてのサイトで、表の一貫性を維持することができます。
遅延プロシージャ本体の行レベルのレプリケーションを無効化する必要があります。詳細は、「データ・ディクショナリ・ビュー内のコメント・フィールドの更新」を参照してください。
「トランザクションのシリアル化」で説明するように、一度に実行できるレプリケート・プロシージャは1つのみです。
遅延トランザクションの伝播は逐次行います。スケジュール・リンクのガイドラインの詳細は、『Oracle Databaseアドバンスト・レプリケーション』を参照してください。
レプリケート・プロシージャはパッケージ化が必要です。ただし、パッケージにファンクションを含めることはできません。スタンドアロン遅延プロシージャおよび、スタンドアロンまたはパッケージ化遅延ファンクションは現在サポートされていません。
遅延プロシージャは所有データをローカルでのみ参照します。
このプロシージャは、ローカルで生成されたフィールド、値または環境に依存するSQLファンクションを使用しません。たとえば、このプロシージャはSYSDATEをコールしません。
データの所有権は静的に分割されます。すなわち、行の所有権はサイト間で変更されません。
マスター・サイトに複数のマスター・グループを所有していて、1つ以上のマスター・グループが静止中の場合は、マスター・サイトのマスター・グループに対するプロシージャ・レプリケーションは実行できません。あるマスター・グループのプロシージャは他のマスター・グループのオブジェクトを更新できるため、この制限が規定されています。マスター・サイトのすべてのマスター・グループがデータを正常にレプリケートした場合にのみ、プロシージャ・レプリケーションを実行できます（すなわち、静止中のマスター・グループがない場合）。
たとえば、マスター・サイトdb1のマスター・グループAにsal_raiseという名前のプロシージャを所有している場合で、マスター・サイトdb1のマスター・グループBが静止中の場合は、マスター・グループAがレプリケーションを正常に終了しても、sal_raiseプロシージャを実行できません。
プロシージャ・レプリケーションを使用する場合は、プロシージャ・コールのみがマスター・レプリケーション・サイトに伝播されます。プロシージャ・コールは、マテリアライズド・ビュー・サイトに伝播されません。しかし、マテリアライズド・ビュー・サイトではプロシージャ・レプリケーションを開始できます。この場合、プロシージャ・コールはレプリケーション環境のすべてのマスター・サイトに伝播されますが、マテリアライズド・ビュー・サイトには伝播されません。他のマテリアライズド・ビュー・サイトは、マテリアライズド・ビューをリフレッシュして、マスター・サイトの変更を取り込む必要があります。
たとえば、レプリケーション環境にmsite1およびmsite2という名前の2つのマスター・サイトとmview1およびmview2という名前の2つのマテリアライズド・ビュー・サイトが含まれているものと仮定します。mview1でプロシージャ・レプリケーションが開始されると、mview1でこのプロシージャが実行されます。また、プロシージャ・コールが2つのマスター・サイト、msite1およびmsite2に伝播され、プロシージャが実行されます。しかし、プロシージャ・コールはmview2に伝播されません。このため、次のリフレッシュの間に、mview2はマスター・サイトのプロシージャが行ったすべての変更をプルします。
プロシージャ・レプリケーションを使用する場合、プロシージャが参照するユーザー定義型およびユーザー定義のオブジェクトは次の条件を満たす必要があります。
オブジェクト型に関しては、すべてのレプリケーション・サイトは、オブジェクト型の属性の順序に従う必要があります。オブジェクト型を作成する場合は、属性の順序を設定します。次のオブジェクト型を考慮します。
CREATE TYPE cust_address_typ AS OBJECT
(street_address VARCHAR2(40),
postal_code VARCHAR2(10),
city VARCHAR2(30),
state_province VARCHAR2(10),
country_id CHAR(2));
/
すべてのレプリケーション・サイトで、street_addressは1番目の属性、postal_codeは2番目の属性、cityは3番目の属性である必要があります。
Oracleオブジェクトに関しては、すべてのレプリケーション・サイトは同一のオブジェクト識別子（OID）、スキーマ所有者および各レプリケート・オブジェクト型のタイプ名を所有する必要があります。
分散スキーマ管理を常に使用して、オブジェクト型、列オブジェクトを持つ表およびオブジェクト表などのレプリケート・オブジェクトを作成または修正することで、これらの条件を満たすことができます。オブジェクト型の作成や修正に分散スキーマ管理を使用しない場合は、レプリケーション・エラーが発生することがあります。
|
関連項目: レプリケーション・サイトにおける型の取決めの詳細は、『Oracle Databaseアドバンスト・レプリケーション』を参照してください。 |
逐次実行ではデータの一貫性が維持できます。レプリケーション機能では、一度に1つのレプリケート・トランザクションを伝播および実行します。たとえば、ローカル・データの更新を行う2つのプロシージャ、AとBがあるとします。この条件で次のアクションを順番に実行するとします。
AとBをローカルで実行します。
別のノード上にあるAとBの他のレプリカの実行要求をキューします。
コミットします。
別のノードにあるAとBのレプリカは、起点となるサイトでコミットされた順番通りに、逐次実行されます。AとBが起点となるサイトで同時に実行されると、ローカルとリモートとでは結果が異なることになります。起点となるサイトでAとBを逐次実行した場合は、すべてのサイトで同一の結果が得られます。トランザクションを逐次伝播することで、AとBはターゲット・サイトで必ず順番に実行されます。
一方、シリアル化を確実に行うために、プロシージャへの書込みは慎重に行います。 たとえば、パラレル伝播を使用している場合は、起点となるサイトおよびターゲット・サイトにおけるシリアル化を確実に行うための問合せには、SELECT... FOR UPDATEを使用します。
プロシージャの開始時には行レベルのレプリケーション・サポートを無効化し、終了時にはサポートを再び有効化する必要があります。この操作により、プロシージャを実行したことで発生する更新が他のサイトに伝播されることがなくなります。行レベルのレプリケーションの有効化および無効化は、次のプロシージャをコールすることで行います。
DBMS_REPUTIL.REPLICATION_ON
DBMS_REPUTIL.REPLICATION_OFF
レプリケート・パッケージのレプリケーション・サポートを生成すると、Oracleでは、レプリケーション・プロパゲータのスキーマにWrapperパッケージが作成されます。
|
注意: 現行のプロパゲータを登録解除すると、プロパゲータのスキーマにある既存の生成済ラッパーのすべてが削除されます。新しいプロパゲータを登録した後は、ラップされたストアド・プロシージャのレプリケーション・サポートを再生成します。 |
Wrapperパッケージの名前はオリジナル・パッケージと同じですが、このプロシージャのレプリケーション・サポートを生成したときに指定した文字列の接頭辞が付けられています。接頭辞を指定しないと、Oracleでは、デフォルトの接頭辞、defer_が使用されます。ラッパー・プロシージャは、call_localおよびcall_remoteの2つの追加パラメータ以外にオリジナルと同じパラメータを所有しています。これら2つのCHARパラメータで、プロシージャが実行されている場所を特定します。call_localが'Y'の場合は、ローカルでプロシージャが実行されます。call_remoteが'Y'の場合は、レプリケーション環境のすべてのマスター・サイトでプロシージャが実行されます。
同期式で変更を伝播する場合、または非同期式で変更を伝播する場合に、これらのプロシージャに対するコールが遅延トランザクション・キューに追加された場合は、リモート・プロシージャが直接コールされます。デフォルトでは、call_localは'N'で、call_remoteは'Y'です。
Oracleでは、パッケージのレプリケーション・サポートが2つのフェーズで生成されます。フェーズ1では、全サイトのパッケージ仕様部が作成されます。フェーズ2では、全サイトのパッケージ本体が生成されます。同期レプリケーションをサポートするには、これら2つのフェーズが必要です。
たとえば、1つの引数emailを取得するプロシージャnew_deptを含むemp_mgmtパッケージの作成を想定します。このパッケージをシステム内のすべてのマスター・サイトにレプリケートする場合、Oracle Enterprise ManagerのAdvanced Replicationインタフェースを使用してパッケージをマスター・グループに追加し、オブジェクトのレプリケーション・サポートを生成します。これらの手順を完了すれば、アプリケーションは、次に示すレプリケート・パッケージのプロシージャをコールできます。
BEGIN
defer_emp_mgmt.new_dept( email => 'jones',
call_local => 'Y',
call_remote => 'Y');
END;
/
|
関連項目: Oracle Enterprise ManagerのAdvanced Replicationインタフェースを使用したマスター・グループおよびレプリケート・オブジェクトの管理の詳細は、Advanced Replicationインタフェースのオンライン・ヘルプを参照してください。 |
図7-4に示すように、ラッパー・プロシージャの論理により、ローカル・サイトおよびすべてのリモート・サイトでのプロシージャのコールが確実に行えます。また、ラッパー・プロシージャの論理により、レプリケート・プロシージャがリモート・サイトでコールされ、call_remoteがFALSEの場合、プロシージャがさらに伝播されることも回避できます。
データ所有権の静的分割を伴う複合レプリケーション環境で操作を行っている場合（すなわち、行レベルのレプリケーションを妨げない場合）は、行レベル・レプリケーションおよびプロシージャ・レプリケーションの両方が同じ非同期キューを使用するため、Advanced Replicationでは、リモート・ノードでの操作順序が維持されます。
