ID de transaction de réplication SQL Server 2005/8

Question

J'ai un scénario dans lequel j'utilise la réplication transactionnelle pour répliquer plusieurs bases de données SQL Server 2005 (même instance) dans une seule base de données distante (instance différente sur une machine physique distincte). Je réalise ensuite un traitement sur les données répliquées à des fins de génération de rapports. J'utilise des déclencheurs au niveau de la table pour identifier les changements d'actions que mon code de post-traitement.

Jusqu'à présent, tout va bien. Cependant, ce que je voudrais savoir, c'est que, lorsque certaines tables sont créées, mises à jour ou supprimées dans la même transaction, est-il possible d'identifier une sorte d'ID de transaction de réplication (ou n'importe où)? t effectuer le même post-traitement plusieurs fois pour une seule transaction.

Exemple de base: J'ai une table TUser et une table TAddress. Si je devais créer les deux en une seule transaction, ils seraient également répliqués dans une même transaction. Cependant, il y aurait deux déclencheurs déclenchés dans la base de données répliquée - ce qui entraîne actuellement l'exécution de mon code de post-traitement deux fois. Ce que je voudrais vraiment identifier, c'est que ces deux changements sont arrivés dans la réplique dans la même transaction.

Est-ce possible d'une manière ou d'une autre? Est-ce qu'un identifiant tel que je l'ai décrit existe et est-il accessible?

Answer 1

La réponse courte est non, il n'y a rien du genre sur lequel vous pouvez compter. Une réponse longue en résumé serait que oui, il existe, mais il ne serait en aucun cas recommandé de l'utiliser pour quoi que ce soit. Étant donné que la réplication est cohérente sur le plan transactionnel, une approche que vous pourriez envisager consisterait à pousser un identificateur pour l'enregistrement primaire (dans ce cas, TUser, puisque TAddress est lié à TUser) dans une file d'attente (en utilisant quelque chose comme Service Brokeruser-defined queue), puis effectuez le post-traitement en extrayant les données de la file d'attente et en les traitant séparément. Une autre possibilité consisterait simplement à traiter par lots tous les temps x en interrogeant les enregistrements nouveaux/mis à jour à partir des tables primaires et en les traitant de la même manière - vous devez suivre les ID, les rowversions ou les horodatages de un tri que vous avez traité pour chaque table primaire en tant que méta-données et en extrayant tout ce qui n'a pas encore été traité lors de chaque exécution par lots.

Juste quelques réflexions, espérons que cela aide.