>> はじめに

今月は、SharePlexが誇るレプリケーションの高速化アーキテクチャについて第2弾です。

>> トランザクションが多い場合の対策

一日当たりどのくらいのオンラインREDOログが生成されている環境なら、SharePlexを使用することができるか?というご質問をいただくことがありますが、下記のような様々な要因によって状況が異なるため、一概に何とも言えません。

  • システムの性能
  • ストレージ構成
  • トランザクションに占めるCaptureすべき内容の割合
  • 対象テーブルの割合
  • レプリケーションの用途
  • その他

事前のアセスメントで、ある程度の検討をつけ、あとは本番環境に近い状態でのテスト等を通して、パフォーマンスについての見極めをしていきます。

論理レプリケーションのアーキテクチャーを考えると、ソース側のCapture処理の部分の負荷もありますが、この部分は基本的に運用環境のOracleへのアクセスはあまり行われず、ログファイルに対するI/Oに対する考慮が必要です。しかし、ターゲット側は、PostプロセスがPostキューの内容をSQL文に変換して、OracleインスタンスにOCI (Oracle Call Interface) を使用して反映を行います。そのため、このPostの部分がボトルネックになることもあります。

>> Postのマルチプロセス化

Post側のボトルネックを解消するには、Postのプロセスをマルチプロセス化することがとても有効です。この内容は、SharePlexの仕組みをご紹介する際に、こちらの講座で少しご説明させていただきました。

今回は、このマルチプロセス化について、設定方法を見ていきましょう。

>> named post queueとは?

Postプロセスが特定のトランザクションを処理している際に、その処理に時間がかかってpost queueにある他のトランザクションに対して、パフォーマンス上の影響を与えてしまうことがあります。

  • LOB列を持つ設定内のオブジェクト
  • 大規模なトランザクションを行うオブジェクト
  • 隔離する操作を含むオブジェクト

このような場合に、対象のオブジェクト毎にキューファイルの格納先を分けて、その各キューファイル毎に個別にPostプロセスを稼働させることが可能です。何も名前を設定しないデフォルトのpost queueに対して、個別に名前を付けて分けたものをnamed post queueと呼びます。今回は、標準で用意されているテーブルを使用して、以下のような組み合わせを考えてみました。

  • 標準のpost queueを使用して複製する(既に過去の講座で設定済)
    • 転送元: SYSTEM1上のsplex.demo_src
    • 転送先: SYSTEM2上のsplex.demo_dest
  • testという名前のpost queueを使用して複製する(新しい設定)
    • 転送元: SYSTEM1上のsplex.demo_dest
    • 転送先: SYSTEM2上のsplex.demo_src

一見難しいように思われるpostプロセスを分けるという設定も、SharePlexでは定義ファイル1つで行うことができます。

>> named post queueの設定をしよう

まず、最初のシステム側で (つまりactivate configをしたsp_ctrlから)、現在の状態を確認しておきます。

statusコマンドを実行して現在起動しているプロセスがcopとcmd & Ctrlだけであることを確認しておきます (初期のインストール状態と一緒です)。


sp_ctrl (rhel5sposrc1:2100)> status Brief Status for rhel5sposrc1 Process State PID Running Since --------------- ------------------------------ -------- -------------------- Cop Running 4482 27-Sep-12 13:10:22 Cmd & Ctrl Running 4545 27-Sep-12 13:11:11 There are no active configuration files

もし、設定ファイルがactivateされてソース側でプロセスが他にも起動している場合には、deactivate configを実行すると、上記の状態になります。


sp_ctrl (rhel5sposrc1:2100)> deactivate config ORA_config

次に、デフォルトでテンプレートとして用意されているORA_configファイルを使用する場合には、それをeditします。


sp_ctrl (rhel5sposrc1:2100)> edit config ORA_config

以前からの講座に従って進めている場合には、以下のような設定がなされているはずです (ホスト名やSID等は異なると思いますが)。


datasource:o.src1 #source tables target tables routing map splex.demo_src splex.demo_dest rhel5spotrg1@o.trg1

この状態で、既にデフォルトのpost queueを使用して、「SYSTEM1上のsplex.demo_srcをSYSTEM2上のsplex.demo_destへ標準のpost queueを使用して複製する。」という目的のための設定はなされています。そのため、2番目のnamed post queueのための設定だけ追記します。

この部分の書式は以下のようになっています。ターゲットのホスト名の後にコロンを付けてqueue名を記述するだけです。このqueue名を記述しない場合には、デフォルトのpost queueという形になるのです。

<ターゲットホスト名>:<queue名>@o.<ターゲットSID>

そこで、要件に従って設定すると、次のようになります。


datasource:o.src1 #source tables target tables routing map splex.demo_src splex.demo_dest rhel5spotrg1@o.trg1 splex.demo_dest splex.demo_src rhel5spotrg1:test@o.trg1

この設定を実際にソース側でactivateをして、statusを確認してみても、状態に変化はありません。これは、ソース側には特に影響しないためです。


sp_ctrl (rhel5sposrc1:2100)> activate config ORA_config sp_ctrl (rhel5sposrc1:2100)> status Brief Status for rhel5sposrc1 Process State PID Running Since --------------- ------------------------------ -------- -------------------- Cop Running 4482 27-Sep-12 13:10:22 Cmd & Ctrl Running 4545 27-Sep-12 13:11:11 Capture Running 5513 27-Sep-12 14:01:15 Read Running 5514 27-Sep-12 14:01:15 Export Running 5556 27-Sep-12 14:01:19 System is used as a source machine There is 1 active configuration file

ターゲット側でstatusを確認してみると、post queueを分けたことで、postプロセスが2つ起動するため、その状態を確認することが可能です。


sp_ctrl (rhel5spotrg1:2100)> status Brief Status for rhel5spotrg1 Process State PID Running Since --------------- ------------------------------ -------- -------------------- Cop Running 4550 27-Sep-12 13:11:04 Cmd & Ctrl Running 20714 27-Sep-12 14:10:33 Import Running 14397 27-Sep-12 14:11:56 MTPost Running 14398 27-Sep-12 14:11:56 MTPost Running 14399 27-Sep-12 14:11:56 There are no active configuration files

また、queueの状態を確認するqstatusコマンドを実行すると、通常は1つのqueueがName: testというように、名前を付けたqueue nameを確認することができました。


sp_ctrl (rhel5spotrg1:2100)> qstatus Queues Statistics for rhel5spotrg1 Name: rhel5sposrc1 (o.src1-o.trg1) (MTPost queue) Number of messages: 0 (Age 0 min; Size 1 mb) Backlog (messages): 0 (Age 0 min) Name: test (o.src1-o.trg1) (MTPost queue) Number of messages: 0 (Age 0 min; Size 1 mb) Backlog (messages): 0 (Age 0 min)

ためしに、それぞれのテーブルに対してトランザクションを発生させてみます。


SQL> insert into demo_src values ('Default','Queue','12345'); 1行が作成されました。 SQL> insert into demo_dest values ('Named','test','67890'); 1行が作成されました。 SQL> commit; コミットが完了しました。

すると、ターゲット側のqstatusが両方とも更新されていることがわかります。ちなみに、全部で3件だったのが、ターゲット側で合計4件になっているのはおかしいな?と思われた方もいるかもしれません。これは、postプロセスを分けることで、処理が分散されますので、commitも分散して実行する必要があるからです。このような内部の細かい処理はすべてSharePlexが管理しています。


sp_ctrl (rhel5spotrg1:2100)> qstatus Queues Statistics for rhel5spotrg1 Name: rhel5sposrc1 (o.src1-o.trg1) (MTPost queue) Number of messages: 2 (Age 0 min; Size 1 mb) Backlog (messages): 0 (Age 0 min) Name: test (o.src1-o.trg1) (MTPost queue) Number of messages: 2 (Age 0 min; Size 1 mb) Backlog (messages): 0 (Age 0 min)

 

>> まとめ

Postの部分は比較的、ターゲット側のOracleの状態にもよりますが、遅延が起きやすい部分ですが、デフォルトの動作であるマルチスレッドと合わせて、このようなマルチPostの仕組みを使用すると、更なる高速化を行うことが可能です。

次回も高速化するアーキテクチャーの続編をご紹介します。