Les éléments internes du suivi des modifications sont-ils passés de SQL Server 2008 à 2012?

Lors du dépannage d'un problème de synchronisation des appareils déconnectés avec un serveur de base de données central, nous rencontrons un problème après la mise à niveau vers SQL Server 2012 sur le serveur. Il semble que CHANGE_TRACKING_MIN_VALID_VERSION renvoie une valeur 1 supérieure à ce qu'elle devrait (ou au moins à ce qu'elle faisait avant la mise à niveau.)

J'ai travaillé à travers la grande marche d'Arshad Ali à travers l'exemple de la façon de mettre en place un exemple simple.

J'ai exécuté les scripts de # 1 à # 5 pour insérer, supprimer et mettre à jour une ligne dans la table Employee dans un environnement SQL Server 2008 et 2012.

En 2008, l'instruction suivante renvoie un 0:

SELECT CHANGE_TRACKING_MIN_VALID_VERSION(OBJECT_ID('Employee'))

En 2012, il renvoie un 1.

En travaillant avec quelques autres scripts (6-8) dans les tests, j'ai défini la période de rétention sur 1 minute pour forcer, espérons-le, une action de nettoyage. Je suis parti pour la journée et apparemment ça a fonctionné toute la nuit.

Dans l'instance de 2008, CHANGE_TRACKING_CURRENT_VERSION et CHANGE_TRACKING_MIN_VALID_VERSION sont égaux (11). Dans l'instance 2012, le CHANGE_TRACKING_MIN_VALID_VERSION est un supérieur (12) que le CHANGE_TRACKING_CURRENT_VERSION (11). Cela peut avoir un impact sur le processus de synchronisation lorsqu'une base de données est inactive pendant de longues périodes. Et nous avons constaté que le processus pouvait se coincer dans une boucle, en particulier lorsque le test suivant est effectué pour déterminer si une réinitialisation, par opposition à la synchronisation, est nécessaire:

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''...

Quelqu'un d'autre a-t-il connu ce changement de comportement? Est-ce que quelqu'un a une explication?

sql-server sql-server-2012 change-tracking

— Glenn Estrada
source

Il existe un élément Microsoft Connect pour ce problème, connect.microsoft.com/SQLServer/feedback/details/770014/… essentiellement Microsoft pense que le problème peut être lié à une corruption dans la base de données en question. Pouvez-vous reprocher cette situation dans une base de données nouvellement créée?

— Max Vernon

Max, j'ai revu l'article Connect. Malheureusement, l'affiche originale semble avoir abandonné la discussion et MS a clos le problème. Lors de la configuration de la reproduction du problème, j'ai commencé les tests avec les bases de données nouvellement créées dans une instance 2008R2 et 2012. Les deux bases de données semblent fonctionner normalement sous tous les autres aspects.

— Glenn Estrada

Avec les étapes de repro du problème, veuillez le signaler sur Connect afin qu'ils puissent le résoudre!

— Jon Seigel

Avez-vous modifié le niveau de compatibilité de la base de données après la mise à niveau? Je n'utilise pas le suivi des modifications, mais je pense à une incompatibilité de version après la mise à niveau.

— Guillaume R.

On n'utilise pas la min_valid_version pour suivre les changements. Ceci n'est utilisé que pour valider si votre client doit être réinitialisé, si les métadonnées ont été nettoyées avant que le client puisse consommer les modifications.

CHANGE_TRACKING_MIN_VALID_VERSION (Transact-SQL)

Obtient la version minimale qui peut être utilisée pour obtenir des informations de suivi des modifications à partir de la table spécifiée lorsque vous utilisez la CHANGETABLEfonction.

Min_valid_version change avec la version de nettoyage et ne dépend pas des modifications apportées à la table utilisateur. Chaque fois que le thread de nettoyage s'exécute, il peut y avoir une mise à jour de min_valid_version indépendamment des modifications de données.

Avant 2012, min_valid_version était marqué de la même manière que la version de nettoyage, alors qu'en fait, il devrait être un de plus que la version de nettoyage car les métadonnées de cette version ont déjà été nettoyées. En 2012, c'est ce qu'ils ont changé pour s'assurer de mettre à jour la bonne version min_valid_version.

Il ne faut pas suivre les modifications à l'aide de min_valid_version, mais plutôt enregistrer last_sync_version après chaque synchronisation et appeler le CHANGETABLEpour énumérer les modifications après la dernière version de synchronisation.

De par leur conception: la version valide de Min change avec la version de nettoyage et ne dépend pas des modifications apportées à la table utilisateur. Chaque fois que le thread de nettoyage s'exécute, il peut y avoir une mise à jour vers une version minimale valide indépendamment des modifications des données.

Resolve - Changer la procédure pour utiliser 'current_version' au lieu de 'min_valid_version'

— stacylaray
source