[Källa] SQLserver-transaktionsreplikering lägger till nya tabeller utan ominitialisering

Det finns flera möjliga sätt

1. Det enklaste sättet är förstås att starta om. Lägg till tabellen (sp_addarticle eller använd kopieringsguiden) och högerklicka för att återinitiera den och skapa en ny snapshot.
  Denna metod har otaliga fördelar, men en nackdel är att alla tabeller i replikationsprenumerationskedjan reinitialiseras en gång, och de tabeller som läses under initialiseringen har ingen data. Det kan också hålla längre

2. Skapa en ny version och gör sedan en kopiprenumeration på den uppdaterade tabellen separat
  Denna metod är relativt säker och kommer definitivt inte att påverka den befintliga replikationsprenumerationskedjan, och nyligen tillagda tabeller kan initieras när som helst. Nackdelen är att du inte alltid kan bygga en release på den senaste tabellen, ett mer pålitligt sätt är att regelbundet migrera projektet (tabellen) i denna nya release till den officiella versionsprenumerationskedjan. Naturligtvis finns det också en fördel med detta, eftersom det nya bordet ibland kan hanteras när det uppstår problem.

3. I tre steg:
A. Fyll den nya tabellen med data i hela läs-/skrivdatabasen (datakonsistens krävs)
B. Sluta läsa loggagenten
C. Lägg till den nya tabellen i publiceringsprenumerationen
D. Aktivera loggläsagenten
  Denna metod har ingen betydande påverkan på onlinepublicering (jämfört med metod 1), men den stoppar läsning och kopiering av data under drift, vilket ökar fördröjningen för läs-/skrivreplikering. Om du inte är hård med läs- och skrivfördröjningen kan du välja det. Det rekommenderas starkt att förbereda manuset i förväg. Snabb strid och snabbt beslut

Det här är de tre metoder som dyker upp i mitt huvud

Teoretiskt sett är den tredje typen den mest rimliga (kompromiss), men när det gäller kraven i den replikationsprenumerationsmiljö jag för närvarande hanterar används metod 2 oftare. Även om det kan ha en liten negativ inverkan på serverprestandan. Men det skapar också en ordentlig buffert för DBA:er att hantera denna 22-åriga replikeringsprenumeration