Intégration de données provenant de plusieurs sites (Serveur)
De nombreuses sociétés ont des bureaux ou des entités régionales qui collectent et traitent des données qui doivent être envoyées à un emplacement central. Par exemple :
Des données d'inventaire peuvent être « remontées » ou consolidées depuis plusieurs serveurs d'entrepôts de données locaux vers un serveur central au niveau du siège.
Des informations des divisions commerciales autonomes d'une société peuvent être envoyées à un serveur central.
Des informations de traitement des commandes provenant d'emplacements dispersés peuvent être consolidées.
Dans certains cas, des données sont également envoyées du site central vers des sites distants. Ces données sont généralement destinées à être des données en lecture seule sur le site distant, par exemple dans le cas de tables d'inventaire de produits qui sont seulement mises à jour sur un site central.
Le diagramme suivant montre un scénario courant, où des données sont remontées depuis des sites distants. Des données en lecture seule sont également envoyées à chaque site distant.
.gif "Réplication de données vers les bureaux régionaux")
Exemple de la base de données Adventure Works Cycles
Adventure Works Cycles est une société de fabrication fictive utilisée pour illustrer des scénarios et des concepts de base de données. Pour plus d'informations, consultez Exemples de bases de données AdventureWorks.
Adventure Works Cycles a plusieurs bureaux de vente régionaux à travers les États-Unis. Ces bureaux utilisent la réplication de deux façons :
Pour fournir les informations sur les commandes, destinées à l'exécution des commandes et à la création de rapports. Les données sont collectées et traitées dans chaque bureau de vente, puis elles sont répliquées vers le bureau central.
Pour offrir des possibilités de consultation de données et de prise de commande à leur équipe de vendeurs mobiles. Ce scénario est décrit dans la rubrique Échange de données avec des utilisateurs mobiles.
Conditions générales requises pour ce scénario
Les applications des bureaux régionaux ont généralement les besoins suivants, qui doivent être satisfaits via une solution de réplication appropriée :
Le système doit maintenir la cohérence transactionnelle.
Le système doit avoir une latence faible : les mises à jour sur les sites distants doivent atteindre rapidement le site central.
Le système doit avoir une capacité de traitement élevée : il doit pouvoir gérer la réplication d'un grand nombre de transactions.
Le processus de réplication doit impliquer une surcharge de travail minimale sur les sites distants.
Les modifications des données doivent circuler dans les deux sens : dans certains cas, des données en lecture seule sont envoyées aux sites distants, en plus des données envoyées pour consolidation des sites distants vers le site central.
Les données requises sur le site central peuvent être un sous-ensemble des données disponibles sur chaque site distant.
Type de réplication à utiliser pour ce scénario
MicrosoftSQL Server utilise une métaphore du secteur de l'édition pour décrire les composants du système de réplication. Les composants comprennent le serveur de publication (l'éditeur), des abonnés, des publications et des articles, ainsi que des abonnements.
Dans le diagramme ci-dessus, chaque site distant est un serveur de publication. Tout ou partie des données sur le site distant sont incluses dans la publication, chaque table de données constituant un article (les articles peuvent aussi être d'autres objets de base de données, par exemple des procédures stockées). Le site central est un abonné à ces publications, qui reçoit un schéma et des données sous forme d'abonnements.
Le site central sert également de serveur de publication pour les données qui sont envoyées aux sites distants. Chaque site distant s'abonne à la publication du site central.
Pour plus d'informations sur les composants du système, consultez Présentation du modèle de publication de réplication.
SQL Server offre différents types de réplication pour les différents besoins des applications : la réplication de capture instantanée, la réplication transactionnelle et la réplication de fusion. La meilleure mise en œuvre de ce scénario se fait avec la réplication transactionnelle, qui convient bien pour gérer les besoins indiqués dans la section précédente. Pour plus d'informations sur la réplication transactionnelle, consultez Présentation de la réplication transactionnelle et Fonctionnement de la réplication transactionnelle.
Par sa conception, la réplication transactionnelle répond aux principaux besoins de ce scénario :
Homogénéité des transactions
Latence faible
Haute capacité de traitement
Charge minimale
[!REMARQUE]
Un scénario similaire peut être mis en œuvre avec la réplication de fusion. Si votre application requiert la résolution des conflits ou des filtres qui fournissent à chaque site distant un jeu de données unique, utilisez la réplication de fusion. Pour plus d'informations, consultez Intégration de données à partir de plusieurs sites (client).
Étapes pour la mise en œuvre de ce scénario
Pour mettre en œuvre ce scénario, vous devez d'abord créer une publication et des abonnements, puis initialiser chaque abonnement. Cliquez sur les liens ci-dessous pour plus d'informations sur chacune des étapes :
Quand l'abonnement a été initialisé et que les données circulent entre le serveur de publication et les Abonnés, il peut être nécessaire de consulter les rubriques suivantes pour des informations sur les tâches courantes d'administration et de surveillance :