Discussion :

[nico1492]

Bonjour,

Nous sommes en phase de test de mise en place d'une réplication SQL Server d'une base "master" vers une seule "slave" abonnée. (instances et serveurs différents)

Le côté mise en place sur environnement de test n'a posé aucun problème, les bases se répliquent bien en mode transactionnel après un snapshot initial, je n'ai que quelques secondes d'écart en terme de données, ce qui est tout à fait acceptable puisque l'idée de la slave est de mettre sur pied une alternative en readonly pour du reporting et arrêter de solliciter la prod.

Sauf que je m'aperçois que sur l'instance où la base "slave" se trouve, j'ai un souci de performances sur des requêtes. Attention : pas un souci de performance de réplication, un souci de perf sur la base SQL "slave", autrement dit un SELECT sur une table met 10 secondes sur la slave alors qu'il met 3 secondes sur master. Alors que la Slave n'est absolument pas sollicitée.
Si je fais un backup de la master pour restore sur la même instance où se trouve la base slave, pour comparer, là je retrouve des performances comparables à la master. Seule la base "slave" semble être impactée sur l'instance, pas la copie de la prod faite en backup/restore à la main.

Comment l'expliquer ?

Les pistes déjà explorées :

- problème d'index tables (j'ai activé depuis la réplication des index non clustered qui ne l'étaient pas par défaut), mais même problème ensuite, pas d'amélioration avec pourtant des index identiques entre prod et slave
- arrêt du moteur de synchronisation sur l'instance "slave" juste pour tester (car j'ai choisi de le faire tourner sur le slave pour déporter la charge de travail dessus plutôt que la prod), mais pas d'amélioration non plus

Auriez-vous des pistes générales à explorer ? Est-ce quelque chose de connu ? (Par ex. une base slave issue de réplication est par définition moins performante ?)

Merci pour vos lumières

[SQLpro]

• Est-ce que vos machines sont strictement identiques ? Si ce sont des VM, est-ce que les coeurs et le RAM sont fixés ?
• Les versions / éditions de SQL Server sont-elles les memes ?
• Les ressources allouées sont-elles identiques ?
• La réplication transactionnelle ne propage pas la maintenance des index... Faites vous une maintenance d'index et stats régulièrement ?
• Êtes vous en mode de verrouillage optimiste ou pessimiste ?
• La base tempdb est-elle correctement dimensionnée ? (y a t-il eu des opérations de croissance de fichiers)...

Enfin, très important, OS ? Version/edition de SQL Server ? Patch/CU ???

A

[nico1492]

Bonjour, merci pour ta réponse.

Je veux bien entendu bien répondre à ces questions, mais comment expliquer que sur même instance, donc même serveur, une copie backup/restore de la base prod soit plus performante que la base slave complètement répliquée à partir de la prod ?
On devrait dans ce cas avoir des performances identiques non (en considérant que les index sont bien répliqués ce qui est le cas) ? C'est surtout ça ma question.

J'ai l'impression que les questions posées ne tiennent pas compte de cette précision, si ? (Car clairement, nous ne sommes pas dans une condition "best performances" car nous sommes en tests, le but ce ne sont pas les perfs. C'est juste de comprendre pourquoi on a cette disparité sur une base a priori identique, sur même instance, même serveur)

[SQLpro]

Il peut y avoir de multiples réponses, comme par exemple le vieillissement des statistiques, la non maintenance des index ou encore le verrouillage pessimiste.....

Par exemple, votre base répliquée fait de nombreux INSERT/UPDATE/DELETE ce qui pose des verrous exclusifs et retarde/empêche les lectures...

C'est pourquoi il est important de séraaliser le problème en répondant à toutes les questions....

A +