SharePlex 11.4 - 管理者ガイド

ソースデータとターゲットデータについて

SharePlexのレプリケーションではソースとターゲットの概念を使用します。

• ソースデータは、複製されるプライマリデータです。このデータはソースシステム上にあります。
• ターゲットデータは、プライマリデータのフルコピーまたはサブセットコピーです。このデータはターゲットシステム上にあります。

レプリケーションの目的は、ソースデータとターゲットデータの同期（in-sync）を保つことです。これは、ソースデータの状態が、実行されたトランスフォーメーションやレプリケーションストリーム内のタイムラグを調整しながら、ターゲットデータに正確に反映されることを意味します。

ターゲットデータは、SharePlexがサポートする任意のターゲットタイプにすることができます。データベース内のテーブル、メッセージングキューやトピック内のメッセージ、他のソフトウェアプログラムによって消費されるファイル内のXMLまたはSQLレコードなどがその例です。

SharePlexのアーキテクチャにつて

SharePlexのアーキテクチャについて

このトピックでは、SharePlexのデフォルト設定について説明します。SharePlexの設定は、データストリームの分離やパフォーマンスの向上のためにキューやプロセスを追加するカスタマイズが可能です。

SharePlexディレクトリ

SharePlexでは2つの主要なディレクトリを使用します。

製品ディレクトリ: これはSharePlexのインストールディレクトリで、SharePlexのプログラムとライブラリが格納されています。

変数データディレクトリ: これはSharePlexの作業ディレクトリで、現在のレプリケーション環境を構成するキューファイル、ログファイル、その他のコンポーネントが格納されています。

注意: 多くの場合、これらのディレクトリは、それぞれproductdirおよびvardirと呼ばれます。

SharePlexによってインストールされたファイルやディレクトリを削除、名前変更、または編集しないでください。ディレクトリの中には、レプリケーションに不可欠な隠しファイルが含まれているものもあります。一部のファイルは空のように見えますが、SharePlexの1つまたは複数のプロセスによって参照されているため、元の名前で存在している必要があります。ディレクトリの中には、Questテクニカルサポートの監督下でのみ使用される項目もあります。

本番稼働環境で一般的な使用を目的としたプログラムは、SharePlexのドキュメントで公開されています。SharePlexディレクトリのプログラムに対するドキュメントが見付からない場合は、実行を試みないでください。まず、Questテクニカルサポートへお問い合わせください。

ファイルやディレクトリはSharePlexのバージョンによって異なることがありますが、基本的な構造は以下の通りです。

SharePlexの製品ディレクトリ

SharePlexの変数データディレクトリ

sp_copプロセス

sp_copプログラムは、SharePlexのレプリケーションプロセス（Capture、Read、Export、Import、Post）とSharePlexのキューを調整し、特定のタスクを実行する他のすべてのバックグラウンドプロセスを開始します。また、レプリケーションネットワーク内の他のシステムとのやり取りも維持します。一般的に、ほとんどのSharePlexユーザは、開始と停止以外にはsp_copを操作することはほとんどありません。sp_copは、開始されるとバックグラウンドで実行されます。

• SharePlex管理者（SharePlex adminグループのメンバー）のみがsp_copを開始または停止できます。
• sp_copは、レプリケーションに関与するすべてのソースシステムとターゲットシステムで開始する必要があります。
• アプリケーションがソースシステム上のデータにアクセスしたら（またはその前に）sp_copをただちに開始し、すべてのSharePlexプロセスがトランザクション処理を開始できるようにします。この結果、Captureはソースデータに加えられる変更に合わせることができます。

sp_ctrlプロセス

sp_ctrlを使用して、SharePlexのアクティビティを開始、停止、設定、指示、監視するコマンドを発行することできます。sp_ctrlプログラムは、コマンドを実行するsp_copの子プロセスであるsp_cnc（コマンドおよび制御）プロセスと内部でやり取りします。ユーザとsp_cnc自体とのやり取りはありません。

SharePlexのレプリケーションプロセス

SharePlexは、SharePlexのメインプロセスであるsp_copによって開始される一連のレプリケーションプロセスを通じてデータをレプリケートします。

• Captureプロセス: Captureプロセスは、SharePlexによってレプリケーション用に設定されたオブジェクトを変更するために、ソースシステム上のトランザクションレコードを読み取ります。Captureプロセスはデータをcaptureキューに書き込み、Readプロセスの準備が整うまでデータを蓄積します。データが複数のデータソースからレプリケートされる場合、それぞれのデータソースには個別のCaptureプロセスが存在し、それぞれが独立して同時に機能します。Captureプロセスの名前はsp_ocap（Oracle Capture）です。
• Readプロセス: Readプロセスはソースシステム上で動作し、captureキューからデータを読み取り、ルーティング情報を追加します。データを処理した後、ReadプロセスはこのデータをExportキューに送ります。Readプロセスの名前はsp_ordrです。
• Exportプロセス: Exportプロセスはソースシステム上で動作し、exportキューからデータを読み取り、ネットワークを経由してターゲットシステムに送信します。デフォルトでは、ターゲットシステムごとに1つのExportプロセスが存在します。例えば、ターゲットシステムが2つあれば、Exportプロセスも2つあります。Exportプロセスは、TCP/IPネットワークを介してシステム間でデータを移動させるExport/Importトランスポートペアの最初の部分です。Exportプロセスの名前はsp_xportです。

• Importプロセス: Importプロセスは、Export/Importトランスポートペアの後ろの部分です。Importプロセスはターゲットシステム上で動作し、データを受信してpostキューを構築します。ターゲットにデータを送信するExportプロセスごとに、ターゲットシステム上に1つのImportプロセスが存在します。例えば、2つのソースシステム（それぞれにExportプロセスがある）が1つのターゲットシステムにデータをレプリケートする場合、そのターゲットには2つのImportプロセスが存在します。Importプロセスの名前はsp_mportです。

  注: 同一システム上のデータベース間でデータをレプリケートすることができます。この場合、ExportプロセスとImportプロセスは作成されません。Readプロセスが、そのシステム上のpostキューにデータを直接配置します。

• Postプロセス: Postプロセスはターゲットシステム上で動作し、postキューを読み込んで、レプリケートされた操作をターゲットのデータベース、ファイル、メッセージキューまたはトピックに適用します。ターゲットシステム上のpostキューごとに対応するPostプロセスが存在します。1つのシステム上で複数のPostプロセスを同時に動作させることができます。Postプロセスは、sp_opst_mt（Oracle Post）またはsp_xpst（Open Target Post）です。

SharePlexによるすべての通信とデータの移動は、内部のメッセージングとトランスポートシステムによって処理されます。TCP/IP接続を利用した非同期ストリームプロトコルの使用は、大規模なデータ転送の際に非常に効率的な方法です。この方法は、通信帯域幅を節約しながら、最適なパフォーマンス、信頼性、リスタート機能を保証します。SharePlexはあらゆるTCP/IPネットワーク上でレプリケートできます。

SharePlexのキュー

キューは、ソースシステムからターゲットシステムに転送されるレプリケートデータを格納します。キューは、データの安全な非同期転送を促進するチェックポイント・リカバリ・システムの一部です。データは生成された順序でキューを通過します。

データは、次のキューに書き込まれるまで、1つのキューから読み取り/リリース（削除）されることはありません。ネットワーク、システム、またはデータベースで速度の低下、障害の発生、またはレプリケーションプロセスの停止が発生すると、ソースシステムとターゲットシステムのキューにデータが蓄積されます。問題や障害が解決されると、SharePlexは停止した時点から処理を再開します。

SharePlexのレプリケーションでは以下のキューを使用します。

• captureキュー: captureキューはソースシステム上にあり、SharePlexでさらに処理するためにキャプチャしたデータを保存します。captureキューは、レプリケートされるデータソースごとに1つずつあります。captureキューは、データソースによってo.fin1のように識別されます。
• exportキュー: exportキューはソースシステム上にあり、SharePlexで処理され、ターゲットシステムに転送する準備ができたデータを保持します。デフォルトでは、アクティブな設定やターゲットシステムの数にかかわらず、ソースシステム上に1つのexportキューがあります。デフォルトのexportキューは、それが置かれたソースシステムの名前、例えばSysAによって識別されます。より複雑なレプリケーション戦略のために、SharePlexに対し、追加の名前付きexportキューを作成するよう指示することができます。
• postキュー: postキューはターゲットシステム上にあり、Postがターゲットデータベース、ファイル、メッセージキュー、またはトピックに書き込む準備ができたデータを保持します。各ターゲットシステムには、データソースとそのターゲット間のレプリケーションストリーム用に1つのpostキューがあります。例えば、DatabaseAとDatabaseBの両方がDatabaseCにレプリケートしている場合は、2つのpostキューがあります。デフォルトのpostキューは、例えばSysA (o.DatabaseA-o.DatabaseB)のように、ソースシステムに加えてデータソースおよびターゲットの名前により識別されます。より複雑なレプリケーション戦略のために、追加の名前付きpostキューを作成するようSharePlexに指示することができます。

注: SharePlexのすべてのキューファイルは、SharePlexの変数データディレクトリのrimサブディレクトリで作成され、保持されます。

SharePlexのインストール済みオブジェクト

レプリケーションプロセスの多くは、SharePlexのインストール時にソースまたはターゲットデータベースにインストールされる一連の内部オブジェクトによって制御および追跡されます。これらはSharePlexが動作するために不可欠なものであるため、決して変更しないでください。

注意: すべてのオブジェクトがすべてのデータベースで使用されるわけではありません。ほとんどはOracleデータベースに使用されます。データベースにオブジェクトが表示されない場合、そのオブジェクトはデータベースに関連していないか、その情報はSharePlexの内部設定に保存されています。使用中のデータベースにありながら、このリストにないオブジェクトがあれば、それは現在のリリースでは使用されていません。

SharePlexのレプリケーションの仕組み

SharePlexのレプリケーションの仕組み

データをレプリケートするために、SharePlexは、ソースシステム上のトランザクションデータのストリームを読み取り、設定ファイルで指定されたオブジェクトに加えられた変更をキャプチャします。設定ファイルでは、レプリケートするデータとそれを適用するターゲットを指定します。

レプリケーションを開始するには、設定ファイルをアクティベーションします。これは、sp_ctrlのactivate configコマンドによって、ソースとターゲットのデータを初めて同期させる一連のステップの中で行われます。設定がアクティブな場合、SharePlexはデータレコード全体ではなく、設定ファイルで指定されたオブジェクトに加えられた変更のみをレプリケートするため、高速で信頼性の高いレプリケーションソリューションを実現します。

詳細については、次を参照してください。

• 「データをレプリケートするためのSharePlexの設定ページ
• 「本番システムでのレプリケーションの開始ページ

SharePlexは、トランザクション操作に関する情報から、ソースシステムからターゲットシステムに送信される1つ以上のメッセージを作成します。メッセージは、SQL操作またはSharePlexの内部操作を反映することができますが、ほとんどの場合、メッセージはINSERT、UPDATE、DELETE、COMMIT、TRUNCATE、またはサポートされているDDL操作です。

注: LONG列やLOB列に対する操作のような大規模な操作の場合、メッセージのサイズに制限があるため、複数のメッセージが必要になることがあります。小さなレコードの配列挿入など、他の操作は逆の結果をもたらします。1つのレコードが多数の操作に対応する可能性があります。例えば、データによっては、70,000行の配列挿入がわずか700個のメッセージとしてトランザクションストリームに記録されることもあります。一般的に、そのようなデータ型に対する多数の変更をレプリケートしているのでなければ、プロセスやキューのステータス出力に表示されるメッセージの数は、同じ数のSQL操作にほぼ対応すると考えることができます。

Postプロセスはpostキューからメッセージを読み込み、レプリケートされたデータの変更をターゲットに適用します。データベースターゲットの場合、PostはSQLステートメントを構築してデータを適用します。データベース以外のターゲットの場合、Postはターゲットが要求する形式（ファイルやメッセージングキューまたはトピックなど）でデータレコードを出力します。

SharePlexがターゲットシステム上でSQLステートメントを作成するデフォルトの方法について、以下に説明します。

• 変更がINSERTの場合、SharePlexは行のすべての列を使用してINSERTステートメントを作成します。
• 変更がDELETEの場合、SharePlexはキーのみを使用して、正しい行を見付けるためにWHERE句を作成します。Oracleの場合、テーブルにキーがなければ、SharePlexはLONG列とLOB列を除くすべての列の値を使用してキーをシミュレートします。設定ファイルを作成する際に、キーとして使用する列を指定することができます。SQL Serverの場合、設定されたすべてのオブジェクトにはプライマリキーが必要です。
• 変更がUPDATEの場合、SharePlexはキーと変更された列の値を使用してWHERE句を作成し、正しい行を探します。データベースに変更を適用する前に、Postプロセスでは、ソース列の値のプリイメージとターゲット列の既存の値を比較します。プリイメージ（変更前イメージとも呼ばれる）は、UPDATE前に変更された各列の値です。プリイメージと既存のターゲット値が一致し、同期していることが確認されると、Postは変更を適用します。そうでない場合、Postは操作をエラーファイルに記録し、SharePlexは「非同期」エラーを返します。
• 変更がUPDATEまたはDELETEステートメントで、ソースマシン上の複数の行に影響する場合、SharePlexはターゲット上で複数のステートメントを発行してタスクを完了します。例えば、UPDATE tableA set name = 'Lisa' where rownum < 101ステートメントは、ソース上では1つのステートメントしか発行されていないにもかかわらず、実際には100のUPDATEステートメントをターゲットに送信します。

同期の概念の理解

同期の概念は主にテーブル間レプリケーションに適用され、Postは、ターゲット内の1つの行だけがレプリケートされる行の変更と一致することを確認するために整合性チェックを実行します。これはファイル、メッセージングターゲット、変更履歴ターゲットには適用されません。これらには、Postによって複製されるすべての操作のレコードが含まれており、そのうちのいくつかは時間が経過しても変わらない可能性があります。Postプロセスは、これらのターゲットに対して整合性チェックを実行しません。

同期化されたテーブルの特徴

同期化されたソース側のテーブルとターゲット側のテーブルの基本的な特徴は、以下の通りです（トランスフォーメーション機能を使用した場合を除く）。

• ソースデータベースに行が存在すれば、ターゲットにも存在します。
• ソース側のテーブルとターゲット側のテーブルの対応する列の構造とデータ型は同一です。
• 対応する行のデータ値は、キーの値も含めて同一です。

データ整合性はPostプロセスで確保します。PostではWHERE句を適用して、処理するSQL操作のキー値と前の値を比較します。Postは、ソース側のテーブルとターゲット側のテーブルの間の同期を検証するために以下の論理を使用します。

• Postは複製されたINSERTを適用しますが、同じキーを持つ行が既にターゲットにあります。Postは以下のロジックを適用します。

  • ターゲット行の現在の値がすべてINSERT値と同じ場合、Postは行が同期していると見なし、操作を破棄します。
  • いずれかの値がINSERTの値と異なる場合、Postはこれを非同期状態と見なします。

  注意: INSERTをポストする際に、キー以外の値を考慮しないようにPostを設定することができます（OracleからOracleにデータを複製する場合にのみ適用可能）。『SharePlexリファレンスガイド』のSP_OPO_SUPPRESSED_OOSパラメーターを参照してください。

• Postは複製されたUPDATEを適用しますが、UPDATEのキー値と同じキー値を持つ行がターゲットに見付かりません。または、Postは正しい行を見付けますが、その行の値がUPDATEの前の値と一致しません。Postは以下のロジックを適用します。

  • ターゲット行の現在の値がUPDATEの後の値と一致する場合、Postはその行が同期していると見なし、操作を破棄します。
  • ターゲット行の値がUPDATEの前または後の値と一致しない場合、Postはこれを非同期状態と見なします。

  注意: ターゲット行の現在の値がUPDATEの後の値と一致する場合、非同期のメッセージを返すようにPostを設定できます（OracleからOracleにデータを複製する場合にのみ適用可能）。『SharePlexリファレンスガイド』のSP_OPO_SUPPRESSED_OOSパラメーターを参照してください。

• DELETEはソースデータで実行されますが、Postはキーを使用してターゲット行を見付けることができません。Postは、DELETEステートメントを作成するときにWHERE句にキー値だけを含めます。ターゲットに行が存在しない場合、Postは操作を破棄します。

隠れた非同期の状態

Postが検証するのは、現在のSQL操作によって変更される行の整合性だけです。ターゲットデータベースでそのテーブルや他のテーブルの他の行が非同期になっているかどうかは検証しません。隠れた非同期状態は、かなり後になって、影響を受ける行に対する変更がSharePlexによって最終的にレプリケートされたり、そのデータを使用する過程で不一致が検出されたりするまで現れない可能性もあります。

検出可能な非同期状態の例

誰かがターゲットにログインし、ターゲット側のテーブルのCOLOR列でRow1を「blue」から「red」に更新します。次に、ソースシステム上のアプリケーションユーザがソース側のテーブルに同じ変更を加え、SharePlexがこれをターゲットにレプリケートします。Postが使用するWHERE句では、ターゲットテーブルのプリイメージは「blue」ですが、ターゲット行の現在値は「red」です。Postは非同期エラーを生成し、非同期の状態を警告します。

隠れた非同期状態の例

誰かがターゲットにログインし、ターゲット側のテーブルのCOLOR列でRow2を「blue」から「red」に更新しますが、この変更はソース側のテーブルには反映されず、レプリケートされません。現在、この2つのテーブルは同期していませんが、Postはエラーメッセージを返しません。これは、その行でレプリケーションが実行されていないからです。その後は、その行の他の列（SIZE、WEIGHT）を何回更新しても、誰かがソース側のテーブルのCOLOR列を更新するまではCOLOR列の隠れた非同期状態は持続され、ターゲット上のユーザが持っている情報は不正確になります。その変更がレプリケートされたときにのみ、Postはプリイメージを比較し、エラーメッセージを返します。

ほとんどの場合、非同期データの原因は、レプリケーションで発生した問題ではなく、ターゲットで適用されたDML、不完全なバックアップの復元、またはその他の隠れた非同期状態であり、これらはレプリケーションがその行に影響を与えるまで検出されません。非同期の状態を解決するのには時間がかかり、ユーザアクティビティを妨げる可能性があります。レプリケーションが開始されたら、以下をお勧めします。

• ターゲット側のテーブルへの書き込みアクセスを禁止し、DMLやDDLを適用できないようにします。
• compareコマンドを使用して、ソースとターゲットのデータを定期的に比較し、同期の確認と隠れた非同期の状態を検出します。repairコマンドを使用して非同期の行を修復することができます。これらのコマンドの詳細については、『SharePlexリファレンスガイド』を参照してください。

SharePlexによる非同期状態への対応方法

お客様が、非同期エラーが発生したトランザクションに対するSharePlexの対応を以下のように決めることができます。

• トランザクションに非同期の操作が含まれる場合のPostのデフォルトの動作は、トランザクション内の他の有効な操作の処理を継続し、レイテンシを最小限に抑え、ターゲットを可能な限り最新の状態に保つことです。レイテンシとは、ソースでトランザクションが発生してから、それがターゲットに適用されるまでの時間のことです。きわめて量の多いトランザクションやネットワークトラフィックの中断など、さまざまな要因がレプリケーションのレイテンシの大きさに影響を与えます。

  Postは、SQLステートメントと非同期の操作のデータをID_errlog.sqlログファイルに記録します。ここで、IDはデータベース識別子です。このファイルは、ターゲットシステムの変数データディレクトリのlogサブディレクトリにあります。

• 以下のパラメーターを1に設定することで、Postが非同期状態を見付けたときに停止するように設定できます。

  • Oracleターゲット: SP_OPO_OUT_OF_SYNC_SUSPEND
  • Open Targetターゲット: SP_OPX_OUT_OF_SYNC_SUSPEND

• Postでは、トランザクション内のいずれかの操作で非同期エラーが発生した場合に、トランザクションをロールバックして破棄するように設定できます。トランザクション全体がSQLファイルに記録されますが、ターゲットには適用されません。SQLファイルを編集して無効なDMLを修正し、SQLファイルを実行してトランザクションを適用することができます。この機能は、SP_OPO_SAVE_OOS_TRANSACTIONを1に設定することで有効になります。