0

注: ユーザーはステージング DB でのみ機能します。本番DBは閲覧専用です。

開始したとき、これら 2 つのデータベースはまったく同じであったため、データベースのプロビジョニングと同期は正常に機能していました。

ここに画像の説明を入力

次に、スキーマを変更すると問題が発生します（ユーザーがまだステージングデータベースで作業している間）。これが私の手順です。

  1. Staging での行の追加/更新/削除 (ユーザーによる)
  2. データベースのプロビジョニング解除
  3. テーブルへの列の追加/更新
  4. データベースの再プロビジョニング

デプロビジョニングと再プロビジョニングの後、データベースに一貫性がなくなります。

ここに画像の説明を入力

現在、再プロビジョニング前の変更は本番 DB に同期されません。SF は、プロビジョニング後に行を (追跡テーブルで) 追跡するだけです。

私の回避策 - 各テーブルの各行を強制的に更新します (同期フレームワークが行が更新されたと見なすように)。ただし、再プロビジョニング後の最初の同期には数時間かかります。

質問 - これは同期フレームワークが機能するように想定/設計されているものですか?

ご意見ありがとうございます。

4

2 に答える 2

1

動作するはずの方法：

1 つのデータベースを完全にプロビジョニング解除して再プロビジョニングする場合、Sync Framework は、他のデータベースも再初期化することを想定しています。つまり、(再) プロビジョニング後に「プライマリ」データベースのバックアップを作成し、それをセカンダリにコピーして復元し、その後で PostRestoreFixup を実行します (http://msdn.microsoft.com/en-us/library/microsoft) .synchronization.data.sqlserver.sqlsyncstorerestore.performpostrestorefixup.aspx)。

別の方法:

デプロビジョニングと再プロビジョニングの代わりに、スコープをインプレースで変更する回避策があります。JuneT は、ここから始まる一連のブログ投稿で、それを開始する方法の概要を作成しました。紹介/ .

あなたの状況に具体的に対処するには：

あなたが直面している問題の核心は、ステージング データベースに同期されていないローカルの変更があるときに、スキーマの変更とプロビジョニング解除/再プロビジョニングが発生していることにあるようです。スキーマの変更を行い、デプロビジョニング/再プロビジョニングを行う直前に同期を実行することで、発生している問題のほとんどを修正できる場合があります。それが可能であれば、他のオプションよりも簡単かもしれません。

于 2012-07-11T16:40:49.380 に答える
0

プロビジョニング解除後、再プロビジョニング前に行われた変更は、変更を追跡するためのトリガーと追跡テーブルがないため、取得されません。

おそらく競合が発生するため、時間がかかります。

プロビジョニング解除と再プロビジョニングの前に、含まれる行に関して同一のテーブルがある場合があります。

したがって、ソースと宛先に100万行あるとします。

ここでプロビジョニングを解除すると、SyncFxは同期されたものの知識を一掃します。再プロビジョニングすると、Sync Fxは、トラッキングテーブルに新しいメタデータ（100万行プラスマイナス新しく挿入または削除された行）を再入力します。

これで、Sync Fxは、ソース内のデータが宛先上にすでにあるデータとほぼ同じであることを認識していません。

したがって、100万以上の行が宛先に送信されます。これらの行が適用されると、行がすでに存在するため、PK違反が発生します。

ソースのスキーマを変更したことがわかりますが、同じ列のセットを同期していますか？新規/削除された列がスコープの一部でない場合は、プロビジョニングを解除する必要はありません。スコープ定義でスキーマの変更を有効にする場合にのみ、プロビジョニング解除または再プロビジョニングします。

于 2012-07-12T08:01:10.127 に答える