Partager via

  • Article

Optimisation des performances de la réplication de fusion avec le suivi conditionnel des suppressions

[!REMARQUE]

Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité.

Avec la réplication de fusion, vous pouvez spécifier que les suppressions d'un ou plusieurs articles ne doivent pas faire l'objet d'un suivi par les déclencheurs de réplication et les tables système. Si vous spécifiez cette option pour un article, les suppressions ne sont pas suivies ni répliquées à partir du serveur de publication ou de quelque Abonné que ce soit. Cette option est disponible pour la prise en charge d'un certain nombre de scénarios d'application et pour l'optimisation des performances dans les cas où la réplication des suppressions n'est pas nécessaire ou souhaitable. Les performances sont améliorées de trois façons : les métadonnées des suppressions ne sont pas stockées ; les suppressions ne sont pas énumérées durant la synchronisation ; les suppressions ne sont pas répliquées sur l'Abonné, ni appliquées.

[!REMARQUE]

Pour l'utilisation des articles en téléchargement seul, le niveau de compatibilité de la publication doit être au minimum 90RTM. Pour plus d'informations, consultez la section « Niveau de compatibilité pour les publications de fusion » dans la rubrique Utilisation de plusieurs versions de SQL Server dans une topologie de réplication.

Cette option peut être spécifiée lors de la création d'une publication, ou être activée ou désactivée par bascule si une application nécessite que certaines suppressions soient répliquées et d'autres pas, telles que les suppressions de traitement. Les exemples qui suivent illustrent diverses utilisations possibles de cette option dans une application :

  • Une application pour une force de vente mobile possède en général des tables telles que SalesOrderHeader, SalesOrderDetail et Product. Les commandes sont entrées au niveau de l'Abonné puis répliquées vers le serveur de publication, qui souvent fournit ces données à un système d'exécution de commandes. Beaucoup de travailleurs mobiles utilisent des périphériques portables qui ont une mémoire limitée : une fois la commande reçue par le serveur de publication, elle peut être supprimée sur l'Abonné. La suppression n'est pas propagée vers le serveur de publication, puisque cette commande est toujours active dans le système.

    Dans ce scénario, les suppressions ne font pas l'objet d'un suivi pour les tables SalesOrderHeader et SalesOrderDetail. En revanche les suppressions sont suivies pour la table Product parce que, si un produit est supprimé sur le serveur de publication, cette suppression doit être envoyée à l'Abonné pour qu'il garde à jour sa liste de produits.

  • Une application pourrait stocker les données historiques dans une table telle que TransactionHistory, périodiquement purgée des enregistrements de plus d'un an. Cette table peut être filtrée de sorte que les Abonnés ne reçoivent que les données de transactions du mois en cours. Les suppressions de traitement mensuelles sur le serveur de publication purgeant les données plus anciennes ne concernent pas les Abonnés, mais sont quand même suivies et énumérées par défaut.

    Dans ce scénario, avant le traitement par lots, l'activité pourrait être interrompue sur le système, et l'application pourrait désactiver le suivi des suppressions. Une fois le traitement terminé, le suivi pourrait être réactivé.

Important

Si les autres activités se poursuivent sur le serveur de publication, vous devez vous assurer que les suppressions qui doivent être propagées aux Abonnés ne se produisent pas lorsque le suivi des suppressions est désactivé.

Pour spécifier que les suppressions ne doivent pas être suivies