同期するデータがあることを自動的に通知するものは何もありません。Ben の提案に加えて、リモート データベースの SYS.SYSSYNC テーブルにクエリを実行して、変更があるかどうかを確認するという別のアイデアもあります。次のステートメントは、最後の同期の簡単なステータスを示す結果セットを返します。
select ss.site_name, sp.publication_name, ss.log_sent,ss.progress
from sys.syssync ss, sys.syspublication sp
where ss.publication_id = sp.publication_id
and ss.publication_id is not null
and ss.site_name is not null
の場合progress < log_sent
、最後の同期のステータスは不明です。アップロードは送信されましたが、Mobile Link サーバーからの応答が受信されなかったため、最後のアップロードが統合で適用されている場合と適用されていない場合があります。この場合、同期を提案することは悪い考えではありません。
の場合progress = log_sent
、最後の同期は成功しています。これを知っていればdb_property('CurrentRedoPos')
、リモート データベースの現在のログ オフセットを返す の値を確認できます。この値が進行状況の値よりも大幅に大きい場合は、最後の同期以降にデータベースに適用された多くの操作があるため、同期するデータがある可能性が高くなります。db_property('CurrentRedoPos')
進行状況に大きな違いがあったとしても、同期が必要な実際のデータがなくなる可能性がある理由はたくさんあります。
- ML サーバーからのダウンロードは、アップロードが ML サーバーによって確認されたときにリモートでの進行状況の値が dbmlsync によって更新された後、dbmlsync によって適用されます。dbmlsync によってダウンロードに適用された操作は ML サーバーに同期されないため、オフセット範囲全体が適用された最後のダウンロードになる可能性があります。これは、テーブル値
sp_hook_dbmlsync_end
の終了コード値がゼロの場合に、フックで現在のログ オフセットを追跡することで回避できます。#hook_dict
これにより、ダウンロードが適用された後のデータベースのログ オフセットがわかり、保存された値を現在のログ オフセットと比較できるようになりました。
- トランザクション ログ内のすべての操作は、同期されていないテーブルに対する操作である可能性があります。
- トランザクション ログ内のすべての操作がロールバックされた可能性があります。
私の解決策は理想的ではありません。同期されたテーブルへの変更を自分で追跡することが最善の解決策ですが、同期されたテーブルで実行されるすべての操作で余分なアクションをトリガーしないという利点があるため、ニーズに合った代替手段を提供できると思いました。