Discussion :

[dari68]

Bonjour,

J'ai un serveur avec une centaines de bases que je veux répliquer tous les jours ou toutes les semaines sur un autre site, alors je me demande si je me pencher sur la réplication transactionnelle ? Mirroring ? AlwaysOn ?

Merci.

@+

[SQLpro]

La réplication transactionnelle est une réplication de données et c'est fait pour du fonctionnel (envoyer certaines données de certaines tables à certaines autres bases de différents serveurs).
Ce que vous voulez c'est sans doute de la haute dispo, c'est à dire qu'un serveur de secours puisse reprendre la marche des applications en cas de défaillance majeur d'une des bases ou du serveur, je me trompe ?
Dans ce cas 4 solutions :
1) log shipping, simple à mettre en œuvre, base par base, mais pas de basculement automatique et totalement asynchrone. Latence élevée (au moins quelques minutes), autant de serveur de secours que vous désirez.
2) cluster Windows, complexe à mettre en œuvre, basculement automatique de l'instance, latence minimale de 30 secondes à quelques minutes, mode synchrone, jusqu'à 8 nœuds (serveurs de secours). Nécessite en sus une réplication physique au niveau hardware des IO sur la baie de disque partagée, pas de lecture sur les secours.
3) Mirroring (deprecated depuis la version 2012) : mise en œuvre simple à moyenne, base par base, basculement manuel ou automatique, pas de latence si mode automatique, mode synchrone ou asynchrone. Pas de lecture sur les secours.
4) AlwaysOn (apparu à partir de la version 2012) : mise en œuvre simple à moyennement dure, par groupe de bases de données, basculement manuel ou automatique, pas de latence si mode automatique, mode synchrone ou asynchrone, plusieurs serveurs de secours possible, lectures possible sur les secours et sauvegarde possible sur les secours.

A +

[SQLpro]

Mise à part pour le log shipping ou c'est vous qui décidez du moment ou vous capturez les informations nouvelles et du moment ou vous les ré-appliquées, tous les autres modes fonctionnent en continu (envoi automatique par SQL Server des transactions par communication à l'aide de Web Services internes, sauf pour le clustering qui ne fait que partager les fichiers des bases entre les nœuds.

A +

[dari68]

Bonjour et Merci de vos retours.

Le besoin est pouvoir travailler sur les données fraiches de la production de la vieille en lecture.

Merci

@+

[SQLpro]

Dans ce cas un simple backup restore devrait suffire. Les sauvegardes SQL Server sont très rapides en mode compressées, idem pour la restauration. Quelle volumétrie avez vous ?

Pouvez vous nous renvoyer le contenu de cette requête ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT ROUND(SUM(size) * 8 / 1048576.0, 3) AS TOTAL_GB
FROM   sys.master_files
WHERE  database_id > 4

Cela donne la volumétrie globale de vos bases de prod

Si en sus vous voulez les données à une date exacte (par exemple minuit au plus tard) vous pouvez utiliser des journaux de transactions avec un STOPAT (PITR)


A +

[dari68]

Ce sont des petites bases => 21.743000000 GB , ma contrainte c'est qu'il y a une centaine de bases à restaurer.

Merci.

@+