Migration d'une base SQL Server sans perte de donnée

Bonjour,
J'ai une question qui me hante depuis quelques jours, comment faire une migration SQL Server sans perdre de donné.
(actuelement, pour faire une migration on fait un backup full et on déploie l .bak sur la nouvelle machine).

On peut également faire une migration avec le .bak + les fichiers transaction log si la base est en modèle full, mais ça ne change rien sur le fait que la restauration + récupération est incroyablement long.
(et que la base est fermé le temps de la migration).
et que si on a 200 bases SQL Server, ça risque d'être compliqué à migrer.

Une autre solution qui m'a traversé l'esprit, pourquoi on ne ferai pas une réplication transactionnel sur la machine de prod? (ça nous évite de fermer les bases durant la migration non?)
(n'hésitez pas à m'arrêter si je dis une connerie surtout que je pense que j'en dis une :p).

Du coup, je voulais savoir comment vous faîtes pour migrer vos bases SQL Server de votre instance préprod vers votre serveur de prod par exemple?

Vous n'avez pas à fermer les bases pour faire une sauvegarde en vue de migrer, à moins que vous ne vouliez abandonner définitivement l'ancien serveur.

Une solution pour minimiser le temps de migration et même n'avoir aucune coupure est d'utiliser le principe du mirroring ou de AlwaysOn.
Ces deux systèmes (le mirroring étant plus simple dans votre cas) procède par duplication de l'intégralité des bases...

A +

Citation:

---

Envoyé par Providence0

J'ai une question qui me hante depuis quelques jours, comment faire une migration SQL Server sans perdre de donné.
(actuelement, pour faire une migration on fait un backup full et on déploie l .bak sur la nouvelle machine).

---

C'est une bonne méthode. C'est ce que j'utilise quand j'en ai besoin. Mais c'est très rare ^^ La migration intervient quand je change de serveur par exemple, pour pour gérer des mises à jour.

Citation:

---

Envoyé par Providence0

Une autre solution qui m'a traversé l'esprit, pourquoi on ne ferai pas une réplication transactionnel sur la machine de prod? (ça nous évite de fermer les bases durant la migration non?)
(n'hésitez pas à m'arrêter si je dis une connerie surtout que je pense que j'en dis une :p).

---

Tu prends le problème à l'envers. L'objectif de la réplication transactionnel est de transmettre l'intégralité des changements d'une base vers une autre, et non de faire une fusion des modifications ! A moins que ta base de données de production ne soit en lecture seule, prendre le risque de se retrouver avec des conflits de mise à jour en prod est une très très très mauvaise idée.

Citation:

---

Envoyé par Providence0

Du coup, je voulais savoir comment vous faîtes pour migrer vos bases SQL Server de votre instance préprod vers votre serveur de prod par exemple?

---

Pour ma part, je réalise des scripts. Toute mise à jour de ma base de données passe par la création d'un script SQL qu'il me suffit d'exécuter pour mettre à jour l'instance. J'écris mon script lors des dev. Je teste le script en préprod. Après validation, je le passe en prod.

[EDIT]
En fait, je crois que je suis complètement hors sujet ! Le problème n'est pas de mettre à jour une base de données, mais de la mettre en prod. J'ai été trompé par l'aspect "et que la base est fermé le temps de la migration"...
[/EDIT

Je n'ai jamais testé mais j'ai vu une session lors des derniers SQL Saturday à Paris par Chrissy Lemaire qui fait une migration via powershell.

Si tu fais une recherche sur google avec "dbatools powershell", tu auras tous ces scripts. Si tu es à l'aise avec powershell, tu peux faire un test.

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

J'ai lu ce que vous avez écris et je pense que je vais creuser un peu plus sur la méthode de Mirroring.

Mais du coup, si j'ai bien compris :
Mirroring = High availability = haute disponibilté = permet de répliquer les données sur 2 bases différentes (Donc en plus d'être une méthode pour migrer une base vers un autre serveur sans arrêter la base, il joue également le rôle de fail over et de load balancer vu qu'il fait de la répartition de charge et que si le serveur contenant la base 1 a un soucis, j'ai toujours la base 2 qui tourne) ? (C'est complètement génial 8O)


Dans ce cas, je ne suis pas sûr d'avoir bien saisi le but de la réplication?
Surtout qu'en fonction des méthodes choisi il peut y avoir plusieurs contraintes
(comme le fait que la base de publication ne doit pas être plus vieille que la base de distribution
ou
qu'en réplication transactionnel, la base de distribution est en read-only).
J'ai lu la description de dorinf sur la réplication transactionnel (qui permet de "transmettre l'intégralité des changements d'une base vers une autre") mais si c'est pour avoir une base de publication en read-only, je me dis autant faire un Mirroring non?

Citation:

---

Envoyé par Providence0

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

J'ai lu ce que vous avez écris et je pense que je vais creuser un peu plus sur la méthode de Mirroring.

Mais du coup, si j'ai bien compris :
Mirroring = High availability = haute disponibilté = permet de répliquer les données sur 2 bases différentes (Donc en plus d'être une méthode pour migrer une base vers un autre serveur sans arrêter la base, il joue également le rôle de fail over et de load balancer vu qu'il fait de la répartition de charge et que si le serveur contenant la base 1 a un soucis, j'ai toujours la base 2 qui tourne) ? (C'est complètement génial 8O)

---

Attention, dans le cadre du mirroring la base miroir n'est pas accessible. Dans le cas de AlwaysOn, les replicas peuvent être lus uniquement

Citation:

---

Dans ce cas, je ne suis pas sûr d'avoir bien saisi le but de la réplication?

---

Le terme réplication est assez galvaudé et appliqué à tout et n'importe quoi. Dans SQL Server la réplication sert à répliquer des données d'une base à l'autre; des données ne signifie en aucune manière l'intégralité des tables et lignes de la base, mais un choix de tables et pour certaines lignes. De plus la base de destination n'a pas l'obligation d'avoir strictement les mêmes tables, ni que les tables répliquées aient la même structure... !

Citation:

---

Surtout qu'en fonction des méthodes choisi il peut y avoir plusieurs contraintes
(comme le fait que la base de publication ne doit pas être plus vieille que la base de distribution
ou
qu'en réplication transactionnel, la base de distribution est en read-only).
J'ai lu la description de dorinf sur la réplication transactionnel (qui permet de "transmettre l'intégralité des changements d'une base vers une autre") mais si c'est pour avoir une base de publication en read-only, je me dis autant faire un Mirroring non?

---

Non, du ALwaysOn !

A +

Merci pour votre aide :)

Vu que le sujet commence à partir sur la différences des différentes méthode de réplication,
J'ai créé un autre topic portant ce nom :
http://www.developpez.net/forums/d16...ransactionnel/