同期の概念は、主にテーブル間複製に適用されます。テーブル間複製では、Post は整合性チェックを実行して、ターゲットの 1 行だけが複製対象の行変更と一致するようにします。同期はファイル、JMS、Kafka、および変更履歴ターゲットには適用されません。これらには Post によって複製された操作ごとのレコードが含まれますが、時間の経過によって同一になることがあります。Post プロセスはこれらのターゲットに対して整合性チェックを実行しません。
同期されたソースおよびターゲットテーブルの基本的な特性は、次のとおりです（トランスフォーメーション機能が使われていない場合のみ）。
データの整合性を確認するのは、Post プロセスの役目です。Post は WHERE 句を適用して、キーの値と処理する SQL 操作の前の値を比較します。Post は次のロジックを使用して、ソーステーブルとターゲットテーブルの同期を検証します。
Post が複製された INSERT を適用したときに、同じキーを持つ行がすでにターゲットに存在します。Post は、以下のロジックを適用します。
注： Post が INSERT を post するときに非キー値を考慮しないように設定できます。『 SharePlex リファレンスガイド』の SP_OPO_SUPPRESSED_OOS パラメータの説明を参照してください。
Post が複製された UPDATE を適用したときに、UPDATE とキー値が同じ行がターゲットに見つからないか、正しい行が見つかったが行の値が UPDATE の前の値と一致しません。Post は、以下のロジックを適用します。
注： ターゲット行の現在の値が UPDATE の後の値と一致する場合に非同期メッセージを返すように Post を設定できます。『 SharePlex リファレンスガイド』の SP_OPO_SUPPRESSED_OOS パラメータの説明を参照してください。
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 によって適用されるまで非同期状態が長期間検出されず、最終的にデータに影響してエラーが返される場合もあります。非同期の状態の解決は時間がかかり、ユーザー活動にも悪影響を及ぼします。複製が開始されたら、次の操作を行うことを推奨します。
© 2021 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy
