b4f14fv
UNIVERSITATEA TEHNICA DIN CLUJ-NAPOCA
COLEGIUL UNIVERSITAR TEHNIC, ECONOMIC SI DE ADMINISTRATIE
SPECIALIZAREA TEHNICA DE CALCUL UTILIZAREA REPLICARII INTR-O APLICATIE DE BAZE DE DATE

CUPRINS

INTRIDUCERE
CAPITOLUL I
1.1. Bazele de date distribuite si procesele distribuite………………….…..….4
1.2.Bazele de date distribuite si replicarea lor ………………………..…..……4
1.3.Ce este replicarea….………………………………………………………….4

CAPITOLUL II
2.1. Tipuri de replicare…………………………………………………..………6
2.2. Replicarea snapshot (SQL Server)…………………………………..……..7
2.3. Cum functioneaza replicarea snapshot ………………………….………...8
2.4. Replicarea tranzactionala…………………………………………………..10
2.5. Cum functioneaza replicarea tranzactionala……………………………...10
2.6. Snapshotul initial……………………………………………………………11
2.7.Procesele snapshot concurente……………………………………..……….12
2.8. Modificarea datelor si agentul log reader……………………….……… ..14
2.9. Agentul de distributie…………………………………………….……… 14
2.10. Replicarea merge…………………………………………….……………15
2.11. Functionarea replicarii merge………………………………….………...17
2.12. Identificatorul unic de coloana………………………………….………..18
2.13. Mecanismele replicarii merge…………………………………….………18
2.14. Procedurile stocate………………………………………………….……..18
2.15. Tabelele sistem ale replicarii merge……………………………….……..19
2.16. Snapshotul initial si agentul snapshot…………………………………...20
2.17. Agentul merge…………………………………………………………….21
2.18.Sincronizarea………………………………………………………………21
2.19. Validarea permisiunii pentru semnatari………………………….……..22
2.20.Modele fizice de replicare in SQL Server…………………………….…..23

CAPITOLUL III
3.1. Replicarea in Oracle…………………………………………….…….……25
3.2. Definirea unei interogari snapshot…………………………….….……….28
3.3. Reimprospatarea snapshoturilor……………………………………..……29
3.4. Conectarea snapshoturilor………………………………………….……...30
3.5. Reimprospatarea automata a snapshoturilor...…………………….…….30
3.6. Snapshoturi complexe………………………………………….…….……..31
3.7. ROWID snapshot…………………………………………………….……..32
3.8. Locurile snapshoturilor si actualizarea lor………………………….…….33
3.9. Configuratii hibrid…………………………………………………….……34
3.10. Locurile replicarii…………………………………………….…….…..…35
3.11. Administrarea replicarii API si cerintele administrarii………….……..36
3.12. Propagarea datelor asincron (stocheaza si mai departe)………….….…37
3.13. Tipuri de conflicte ale replicarii…………………………………….……38
3.14. Detectarea conflictelor……………………………………………….……39
3.15. Grupuri de coloane………………………………………….………...…..40
3.16. Replicarea procedurala……………………………………….…………...40
3.17. Propagarea datelor asincron (timp real)………………………….……..41
3.18. Conflictele de replicare si replicarea sincrona a datelor……………….43

CAPITOLUL IV
1.1. Prezentarea cerintelor aplicatiei…………………………………….…..…45
1.2. Partea de implementare a aplicatiei………………………………….……45
1.3. Ghid de instalare si utilizare a aplicatiei…………………………….…….45
PAS 1: crearea bazei de date in SQL Server……………...……...……45
PAS 2: Configurarea serverului ca fiind distribuitor si editor……….46
PAS 3: folosirea aplicatiei client…………………………………….….48
1.4. Concluzii……………………………………………………………….……49
BIBLIOGRAFIE……………………………………………………………………….. ANEXE……………………………………………………………………………….…..50

CAPITOLUL I
INTRODUCERE

1.1. Bazele de date distribuite si procesele distribuite.

Termenii da baze de date distribuite si procesele distribuite sunt foarte apropiati, dar au intelesuri diferite. O baza de date distribuita este un set de baze de date stocate pe mai multe calculatoare care apar in aplicatie ca o singura baza de date.
Procesele distribuite apar atunci cand aplicatia unui sistem distribuie task-urile la diferite calculatoare intr-o retea. Procesarea unui sistem cu baze de date distribuite este vazuta mai mult ca o aplicatie sistem de baze de date client-server. Un sistem cu baze de date distribuite necesita functionarea unei aplicatii de procese distribuite.

1.2. Baze de date distribuite si replicarea lor.

Intr-o baza de date distribuita simplu, sistemul administreaza o singura copie a tuturor datelor si obiectelor de baze de date sustinute. Aplicatiile de baze de date distribuite folosesc tipic tranzactii distribuite pentru a accesa ambele locuri si datele indepartate si pentru a modifica bazele de date globale in timp real.

1.3. Ce este replicarea.

Replicarea este procesul de copiere si pastrare a schemelor obiectelor in multiple baze de date distribuite. Replicarea poate sa imbunatateasca performantele si sa protejeze disponibilitatea aplicatiilor fiindca exista o alternativa de acces la date. De exemplu, o aplicatie poate normal sa acceseze o baza de date locala mai repede decat a unui server indepartat, poate sa minimizeze traficul intr-o retea si sa obtina cele mai bune performante. In afara de aceasta aplicatia poate sa functioneze chiar daca cade un server local, dar alte servere cu baze de date replicate raman accesibile. Exista mai multe forme de replicare: replicarea de baza si replicarea avansata .

Folosind replicarea putem distribui datele intre diferite locuri, la utilizatorii indepartati sau mobili, intr-o arie locala folosind o retea cu conexiune dial-up si prin Internet. Replicarea de asemenea ne permite sa imbunatatim performantele aplicatiilor, sa separam datele fizice si modul cum sunt folosite procesele de baze de date distribuite intre mai multe servere.
Replicarea ofera diferite beneficii depinzand de tipul replicarii si de optiunile pe care le alegem, dar cel mai comun beneficiu este valabilitatea datelor cand si cum este nevoie.
Alte beneficii includ:
- permite mai multor locuri sa pastreze copii ale acelorasi date. Aceasta este util cand mai multe locuri au nevoie sa citeasca aceleasi date sau au nevoie de servere diferite pentru a rula aplicatiile;
- separarea aplicatiilor read-intensive cum ar fi procesele analitice de baze de date online sau depozitele de date;
- permite o mare autonomie. Utilizatorii pot lucra cu copii ale datelor in timp ce sunt deconectati si apoi, dupa ce fac modificari asupra bazelor de date le pot propaga atunci cand sunt reconectati;
- creste performantele de citire;
- aduce datele mai aproape de grupurile individuale. Aceasta ne ajuta sa reducem conflictele bazate pe mai multi utilizatori care modifica datele si cerintele din cauza carora datele pot fi distribuite in retea si putem partitiona datele pe baza nevoilor diferitor tranzactii sau utilizatori;
- replicarea este o alegere pentru strategia server standby.
Tot mai nou este nevoia de a fi necesar ca datele sa fie stocate redundant. Diferite aplicatii au nevoi diferite pentru autonomie si consistenta datelor.
Replicarea este o solutie pentru un mediu cu date distribuite cand avem nevoie :
- sa copiem si sa distribuim datele spre unul sau mai multe locuri;
- pentru distribuirea copiilor datelor spre baze programate;
- sa distribuim modificarile datelor spre alte servere;
- atunci cand este nevoie sa permitem mai multor utilizatori si locuri sa faca schimbarile, apoi sa trimita modificarile de date impreuna si chiar potential sa rezolve conflictele;
- de a construi aplicatii de date care trebuie folosite in medii online sau offline;
- sa construim aplicatii Web in care utilizatorii pot accesa un mare volum de date;
- optional sa facem modificari la semnatarii care au un control transparent pentru editor.

CAPITOLUL II

2.1. Tipuri de replicare.

In cercetarea mea asupra acestui subiect am intalnit urmatoarele tipuri de replicare pe care le putem folosi in aplicatiile distribuite:

- replicarea snapshot;
- replicarea tranzactionala; folosite in SQL Server;
- replicarea merge;
- replicarea de baza;
- replicarea avansata; folosite in Oracle;
- replicarea procedurala;

Fiecare dintre aceste tipuri furnizeaza capabilitati diferite, depinzand de aplicatie si de diferite niveluri de proprietati (consistenta, izolare, durabilitate) ale tranzactiilor si autonomiei locurilor de replicare. De exemplu replicarea merge permite utilizatorilor sa lucreze si sa actualizeze datele autonom, in schimb cand serverele sunt reconectate, toate locurile cu topologie de replicare converg la aceeasi valoare de date.
Replicarea tranzactionala mentine consistenta tranzactiilor, dar locurile semnatare (subscriber) nu sunt asa de autonome cum sunt la replicarea merge din cauza ca editorii (Publisher) si semnatarii, in general ar trebui sa fie conectati continuu pentru ca actualizarile sa fie propagate la semnatari (subscribers).
Este imposibil ca pentru o aplicatie sa se foloseasca mai multe tipuri de replicare si optiuni. Unele din datele unei aplicatii s-ar putea sa nu necesite nici o actualizare la semnatari (subscriber), unele seturi de date necesita actualizari ocazionale facute la unul sau mai multe servere, in timp ce alte seturi de date necesita sa fie actualizate zilnic la mai multe servere.
Atunci cand se creeaza o aplicatie, pentru aceasta este aleasa un anumit tip de replicare, depinde de cerintele bazate pe factorii de date distribuiti, daca sau nu datele vor trebui actualizate la semnatari (subscribers), mediul de replicare, de nevoile si cerintele datelor care vor fi replicate.
Atunci cand planificam replicarea trebuie sa punem urmatoarele cerinte:
- daca datele replicate au nevoie de actualizare si de la cine;
- daca datele trebuie sa priveasca consistenta, autonomia si latenta;
- daca mediul replicarii include utilizatori business, infrastructura tehnica, retele si securitate si caracteristicile datelor.;
- tipul de replicare si optiunile;
- topologia replicarii si cum se aliniaza cu tipul replicarii.
Fiecare tip de replicare incepe cu generarea si aplicarea snapshoturilor la semnatar (subscriber), asa ca este important sa intelegem replicarea snapshot .

2.2. Replicarea snapshot (SQL Server).

Replicarea snapshot distribuie datele exact asa cum apar intr-un moment specific in timp si nu monitorizeaza actualizarile de date. Este cel mai bine folosita ca o metoda pentru replicarea datelor care se modifica ocazional sau unde cele mai multe actualizari ale valorilor de date nu sunt necesare. Cand are loc sincronizarea intregul snapshot este generat si trimis la semnatar (subscriber).
Replicarea snapshot va fi preferabila in locul replicarii tranzactionale cand schimbarile de date sunt substantiale, dar ocazionale. Daca o organizatie de vanzari mentine o lista cu pretul produselor si pretul este actualizat o data sau de doua ori in acelasi an, este recomandat replicarea intregului snapshot de date dupa ce a fost modificat. Crearea unor snapshoturi noi este o optiune daca editam tabele relativ mari, care sunt actualizate doar de editori (publishers).
Replicarea snapshot este adesea folosita atunci cand e nevoie de a rasfoi o lista de preturi, cataloguri, sau date pentru suport de decizii unde cele mai multe date nu sunt esentiale si datele sunt folosite ca read-only.
Aceasta replicare este utila atunci cand:
- datele sunt in special statice si nu se modifica des. Atunci cand se modifica este util sa editam o noua copie pentru semnatar;
- este acceptabil sa avem copii ale datelor care sunt expirate de o perioada de timp.
Replicarea snapshot este utila atunci cand avem nevoie sa distribuim o copie de date read-only, dar deasemenea ofera posibilitatea de a actualiza datele la semnatar (subscriber). Cand semnatarul doar citeste datele, consistenta tranzactiilor este mentinuta intre editor si semnatar din cauza ca datele sunt propagate folosind doua faze, protocolul de incredintare (intre doua PC), o trasatura a optiunii de actualizare imediate. Replicarea snapshot necesita o procesare constanta mai mica decat replicarea tranzactionala din cauza ca nu necesita o monitorizare continua a modificarilor de date de la sursele server. Daca setul de date care trebuie replicat este foarte mare, poate avea nevoie de o sursa substantiala de retea pentru a fi transmis.

2.3. Cum functioneaza replicarea snapshot.(SQL)

Replicarea snapshot este implementata de agentul snapshot si agentul de distributie. Agentul snapshot pregateste fisierele continand schemele si datele tabelelor si obiectelor de baze de date editate, stocheaza fisierele in foldere snapshot si inregistreaza sincronizarea functiilor in bazele de date distribuite la distribuitor. Implicit folderele snapshot sunt amplasate in distribuitor, dar se poate specifica o locatie alternativa (care poate fi un alt server, Cd-rom, disc, etc.).
Agentul de distributie muta snapshoturile tinute in tabelele de baze de date spre tabelele de destinatie ale semnatarului. Bazele de date distribuite sunt utilizate doar de replicare si nu contin nici o alta tabela utilizator.

Agentul snapshot de fiecare data cand este activat, el verifica daca a mai fost adaugata vreo noua semnatura. Daca nu este nici o noua semnatura, nu este creata nici o noua scriere de fisiere de date. Daca publicatia este creata cu optiunea de a crea primul snapshot imediat activat, noua schema si fisierele de date sunt create de fiecare date cand agentul snapshot este activat. Toate schemele si fisierele de date sunt stocate in folderul snapshot, agentul de distributie sau agentul merge le transfera la semnatari (vezi fig.2 si fig. 3, paginile 10 respectiv 15).

Fig. 1 Functionarea replicarii snapshot.

Agentul de distributie de fiecare data cand este activat pentru o publicatie snapshot, el muta schema si datele la semnatar(subscriber).

2.4. Replicarea tranzactionala.

Un snapshot initial de date este aplicat la semnatar, iar apoi cand modificarile de date sunt facute la editor, tranzactia individuala este capturata si propagata la semnatar.

Replicarea tranzactionala foloseste conectarea tranzactiei pentru a capta modificarile de incrementare care au fost facute asupra datelor din tabelele publicate. Microsoft SQL server 2000 monitorizeaza declaratiile de inserare, actualizare si stergere, sau alte modificari facute datelor si stocheaza aceste modificari in baze de date distribuite, care de fapt stau la coada. Modificarile sunt apoi propagate la semnatari si aplicate in aceeasi ordine in care au aparut.
Daca semnatarii au nevoie sa primeasca modificarile de date aproape in timp real, ei au nevoie de o retea conectata la editor. Replicarea tranzactionala poate oferi semnatarilor o latenta foarte mica. Semnatarii primesc de obicei datele folosind “push subscription” si de obicei primesc modificarile de la editor intr-un minut sau chiar mai putin, aceasta depinzand de retea, distanta si traficul de informatii.

2.5. Cum functioneaza replicarea tranzactionala.

Replicarea tranzactionala este implementata de agentul snapshot, agentul log reader si agentul de distributie. Agentul snapshot pregateste fisierele snapshot care contin scheme si date ale obiectelor de baze de date si tabelelor editate, stocarile de fisiere in folderul snapshot, inregistreaza sincronizarile de functii ale bazelor de date distribuite la distribuitor.
Agentul “log reader” monitorizeaza conectarea tranzactiilor a fiecarei baze de date configurata pentru replicarea tranzactionala si copiaza tranzactiile facute pentru replicare de la conectare in baze de date distribuite.
Agentul de distributie muta functiile initiale snapshot si tranzactiile tinute in tabele de baze de date distribuite.

2.6. Snapshotul initial.

Inainte ca o noua replicare tranzactionala spre un semnatar sa poata primi modificarile de la un editor , semnatarul trebuie sa contina tabele cu aceleasi scheme si date ca si tabelele editorului.
Copierea completa a publicatiei curente de la editor la semnatar este efectuata in snapshotul initial.
Dupa ce o publicatie si o semnatura au fost create, este nevoie sa se creeze si transfere un snapshot initial pentru semnatar. Schema transferului snapshot si datelor spre semnatar contine constrangeri, proprietati extinse, indexi, mecanisme si tabele sistem necesare pentru replicare. Snapshotul contine diferite tipuri de fisiere depinzand de tipul replicarii si articolele din publicatie:

Tipul replicarii Fisiere comune snapshot
Replicare snapshot si replicare tranzactionala Scheme (.sch); date (.bcp); constrangeri si indexi (.dri); constrangeri (.idx)
Replicare merge Scheme (.sch); date (.bcp);constrangeri si indexi (.dri); mecanisme (.trg); tabele de date sistem (.sys); tabele in conflict (.cft).

Cand snapshoturile sunt distribuite si aplicate asupra semnatarului, doar semnatarul care asteapta snapshotul initial este afectat, ceilalti semnatari la acea publicatie (care au primit adaugarile, actualizarile, stergerile sau alte modificari asupra publicatiei) nu sunt afectati.

Fig 2 Functionarea replicarii tranzactionale.

2.7. Procesele snapshot concurente.

Tipic prin generarea snapshotului, SQL Server va pune parti de chei (blocheaza accesul temporar) in toate tabelele publicate pe toata durata generarii snapshotului. Aceasta previne actualizarile nedorite care pot fi facute tabelelor publicate. Procesele snapshot concurente, valabile doar pentru replicarea tranzactionala nu tin aceste chei in timpul generarii snapshotului si permit utilizatorului sa poata sa lucreze, in timp ce SQL Server creeaza fisierele snapshotului initial. Dupa inceperea replicarii, agentul snapshot plaseaza cheile in tabelele publicatiei, iar dupa ce tranzactia este primita de semnatar cheile sunt retrase si modificarile in bazele de date pot continua.
Procedurile prin care agentul snapshot implementeaza snapshotul initial sunt aceleasi ca procedurile folosite in replicarea snapshot (vezi pagina 6 ).
Durata tinerii cheilor este foarte mica (cateva secunde), chiar daca este copiata o mare cantitate de date. Din acest punct agentul snapshot incepe sa genereze fisierele snapshot. Cand snapshotul este complet, o inregistrare secundara care indica sfarsitul snapshotului este scrisa la conectare. Orice tranzactie care apare pana ce snapshotul este generat este capturata intre cele doua indicii, de inceput si de sfarsit si trimisa mai departe la bazele de date distribuite de catre agentul log reader. Atunci cand snapshotul este aplicat semnatarului, agentul de distributie aplica in primul rand fisierele snapshot (schemele si fisierele .bcp), apoi revizuieste fiecare tranzactie capturata pentru a vedea daca a fost deja trimisa la semnatarul careia ii era destinata. In timpul procesului de revizuire, tabelele semnatarului sunt blocate.
Depinzand de numarul tranzactiilor capturate la editor in timp ce snapshotul a fost creat, ne putem astepta la o crestere a timpului necesar pentru aplicarea snapshotului asupra semnatarului.
Declaratiile de actualizare text (UPDATETEXT) nu pot fi efectuate asupra datelor marcate pentru replicare, in timp ce ele sunt extrase, in timpul proceselor snapshot concurente. Daca vom initia o declaratie UPDATETEXT vom primi un mesaj de eroare, care indica ca aceasta operatie nu este posibila din cauza ca se desfasoara procese snapshot concurente. Dupa ce snapshotul e complet, declaratiile UPDATETEXT pot fi efectuate din nou.
Procesele snapshot concurente folosesc un volum mare de tabele inserate, urmate de o serie de declaratii speciale INSERT si DELETE care aduc tabelele intr-o stare consistenta. Aceste operatii sunt efectuate ca o singura tranzactie, astfel incat utilizatorii bazelor de date nu vad datele ca fiind intr-o stare inconsistenta. Pentru a preveni modificarea datelor cu identitate proprie ale semnatarului, este indicat sa folosim optiunea NOT FOR REPLICATION. Procesele concurente snapshot sunt valabile doar la replicarea tranzactionala, atunci cand se ruleaza instante ale SQL Server.
Procedurile prin care agentul snapshot implementeaza snapshotul initial in replicarea tranzactionala sunt aceleasi proceduri cu cele folosite in replicarea snapshot. Dupa ce fisierele snapshot au fost generate le putem vedea in folderele snapshot folosind Snapshot Explorer. In SQL Server extindem folderele de replicare si publicari (Publisher), facem clic dreapta pe publicatie (publication_name) si alegem “Explore the Latest Snapshot Folder”.

2.8. Modificarea datelor si agentul log reader.

Agentul log reader functioneaza continuu, sau cu acordul unui program stabilit atunci cand a fost creata publicatia. Cand se executa, in primul rand citeste conectarea tranzactiilor publicate si identifica orice declaratie de inserare, actualizare si stergere, sau modificarile facute tranzactiilor de date care au fost marcate pentru replicare, apoi agentul trimite intreaga copie a tranzactiilor de la bazele de date distribuite spre distribuitor. Agentul log reader foloseste proceduri stocate intern sp_replcmds pentru a da urmatorul set de comenzi. Baza de date devine o cerinta store-and-forward (stocheaza si mai departe) in asteptare, ale carei modificari sunt trimise semnatarului. Doar tranzactiile care au consimtamant sunt trimise bazelor de date distribuite.
Agentul log reader apeleaza sp_repldone pentru a marca replicarea acolo unde s-a terminat. In final agentul marcheaza randurile din tranzactie care sunt gata pentru terminare si care au fost replicate deja. Randurile care asteapta sa fie replicate spre semnatar nu sunt terminate.
Modificarile de date facute semnatarului, vor fi propagate intotdeauna ca o singura declaratie de randuri. Daca o actualizare vrea sa modifice doar o singura coloana dintr-o tabela de date, actualizarea va fi propagata ca o serie de declaratii de stergere urmata de o serie de declaratii de inserare. Actualizarile facute vederilor indexate sau tabelelor de baza in care vederile indexate sunt stabilite, vor fi propagate ca o pereche DELETE/INSERT.
Agentul log reader functioneaza in agentul SQL server, la distribuitor si poate fi administrat direct accesand SQL Entreprise Manager, in monitorul de replicare si in folderele agentului.

2.9. Agentul de distributie.

Comenzile tranzactiilor sunt stocate in baze de date distribuite pana ce agentul de distributie le propaga tuturor semnatarilor. Bazele de date distribuite sunt folosite doar de replicare si nu contin alte tabele utilizator. Semnatarii vor primi tranzactiile in aceeasi ordine in care sunt aplicate la editor.
SQL Server poate valida datele actualizate la semnatar de catre procesele replicate si ne putem asigura ca datele de la editor sunt aceleasi si la semnatar. Validarea datelor de catre SQL Server se face calculand numarul de randuri si/sau verificarea sumei de la editor si apoi prin compararea acestor valori cu numarul de randuri si/sau verificarea sumei calculate la semnatar. O singura valoare este calculata pentru tabelele intregii publicatii si una pentru tabelele semnatarului, dar datele din coloanele cu text sau imagini nu sunt incluse in calcul. In timpul efectuarii verificarii, cheile (blocheaza temporar accesul la tabele) sunt plasate temporar in tabelele a caror randuri sau sume sunt efectuate, dar calculul se efectueaza repede (cateva secunde) si cheile sunt retrase.
Saltul erorilor in replicarea tranzactionala. Agentul skiperrors ne permite sa specificam care erori pot fi sarite in timpul proceselor distribuite. Tipic, atunci cand agentul log reader si agentul de distributie functioneaza in mod continuu, si unul dintre ei intalneste o eroare, agentul si procesele de distributie se opresc. Prin specificarea erorilor asteptate sau erorile care nu vrem sa intervina in replicare, cu parametrul skiperrors agentul de distributie va incarca informatiile despre erori si apoi va continua sa functioneze.

2.10. Replicarea merge (merge replication).

Replicarea merge este procesul de distribuire al datelor de la editor la semnatar, permitand editorului si semnatarului sa faca modificari si actualizari in timp ce conexiunea intre ei este deconectata, iar apoi se transmit actualizarile intre locuri (editor-semnatar) atunci cand se conecteaza. Replicarea merge permite diferitor locuri sa faca actualizari merge ca un rezultat uniform.
Snapshotul initial este aplicat semnatarilor si apoi SQL Server colecteaza modificarile de date de la editor la semnatari. Datele sunt sincronizate intre servere printr-un ceas programat, sau la cerere. Din cauza ca actualizarile sunt facute la mai mult decat un server, datele asemanatoare trebuie actualizate de editor, sau mai mult decat un semnatar. Replicarea merge contine optiuni care sunt din default si unele setate pentru conflictele de rezolutie pe care le putem defini pentru a configura publicatiile merge. Cand apare un conflict, este solicitata o hotarare de catre agentul merge si determinate ce date vor fi acceptate si propagate spre alte locuri.
Replicarea merge este utila cand:
• mai multi semnatari au nevoie sa actualizeze datele in diferite momente si sa propage modificarile editorului spre alti semnatari;
• semnatarii au nevoie sa primeasca date, sa faca modificari indirect si mai tarziu sa sincronizeze modificarile intre editor si alti semnatari;
• cand nu se asteapta multe conflicte cand datele sunt actualizate in mai multe locuri.
Atunci cand datele trebuie sa fie actualizate de semnatari, se poate folosi replicarea snapshot sau replicarea tranzactionala cu optiunile de actualizare a subscriptiei, sau se poate folosi replicarea merge.
Metoda pe care o alegem depinde de topologia replicarii, de nevoile aplicatiei si a celor care o folosesc si carora le este destinata:

Folosim replicarea merge atunci cand… Folosim replicarea snapshot sau replicarea tranzactionala cu actualizare imediata sau actualizare in asteptare atunci cand…
• datele replicate sunt citite si actualizate de semnatari; • datele sunt mai mult read-only la semnatar;
• semnatarii si editorii sunt conectati doar ocazional; • semnatarul, distribuitorul si editorul sunt conectati cea mai mare parte a timpului;
• avem nevoie ca actualizarile sa fie propagate pe baza rand-cu-rand si conflictele sa fie evaluate si rezolvate la nivel de randuri; • conflictele cauzate de actualizarile multiple ale acelorasi date sunt ocazionale;
• conflictele cauzate de actualizarile multiple ale acelorasi date sunt manipulate si rezolvate. • Avem nevoie ca actualizarile sa fie propagate intr-o tranzactie de baza si conflictele sa fie evaluate si rezolvate.

2.11. Functionarea replicarii merge (merge replication).

Replicarea merge este implementata de agentul snapshot si agentul merge. Agentul snapshot pregateste fisierele continand scheme si date ale tabelelor publicate, stocheaza fisierele in folderul snapshot si insereaza functii de sincronizare in publicatiile de baze de date. Deasemenea agentul snapshot creeaza replicarea -; procedurile specificate si tabelele sistem.
Agentul merge aplica functiile snapshotului initial tinute in tabelele de baze de date publicate, asupra semnatarului. Totodata incrementeaza modificarile de date care apar la editor sau la semnatar, dupa ce a fost creat snapshotul initial.
Rolul distribuitorului este foarte limitat in replicarea merge, astfel incat implementarea distribuitorului este locala (pe acelasi server cu editorul). Agentul de distributie nu este folosit pe toata durata replicarii merge, iar bazele de date distribuite din distribuitor stocheaza “istoricul “ informatiilor despre replicarea merge.
Fig.3 Functionarea replicarii merge (merge replication).

2.12. Identificatorul unic de coloana.

SQL Server identifica o coloana unica pentru fiecare rand (row) in tabelele care sunt replicate. Aceasta permite randurilor sa fie identificate unic atunci cand exista mai multe copii de tabele. Daca tabela contine deja o coloana cu prioritatea ROWGUIDCOL, care este un index unic, sau o constrangere a unei chei primare, SQL Server va folosi automat acea coloana ca fiind identificator de rand pentru tabela publicata.
Astfel SQL server adauga uniqueidentifier (identificator unic) de coloana numit rowguid, care are proprietatea ROWGUIDCOL si un index a tabelelor publicate. Adaugarea coloanei ROWGUIDCOL creste marimea (size) tabelelor publicate. Coloana rowguid si indexul sunt adaugate tabelelor publicate atunci cand agentul snapshot se executa pentru prima data pentru o publicatie.

2.13. Mecanismele replicarii merge.

SQL Server instaleaza mecanismele care urmaresc modificarile datelor in fiecare rand sau coloana. Mecanismele captureaza modificarile facute tabelelor publicate si le inregistreaza in tabelele sistem merge. Urmarirea mecanismelor in tabelele publicate se face in timp ce agentul snapshot ruleaza prima data. Mecanismele sunt create pentru semnatar cand ii este aplicat snapshotul. Mecanisme diferite sunt generate pentru articole care urmaresc modificarile la nivel de rand si coloana. Din cauza ca SQL Server suporta mecanisme multiple de acelasi tip in tabelele publicate, mecanismele replicarii merge nu se interfereaza cu aplicatiile.

2.14. Procedurile stocate.

Agentul snapshot creeaza deasemenea proceduri stocate optionale care actualizeaza bazele de date subscrise. Cand datele sunt actualizate si noile inregistrari au nevoie sa intre in bazele de date subscrise, optiunile de proceduri stocate sunt folosite mai mult ca declaratii individuale de inserare, actualizare si stergere.

Cand agentul log reader intalneste declaratii de inserare, actualizare sau stergere marcate pentru replicare in conectarea tranzactiilor a unei publicatii de baze de date, el reconstruieste un rand din declaratia tranzactiei SQL din inregistrarea modificarilor de date. Apoi agentul log reader trimite declaratia tranzactiei SQL reconstruita la fiecare semnatar si aplica declaratiile tabelelor destinatie in fiecare baza de date destinatara. Acesta este un mecanism default folosit de SQL Server acolo unde sunt unul sau mai multi semnatari diferiti.
Daca toti semnatarii au instante ale SQL Server se pot inlocui declaratiile de inserare, actualizare si stergere din conectarea tranzactiilor cu optiuni de proceduri stocate pentru fiecare semnatar. Pentru fiecare tabela publicata exista trei cai prin care se pot manevra declaratiile (inserare, actualizare si stergere) detectate de agentul log reader in timpul procesului:
• Sa lasam mecanismele default ale replicarii sa lucreze;
• Specificarea ca nici o actiune nu va fi facuta la nici un semnatar. Tranzactiile de acest tip nu sunt replicate. De exemplu daca selectam inlocuirea declaratiilor de stergere cu proceduri stocate si nu introducem in loc nici o declaratie, declaratiile de stergere nu sunt replicate pentru acel articol;
• Specificarea unor proceduri optionale care pot fi apelate de toti semnatarii. Cand agentul log reader intalneste un astfel de tip de declaratie, intr-o tranzactie marcata pentru replicare, el construieste o apelare a unei proceduri stocata bazata pe aceasta sintaxa si deplaseaza valorile coloanelor la procedura stocata de referinta. Acesta este comportamentul default al SQL Server.

2.15. Tabelele sistem ale replicarii merge.

SQL Server adauga cateva tabele sistem la bazele de date pentru a sprijini urmarirea datelor, sincronizarea eficienta si conflictele de detectare, rezolutiile si rapoartele. Pentru fiecare modificare sau rand nou creat, tabela Msmerge_contents contine generarea in care au aparut cele mai recente modificari. Deasemenea contine versiunea unui intreg rand si toate atributele randurilor. Tabelele contin coloane ROWGUID pentru a se alatura tabelelor publicate.
Coloanele generate in astfel de tabele sunt ca un ceas logic indicand cand un rand a fost ultima data actualizat. Valorile actuale datetime nu sunt folosite pentru marcare cand apar modificari, sau conflicte de decizie si nu este nici o dependenta intre ceasurile sincronizate in diferite locuri (site). Aceasta face conflictele de detectie si algoritmii de rezolutie mai elastici la diferentele de ora ale zonelor si diferenta dintre ceasurile fizice de pe mai multe servere. La un loc dat, generarea numerelor corespund cu ordinea in care modificarile au fost facute de agentul merge, sau un utilizator din alt loc. Daca o tabela publicata are coloane rezervate pentru procesele merge, nu se va putea genera un snapshot initial din cauza coloanelor cu nume duplicate, numele de coloane rezervate sunt: reason_code, source_object, reason_text, pubid, conflict_type, origin_datasource.

2.16. Snapshotul initial si agentul snapshot.

Inainte ca un un semnatar sa poata primi incrementarea modificarilor de date de la editor, semnatarul trebuie sa contina tabele cu aceleasi scheme si date ca tabelele de la editor. Copierea completa a publicatiei de la editor la semnatar este aplicata apeland snapshotul initial, asa cum am explicat in capitolul anterior la replicarea snapshot.
Replicarea modificarilor de date apare doar dupa ce replicarea merge se asigura ca semnatarul are cele mai recente snapshoturi ale tabelelor de scheme si date care au fost generate. Cand snapshoturile sunt distribuite si aplicate asupra semnatarilor, doar acei semnatari care au nevoie de snapshotul initial sunt afectati. Semnatarii care au primit deja inserarile, actualizarile si stergerile, sau alte modificari asupra datelor publicate nu sunt afectati, numai daca subscrierea (aderarea) este marcata pentru reinitializare sau publicatia este marcata pentru reinitializare. In acest caz toate subscrierile corespunzatoare unei publicatii sunt reinitializate in timpul urmatorului proces merge.
O tabela de subscriere, poate subscrie doar la o singura tabela merge. De exemplu daca publicam o tabela de optiuni in doua publicatii, iar apoi suntem semnatari la ambele publicatii de la un semnatar, indicarea aceleiasi aderari la baza de date, vom primi date de la ambele publicatii. Unul dintre agentii merge va esua in timpul sincronizarii initiale.
Snapshotul initial poate fi o subscriptie atasata bazei de date in replicarea snapshot, replicarea tranzactionala, si replicarea merge. Daca folosim subscriptii de baze de date atasabile si subscriptia va fi copiata, ea nu va mai putea fi aplicata altui semnatar.
Agentul snapshot implementeaza snapshoturile initiale folosind aceiasi pasi ca agentul snapshot din replicarea snapshot (vezi pagina 6 ).

2.17. Agentul merge.

Dupa ce snapshotul initial a fost aplicat unui semnatar, mecanismele SQL Server vor incep sa urmareasca declaratiile de inserare , actualizare si stergere facute la editori si semnatari. Agentul merge urmareste la fiecare loc (site), cea mai mare generare de date care a fost trimisa celorlalte locuri si cea mai mare generare de date care a fost trimisa din alte locuri spre el. Aceasta ofera punctul de plecare, astfel incat fiecare tabela poate fi examinata fara a se uita la datele care sunt deja in alte locuri. Generarea stocarilor unui rand (row) trimis poate diferi intre diferite locuri, fiindca numarul locului reflecta ordinea in care modificarile au fost procesate in acel loc. Putem limita numarul de procese care lucreaza simultan prin setarea parametrului @max_concurrent_merge al sp_addmergepublication sau sp_changemergepublication. Daca numarul maxim de procese deja lucreaza, orice nou proces merge care apare va sta in asteptare pana ce alte procese vor fi terminate. Putem seta StartQueueTimeout in linia de comanda a agentului merge pentru a specifica cat timp agentul ar trebui sa astepte pentru ca celelalte procese merge sa se termine.

2.18. Sincronizarea.

Sincronizarea apare atunci cand editorii si semnatarii, intr-o topologie cu replicare merge se reconecteaza si modificarile sunt propagate intre ei, si daca este necesar, conflictele sunt detectate si rezolvate. In timpul sincronizarii, agentul merge trimite toate modificarile de date la semnatar. Datele se deplaseaza de la originea modificarilor spre locurile care au nevoie sa fie actualizate sau sincronizate. Daca numarul modificarilor trebuie sa fie controlate, agentul merge comanda linia de parametrii -;MaxUploadChanges si -; MaxDownloadChanges care pot sa fie configurate. In acest caz datele de la editor si semnatar converg doar atunci cand toate modificarile sunt propagate.
La destinatia bazelor de date, actualizarile propagate din alte locuri sunt comparate cu valorile, detectarea conflictelor si regulile de rezolutie. Un agent merge evalueaza valorile datelor primite si a celor curente, si orice conflict intre cele noi si cele vechi este rezolvat automat pe baza unui default resolver, care a fost specificat cand a fost creata publicatia sau unul optional. Replicarea merge ofera mai multe out-of-the-box custom resolver care pot fi setati dupa necesitati.
Modificarile valorilor de date sunt replicate spre alte locuri si converg cu modificarile facute in acele locuri doar atunci cand apare sincronizarea. Sincronizarea poate sa apara in cateva minute, zile, sau chiar la distante de saptamani si este definita in programarea agentului merge. Datele converg si se actualizeaza, din momentul ultimei sincronizari. Perioada de pastrare pentru sbscriere este specificata pentru fiecare publicatie si cum editorul si semnatarul vor fi sincronizati. Daca semnatarul nu se sincronizeaza cu editorul in perioada de pastrare, publicatia este marcata ca expirata si va trebui sa fie reinitializata. Perioada default pentru retinerea unei publicatii este de 14 zile.

2.19. Validarea permisiunii pentru semnatari.

SQL Server ofera posibilitatea de a valida permisiunea pentru un semnatar de a face descarcarile de modificari de date de la un editor. Aceasta verifica daca conectarea agentului merge are permisiunea de a efectua comenzi de inserari, actualizari si stergeri asupra bazei de date publicate. Validarea permisiunii necesita ca agentul merge conectat sa fie un utilizator valid cu permisiuni corespunzatoare asupra bazelor de date publicate. Validarea permisiunii este adaugata la verificarea daca conectarea utilizata de semnatar este in lista de acces a publicatiei (publication access list <P.A.L.>). Validarea permisiunii pentru un semnatar poate fi setata folosind proprietatea @check_permissions in sp_addmergearticle.
Valoare Descriere
0 (default) Permisiunea nu va fi verificata.
1 Verificarea permisiunii la editor inainte ca inserarile facute la un semnatar sa poata fi descarcate.
2 Verificarea permisiunii la editor inainte ca actualizarile facute la un semnatar sa poata fi descarcate.
4 Verificarea permisiunii la editor inainte ca stergerile facute la un semnatar sa poata fi descarcate.

2.20. Modelele fizice ale replicarii in SQL Server.

Fig4. Modelul editor si distribuitor -; semnatar.

Fig. 5 Modelul editor si distribuitor -; n semnatari.

Fig.6 Modelul legaturii intre doua servere editor -; semnatar.
Fig. 7 Modelul editor cu distribuitor indepartat

Fig. 8 Modelul semnatarului central.

CAPITOLUL III

3.1.Replicarea in Oracle

In Oracle exista asa cum am amintit si in prima parte (vezi pagina 4 ) urmatoarele tipuri de replicare:

Replicarea de baza. Folosind replicarea de baza, replicarea datelor furnizeaza acces read-only la tabelele de date cu origine intr-un loc primar sau master. Oricum, aplicatiile in toate privintele sistemului trebuie sa acceseze datele din locul primar cand este necesara o actualizare de date.

Fig. 2.1.

Replicarea avansata. Trasaturile caracteristice ale replicarii avansate extind capacitatile replicarii de baza (read-only) prin permiterea aplicatiilor de a actualiza tabelele replicate in toate privintele unui sistem de baze de date replicate .Datele replicate de oriunde din sistem au acces de citire si de actualizare asupra tabelelor de date. Serverele de baze da date functioneaza automat prin convergerea tuturor datelor din tabelele replicate si asigura consistenta tranzactiilor locale si integritatea datelor.

Fig. 2.2.

Mediile inconjuratoare ale replicarii de baza suporta aplicatii care solicita acces read-only la tabelele de date cu originea intr-un loc primar.
Distributia informatiilor la replicarea de baza este utila pentru informatiile distribuite. De exemplu, sa consideram operatiile efectuate de un mare lant de magazine. In acest caz, este critic de a garanta ca informatia despre pretul unui produs este intotdeauna valabila, relativ curenta si consistenta la vanzarea cu amanuntul.
Informatiile descarcate la replicarea de baza sunt utilizate ca o cale de replicare a tuturor bazelor de date sau a informatiilor descarcate. De exemplu, cand performantele unui sistem care proceseaza un volum mare de tranzactii este critic, poate fi avantajos sa mentinem o baza de date duplicata pentru a izola interogarile cerute asupra suportului de decizii ale aplicatiei .
Transportul informatiilor la replicarea de baza poate fi folosita ca un mecanism de transport al informatiilor. De exemplu replicarea de baza poate sa mute periodic datele din procesarea datelor dintr-o tranzactie spre un depozit de date (warehouse).
O tabela snapshot read-only este o copie locala a unei tabele de date originara in una sau mai multe tabele master indepartate. O aplicatie poate interoga datele dintr-o tabela snapshot read-only, dar nu poate introduce, actualiza sau sterge randuri in snapshot.

3.2. Definirea unei interogari snapshot.(Oracle)

Structura logica a tabelelor snapshot este definita de o interogare care recomanda datele in una sau mai multe talele master indepartate.
Cerintele de definire a snapshoturilor ar trebui facute astfel incat fiecare rand din snapahot corespunde direct unui rand sau unei parti de rand intr-o singura tabela mastrer. Specific definirea unui snapshot nu ar trebui sa contina o functie distincta sau agregata, o clauza GROUP BY sau CONNECT BY, alaturari tipuri de subcerinte pentru restrictii sau un set de operatii.
Exemplu: definirea unei tabele simple snapshot.
CREATE SNAPSHOT sales. customers AS
SELECT * FROM sales.customers@hg.acme.com
In toate cazurile, definitia unei cerinte snapshot trebuie sa referentieze toate cheile primare ale coloanelor din tabela master. Definirea unei cerinte snapshot poate include tipuri restranse de subcerinte cu referinte la mai multe tabele, pentru a filtra randurile din tabelele master snapshot. O subcerinta snapshot poate fi folosita pentru a crea snapshoturi cu referinte de la tabelele copil la tata, ceea ce implica mai multe nivele:

CREATE SNAPSHOT sales.orders AS
SELECT * FROM sales.ordres@hg.acme.com O
WHERE EXISTS
(SELECT c_id FROM sales.customers@hg.acme.com c WHERE o.c_id AND zip = 19555);

Cand se creeaza o noua tabela snapshot, se creeaza cateva baze de date fundamentale ale obiectelor pentru a sprijini snapshotul. Intotdeauna se creeaza o tabela de baza ca sa stocheze datele snapshot. Numele tabelei de baza snapshot este SNAP$_snapshotname. Se creeaza un index pentru cheia primara in tabela de baza snapshot. Numele indexului este numele indexului folosit pentru a aplica cheia primara corespondenta, constransa la locul master. Se creeaza o vedere (view) pentru fiecare snapshot. Privirea ia numele snapshotului si e prevazuta cu acces read-only la snapshot. Se pot crea indecsi aditionali pentru un snapshot definit printr-o subcerinta.

3.3. Reimprospatarea snapshoturilor.(Oracle)

Nu este necesar ca datele din snapshot sa se potriveasca cu datele curente din tabelele master. O tabela snapshot este o reflectare a unei tranzactii consistente a datelor master astfel incat datele exista la un punct specificat in timp. Pentru a pastra datele unui snapshot relativ curente cu datele din master, se reimprospateaza periodic snapshotul. Reimprospatarea unui snapshot este un teanc de operatii eficiente care fac ca snapshotul sa reflecte o stare curenta a masterului. Noi trebuie sa ne decidem cum si de unde reimprospatam fiecare snapshot pentru a-l face mai curent. De exemplu, aplicatia de baza snapshot din tabela master necesita actualizare si reimprospatare frecventa, in contrast snapshoturile care depind de tabele master relative necesita reimprospatari ocazionale. Trebuie analizate cerintele si caracteristicile aplicatiei pentru a determina intervalele de reimprospatare a snapshoturilor.
Pentru a reimprospata snapshoturile se utilizeaza diferite tipuri de reimprospatari: “complet” si “rapid” la reimprospatarea grupurilor snapshot, sau “manual” si “automat”.
Pentru a executa reimprospatarea completa a unui snapshot, serverul care administreaza snapshotul executa cerintele definite in snapshot. Setul rezultat al cerintelor este inlocuit in datele snapshotului existent pentru a-l reimprospata
Pentru a efectua o reimprospatare rapida, serverul care administreaza snapshotul, in primul rand identifica schimbarile care au avut loc in master pana la cea mai recenta reimprospatare a snapshotului, dupa care o aplica asupra snapshotului . Reimprospatarea rapida este mai eficienta decat cea completa cand sunt putine schimbari in master, fiindca participarea serverului si retelelor replica mai putine date. Reimprospatarea rapida este valabila doar atunci cand tabelele master au un snapshot conectat.

3.4.Conectarea snapshoturilor.(Oracle)

Cand o tabela master corespunde unuia sau mai multor snapshoturi, se creeaza un snapshot conectat. O tabela master a unui snapshot conectat urmeaza reimprospatarea rapida a datelor. Pentru toate snapshoturile corespondente este posibil sa existe doar un singur snapshot conectat pentru o tabela master. Cand un server executa o reimprospatare rapida pentru un snapshot, foloseste datele din tabela master a snapshotului conectat pentru a reimprospata eficient. Cand se creeaza un snapshot conectat pentru o tabela master, se creeaza o tabela de baza pentru a sprijini conectarea. O tabela a unui snapshot conectat contine o cheie primara, o marca de timp si optional ROWID al randurilor aplicatiei care actualizeaza tabela master. Poate sa mai contina coloane filtru care sa sprijine reimprospatarea rapida pentru snapshoturile cu subcerinte. Numele tabelei snapshotului este MLOG$_master_table_name.
Reimprospatarea grupurilor snapshot se efectueaza pentru a mentine integritatea referirilor si consistenta tranzactiilor intre snapshoturile mai multor tabele master, Oracle alcatuieste si reimprospateaza fiecare snapshot ca parte a grupului reimprospatat. Reimprospatarea snapshoturilor in grup se face intr-o singura operatie. Dupa reimprospatarea tuturor snapshoturilor in reimprospatarea grupului, datele snapshotului din grup corespund in timp aceluiasi punct de consistenta a tranzactiei.

3.5. Reimprospatarea automata a snapshoturilor.

Reimprospatarea automata a snapshoturilor se realizeaza atunci cand se creeaza un grup de reimprospatare. De obicei administratorul configureaza grupul astfel incat isi reimprospateaza automat snapshoturile. Administratorii pot reimprospata manual grupurile oricand este necesar.
Cerintele care se impun atunci cand se configureaza un grup pentru reimprospatare automata sunt:
• Specificarea unui interval de reimprospatare pentru grup
• Serverul trebuie configurat sa administreze snapshoturi cu unul sau mai multe procese SNP background pentru a reimprospata periodic snapshoturile care sunt alocate.
Atunci cand se creeaza un grup de reimprospatare snapshot, se poate specifica un interval de reimprospatare automata pentru grup. Cand se seteaza un interval de reimprospatare pentru grupuri trebuie tinut cont de urmatoarele caracteristici:
• Datele sau expresiile de date care specifica intervalul de reimprospatare trebuie sa fie evaluate la un punct de timp viitor.
• Intervalul de timp al reimprospatarii trebuie sa fie mai mare decat lungimea timpului necesar pentru efectuarea reimprospatarii.
• Expresiile datelor relative trebuie evaluate la un punct relativ in timp a celei mai recente reimprospatari de date. Daca esecul unei retele sau sistem se amesteca cu schema de reimprospatare a grupului, evaluarea unei expresii relative de date se poate schimba in consecinta.
• Expresiile de date explicite evaluate la un anumit punct in timp, nu tin cont de reimprospatarea datelor cele mai recente.
Daca nu se poate realiza o reimprospatare rapida pentru un anumit snapshot serverul executa o reimprospatare completa a snapshotului.
Reimprospatarea automata a snapshoturilor se face folosind functii care asteapta pentru a programa procedurile din interiorul sistemului. Functiile in asteptare necesita ca ultimul SNP background sa fi rulat. Un proces SNP background verifica periodic functiile in asteptare si executa toate functiile speciale.

3.6. Snapshoturi complexe.(Oracle)

Cand definirea unei cerinte pentru un snapshot contine o agregare distincta a unei functii, clauze GROUP BY sau CONNECT BY, alaturari de tipuri limitate a subcerintelor, sau un set de operatii, atunci snapshotul e unul complex.
Exemplu de definire a unei tabele complexe a unui snapshot:
CREATE SNAPSHOT scott.emp AS
SELECT ename, dname
FROM scott.emp@hg.acme.com a, scott.dept@hg.acme.com b
WHERE a.deptno=b.deptno
SORT BY dname
Dezavantajul fundamental al unui snapshot complex este ca Oracle nu poate executa o reimprospatare rapida ci doar una completa. Consecintele sunt ca utilizarea unor astfel de snapshoturi complexe pot afecta performantele retelei in timpul reimprospatarii complete a snapshotului.

3.7. ROWID snapshot(Oracle)

Oracle stabileste o cheie primara a snapshotului in cheia primara a tabelei master. Din aceasta cauza putem:
• Recunoaste tabela master a unui snapshot fara a completa o reimprospatare completa a snapshotului.
• Crearea unui snapshot cu definirea cerintelor care include un tip restrans de subcerinte.
• Pentru a sprijini un ROWID snapshot, Oracle creeaza un index aditional in tabela de baza a snapshoturilor cu numele I_SNAP$_snapshotname.
•
Replicarea avansata este folosita pentru mai multe tipuri de aplicatii cu cerinte speciale. Este utila pentru desfasurarea prelucrarii aplicatiilor care folosesc medii separate de date.
Replicarea avansata e utila pentru desfasurarea prelucrarii tranzactiilor si aplicatiilor care necesita puncte multiple de acces la informatiile de baze de date care au ca scop incarcarea unei aplicatii distribuite mare, asigurarea valabilitatii continue sau furnizarea accesului la mai multe date.

Replicarea avansata poate fi folosita ca un mecanism de transport al informatiilor. De exemplu un sistem cu replicare avansata poate periodic incarca si descarca date de la baze de date actualizate spre un depozit de date.

Fig. 2.3.

3.8. Locurile snapshoturilor si actualizarea lor.(Oracle)

Locurile master in sistemele cu replicare avansata pot consolida informatiile pe care aplicatiile le actualizeaza la snapshoturile indepartate. Facilitatile replicarii avansate permit aplicatiilor sa adauge, actualizeze si sa stearga randuri din tabele prin actualizarea snapshoturilor.
Snapshoturile actualizabile au urmatoarele proprietati:
- sunt intotdeauna simple, reimprospatare rapida a tabelelor;
- Oracle propaga modificarile facute snapshoturilor actualizabile asupra snapshoturilor indepartate;
- Oracle reimprospateaza un snapshot actualizabil ca parte a grupului reimprospatat;
- Snapshoturile actualizabile au aceleasi obiecte de baza, tabele de baza, indecsi, vederi ca snapshoturile read-only;
- aditional Oracle creeaza tabela USLOG$_snapshotname pentru a suporta actualizarea snapshoturilor.

Replicarea multimaster. Aplicatiile pot actualiza orice tabela replicata in orice loc intr-o configuratie multimaster.
Fig. 2.4.
3.9. Configuratii hibrid.(Oracle)

Replicarea multimaster si snapshoturile actualizabile pot fi combinate in configuratii hibrid sau mixte pentru a indica cerintele unor diferite aplicatii. Configuratiile mixte pot avea orice numar de locuri master si mai multe locuri snapshot pentru fiecare master.

Masterul replicat trebuie sa contina datele din tabelul complet care a inceput sa fie replicat, avand in vedere ca snapshoturile pot replica subseturi de date a tabelelor master.
Replicarea multimaster permite replicarea schimbarilor pentru fiecare tranzactie daca acestea au avut loc. Daca au loc conflicte la schimbarile facute la mai multe copii ale aceleiasi date, locurile master detecteaza si rezolva conflictele.
Un obiect replicat este un obiect de baze de date care exista in mai multe servere, intr-un sistem de baze de date distribuite. Replicarea avansata in Oracle faciliteaza si permite replicarea tabelelor, declansarea bazelor de date, replicarea pachetelor, indecsilor si sinonimelor.

In mediile replicarii avansate Oracle administreaza replicarea obiectelor folosind replicarea grupurilor. Prin organizarea bazelor de date referitoare la obiecte cuprinse intr-un grup replicat, este usor sa se administreze mai multe obiecte impreuna. Tipic se creeaza si foloseste un grup replicat pentru a organiza schema obiectelor necesare pentru a sustine o aplicatie particulara de baze de date. Obiectele dintr-un grup replicat pot fi din mai multe scheme de baze de date si o schema poate contine obiecte care fac parte din diferite grupuri replicate. Restrictia este ca un obiect replicat poate apartine unui singur grup.

3.10. Locurile replicarii.(Oracle)

Un grup replicat poate exista in mai multe locuri de replicare. Mediile replicarii avansate sustin doua tipuri de baza a locurilor: locuri master si locuri snapshot.
- Un loc master mentine o copie completa a tuturor obiectelor dintr-un grup replicat. Toate locurile master fac parte dintr-un multi master, mediile replicarii avansate comunica direct cu unul sau altul pentru a propaga schimbarile de date si scheme din grupul replicat.
- Fiecare grup replicat are un singur si doar un loc master definit. Definirea locurilor grupurilor master este un loc master care este punctul de control pentru administrarea grupurilor replicate si obiectelor din grup.
- Un loc snapshot sustine doar snapshoturi read-only si actualizabile a tabelelor de date asociate intr-un loc master. O tabela a unui loc snapshot poate contine toate, sau un subset a datelor din tabelul cuprins in interiorul unui grup replicat. Oricum acestea trebuie sa fie snapshoturi simple cu corespondenta unu la unu la tabelele unui loc master. De exemplu, un loc snapshot poate contine snapshoturi pentru tabelele selectate intr-un grup replicat. Un snapshot particular ar putea fi doar o portiune selectata dintr-o anumita tabela replicata. Un grup replicat poate contine si alte obiecte replicate.

3.11. Administrarea replicarii API si cerintele administrarii.

Pentru a configura si administra un mediu cu replicare avansata, fiecare server care participa si foloseste replicarea Oracle este programat cu o interfata API. Administrarea serverelor cu replicare este un set de pachete incapsulate PL/SQL, proceduri si functii pe care administratorii le pot configura
O cerere de administrare este folosirea unei proceduri sau functii din administrare a replicarii Oracle. De exemplu: cand folosim administrarea replicarii pentru a crea un nou grup master, administratorul replicarii completeaza un task utilizand: DBMS_REPCAT.CREATE_MASTER_REPGROUP. Alte cereri de administrare genereaza replicari aditionale ale administrarii API pentru a completa cererile.
Pentru a sustine replicarea intr-un mediu cu replicare avansata, trebuie generate unul sau mai multe obiecte sistem pentru a sustine fiecare tabela replicata, pachet sau procedura.
Cand se replica o tabela trebuie generate doua pachete corespondente. Oracle foloseste tabele replicate tablename$RP pentru a replica tranzactiile care implica tabele si pachete de tabele replicate tablename$RP pentru a rezolva conflictele de replicare in care sunt implicate tabele.
3.12. Propagarea datelor asincron (stocheaza si mai departe).
Configuratiile tipice replicarii avansate care au incredere in nivelul de randuri se schimba folosind replicarea datelor asincrona. Replicarea datelor asincrona are loc cand o aplicatie actualizeaza o replica locala unei tabele, cand se stocheaza informatii care stau in asteptare si apoi informatia e replicata mai departe in alte locuri de replicare.
Fig. 2.5.

Cum arata si figura de mai sus Oracle foloseste mecanismele sistemului intern, amanari de tranzactii, tranzactii amanate care stau in asteptare si functii in asteptare pentru a propaga nivelele da date schimbate asincron in locurile master intr-un sistem cu replicare avansata, precum si dintr-un snapshot spre o tabela master.
Cand aplicatiile functioneaza intr-un mediu cu repli