| >> はじめに |
前回は、非同期の状態を作り出して、エラーの状況を確認するところまでご紹介しました。今回は、そこで発生したエラーの状況を解消していく方法について、ご案内したいと思います。
| >> エラーの原因を特定するには? |
論理レプリケーションの特徴として、ソース側で発生したトランザクションの内容を、ターゲットへ転送して処理するというのがありますが、そのターゲット側で反映する際に、何が原因でエラーとなったか確認するために、<SID名_errlog.sql>というファイルをlogディレクトリ以下で確認することができます。
|
このログの中には、ソース側で発生したトランザクションの詳細として、REDOログやオリジナルのROWIDに関する情報、そしてターゲット側で実行しようとしたSQL文と、エラーの内容が記載されています。
| >> エラー内容を修正するには? |
<SID名_errlog.sql>というファイル名には、理論的にはエラーとなったSQL文が格納されていきますので、それらをすべてターゲット側に再適用できればエラーは解消するはずです。しかし、そもそもその適用でエラーが出てしまっています。
今回のように、自分で非同期の状態を作り出したのであれば、例えばエラーとなったSQL文から、BALANCE列のチェックを外すなどすれば、更新できることは簡単に想像できますが、一般的に非同期状態は予期しない原因によって引き起こされるため、修正するのが難しい状況も考えられます。
そんなとき、SharePlexでは簡単に同期状態を修復することが可能です！
| >> SharePlexの比較＆修復機能がすごい訳 |
■完全に無料で使える
SharePlexと同種の考え方を持つ論理レプリケーションソフトは、いくつかの会社からリリースされていますが、比較機能が標準搭載されている製品はSharePlexだけです。論理レプリケーションの場合、データが同期されていない可能性というのを排除するのが難しいのですが、そんなときにも比較機能が搭載されていることで、健全性を確認することが容易になっています。
■1対1のノードで動作し、第3のサーバが必要ない
データの比較を行う際に、SharePlexは、レプリケーションを実施しているサーバ間だけで、動作します。一部の製品で比較機能を別製品としてリリースしているところでは、別途有償の第3の比較専用サーバを構築しなければならないものもあります。
■チェックだけでなく、修復も可能
データを比較して、問題が見つかった際に、それを発見して終わりということにはなりません。問題を修復して、そこから通常通りにレプリケーションを再開する必要があります。
SharePlexでは、通常のレプリケーション動作と、比較および修復機能が完全に統合されており、すべてSharePlexの動作の管理下でシームレスに動作し、整合性のあるデータによって非同期状態の解消を実現します。
■もちろん日本語文字列対応
テーブルに格納されたデータ自体はもちろんのこと、日本の環境ではテーブル名等に日本語文字列が使用されることもあります。SharePlexでは、これらの日本語文字列に対して、正しくレプリケーションおよび比較＆修復機能が動作します。
| >> 実際に非同期状態を確認および修復してみる |
使い方自体は、第10回の講座でも少しご紹介していて、それほど大きな違いはありません。
ソース側のsp_ctrlから、compareコマンドを使用して、今回の場合test.salaryテーブルを指定して実行することになります。compare statusで状況を確認すると、最終的にOut Syncの状態が確認できます。
|
ターゲット側のVARDIR/log以下のcompareによって生成されたsqlスクリプトを確認すると、ターゲット側でこれを実行することで非同期状態を修正することが可能です。
|
もしくは、repair機能を使用して修復するのもよいでしょう。
|
どちらの方法でも最終的に、ソースとターゲットで値が同じになっていることが確認できます。より慎重に確認したいという場合には、repair後にもう一度compareを実行することも可能です。
|
| >> まとめ |
以上、比較と修復機能の特徴と簡単な使い方をご紹介しました。
次回は、SharePlexの監視をGUIでわかりやすくするSharePlex Managerについて取り上げます。