Syniti DRではOracleデータベース上の変更を追跡するため複数のアプローチを提供しています。今回はこれらのアプローチに関して、それぞれを紹介していきます。
ログリーダー方式
もっとも古くから使用されている方式であり、構成としてもシンプルです。ソースとなるOracleデータベースサーバ上のログマイナーに対してSyniti DRのレプリケーションエージェントから直接クエリを実行し、REDOやアーカイブログ上のトランザクションログを参照、それをターゲットデータベースへレプリケーションします。
青色の矢印は、ソースから読み取り/送信するデータを表します。
灰色の矢印は、アプリケーションからターゲットに書き込むデータを表します。
シンプルであるため、構成しやすいというメリットがありますが、レプリケーションジョブまたはグループ単位でログマイナーにリクエストを行うため、対象のテーブル数が多い環境などでは、ログマイナーへのリクエストが過多となり、ソースデータベースからの変更トランザクション読み取りでボトルネックとなるケースもあります。
ログサーバエージェント方式
WindowsサービスとしてSyniti Data Replicationサーバ上で実行されるログサーバエージェントを使用して、Oracleログマイナーへクエリを実行、変更されたデータをSyniti Data Replicationサーバ上のバイナリログに記録します。それをレプリケーションエージェントが参照してターゲットデータベースへレプリケーションすることで、大量のデータを扱う際のパフォーマンスを向上させます。このオプションは、Oracleデータベースバージョン11以降でサポートされています。
ログリーダーでネックとなっていた、ログマイナーへのリクエストをログサーバエージェントに一本化し、調整することで、変更追跡を最適化した方式です。
ただし、Syniti DRサーバのローカルでバイナリログを保持しますので、その分の容量が必要になるといったデメリットもあります。また、バイナリログはレプリケーションエージェントから繰り返し参照されることになりますので、高速なSSDなどのストレージに配置いただく構成が推奨されます。
ログサーバエージェント+リモートログサーバ方式
リモートログサーバ(RLS)は、Oracleデータベースが存在するシステムにインストールし、ログファイルを直接読み取るためのJavaアプリケーションです。
Syniti DR ログサーバエージェントからの要求に応じて、RLSはredoおよびアーカイブログファイルから変更レコードを読み取り、それらをログサーバエージェントに返します。取得された情報はすべて返され、リモートログサーバ側に情報が保存されることはありません。RLSは、TCP/IPポートをリッスンし、接続を受け付けます。ログサーバエージェントはこのポートに接続し、RLSに対して変更されたレコードの読み取りを要求します。
ログマイナーの代わりにリモートログサーバがREDOまたはアーカイブログを直接参照するため、ログマイナーの利用を避けたい場合などに利用いただく方式です。
もっとも新しく追加されたものであり、リモートログサーバの構成は手動でOracleデータベースサーバ上にJavaアプリケーションを配置する必要があります。
構成を検討される際には、クライムまでお問い合わせください。
トリガー方式
Oracleデータベース上にSyniti DRから構成したトリガーを使用して、変更をログテーブルに記録します。レプリケーションエージェントはこのログテーブルを参照して、ターゲットデータベースへレプリケーションします。
データベーストリガーは、データベーステーブル上の特定のイベントに応答して自動的に実行されるコードです。トリガーベースのレプリケーション(ミラーリングまたはシンクロナイゼーション)を定義するには、レプリケーションのためにテーブルの変更を記録するトリガーを作成できるように、ソースおよび/またはターゲット接続ウィザードに情報を提供する必要があります。
レプリケーションに関与する各テーブルについて、Syniti DRはソーステーブルに3つのトリガーを作成し、レコードに特定のイベントが発生したときに起動します:
- テーブルに新しいレコードが挿入されるときに起動するINSERTトリガー
- レコードが変更されるときに起動するUPDATEトリガー
- レコードが削除されるときに起動するDELETEトリガー
OracleデータベースネイティブのREDOまたはアーカイブログにアクセスできなくても変更追跡が行えるため、権限が限られているような一部のクラウドデータベースでも利用できるアプローチです。
ただし、ソースDB上にトリガーが作成され対象テーブルへの変更があるたびにログテーブルに記録されますので、その分のリソース(トリガー負荷と容量)をソースDBサーバで確保いただく必要があります。
まとめ
このようなアプローチを用いてOracleプラガブルデータベース(PDB)や、マテリアライズドビューなど、Oracle特有の環境のレプリケーションも対応しています。Oracle RACでクラスタを構成している環境や、Oracle Exadataなどの大規模な環境でもSyniti DRであればデータ連携を実現することが可能です。
ご興味ありましたら是非、弊社までお問い合わせください。
また、詳細なセットアップガイドは弊社ドキュメントサイトをご参照ください。
関連したトピックス
- サプリメンタルロギング設定の影響に関して[Syniti DR]
- Oracle Exadataのパフォーマンス Part3: 更なるモニターとクエリーによるチューニング
- レプリケーション対象テーブル構成変更後のSyniti Data Replication (旧DBMoto) マッピング対応について
- 初期同期(リフレッシュ)がより便利に! ステージングリフレッシュ機能
- OracleでのNOLOGGING運用によるDBMotoレプリケーションへの影響
- DBMotoからSyniti Data Replicationへのアップグレード方法
- Oracle Exadataのパフォーマンス Part2: DBRM/IORM と Smart Flash Cache
- [ DB2 Connectivity ] 開発キット C# Toolkit で出来ること :プログラミング無しで検証可能
- Syniti Data Replication (旧DBMoto)でのスクリプトの書き方④:レプリケーションスクリプト
- レプリケーションの設定から処理までの流れ【リアルタイムレプリケーションツールDBMoto】