[Джерело] Реплікація транзакцій SQL Server додає нові таблиці без повторної ініціалізації

Існує кілька можливих способів

1. Найпростіший спосіб — це, звичайно, повторна ініціалізація. Додайте таблицю (sp_addarticle або скористайтеся майстром копіювання) і клацніть правою кнопкою миші, щоб переініціалізувати її для створення нового знімка.
  Цей метод має безліч переваг, але одним із недоліків є те, що всі таблиці в ланцюжку підписки реплікації переініціалізуються один раз, а таблиці, прочитані під час ініціалізації, не містять даних. Він може служити довше

2. Створіть новий реліз, а потім окремо оформіть підписку на оновлену таблицю
  Цей метод відносно безпечний і точно не вплине на існуючий ланцюжок підписок реплікації, а нові таблиці можна ініціалізувати за бажанням. Недолік у тому, що не завжди можна створити реліз на останній таблиці, більш надійний спосіб — регулярно мігрувати проєкт (таблицю) у цьому новому релізі до офіційного ланцюга підписки релізів. Звісно, у цьому є й перевага, адже нову таблицю іноді можна вирішити, коли виникає проблема.

3. У трьох кроках:
A. Заповніть нову таблицю даними про повну базу даних читання/запису (потрібна узгодженість даних)
Б. Припиніть читати журнал-агент
C. Додати нову таблицю до підписки на публікації
D. Увімкнути агент читання журналів
  Цей метод не має суттєвого впливу на онлайн-публікацію (порівняно з методом 1), але припиняє читання та копіювання даних під час роботи, збільшуючи затримку реплікації читання/запису. Якщо ви не суворі до затримки читання і запису, можете обрати його. Рекомендується заздалегідь підготувати сценарій. Швидкий бій і швидке рішення

Ось три методи, які спадають на думку

Теоретично третій тип є найбільш розумним (компроміс), але щодо вимог середовища підписки на реплікацію, яким я зараз керую, частіше використовують метод 2. Хоча це може трохи негативно вплинути на продуктивність сервера. Але це також створює належний буфер для DBA для управління цією 22-річною підпискою на реплікацію