[Source] La réplication des transactions SQLserver ajoute de nouvelles tables sans réinitialisation

Il existe plusieurs façons possibles

1. Le moyen le plus simple est bien sûr de réinitialiser. Ajoutez la table (sp_addarticle ou utilisez l’assistant de copiage) et faites un clic droit pour la réinitialiser et générer un nouvel instantané.
  Cette méthode présente d’innombrables avantages, mais un inconvénient est que toutes les tables de la chaîne d’abonnement de réplication sont réinitialisées une seule fois, et les tables lues lors de l’initialisation ne contiennent aucune donnée. Cela peut aussi durer plus longtemps

2. Créer une nouvelle version, puis s’abonner séparément à la table mise à jour
  Cette méthode est relativement sécurisée et n’affectera certainement pas la chaîne d’abonnement de réplication existante, et les nouvelles tables ajoutées peuvent être initialisées à volonté. L’inconvénient, c’est qu’on ne peut pas toujours construire une version sur la dernière table, une méthode plus fiable est de migrer régulièrement le projet (le tableau) dans cette nouvelle version vers la chaîne d’abonnement officielle. Bien sûr, cela a aussi un avantage, car la nouvelle table peut parfois être prise en compte en cas de problème.

3. En trois étapes :
A. Remplir la nouvelle table avec les données de la base de données complète, en lecture/écriture (la cohérence des données est requise)
B. Arrêtez de lire le journal agent
C. Ajouter le nouveau tableau à l’abonnement de publication
D. Activer l’agent de lecture de journal
  Cette méthode n’a pas d’impact significatif sur la publication en ligne (comparée à la méthode 1), mais elle arrête la lecture et la copie des données pendant le fonctionnement, augmentant ainsi le délai de réplication en lecture/écriture. Si vous n’êtes pas sévère sur le délai de lecture et d’écriture, vous pouvez le choisir. Il est fortement recommandé de préparer le scénario à l’avance. Bataille rapide et décision rapide

Ce sont les trois méthodes qui me viennent à l’esprit

Théoriquement, le troisième type est le plus raisonnable (compromis), mais en ce qui concerne les exigences de l’environnement d’abonnement de réplication que je gère actuellement, la méthode 2 est plus souvent utilisée. Bien que cela puisse avoir un léger impact négatif sur les performances du serveur. Mais cela crée aussi une véritable réserve de sécurité pour que les DBA puissent gérer cet abonnement de réplication de 22 ans