Comment suivre l'heure des lignes répliquées pour les abonnés dans SQL Server 2005?

Question

Le problème de base est le suivant:
Un abonné a réussi à répliquer une ligne auprès de l'éditeur à l'aide de la réplication transactionnelle. Maintenant, comment pouvons-nous suivre le temps de la dernière réplication réussie de cette ligne?

Un ami a suggéré la solution suivante, qu'il a utilisée pour son SQL Server 2000:
1) Ajouter une colonne datetime.
2) Modifiez la procédure de réplication stockée pour mettre à jour la colonne datetime (!). L'étape # 2 déclenche toutes sortes de cloches d'avertissement en moi, donc je demande s'il y a de meilleures solutions pour SQL Server 2005 dans cette situation, avant même d'entrer dans le détail avec sa solution.

Answer 1

Je ferais exactement ce que votre ami a suggéré. De cette façon, seuls les appels à la procédure de réplication mettent à jour l'horodatage.

Le problème avec cette approche est que vous avez besoin d'un verrou en écriture, mais je ne vois aucun autre moyen pratique.

Vous pouvez par ailleurs utiliser un déclencheur qui se déclenche lorsque vous allez chercher la ligne (ne me citez pas là-dessus, je très rarement utilisé déclencheurs), mais cela ne semble pas juste (vous pourriez finir avec les faux positifs)

Answer 2

Si vous travaillez avec la réplication transactionnelle, pourquoi ne pas simplement enregistrer l'heure de la mise à jour des données primaires et considérer qu'elle a été répliquée sur les autres bases de données lors du prochain travail de réplication?

Answer 3

@Philippe: Le principal problème de cette approche est que la réplication peut prendre un certain temps pour atteindre une partie de la base de données la plus éloignée, en raison d'une mauvaise connexion réseau. Ainsi, l'heure de mise à jour de l'enregistrement principal ne reflète pas l'heure de l'enregistrement réellement répliqué dans la base de données distante.

De toute façon, j'ai testé la méthode de mon ami, et cela a bien fonctionné pour notre exigence.

Si quelqu'un veut faire cela aussi, voici une note importante: faites attention à l'initialisation de l'abonnement et aux changements de schéma futurs.

Pour mon cas, nous avons décidé de initialize the snapshot manually afin de conserver la colonne datetime ajoutée dans la base de données Subscriber. Une autre approche possible pourrait être d'autoriser l'initialisation, mais de modifier les procédures stockées existantes pour ignorer la réplication de la colonne datetime ajoutée.

Answer 4

J'ai eu ce problème exact il y a quelques semaines en essayant de trouver des enregistrements qui ont changé récemment.

Créez une colonne et définissez le type de données sur TIMESTAMP. SS2005 met automatiquement à jour ce type lorsque la ligne est mise à jour. Le seul problème est que cet 'horodateur' n'a rien à voir avec une date ou une heure, c'est juste un nombre qui reflète la dernière mise à jour réussie de cette ligne (n'importe quelle mise à jour, pas seulement via la réplication). Si c'est tout ce dont vous avez besoin, alors ça devrait aller.

Si vous avez besoin de la dernière mise à jour de la réplication , les choses pourraient être un peu compliquées, et vous devrez vous salir les mains avec des triggers et des procédures stockées.

http://www.sqlteam.com/article/timestamps-vs-datetime-data-types

espoir qui aide ~