前回までにインストールと、SharePlexの動作に必要なOracleへのアカウント等の設定を行いました。 レプリケーションの実際の動作まで、OracleとSharePlexの設定があと少し必要になりますので、それらを順にご紹介したいと思います。
SharePlexの動作に、アーカイブログモードの設定は必須ではありませんが、オンラインREDOだけで運用すると、キャプチャーすべき内容が循環して既に上書きされてしまっているような事態が発生し、動作を継続することができなくなります。そのため、アーカイブログモードの設定は、ほぼ必須要件と考えてください。 ここでは、アーカイブログモードに関する詳しい設定方法はご紹介しませんが、必要な方はバックアップの講座を参考にしてみてください。 念のため現在のログ・モードがアーカイブ・モードであることを確認しておきます。
第2回の講座で、SharePlexの簡単な動作の仕組みをご紹介しましたが、SharePlexはOracleが生成するオンラインREDO等のログから、レプリケーションに必要な内容を読み取ります。 しかしながら、デフォルトではレプリケーションするのに必要なすべての情報が、ログ内に記録されていません。レプリケーションを行う際には、SQL文として他のデータベースに適用すべき内容をログから取得しますが、他のデータベースでは意味を持たないROWID等で記録されているためです。それを最低限、最少サプリメンタル・ロギングという設定を行い、SharePlexで動作できる状態にする必要があります。 なお、この設定を行っていない場合は、SharePlexの設定を有効化しようとしても、メッセージが表示され中断されます。
また、サプリメンタル・ロギングにはいくつかのレベルがあり、レプリケーションの対象に応じた設定が必要となります。今回はまず必須要件である最少サプリメンタル・ロギングの設定のみを行ってみます。 まず、この最少サプリメンタル・ロギングの設定の状態を確認するために、v$databaseのSUPPLEMENTAL_LOG_DATA_MIN列を確認します。
このようにデフォルトは、NOに設定されています。以下のコマンドにより、最少サプリメンタル・ロギングの設定を行い、設定値を確認します。
本来は、オプションの設定でPRIMARY KEY, UNIQUE KEY, FOREIGN KEY, ALLなど様々なレベルを設定ができ、レプリケーションの要件に合わせて設定を行います。詳細についてはマニュアル等でご確認ください。
レプリケーションの設定は、ソース側とターゲット側でそれぞれ、メインのsp_copが起動している必要があるので、念のため確認しておきます。 まず、ソース側でsp_ctrlのコンソールよりstatusにて確認します。
次に、ターゲット側でsp_ctrlのコンソールよりstatusにて確認します。
両側でプロセス (Cop) が正常に稼働していれば問題ありません。
SharePlexの設定ファイルは、1つのファイルに集約されており、とても簡単に設定することが可能です。また、デフォルトでサンプル・ファイルが用意されているため、それを活用することで、初期の動作テストに使用することも可能です。 すべての設定ファイルは、vardir/config以下に格納されている必要があります。これらのファイルは、OS上のコマンド等で編集することもできますが、sp_ctrlの管理ツールから抜けずに行うこともできますので、その方法をご紹介しましょう。 まず、list configコマンドにより、vardir/config以下の設定ファイルとその概要を確認することができます。以下の例では、デフォルトで用意されているORA_configという設定ファイルが表示されています。
この設定ファイルをedit configコマンドで指定して編集します。
これで、viエディタにより中身を編集することが可能です。ソース側とターゲット側のOracleのSIDおよびターゲット側のホスト名を除いて、デフォルトの設定ファイルは、既にSharePlexがデフォルトで用意したSPLEXユーザのdemo_srcテーブルからdemo_destテーブルへのレプリケーションが設定された状態になっています。
そのため、まず1行目の"SOURCE_SID"の部分をソース側のSIDに置き換え、次に最終行に記載されている"target_sid"をターゲット側のSIDに置き換えます。また、"target_system"にはターゲット側のホスト名(ソース側から名前解決されている場合)もしくはIPアドレスの指定を行います。ソース側のSIDを"src1"とし、ターゲット側ホスト名を"rhel5spotrg1"およびSIDを"trg1"とした場合の設定例は以下の通りです。
すべての条件が整って、正しく設定が行われている場合には、最後に設定の有効化 (アクティベイト) を行います。activateコマンドにより有効化して少し時間た立つと、statusコマンドによりレプリケーションに必要なプロセスが起動されていることが確認できます。
また、ターゲット側でも同様に今度はキューの内容をImportにより受け取り、それをSQLとして処理するPostがプロセスとして起動しているのがstatusコマンドにより確認できます。
設定の有効化により、レプリケーションが実行できるようになっています。なお、SharePlexは本来、変更データのみを複製するソリューションであるため、初期同期が必要なのですが、テストのテーブルは空の状態でテーブル構造が作成されただけであるため、初期同期は必要ありません。 念のため、ソース側(demo_src)とターゲット側(demo_dest)のそれぞれのテーブルの内容を確認しておきます。
次に、ソース側のdemo_srcテーブルにデータを追加し、コミットします。
このトランザクションの内容がターゲット側にレプリケーションされているはずですので、内容を確認します。これにより、テーブル名を変更してのレプリケーションが正常に行われていることが確認できました。
以上、最低限のレプリケーションが行えるまでのインストールから実際の複製までの流れについて、ひと通りご覧いただきました。動作させるだけなら、思ったより簡単!と思っていただけたと思います。 なお、上記手順は、あくまで評価用に動作させるための流れになっており、詳細については触れられていません。実際の運用の場合は必ずマニュアル等をご確認ください。 次回からは、SharePlexを使用した動作について、さらに詳細をご説明していきます。 |
||||||||||||||||||||||||||||||||||||||||||||||||
- Products
- Solutions
- View all Solutions
- Industries
- Platforms
- Cloud Management
- Data Protection
- Database Management
- GDPR Compliance
- Identity & Access Management
- Microsoft Platform Management
- Performance Monitoring
- Unified Endpoint Management
- Resources
- Trials
- Services
- Support
- Partners
- Blogs
- Forums