[Quelle] Die SQL-Server-Transaktionsreplikation fügt neue Tabellen ohne Neuinitialisierung hinzu

Es gibt mehrere mögliche Wege

1. Am einfachsten ist es natürlich, neu zu initialisieren. Füge die Tabelle hinzu (sp_addarticle oder benutze den Kopierassistenten) und klicke mit Rechtsklick, um sie neu zu initialisieren und einen neuen Schnappschuss zu erzeugen.
  Diese Methode hat unzählige Vorteile, aber ein Nachteil ist, dass alle Tabellen in der Replikations-Abonnementkette einmal neu initialisiert werden und die während der Initialisierung gelesenen Tabellen keine Daten enthalten. Es kann auch länger anhalten

2. Erstellen Sie eine neue Version und erstellen Sie anschließend separat ein Kopie-Abonnement für die aktualisierte Tabelle
  Diese Methode ist relativ sicher und beeinflusst sicherlich nicht die bestehende Replikations-Abonnementkette, und neu hinzugefügte Tabellen können nach Belieben initialisiert werden. Der Nachteil ist, dass man nicht immer eine Veröffentlichung auf der letzten Tabelle aufbauen kann; eine zuverlässigere Methode ist, das Projekt (die Tabelle) in dieser neuen Version regelmäßig auf die offizielle Versions-Abonnementkette zu migrieren. Natürlich hat das auch einen Vorteil, denn manchmal kann man mit dem neuen Tisch umgehen, wenn es ein Problem gibt.

3. In drei Schritten:
A. Füllen Sie die neue Tabelle mit Daten aus der vollständigen Lese-/Schreibdatenbank (Datenkonsistenz ist erforderlich)
B. Hör auf, das Log-Agent zu lesen
C. Füge die neue Tabelle zum Publishing-Abonnement hinzu
D. Aktiviere den Log Read Agent
  Diese Methode hat keinen signifikanten Einfluss auf die Online-Veröffentlichung (im Vergleich zur Methode 1), stoppt jedoch das Lesen und Kopieren von Daten während des Betriebs, wodurch die Lese-/Schreibreplikationsverzögerung erhöht wird. Wenn du nicht streng mit der Lese- und Schreibverzögerung bist, kannst du es wählen. Es wird dringend empfohlen, das Skript im Voraus vorzubereiten. Schneller Kampf und schnelle Entscheidung

Das sind die drei Methoden, die mir einfallen

Theoretisch ist der dritte Typ der vernünftigste (Kompromiss), aber wenn es um die Anforderungen der Replikations-Abonnementumgebung geht, die ich derzeit verwalte, wird Methode 2 häufiger verwendet. Allerdings könnte es einen leichten negativen Einfluss auf die Serverleistung haben. Aber es schafft auch einen angemessenen Puffer für DBAs, um dieses 22-jährige Replikationsabonnement zu verwalten