Schimbarea coloanei unui tabel care participă la replicare

Uneori, structura mesei implicate în replicare trebuie schimbată. Pot exista mai multe motive pentru aceasta - selectarea inițială incorectă a tipului de date, absența unei valori implicite sau necesitatea redenumizării coloanei. O încercare de a schimba structura tabelului se încheie direct cu o eroare:







Deci, cum modificați o coloană existentă fără a dezactiva replicarea? Să presupunem că dorim să facem următoarele schimbări de structură:

Metoda pe care o alegem depinde în parte de tipul de replicare și de dimensiunea tabelului, dar există două opțiuni principale:

Pentru replicarea instantanee, aceasta este o alegere evidentă. Ștergem abonamentul la acest articol, ștergem articolul, apoi facem schimbări în tabel. Apoi, în ordinea inversă (adăugați un articol, adăugați un abonament la articol). Data viitoare când se lansează Agentul Snapshot (agentul instantaneu), acesta va colecta noua schemă fără probleme.
Pentru Replicarea Tranzacțională, putem selecta scenariul descris mai sus. Cu toate acestea, trebuie să fim mai atenți în acest caz. Implicit, inserarea, modificarea și ștergerea operațiunilor efectuate de editor sunt distribuite abonatului sub forma apelarea procedurii memorate. Prin modificarea definiției unei coloane, este posibil să fie necesar să modificăm procedurile stocate asociate tuturor abonaților. Finalizarea valorii implicite a complexităților nu va cauza, dar schimbarea directă a tipului de câmp așa cum este descris mai sus va necesita modificarea argumentelor procedurilor stocate. Pentru tabelul tEmployees din exemplul de mai sus, aceste proceduri există pe abonat sub forma:







modificarea operativă a tabelului

Deși scenariul de mai sus poate fi utilizat pentru replicarea tranzacțiilor sau pentru replicare, metodologia internă este diferită datorită naturii diferite a celor două metode. Pentru replicare prin reducere, detalii de linii actualizate vor fi stocate în MSmerge_contents, iar în cazul în care șirul specificat a fost schimbat o dată sau de o sută, în tabelul de sistem are doar o singură intrare (pentru sincronizare / replicare), în timp ce tranzacțiile de replicare 100 de modificări de linie va avea ca rezultat actualizări de 100 de abonați. Aceasta înseamnă că replicarea mixului are un avantaj față de replicarea tranzacțiilor, deoarece trebuie să executăm 2 modificări din fiecare interval de timp pentru a schimba schema.







Trimiteți-le prietenilor: