Discussion :

[santana45]

Bonjour à tous,

Je suis actuellement en phase de développement pour la refonte d'un laboratoire d'essais et je souhaite, dans un premier temps, synchroniser deux bases de données SQL.

J'ai deux bases de données :

- SRV01 en local qui récupère des données provenant de bancs d'essais avec une application LabVIEW et stocke les données au sein d'une base de données SQL Express 2012.
- SRV02 qui va servir de base de données "centrale" avec SQL Server 2008 R2.

Je ne suis pas du tout administrateur de bases de données mais j'ai besoin de conseils ou de propositions pour arriver au résultat désiré.

La base de données en local va enregistrer 240 données à la seconde et il est prévu de relier 6 à 10 autres bancs (donc 6 autres BDD local) avec la même infrastructure.

Je souhaite que toutes les heures (par exemple), uniquement les "nouvelles" données depuis SRV01 soient mises à jour sur SRV02. Si je me trompe pas, j'ai vu que l'on pouvait faire cela via une réplication par fusion mais je vous avouerai que je suis un peu perdu sur les différentes étapes à réaliser pour la mettre ne place.

Je voudrais savoir si le résultat que je souhaite avoir correspond à une réplication par fusion ou me conseiller sur une technique plus simple ou m'envoyer vers un "tutoriel" pour les noobs :-)

Merci d'avance de l'aide que vous pourrez m'apporter.

Santana

[SQLpro]

La réplication par fusion, n'est ps du tout indiquée dans votre cas. La réplication par fusion est intéressantes dans le cas ou les données des différentes bases répliquées peuvent être mises à jour (INSERT, UPDATE, DELETE, MERGE) et renvoyées de l'une à l'autre. Par exemple les bases LabView font des mises à jour envoyées au serveur central et le serveur central fait des mises à jour renvoyés aux bases LabView...
Or je suppose pour avoir pas mal travaillé les LIMS, que vous n'effectuez pas de mise à jour en retour du serveur central vers vos données stockées dans les bases LabView...
De surcroit, la réplication de fusion engendre systématiquement des conflits de réplication qu'il faut tenter d'éviter, table par table en écrivant des déclencheurs pour chaque table dans chaque base, et même avec cela il est encore possi ble d'avoir de nouveaux conflits de réplication qu'il faudra résoudre manuellement...

Dans votre cas, la réplication la plus adaptée est la réplication transactionnelle. C'est d'ailleurs la seule à garantir l'intégrité des données répliquée. Il ne peut être fait que dans un seul sens de flux depuis vos bases LabView vers la base centrale.

dans toutes les réplications de données, il faut que les tables répliquées aient les mêmes structures.

Si ce n'est pas le cas, une solution alternative est d'utiliser Service Broker qui est destiné à réaliser des bases de données distribuées et ventiler les données, les communiquer et les transmettre entre les différents serveurs.

Enfin 240 données à la seconde, c'est ps grand chose, même pour de la version Express.

Avec 10 bases vous n'en seriez qu'à 2400 à la seconde.. Sachez que les records établis pour SQL server dépassent plusieurs millions de transactions à la minute. Ramené à la seconde, cela fait dans les 100 000 transactions par seconde, une transaction comptant souvent de nombreuses données !!!

A +

[santana45]

Bonjour,

Merci de votre réponse aussi rapide et précise. J'en était pas sur mais maintenant j'ai une idée du fonctionnement de ces deux modes de réplication.

J'ai une autre question du coup, la base de données LabVIEW sachant qu'elle est en SQL Server Express 2012, Est-ce possible de configurer une réplication transactionnelle depuis une telle version ?

Pour les 2400 transactions à la seconde, le système de base de données LabVIEW a été pensé pour éviter d'avoir un trop gros trafic réseaux en temps réel mais si cela est peu, je devrai probablement repenser à une connexion directe entre l'application et la base de données centrale sans passer par une base de données en local...?

Bonne journée,

[SQLpro]

Bonjour,

Merci de votre réponse aussi rapide et précise. J'en était pas sur mais maintenant j'ai une idée du fonctionnement de ces deux modes de réplication.

J'ai une autre question du coup, la base de données LabVIEW sachant qu'elle est en SQL Server Express 2012, Est-ce possible de configurer une réplication transactionnelle depuis une telle version ?

La réplication transactionnelle se soucie peu du versionning des bases à condition que vous n'utilisiez pas de types de données inconnues d'une version à l'autre. Entre 2012 et 2016 le risque est donc très faible.

Pour les 2400 transactions à la seconde, le système de base de données LabVIEW a été pensé pour éviter d'avoir un trop gros trafic réseaux en temps réel mais si cela est peu, je devrai probablement repenser à une connexion directe entre l'application et la base de données centrale sans passer par une base de données en local...?

Personnellement j'opterais pour la "Rolls Royce" concernant cette réplication en utilisant Service Broker.
Le principe serait alors le suivant ;
1) laisser vos serveur version Express 2012 sur chacun des PC des bancs
2) mettre en œuvre Service Broker pour communiquer de manière asynchrone, sécurisé (chiffrement), transactionné, fiable et performant sous fome XML les données des bancs vers le serveur central.
Service broker présente tous les avantages et un seul inconvénient celui de devoir vous demander un peu plus d'effort pour créer votre propre mécanisme de réplication. Mais il est extrêmement résilient et extraordinaire souple et rapide, et aucune perte de donnée ne devrait se produire sauf si le PC crame !

Nous avons mis cela en œuvre pour Pasteur Mérieu concernant les chaines de fabrication de vaccins.

A +

[santana45]

Désolé de ma réponse tardive, je me renseignais sur les informations que tu as fournis.

C'est vrai que le "Service Broker" à l'air très intéressant et correspondrait tout à fait à ce que je veux et parait plus souple mais je n'ai pas les compétences nécessaires pour le mettre en place et je saurais difficilement le dépanner.

J'opte donc plus pour la réplication transactionnel à tord probablement. J'ai une dernière question de noob à poser. comme je vous l'ai dis je débute dans SQL, je dois répliquer mes données depuis la base de données LabVIEW vers la base centrale, pouvez-vous me confirmer que le serveur publicateur (publication) est la base LabVIEW et le souscripteur (subscription) est la base centrale ?

En gros, Est-ce que je peux rendre mon serveur en SQL Express, la source de mes données à répliquer ensuite sur le serveur centrale car j'ai effectué plusieurs essais et cela ne fonctionne pas mais peut-être il y a un aspect de la configuration de la réplication que je n'ai pas saisie.

Merci de vos précisions et de votre aide.

Santana

[santana45]

En ayant fait des recherches et fait de multiples tests, la réplication transactionnelle ne peut pas fonctionner car mon serveur de publication ne peut être que en version SQL Server Standard ou Enterprise. J'ai justement besoin que ma base de publication soit la base LabVIEW mais comme à terme je vais avoir près de 10 bases connectées à a base de données centrale, je ne peux pas me permettre d'acheter 10 licences SQL Server Standard c'est ridicule.

Reste plus qu'à regarder le service broker ou sinon voir une autre infra... mais c'est bizarre que Microsoft n'est pas de solution pour ce cas de figure avec le système de réplication...