Discussion :

[Alberic81]

Bonjour,

j'ai 2 bases de données SQL sur 2 serveurs distincts.
L'un étant le serveur principal et l'autre celui de secours.

En fonctionnement normal, les mêmes données sont enregistrées sur les 2 serveurs.

Pour pallier à d'éventuelles pertes de données sur l'un des serveurs, je dois effectuer une consolidation périodique des données dans les 2 sens :
=> compléter la base de données du serveur 1 avec celle du serveur 2 et vice-versa.

Comment dois-je procéder ?

[Boubou2020]

la réplication de fusion répond bien a votre besoin , Transfert des données dans les deux sens

[SQLpro]

Pourquoi n'utilisez vous pas les mécanismes intégrés et dédiés à la haute disponibilité, comme le mirroring ou AlwaysOn, plutôt que d'utiliser une roue branlante ?

A +

[aserf]

Bonjour,

Il serait effectivement préférable d'utilisé les mécanismes natif de sql server.
Maintenant si ce n'est pas possible, il faut que vous ayez développer votre base de donnée en ce sens.
Est ce que vous avez des clef primaire en Uniqueidentifier ou en Autoincrement ?
Est ce que vous avez des jointure récursive ?

Si vous répondez Uniqueidentifier et pas de récursivité, alors j'ai développer un soft qui vous écris automatiquement un script de synchro sql (il tiens compte de toute les relation et ordonne l’exécution des requette par l'ordre des relations).
libre a vous ensuite de l’appeler par code ou ligne de commande.

Cordialement,

[Alberic81]

Bonjour,

Tout d'abord, merci pour vos réponses.

Vu la grande quantité de données enregistrées sur nos bases, nous avons abandonné l'idée de réplication car cette action est beaucoup trop longue.

Nous sommes donc parti sur un export des bases primaires suivit d'un import sur les bases secondaires.

Cordialement

[julien94320]

Bonjour,

Je suis d'accord avec SQLpro le Mirroring ou une solution Always On semble la solution devant répondre a votre besoin.

[SQLpro]

Vu la grande quantité de données enregistrées sur nos bases, nous avons abandonné l'idée de réplication car cette action est beaucoup trop longue.

Décision sage, la réplication de données ne doit concerner que certaines données de certaines tables et non pas des bases entière ce n'est absolument pas fait pour faire de la "haute disponibilité...

Nous sommes donc parti sur un export des bases primaires suivit d'un import sur les bases secondaires.

Donc vous avez réinventé la roue, avec les inconvénients suivants :

• maximisation des ressources utilisées et donc dégradation des performances
• interruption de service lors des manœuvres de restauration
• possibilité de perte totale des données si conjointement la base source est endommagé et la restauration ne peut s'effectuer (vérifiez vous au moins vos sauvegarde après les avoir lancées ?)
• moins grande fiabilité globale
• pas de reprise synchrone possible
• latence des données entrainant une perte très importante en cas de crash
• intervention manuelle en cas de nécessité de basculement
• impossibilité de réparer automatiquement une base endommagée

Un système comme le mirroring ou AlwaysOn assure tous ces service et permet de basculer automatiquement (sans que les applications ne s'en aperçoivent et sans interruption du service des données). C'est un service léger en terme de ressources et avec AlwaysOn on peut définir jusqu'à 4 à 8 serveurs de secours avec la même licence en fonction de la version (2012 ou 2014). Comme vous pouvez le faire fonctionner en synchrone aucune perte de données en cas de crash. Vous pouvez mixer synchrone et asynchrone pour plus de sécurité. Avec le mode synchrone, pas de latence... Enfin, SQL Server répare tout seul les bases endommagées en allant reconstituer les pages abimées d'une base en les demandant à l'autre !

A +