ARTICOL TIINIFIC

1. ntrebri de cercetare i ipotezele cercetrii asociate temei de cercetare

1.1 ntrebri de cercetare
Cum se pot mentine copii actualizate ale acelorai baze de date pe mai multe

servere?
Care sunt modalitile prin care se poate realiza replicarea bazelor de date?
Care sunt tipurile de replicri pe care le putem adopta?
Cum alegem tipul de replicare care urmeaz a fi adoptat?
Cum funcioneaz fiecare tip de replicare din cele dezvoltate de ctre Microsoft

Sql Server?
1.2 Ipotezele cercetrii
Pentru a menine copii ale acelorai baze de date pe mai multe servere, putem
alege ntre mai multe metode, ns cea mai utilizat i cea mai eficient metod
este reprezentat de replicarea datelor.
Replicarea datelor dintr-o baz de date se pot replica sincron sau asincron, n
totalitate sau parial.
Tipurile de replicri pe care le puten adopta sunt unidirecionale(replicare
tranzacional sau replicare snapshot) sau bidirecionale(replicare de tip merge).
Alegerea tipului de replicare se face n funcie de necesitatea disponibilit ii
datelor i de motivul principal pentru care se realizeaz replicarea de date.
Cele trei tipuri de replicri implementate n cadrul SGBD-urilor Microsoft Sql
Server sunt:

replicarea snapshot la un anumit interval, este trimis o copie

integral a bazei de date;

- replicarea tranzacional se pleac de la o copie a bazei de date i se
trimit modificrile la un anumit interval, modificri ce sunt citite din
-

log-ul tranzacional.
replicarea merge se pornete de la o copie iniial a datelor i pe
msur ce datele sunt actualizate pe oricare din serverele aflate n
replicare, se transmit datele ctre celelalte servere.

2. Titlul articolului
Titlul articolului este Replicarea bazelor de date.

3. Abstractul i cuvintele cheie

3.1 Abstractul

Replicarea datelor este o metoda de clonare a bazelor de date, ce spore te securitatea

sistemului i mbuntete viteza operaiunilor de procesare a datelor. Articolul de fa
i propune prezentarea informaiilor generale cu privire la replicare, a tipurilor de
replicri i a opiunilor pe care utilizatorul le are n alegerea implementrii unui astfel de
mecanism. Motivele care contribuie la alegerea implementrii mecanismului de replicare
sunt diverse: de la creterea performanelor serverului de producie, la ntreinerea unor
baze de date de test sincronizate cu cele din producie sau la asigurarea func ionalit ii
aplicaiilor n cazul unor probleme cu serverul principal.
3.2 Cuvintele cheie: sincronizare, server, baze de date

4. Bibliografia articolului
Iacob, Nicoleta, Replicarea datelor in mediile distribuite, Analele Universitii
Constantin Brncui din Trgu Jiu, Seria Economie, Nr. 4/2010
Srbu, Mircea, Originalul i copia, PC Report 87 - decembrie 1999
Ioni, Cristina, Proiectarea bazelor de date distribuite, Revista Informatic Economica,
nr.8/1998
Brad, Andrei, Replicri de baze de date pentru Raportri i BI , Market Watch, Aprilie
2010 , nr. 124
Ivan, I., P. Pocatilu, M. Popa, M. Sacala: Clonarea Informationala. Revista Romna de
Informatica si Automatica, vol 12, nr.2, 2002
Sitar-Tut, Dan-Andrei, Extensii ale bazelor de date distribuite, Annales Universitatis
Apulensis, Series Oeconomica
Williamson, D.A, Database replication in a high up-time environment,

Aerospace

Applications Conference, 1996. Proceedings., 1996 IEEE (Volume:3 )

Ting Zhou, Database replication technology having high consistency requirements,
Information Science and Technology (ICIST), 2013 International Conference on
Pedone, F. , From Object Replication to Database Replication, Dependable Computing,
2009. LADC '09. Fourth Latin-American Symposium on
Wiesmann, M. , Database replication techniques: a three parameter classification,
Reliable Distributed Systems, 2000. SRDS-2000. Proceedings The 19th IEEE
Symposium on

 Grebla, H.A. , Distributed database replication a game theory? , Symbolic and

Numeric Algorithms for Scientific Computing, 2005. SYNASC 2005. Seventh
International Symposium on
Amir, Y. , From total order to database replication, Distributed Computing Systems,
2002. Proceedings. 22nd International Conference on
Elnikety, S. , Database replication using generalized snapshot isolation, Reliable
Distributed Systems, 2005. SRDS 2005. 24th IEEE Symposium on
Holliday, J. , Database replication : if you must be lazy, be consistent, Reliable
Distributed Systems, 1999. Proceedings of the 18th IEEE Symposium on
Ion Lungu, Gheorghe Sabu, Manole Velicanu, Mihaela Muntean, Simona Ionescu, Elena
Posdarie, Daniela Sandu, Sisteme informatice. Analiz, proiectare i implementare,
Editura Economic, Bucureti, 2003
Documentatia
Microsoft
Sql

Server:

http://msdn.microsoft.com/en-

us/library/bb545450.aspx
Date C. J., An introduction to database systems, Eight edition, Pearson Education , 2004
Beynon-Davies P., Database systems, 3rd Edition, Palgrave-Macmillan, 2004.
Lungu, C. Bodea, G. Badescu, C.Ionita, Baze de date. Organizare, proiectare si
implementare, Ed. ALL, 1995
Dorin Carstoiu, Baze de date, Editura Matrix Rom 2009
Thomas Connolly, Carolyn Begg, Database Systems, A Practical Approach to Design,
Implementation, and Management, Addison Wesley, 2005.

5. Fie de recenzie

Articol: Originalul si copia, Srbu Mircea, Revista PC Report 87 decembrie

1999

Principalele probleme abordate n cadrul articolului:

Articolul prezint fundamenele replicrii n domeniul bazelor de date.

Replicarea datelor

reprezint o tehnologie destul de veche care a cptat o popularitate nesperat o data cu succesul
lui Lotus Notes. Ideea a fost preluat cu succes n domeniul bazelor de date i, curnd, a devenit
un loc comun n SGBD-urile de vrf. Pentru a putea fi utilizat n mediile de produc ie, trebuie
nti s nelegem modul de lucru al acesteia i tipurile de reaeplicare ce pot fi implementate.

Alegerea ntre replicarea sincron i replicarea se face n principiu n funcie de necesit ile
utilizatorilor. Replicarea sincron implic faptul c o actualizare n surs trebuie propagat i
aplicat imediat n toate replicile i implic dou cerine eseniale : reeaua trebuie s funcioneze
i fiecare baz de date int s poat comite tranzacia ce realizeaz actualizarea. Replicarea
asincron se bazeaz pe un mecanism de tip store and forward, ceea ce nseamn c actualizrile
sunt reinute i aplicate mai trziu pe serverele replic. Replicarea sincron implic costuri mari,
n timp ce aplicarea asincron este mult mai practic i mai eficient.
Alte probleme abordate n cadrul articolului sunt reprezentate de: principalele tipuri de aplicaii
n care se utilizeaz replicarea asincron - o variant promovat de IBM pentru replicarea
asincron este transformarea configuraiei din reea ntr-o ierarhie, avnd ca rdcin nodul de
referin, cum se pot captura modificrile fr a utiliza vreun mecanism propus deja de
productorii de SGBD-uri sau cum se pot preveni conflictele de replicare.
Conflictele de replicare apar atunci cnd aceeai nregistrare este actualizat la mai multe servere
n acelai timp. Deoarece datele trebuie mereu s fie aceleai pe toate serverele, se vor stabili
care vor fi datele propagate n astfel de situaii prin stabilirea unor reguli de tratare a acestor
conflicte.
Concluzii ale articolului: Exist multe moduri prin care se poate realiza replicarea datelor, fie
prin utilizarea mecanismele deja implementate, fie prin implementarea propriului mod n care
datele se transmit. Decizia este luat n funcie de necesitile utilizatorilor i dup o analiz
riguroas a specificaiilor i a variantelor de implementare.
Aprecieri personale: Articolul prezint n mod explicit implicaiile pe care le are alegerea tipului
de replicare (sincron vs asincron), avantajele i dezavantajele fiecrei abordrii. Modul de
prezentare a noutilor este unul clar i explicit.

Articol: Proiectarea bazelor de date distribuite, Revista Informatic Economic,

nr. 8/1998

Principalele probleme abordate n cadrul articolului:

Distribuirea bazelor de date a aprut ca urmare a cerinelor de cretere a disponibilitii,

siguranei i flexibilitii sistemelor de baze de date, rezultnd astfel sistemele de baze de date
distribuite. n prezent, majoritatea SGBD-urilor au n componen module pentru asigurarea
distribuiei datelor.
Exist mai multe tipuri de proiectare a bazelor de date distribuite:
-

Proiectarea top-down este utilizat atunci cnd proiectarea ncepe de

la zero
Proiectarea bottom-up este recomandat n cadrul n care bazele de

date locale exist i trebuie integrate ntr-un sistem unitar.

Proiectarea mixt, parial top-down i parial bottom-up este
recomandat n majoriatea cazurilor pentru a rspunde mai bine
situaiilor practice.

Replicarea datelor are ca efect pozitiv creterea siguranei sistemului i regsirea mai rapid a
datelor. Replicarea unui fragment este influenat n mare msur de raportul dintre numrul
acceselor de regsire i cel al acceselor de actualizare pentru fragmentul respectiv.
Concluzii ale articolului: Sistemele de baze de date distribuite prezint o serie de avantaje legate
de creterea performanelor sistemului, de reducerea a costurilor de prelucrarea i transmiterea
datelor. Dac mecanismul de replicare al datelor nu ofer facilit i pentru tratarea conflictelor,
atunci acestea trebuie gestionate de aplicaii.
Aprecieri personale: Articolul prezint modul n care poate fi proiectat o baz de date
distribuit. Modul de prezentare este unul simplu, dar bine structurat, iar graficele i figurile din
cadrul articolului au rolul de a fixa i mai bine noiunile prezentate cititorului.

6. Analiza critic a stadiului cunoaterii

Replicarea bazei de date reprezint procesul de copiere electronic a datelor dintr-o baza de date
de pe un calculator sau server n alt baz de date astfel nct to i utilizatorii s mprt easca
aceleai informaii. Rezultatul este o baz de date distribuit n care utilizatorii pot accesa date
relevante sarcinilor pe care trebuie s le ndeplineasca fr a interac iona cu sarcinile altor

utilizatoru. Implementarea replicrii bazei de date cu scopul eliminrii ambiguit ii sau a

inconsistenelor datelor este cunoscut ca normalizare.
Cel mai puternic efect pe care replicarea l are este reprezentat de sigurana sistemului, dar i
disponibilitatea datelor n cazul nefuncionrii unui din servere.
Procesul prin care se asigur captarea, propagarea i reproducerea la inte a actualizrilor din
surse poart numele de sincronizare, acesta fiind elementul central al ntregului proces.
Sincronizarea nu presupune transmiterea doar a actualizrilor datelor prin prisma noilor valori, ci
i a modificrilor asupra obiectelor, cum ar fi modificarea structurilor tabelelor. Sincronizarea
asigur astfel caracterul dinamic al ntregii tehnologii.
Replicarea este realizat de obicei ntre dou sau mai multe servere, cu specifica ia c exist un
singur server master, celelate fiind de tip slave.
Cum funcioneaz replicarea i cum sunt transmise modificrile? Propagarea modificrilor se
realizeaz printr-un mecanism bazat pe cozi de mesaje, mecanism ce garanteaz stocarea sigur a
mesajelor att la surs, ct i la destinaie, permind urmrirea fiecrui mesaj n parte. Aceste
cozi de mesaje se afl iniial pe serverul surs , urmnd a fi transmise serverelor destina ie, unde
vor fi tratate tot prin intermediul mecanismelor bazat pe cozi de mesaje. Un aspect important al
transmiterii modificrilor de la surs la destinaie este reprezentat de faptul c mesajele pot fi
serializate nainte de aplicare, astfel nct ele nu se pierd i nici nu se dubleaz.
Un alt motiv pentru care replicarea datelor este folosit este acela c reprezint o tehnic n
mbuntirea performanelor bazelor de date de producie, fcnd n acelai timp disponibil
informaia aproape n timp real, lucru favorabil raportrii i business intelligence-ului.
Replicarea reprezint astfel procesul prin care tranzaciile asupra bazei de date master sunt
repetate asupra celei de-a doua baze de date slave. Poate fi folosit astfel i pentru a ntre ine o
baz de date de test.
Etapele implementrii tehnologiei de replicare sunt reprezentate de:
o
o
o
o

Identificarea bazelor de date care merit replicate

Identificarea tehnologiei i implementrii potrivite pentru replicare
Analiza cerinelor de uptime i de data latency
Implementarea replicrii

o Testarea replicrii
o Educatrea utilizatorilor pentru replicare

Tipuri de baze de date din punct de vedere al replicrii

Strict din ceea ce priveste replicarea, o baz de date poate face parte din una din urmtoarele
categorii:
a. Baza de date nereplicat atunci cnd sistemul are o singur baza de date, care se afl
doar la un singur nod i nu este nevoie de clonarea acesteia.
b. Baza de date parial replicat atunci cnd ntr-o baz de date, exist obiecte care sunt
replicate i obiecte care nu sunt replicate, n funcie de necesitile utilizatorilor.
Replicarea se face astfel selectiv.
c. Baza de date complet replicat atunci cnd ntreaga baz de date este pe deplin
replicate pe unul sau mai multe noduri din reea.

7. Metode
Replicare sincron versus replicare asincron
O prim diviziune a tehnicilor de replicare se bazeaz pe momentul n care se realizeaz
sincronizarea. Din acest punct de vedere, replicarea poate fi sincron sau asincron.
Replicarea sincron implic faptul c o actualizare n surs trebuie propagat i aplicat imediat
n toate replicile. Acest proces se realizeaz de obicei pe baza unui protocol numit "comitere n
dou faze" (two-phase commit) i se refer la tranzacia care realizeaz actualizarea. n prima
faz, sursa (un server de baze de date) va solicita intelor (alte sisteme de baze de date) s se
pregteasc pentru efectuarea tranzaciei i va atepta confirmrile din partea acestora. Cnd
toate intele sunt pregtite, sursa le va solicita comiterea tranzaciei i va atepta ca fiecare int
s raporteze succesul. Cnd toate intele au comis cu succes tranzacia, sursa declar tranzacia

ncheiat i consemneaz acest lucru n jurnal (log). n cazul n care ntr-una dintre faze cel puin
o int nu poate comite tranzacia, orice modificri produse deja sunt anulate (rollback).
Este evident c replicarea sincron impune un dou cerine eseniale: reeaua (fie ea LAN sau
WAN) trebuie s funcioneze i fiecare baz de date int s poat s comit tranzacia care
realizeaz actualizarea. Aceste cerine pot fi ndeplinite doar n anumite medii, cu anumite
costuri, iar balana este nclinat n favoarea integritii procesrii i n defavoarea
disponibilitii. Anumite aplicaii, cum ar fi de exemplu cele financiare sau cele de rezervare a
locurilor, sunt bine deservite de aceast tehnic.
Care este diferena ntre replicarea sincron i tranzaciile distribuite? Este greu de trasat o linie
de demarcaie clar. n principiu, o tranzacie distribuit nu lucreaz (n mod deliberat) cu copii
ale datelor, ci cu date care sunt distribuite n mai multe locaii. Astfel, este posibil ca prelucrarea
unei comenzi de la un client s implice att date ale serviciului de vnzri (situat la o anumit
locaie) ct i date ale serviciului financiar (situat ntr-o alt locaie). Din punctul de vedere al
aplicaiei, localizarea datelor este un proces transparent.
n cazul replicrii sincrone, un scenariu tipic este urmtorul: O tranzacie T ncearc s
actualizeze (printre altele) nite date care reprezint sursa unei replicri. Pentru ca aceast
actualizare s se propage imediat, sistemul genereaz o tranzacie special P, care s actualizeze
(independent de T) replicile datelor respective. Comiterea cu succes a tranzaciei T este
condiionat de comiterea tranzaciei P. S remarcm c T poate fi tranzacie simpl (local), n
timp ce P este o tranzacie distribuit (care este ns transparent din perspectiva aplicaiei).
Replicarea asincron se bazeaz pe un mecanism de tip store and forward (adesea se folosete i
termenul message based replication). Informaiile despre actualizrile produse n sursa replicrii
sunt stocate ntr-o coad de ateptare, de unde sunt apoi trimise ctre locaiile intelor, care se
sincronizeaz pentru a reflecta starea sursei. Acest proces implic o anumit ntrziere, care
poate fi de cteva secunde sau de cteva zile, n funcie de configurarea sistemului i de
disponibilitatea sistemelor implicate. n schimb, avantajele pot fi considerabile din punct de
vedere al disponibilitii (operarea ntr-o locaie nu este afectat de indisponibilitatea unei alte

locaii) i a costurilor legate de transferul informaiilor (nu este nevoie de o conexiune

permanent).
Deoarece replicarea sincron este adesea asimilat cu bazele de date distribuite i implic un
nivel de complexitate foarte ridicat, ceea ce se traduce n costuri adesea foarte mari (att pentru
comunicaii ct i pentru proiectare i exploatare), replicarea asincron - mult mai practic i mai
ieftin - a devenit alternativa cea mai popular n ultima vreme. n plus, replicarea sincron este
inaplicabil ntr-o ntreag clas de aplicaii, din ce n ce mai rspndit, care implic utilizatori
mobili (ca n cazul celui de-al doilea scenariu evocat). Din aceste motive, n foarte multe lucrri
i articole, termenul "replicare" se refer implicit la replicarea asincron.

Replicare unidirecional versus replicare bidirecional

Cea mai simpl form de replicare o reprezint replicarea unidirecional. Altfel spus, replica
este disponibil doar pentru citire. Deoarece o astfel de replic read-only reprezint doar o
imagine a datelor din surs aa cum se prezentau ele la un anumit moment (un instantaneu), se
folosete adesea termenul snapshot.
Replicarea bidirecional implic faptul c replica este la rndul ei actualizabil i c
modificrile din replic vor fi reflectate n surs.O surs poate fi considerat replic i invers,
motiv pentru care se folosete adesea termenul de "replicare simetric" .
De altfel, trebuie spus c atunci cnd vom lua n considerare diferitele topologii posibile pentru
replicare, nici termenul "bidirecional" nu este foarte corect (de fapt, procesul este
multidirecional) i nici "simetric" (cteodat una dintre locaii este "mai simetric" dect
celelalte).
Mai jos, este reprezentat o schema a mecanismului de replicare bidirecional a unei baze de
date.

Nod A
(Server 1)

Nod B
(Server 2)

Sincronizare

Nod C
(Server 3)

Figura 1. Replicarea bidirecionl a bazelor de date

Tipuri de replicri n Microsoft Sql Server

Deoarece de-a lungul timpului am avut posibilitatea s lucrez n cea mai mare parte cu produsele
Microsoft Sql Server, n ceea ce urmeaz voi face o scurt prezentare a tipurile de replicare puse
la dispoziie de ctre Microsoft n ceea ce privete replicarea bazelor de date.
n tehnologia dezvoltat pentru Microsoft Sql Server, serverul principal poart numele de
Publisher, iar serverele secundare poart numele de Subscribere. Obiectele bazei de date ce vor fi
replicate sunt structurate pe publicaii. Fiecare publicare este format dintr-o mul ime de obiecte,
obiecte ce vor fi transmise subcriberelor specificate.
Pentru a putea configura o replicare n Sql Server este nevoie de minim trei servere, care vor juca
rolurile de Publisher, Subscriber i Distribuitor. Distribuitorul are rolul de a aplica modificrile
aprute asupra datelor i a obiectelor bazelor de date replicate.
n Sql Server ntlnim urmtoarele tipuri de replicri ce vor fi detaliate n cele ce urmeaz:

o Replicarea snapshot
o Replicarea tranzacional
o Replicarea merge
Replicarea snapshot distribuie datele exact asa cum apar ntr-un moment specific i nu
monitorizeaz actualizrile de date. Este cea mai bun metod pentru replicarea datelor atunci
cnd acestea se modific ocazional sau unde nu sunt necesare cele mai multe actualizri ale
valorilor de date. Atunci cnd are loc sincronizarea, ntreg snapshot-ul este generat i trimis la
subscriber.
Replicarea snapshot este preferabil n locul replicrii tranzacionale atunci cnd schimbrile de
date sunt substaniale, dar ocazionale. Crearea de noi snapshoturi este o opiune atunci la editarea
tabelelor relativ mari, care sunt actualizate doar de ctre publisher.
Acest tip de replicare este folosit adesea atunci cnd datele sunt utilizate drept suport de decizii,
unde cele mai multe date nu sunt eseniale i se doresc a fi read-only. Este util atunci cnd
datele sunt n special statice i nu se modific des. Atunci cnd se modific date semnificative,
este recomandat crearea unui noi snapshot i transmiterea acestuia ctre subscriber.
Repicarea snapshot necesit o procesare constant mai mic dect replicarea tranzacional
datorit faptului c nu necesit o monitorizare continu a modificrilor de date de la serverul
surs. Dac setul de date care trebuie sincronizat este foarte mare, poate avea nevoie de o surs
substanial de reea pentru a putea fi transmis.
Cum funcioneaz replicarea snapshot?
Replicarea snapshot este implementat de agentul snapshot i agentul de distribuie. Agentul
snapshot pregtete fiierele ce conin schemele i datele tabelelor i a restului obiectelor din
bazele de date, stocheaz fiierele n directoare snapshot i nregistreaz sincronizarea funciilor
n bazele de date distribuite la distribuitor. Implicit, folderele snapshot sunt amplasate la
distribuitor, dar se poate specifica i o locaie alternativ.
Agentul de distribuie mut snapshot-urile inute n tabelele bazelor de date spre tabelele
destinaie ale subscriberului. Bazele de date distribuite, rezultate n urma procesului, sunt
utilizate doar de replicare i nu conin nicio alt tabel utilizator.

Agentul snapshot verific de fiecare dat cnd este activat, dac a mai fost adugat vreo
subscripie. Daca nu a fost adugat nicio alt subscripie, nu este creat nicio noua scriere de
fiiere de date. Dac publicaia este creat cu opiunea crerii primului snapshot imediat dup ce
a fost activat, atunci noua schem i fiierele de date sunt create de fiecare dat cnd agentul
snapshot este activat. Toate schemele i fiierele de date sunt stocate n folderul snapshot, iar
agentul de distribuie le transfer la semnatari (subscriberi).
O schem a mecanismului de funcionare al replicrii snapshot este prezentat n figura de mai
jos.

Figura 2. Replicarea snapshot

Replicarea tranzacional este iniiat prin intermediul unui snaphot iniial de date aplicate a
subscriber. Pe parcursul apariiei modificrilor de date fcute la publisher, tranzacia individual
este capturat i propagat la subscriber. Acest tip de replicare folosete conectarea tranzac iei
pentru a capta modificrile de incrementare care au fost fcute asupra obiectelor din publicaii.
Mecanismul de replicare monitorizeaz declaraiile de actualizare a datelor sau ale modificrilor
dicionarelor de date fcute asupra datelor i a obiectelor i stocheaz aceste modificri n baze
de date distribuite, care de fapt stau n coad. Modificrile sunt apoi propagate ctre subscriberi
i aplicate n aceeai ordine n care au aprut. Dac semnatarii (subscriberii) au nevoie s
primeasc modificrile aprute aproape n timp real, atunci la crearea publicaiei se va selecta un
interval de sincronizare cat mai redus, ns pentru aceasta, baza de date de la publisher va fi mult
mai solicitat din punct de vedere al resurselor.

Replicarea trazancional este implementat de ctre agentul snapshot, agentul log reader i
agentul de distribuie. Agentul snapshot pregatete fiierele snapshot care conin scheme i date
ale obiectelor bazelor de date.
Replicare merge este caracterizat n primul rnd de faptul c modificrile asupra datelor pot fi
realizate att la publisher, ct i la subscriber, modificri ce vor fi distribuite ctre toate serverele
aflate n replicare, indiferent de tipul acestora, publisher-ul sau subscriberele.
Snapshot-ul iniial este aplicat publisherului, urmnd ca Sql Server s colecteze modificrile de
date. Datele sunt sincronizate la un anumit interval de timp sau la cerere. Deoarece aceleai date
pot fi actualizate pe mai multe servere, pot aprea anumite conflicte. La crearea publica iei,
utilizatorul poate seta anumite reguli pentru prevenirea acestor conflicte. De exemplu,
ctigtor al conflictului poate fi desemnat serverul pe care s-a realizat prima dat modificarea
sau ctigtor al conflictului poate fi mereu publisherul. Date cu privire la conflictele aprute
sunt salvate n tabele de sistem pe care administratorul bazei de date le poate studia i poate lua o
decizie asupra acestora.
Replicarea de tip merge este recomandat atunci cnd:
-

Mai muli subscriberi au nevoie s actualizeze datele n diferitele momente i s propage

modificrile spre alti subscriberi.

Subscriberii au nevoie s primeasc date, s fac modificri indirect i mai tarziu s

sincronizeze modificrile ntre editor i alti semnatari

Datele replicate sunt citite i actualizate de subscriberi
Avem nevoie ca actualizrile s fie propagate pe rnd, iar conflictele s fie evaluate i

rezolvate la nivel de rnduri

Conflictele cauzate de actualizrile multiple ale acelorai date sunt ocazionale

Replicarea merge este implementat de ctre agentul subscriber i agentul merge. Agentul
subscriber pregtete fiierele ce conin scheme i date ale tabelelor publicate, stocheaz fiierele
n folderol snapshot i insereaz funcii de sincronizare n publicaiile bazelor de date. De
asemenea, agentul snapshot creeaz replicarea, procedurile specific i tabelele de sistem.
Agentul merge aplic funciile snapshotului iniial, funcii ce sunt inute n tabelele bazelor de
date publicate, subscriberului.

Rolul agentului de distribuie este unul limitat n replicarea merge, deoarece acesta nu este folosit
pe ntreaga durat a replicrii merge, iar bazele de date distribuite din distribuitor stocheaz
istoricul informaiilor despre replicarea merge.
Cum funcioneaz replicarea merge? Sql Server instaleaz mecaniste ce urmresc modificrile
datelor la nivel de rnd sau coloan. Mecanismele captureaz modificrile fcute tabelelor
publicare i le nregistreaz n tabele de sistem. Agentul snapshot urmrete aceste modificri i
le aplic n ordinea apariiei lor la subscribere.
Pentru a aplica modificrile la serverele subcrise, agentul snapshot creeaza de asemenea o serie
de proceduri stocate de sistem. Cnd datele sunt actualizate i noile nregistrrii trebuie s fie
transmise ctre restul serverelor din publicatie, procedurile sunt folosite mai mult ca declaraii
individuale de actualizare.
Cnd agentul log reader ntlnete actualizrile pentru replicare, reconstruete o serie de
tranzacii din logul tranzacional al bazei de date, tranzacii pe care le trimite i le aplic fiecrui
subcriber. Dac toti subscriberii sunt reprezentai de servere Sql Server, atunci se folosesc direct
procedurile de sistem pentru transmiterea modificrilor.

8. Rezultate
O metod prin care se poate asigura sigurana, disponibilitatea, flexibilitatea datelor i cre terea
performanei sistemelor de baze de date este reprezentat de replicare. Pentru implementarea
acesteia putem alege ntre replicare sincron sau asincron, unidirec ional sau bidirecional n
funcie de cerinelor sistemului. Dac se dorete ca datele replicate s poat fi utilizate n timp
real, iar sincronizarea acestora s se fac ct mai repede, se va alege un mod de replicare
sincron, n caz contrar se poate opta pentru replicarea asincron a datelor, ceea ce presupune
mai puine resurse i o diminuare a scderii performanelor serverului principal.
n principal, replicarea este folosit pentru asigurarea existenei unei baze de date de test, sau
pentru accesarea datelor din mai multe aplicaii. De exemplu, pentru separarea mediului de
producie de serverul special pentru rapoarte, pentru distribuirea datelor se poate alege un mod
de replicare al acestora.

Un aspect important l reprezint modul de tratare al conflictelor de replicare, tratare ce are loc
fie n cadrul sistemelor de gestiune al bazelor de date, fie n cadrul aplicaiilor.
Pentru implementarea unui mecanism de replicare, se pot alege tipurile de replicare
implementate de sistemele de gestiune al bazelor de date, cum ar fi cele trei tipuri de replicrii
implementate de ctre Microsoft SQL Server sau se poate implementa un mecanism propriu.

9. Discuii privind rezultatele

Exist i alte modaliti de asigurare a unei copii a bazei de date pe alt server. Putem vorbi astfel
de Database Mirroring sau Log Shipping. Database Mirroring reprezint oglindirea unei baze
de date de pe serverul principal pe serverul secundar. Dezavantajul principal al acesteia l
reprezint ns faptul c datele nu pot fi accesare de ctre utilizatori i este folosit doar n cazul
nefuncionalitii serverului principal. Astfel, n cazul unui eveniment neplcut, sistemul trece
automat de la utilizarea bazei de date de pe serverul principal, la utilizarea bazei de date de pe
serverul secundar, astfel nct utilizatorului s nu i fie afectat activitatea.
Log shipping-ul reprezint un alt mecanism implementat n cadrul SGBD-urilor Microsoft Sql
Server, prin intermediul cruia se trimit periodic copii ale ntregii baze de date ctre serverul
secundar, unde are loc restaurarea bazei de date pe baza copiei. Dezavantajul principal este c n
procesul de restaurare, baza de date nu va mai putea fi accesat, lucru ce poate fi considerat nu
foarte util.
n comparaie cu celelalte dou soluii prezentate mai sus, replicarea este soluia optim pentru
asigurarea copiilor bazelor de date pe mai multe servere i rspunde unei set mare de cerine .

10. Concluzii si aknowledgment

Replicarea reprezint o metod prin care se poate asigura existen a n timp real a unei copii a
unei baze de date i a structurii acesteia pe mai multe servere, n timp util, fr a fi afectat mediul
de producie. Reprezint de asemenea o modalitate prin care se poate asigura sigurana datelor.

n funcie de cerinele sistemului si a resurselor disponibile, se poate decide alegerea unui anumit
tip de replicare. Deoarece pe pia exist o varietate de mecanisme de replicare, utilizatorul este
liber s aleag ntre acestea, astfel nct s i ndeplineasc obiectivele.
Se poate alege o replicare complet a bazei de date, o replicare par ial sau a nu se replica deloc.
n funcie de tipul replicrii alese, aceasta se va efectua sincron sau asincron.
Un lucru important n alegerea tipului de replicare, l reprezint etapa de analiz a cerinelor.
n opinia mea, replicarea poate fi o soluie pentru ntreinerea unor baze de date de test sau pentru
ntreinerea unui server de rapoarte. Poate duce astfel la creterea performanelor serverului de
baze de date n mediul produciei. O alt abordare poate fi aceea de a ntre ine un server de
rezerv, astfel nct n cazul nefuncionrii serverului central, aceasta s poat fi nlocuit, astfel
nct utilizatorul sa nu simt i s i poat continua activitile.