Partager via

Optimiser les performances de la réplication par fusion avec la surveillance conditionnelle 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 pour un ou plusieurs articles ne doivent pas être traquées par les déclencheurs associés à la réplication et par les tables système. Si vous spécifiez cette option pour un article, les suppressions ne sont pas suivies ou répliquées à partir du serveur de publication ou des abonnés. Cette option est disponible pour prendre en charge un certain nombre de scénarios d’application et fournir une 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 pour les suppressions ne sont pas stockées ; les suppressions ne sont pas énumérées pendant la synchronisation ; les suppressions ne sont pas répliquées vers et appliquées sur l’Abonné.

Remarque

Pour utiliser des articles en téléchargement uniquement, le niveau de compatibilité de la publication doit être d’au moins 90RTM.

L’option peut être spécifiée lorsqu’une publication est créée ou désactivée si une application exige que certaines suppressions soient répliquées et que d’autres ne soient pas répliquées, telles que les suppressions par lots. Les exemples suivants illustrent les façons dont cette option peut être utilisée dans une application :

  • Une application pour une force de vente mobile a généralement des tables telles que SalesOrderHeader, SalesOrderDetail et Product. Les commandes sont entrées sur l'abonné, puis répliquées à l'éditeur, qui fournit souvent des données à un système de traitement des commandes. De nombreux travailleurs mobiles utilisent des appareils portables qui ont un stockage limité : une fois la commande reçue sur le serveur de publication, elle peut être supprimée sur l’Abonné. La suppression n'est pas propagée au Publisher, car la commande est toujours active dans le système.

    Dans ce scénario, les suppressions ne sont pas suivies pour les tables SalesOrderHeader et SalesOrderDetail . Les suppressions sont suivies pour la table Product , car si un produit est supprimé sur le serveur de publication, la suppression doit être envoyée à l’Abonné pour maintenir la liste des produits à jour.

  • Une application peut stocker des données historiques dans une table telle que TransactionHistory, qui est régulièrement vidée des enregistrements de plus d’un an. La table peut être filtrée de sorte que les Abonnés reçoivent uniquement des données sur les transactions au cours du mois en cours. Les suppressions de lots mensuelles sur le serveur de publication qui vident les données plus anciennes ne sont pas pertinentes pour les Abonnés, mais elles seraient toujours suivies et énumérées par défaut.

    Dans ce scénario, avant le traitement par lots, l’activité peut être arrêtée sur le système et l’application peut désactiver le suivi des suppressions. Une fois le traitement terminé, le suivi peut être à nouveau activé.

Important

Si d’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

Voir aussi

Options d’article pour la réplication par fusion
Optimiser les performances de réplication de fusion avec des articles Download-Only

  • Last updated on