Quels facteurs objectifs indiquent qu'il est temps d'implémenter la réplication SQL Server?

J'essaie de trouver un équilibre entre les performances élevées de notre base de données et la facilité de maintenance. Nous envisageons d'utiliser la réplication pour améliorer les performances, en répliquant nos rapports SSRS dans une base de données physiquement distincte de notre base de données transactionnelle. Cependant, l'activation de la réplication présente un certain nombre d'inconvénients du point de vue du développeur:

• Cela rend les changements de schéma plus difficiles
• Il interfère avec notre serveur d'intégration / de construction automatisé
• Il semble compliquer la mise en œuvre du contrôle de code source SQL

Ma question est : quand savez-vous qu'il est temps de procéder à la réplication à la lumière de ces inconvénients? Comment décidez-vous si la complexité supplémentaire justifie les gains?

Nous l'avons utilisé auparavant, donc sa configuration n'est pas un problème. Il s'agit davantage de prendre la décision de l'activer ou non. Je recherche des mesures de performances d'objets que d'autres ont observées avec la réplication.

Bien sûr, la meilleure chose serait de faire des tests de charge simulés sur nos propres serveurs et de le comprendre nous-mêmes, mais j'espère qu'il existe des directives générales.

La réplication doit être envisagée pendant la phase de conception de l'application. Si vous avez un effectif / une base d'utilisateurs répartis géographiquement, il peut être judicieux d'avoir des bases de données régionales et des bases de données centrales. Les bases de données déconnectées sur les ordinateurs portables peuvent se "synchroniser" lorsqu'elles se reconnectent enfin au réseau (pensez aux vendeurs sur la route).

En ce qui concerne les rapports, la réplication n'est PAS la réponse. La plupart des problèmes de performances dans un environnement de génération de rapports proviennent du fait que les rapports sont écrits sur un système configuré pour le traitement des transactions en ligne (OLTP).

La réplication à des fins de génération de rapports consiste simplement à déplacer vos données OLTP vers un autre serveur, tout en conservant la même structure hostile aux rapports. En substance, vous jetez plus de matériel sur le problème et augmentez vos coûts de maintenance, mais pour des gains marginaux.

Ce que vous devriez regarder, c'est comment obtenir les données spécifiques dont vos rapports ont besoin et les transformer en un format plus utile. Créez un flux qui récupère les nouvelles transactions de votre base de données de production et les stocke dans une base de données de rapports, de préférence sur un serveur distinct. Chaque fois que le flux s'exécute, il doit récupérer toutes les données plus récentes que la dernière fois qu'il a été exécuté, transformer ces données et les stocker. Les rapports que vous exécutez actuellement vous donneront une bonne idée des types de transformations nécessaires.

En suivant cette approche, vous allez bénéficier d'énormes avantages en termes de performances.

Pour ce que cela vaut, nous avons trouvé la réplication utile dans une situation similaire car les rédacteurs de rapports peuvent "posséder" les index de la base de données répliquée. Cela nous a permis d'améliorer les performances des requêtes en ajoutant des index que les développeurs d'applications n'auraient jamais approuvés en production en raison de leur impact négatif sur les INSERTS et les MISES À JOUR.

Peut-être qu'une partie de votre cas d'utilisation consiste à copier des tables transactionnelles, à modifier certaines indexations et à voir si cela en vaut la peine?

J'espère que cela t'aides!