[Šaltinis] SQL serverio operacijų replikacija prideda naujų lentelių be pakartotinio inicijavimo

Yra keli galimi būdai

1. Lengviausias būdas, žinoma, yra iš naujo inicijuoti. Pridėkite lentelę (sp_addarticle arba naudokite kopijavimo vedlį) ir dešiniuoju pelės mygtuku spustelėkite, kad ją iš naujo inicijuotumėte ir sugeneruotumėte naują momentinę nuotrauką.
  Šis metodas turi daugybę privalumų, tačiau vienas trūkumas yra tas, kad visos replikacijos prenumeratos grandinės lentelės yra iš naujo inicijuojamos vieną kartą, o inicijavimo metu perskaitytos lentelės neturi duomenų. Tai taip pat gali trukti ilgiau

2. Sukurkite naują leidimą ir atskirai užsiprenumeruokite atnaujintos lentelės kopiją
  Šis metodas yra gana saugus ir tikrai neturės įtakos esamai replikavimo prenumeratos grandinei, o naujai pridėtas lenteles galima inicijuoti savo nuožiūra. Trūkumas yra tas, kad ne visada galite sukurti leidimą paskutinėje lentelėje, patikimesnis būdas yra reguliariai perkelti projektą (lentelę) šiame naujame leidime į oficialią leidimo prenumeratos grandinę. Žinoma, tai taip pat turi pranašumą, nes iškilus problemai kartais galima išspręsti naują lentelę.

3. Trimis etapais:
A. Užpildykite naują lentelę duomenimis apie visą skaitymo/rašymo duomenų bazę (reikalingas duomenų nuoseklumas)
B. Nustokite skaityti žurnalo agentą
C. Naujos lentelės įtraukimas į publikavimo prenumeratą
D. Įgalinkite žurnalo skaitymo agentą
  Šis metodas neturi didelės įtakos internetinei publikacijai (palyginti su 1 metodu), tačiau veikimo metu jis nustoja skaityti ir kopijuoti duomenis, padidindamas skaitymo/rašymo replikavimo delsą. Jei nesate griežtas dėl skaitymo ir rašymo vėlavimo, galite jį pasirinkti. Labai rekomenduojama scenarijų paruošti iš anksto. Greitas mūšis ir greitas sprendimas

Tai yra trys metodai, kurie ateina į galvą

Teoriškai trečiasis tipas yra pats protingiausias (kompromisas), tačiau kalbant apie replikacijos prenumeratos aplinkos reikalavimus, kuriuos šiuo metu valdau, dažniau naudojamas 2 metodas. Nors tai gali turėti nedidelę neigiamą įtaką serverio našumui. Tačiau tai taip pat sukuria tinkamą buferį DBA valdyti šią 22 metų replikacijos prenumeratą