Chat now with support
Chat with Support

SharePlex 8.6.6 - プレインストールチェックリスト

同期の概念について

同期の概念は、主にテーブル間複製に適用されます。テーブル間複製では、Post は整合性チェックを実行して、ターゲットの 1 行だけが複製対象の行変更と一致するようにします。同期はファイル、JMS、Kafka、および変更履歴ターゲットには適用されません。これらには Post によって複製された操作ごとのレコードが含まれますが、時間の経過によって同一になることがあります。Post プロセスはこれらのターゲットに対して整合性チェックを実行しません。

同期されたテーブルの特性

同期されたソースおよびターゲットテーブルの基本的な特性は、次のとおりです(トランスフォーメーション機能が使われていない場合のみ)。

  • 行がソースデータベースに存在する場合、その行はターゲットに存在します。
  • ソースおよびターゲットテーブルで対応する列は、構造とデータ型が同じです。
  • 対応する行のデータの値は、キーの値を含めて同一です。

データの整合性を確認するのは、Post プロセスの役目です。Post は WHERE 句を適用して、キーの値と処理する SQL 操作の前の値を比較します。Post は次のロジックを使用して、ソーステーブルとターゲットテーブルの同期を検証します。

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

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

    注: Post が INSERT を post するときに非キー値を考慮しないように設定できます。『 SharePlex リファレンスガイド』の SP_OPO_SUPPRESSED_OOS パラメータの説明を参照してください。

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

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

    注: ターゲット行の現在の値が UPDATE の後の値と一致する場合に非同期メッセージを返すように Post を設定できます。『 SharePlex リファレンスガイド』の SP_OPO_SUPPRESSED_OOS パラメータの説明を参照してください。

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

隠れた非同期状態

Post は現在の SQL 操作によって変更されている行の整合性のみを確認します。そのテーブルのその他の行や、その他のテーブルがターゲットデータベースで非同期状態であるかどうかは確認しません。隠れた非同期状態は、変更が最終的に SharePlex によってそのデータに加えられるときや、そのデータの使用時に不一致が検出されたときなど、かなり後にならないと明らかにならない可能性があります。

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

あるユーザーがターゲットにログインし、ターゲットテーブルの COLOR 列の 1 行目を「blue」から「red」に変更したとします。次に、ソースシステムのアプリケーションユーザーがソーステーブルに同じ変更を行い、SharePlex がそれをターゲットに複製します。Post によって使用される WHERE 句で、ターゲットテーブルのプリイメージは「blue」ですが、ターゲット行の現在の値は「red」です。Post は非同期状態を警告する非同期エラーを生成します。

隠れた非同期状態の例

あるユーザーがターゲットにログインし、ターゲットテーブルの COLOR 列の 2 行目を「blue」から「red」に変更したが、その変更をソーステーブルに行わなかったため、複製されなかったとします。2 つのテーブルは非同期状態にありますが、Post による処理がないため、前例にあったようなエラーメッセージはありません。たとえ、この行の他の列(SIZE、WEIGHT)にどのような変更があっても、誰かがソーステーブルの COLOR 列を更新するまで、COLOR 列の非同期状態が維持され、ターゲット上のユーザーは不正確な情報を持つこととなります。ソース上での変更が複製される時点で Post によってプリイメージが比較され、初めてエラーメッセージが表示されます。

ほとんどの場合、非同期データの原因は複製時の誤った処理ではなく、ターゲットで適用される DML や不完全なバックアップの復元です。また、Post によって適用されるまで非同期状態が長期間検出されず、最終的にデータに影響してエラーが返される場合もあります。非同期の状態の解決は時間がかかり、ユーザー活動にも悪影響を及ぼします。複製が開始されたら、次の操作を行うことを推奨します。

  • ターゲットテーブルへの書き込みアクセスを防止して、DML と DDL が適用されないようにします。
  • compare コマンドを使用してソースとターゲットのデータを定期的に比較し、同期を確認して隠れた非同期状態を検出します。
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating