変更の追跡の内部はSQL Server 2008から2012に変更されましたか？

切断されたデバイスと中央データベースサーバーの同期に関する問題のトラブルシューティングで、サーバーでSQL Server 2012にアップグレードした後に問題が発生しています。CHANGE_TRACKING_MIN_VALID_VERSIONは、本来よりも1大きい（または少なくともアップグレード前の値よりも）高い値を返しているようです。

簡単な例を設定する方法の例として、Arshad Aliのすばらしいウォークスルーの例を使用して作業してきました。

＃1から＃5までのスクリプトを実行して、SQL Server 2008環境と2012環境の両方で、Employeeテーブルの行を挿入、削除、および更新しました。

2008年、次のステートメントは0を返します。

SELECT CHANGE_TRACKING_MIN_VALID_VERSION(OBJECT_ID('Employee'))

2012年は1を返します。

テストでさらにいくつかのスクリプト（6〜8）を使用して作業する場合は、保持期間を1分に設定して、クリーンアップアクションを強制的に実行できるようにします。私はその日出発し、どうやらそれは一晩走ったようです。

2008年のインスタンスでは、CHANGE_TRACKING_CURRENT_VERSIONとCHANGE_TRACKING_MIN_VALID_VERSIONは等しくなります（11）。2012年のインスタンスでは、CHANGE_TRACKING_MIN_VALID_VERSIONはCHANGE_TRACKING_CURRENT_VERSION（11）よりも1つ高く（12）あります。これは、データベースが長時間アイドル状態のときに同期プロセスに影響を与える可能性があります。そして、特に次のテストを実行して、同期ではなく再初期化が必要かどうかを判断する場合に、プロセスがループに巻き込まれる可能性があることを発見しました。

IF CHANGE_TRACKING_MIN_VALID_VERSION(object_id(N'dbo.Employee')) > @sync_last_received_anchor 
       RAISERROR (N'SQL Server Change Tracking has cleaned up tracking information for table ''%s''...

他の誰かがこの行動の変化を経験しましたか？誰か説明がありますか？

変更の追跡にmin_valid_versionを使用しません。これは、クライアントが変更を消費する前にメタデータがクリーンアップされている場合に、クライアントを再初期化する必要があるかどうかを検証するためにのみ使用されます。

CHANGE_TRACKING_MIN_VALID_VERSION（Transact-SQL）

CHANGETABLE関数の使用時に、指定されたテーブルから変更追跡情報を取得するために有効な最小バージョンを取得します。

Min_valid_versionはクリーンアップバージョンで変更され、ユーザーテーブルへの変更に依存しません。クリーンアップスレッドが実行されるたびに、データの変更に関係なくmin_valid_versionが更新される可能性があります。

2012より前のバージョンでは、min_valid_versionはクリーンアップバージョンと同じようにマークされていましたが、実際には、そのバージョンのメタデータがクリーンアップされているため、クリーンアップバージョンよりも1つ多いはずです。2012年には、正しいmin_valid_versionを確実に更新するために変更されました。

1つはmin_valid_versionを使用して変更を追跡するのではなく、毎回の同期後にlast_sync_versionを保存しCHANGETABLE、最後の同期バージョン以降の変更を列挙するためにを呼び出す必要があります。

設計上-最小有効バージョンはクリーンアップバージョンで変更され、ユーザーテーブルへの変更に依存しません。クリーンアップスレッドが実行されるたびに、データの変更に関係なく、有効な最小バージョンに更新される可能性があります。

解決-「min_valid_version」の代わりに「current_version」を使用するように手順を変更します