|
Kui veebipõhine tehingu koopia tellimus on käimas, pead nüüd lisama sellele uue tabeli. On mitmeid võimalikke viise
1. Lihtsaim viis on muidugi taasalustada. Lisa tabel (sp_addarticle või kasuta kopeerimisviisardit) ja paremklõps, et see uuesti initsialiseerida, et genereerida uus hetktõmmis. Sellel meetodil on lugematu arv eeliseid, kuid üks puudus on see, et kõik replikatsioonitellimuse ahela tabelid initsialiseeritakse uuesti ühe korra ning initsialiseerimisel loetud tabelitel puuduvad andmed. See võib kesta ka kauem
2. Loo uus väljaanne ja seejärel tee eraldi koopiatellimus uuendatud tabelile See meetod on suhteliselt turvaline ega mõjuta kindlasti olemasolevat replikatsiooni tellimusahelat ning äsja lisatud tabeleid saab soovi korral initsialiseerida. Puuduseks on see, et sa ei saa alati versiooni viimasele tabelile ehitada, usaldusväärsem viis on selle uue väljaande projekti (tabeli) regulaarselt ametlikku väljalaske tellimisahelasse migreerida. Muidugi on sellel ka eelis, sest uue tabeliga saab mõnikord tegeleda, kui tekib probleem.
3. Kolmes etapis: A. Täida uus tabel andmetega täielikus lugemis-/kirjutamisandmebaasis (andmete järjepidevus on vajalik) B. Lõpeta logiagendi lugemine C. Lisa uus tabel avaldamistellimusele D. Luba logilugemise agent See meetod ei avalda veebipõhisele avaldamisele märkimisväärset mõju (võrreldes meetodiga 1), kuid lõpetab andmete lugemise ja kopeerimise töö ajal, mis suurendab lugemise/kirjutamise replikatsiooni viivitust. Kui sa ei ole lugemis- ja kirjutamisviivituse suhtes karm, võid selle valida. Soovitatav on stsenaarium ette valmistada. Kiire lahing ja kiire otsus
Need on kolm meetodit, mis pähe tulevad Teoreetiliselt on kolmas tüüp kõige mõistlikum (kompromiss), kuid kui rääkida replikatsioonitellimuse keskkonna nõuetest, mida ma praegu hallan, kasutatakse sagedamini meetodit 2. Kuigi see võib serveri jõudlusele veidi negatiivselt mõjuda. Kuid see loob ka korraliku puhvri DBA-dele, et hallata seda 22-aastast replikatsioonitellimust
|