Replication server pour de la BI

Version imprimable

03/12/2019, 10h34
ledu_alexandre

Replication server pour de la BI

Bonjour à tous,
J'ai besoin d'information sur l'architecture à mettre en place pour le besoin suivant :

J'ai un serveur SQL de production et je souhaiterai sa réplication afin de pouvoir réaliser des extractions de reportings en temps réel. Aujourd'hui j'ai des chargements une fois par jour (la nuit), cela ne répond plus au besoin de mes clients et de plus, charger une DB entièrement prend énormément de temps..

Je suis donc allé voir mon DBA pour lui demander une solution.
D'après lui, il semblerait que mettre en place une réplication de serveur ne serait pas la bonne solution, car de trop lourdes requêtes pourraient pénaliser le moteur (slave) ce qui créerait un goulot d'étranglement pour le serveur de production (master), qui aurait du mal du coup a envoyez ses transactions au serveur (slave)...

Donc sa préconisation serait de taper direct sur la production !!! OMG :weird: !

De mon point de vue, même si cela cause un ralentissement, au moins la prod reste intacte en cas de plantage du serveur.. (full tempDB ou autre.. )

SVP,
j'ai besoin de vos lumières et de vos conseils. j'ai du mal à croire qu'en 2019 le problème n'est pas déjà été rencontré avec son lot de solutions..

Un grand merci à celles et ceux qui prendront le temps de me répondre.
03/12/2019, 17h21
Boubou2020

Cluster ALWAYSON en mode read only sur le serveur secondaire

avec un routage de lecture sur le secondaire

Attention au licence car vous serez en mode cluster Actif/Actif
03/12/2019, 17h37
ledu_alexandre

Merci beaucoup pour votre réponse.

Il reste néanmoins une petite zone d'ombre pour moi concernant la performance du serveur principal.

Mon DBA me dit que si une requête trop lourde est envoyé au serveur secondaire par mon ETL par exemple, cela impacterai la performance du serveur principal (serveur de production) car la réplication aurait du mal du coup a contacter le serveur secondaire.. Et que de ce fait mon goulot d'étranglement se situerait au niveau du secondaire..

Je comprends pas que du "always on" ne puisse anticiper ce cas. Les transactions ne seraient elles pas alors enregistrées dans un cache ou autre en attendant que mon serveur secondaire soit moins sollicité?
04/12/2019, 19h52
Michel.Priori

Bonsoir,

Si c'est pour avoir une base qui est la copie de la prod au delta du refresh alors un backup/restore me semble simple et efficace.

Votre DBA pourra ainsi faire d'une pierre deux coups :
1- valider que ses sauvegardes sont opérationnelles
2- vous offrir une réponse à votre besoin.

Pour avoir une méthode automatisée il faut
1- ne pas être sur la version Express (qui n'a pas d'agent SQL donc pas de planificateur intégré)
2- que la base soit en mode complet
et faire un clic droit sur la base -> propriété -> envoi des journaux

en général l'assistant plante pour cause de contexte d'exécution et de droits de lecture ou écriture sur les partages réseau.
04/12/2019, 21h44
Invité

Citation:

Envoyé par Michel.Priori

Si c'est pour avoir une base qui est la copie de la prod au delta du refresh alors un backup/restore me semble simple et efficace.

Ça dépend de la taille de la bd, tout de même et il est précisé que c'est long à faire...
10/12/2019, 08h58
SQLpro

Citation:

Envoyé par ledu_alexandre

...
Mon DBA me dit que si une requête trop lourde est envoyé au serveur secondaire par mon ETL par exemple, cela impacterai la performance du serveur principal (serveur de production) car la réplication aurait du mal du coup a contacter le serveur secondaire.. Et que de ce fait mon goulot d'étranglement se situerait au niveau du secondaire…

Votre DBA est un con…..

Citation:

Je comprends pas que du "always on" ne puisse anticiper ce cas. Les transactions ne seraient elles pas alors enregistrées dans un cache ou autre en attendant que mon serveur secondaire soit moins sollicité?

Bien évidemment que AlwaysOn a été conçut pour parfaitement gérer ce genre de cas de figure. Par exemple chez Geodis (l'un des plus gros transporteur) la base de prod fait plus de 20 To et 2 replicas secondaires servent à assurer le reporting pour les impressions, sachant que ce sont plusieurs milliers de requêtes par seconde……

A +
10/12/2019, 14h44
ledu_alexandre

Un grand merci à tous pour m'avoir éclairé.
Vous souhaitant bonne continuation ;) .