la cap 1 traduci metode de distribuire a datelor si distributed data transactions..

replication traduci pana la sql server 2005 tools, la cap 2 components of replication..pana la physical replication methods.

Daca gasesti cuvantul performanta il inlocuiesti cu executare , a executa .intelegi u Tim-stamp nu am stiut ce inseamna si l-am pus cu verde mare ca se vezi .
Cap 1

Metode de distribuire a datelor

Exist dou metode de distribuire a datelor n SQL Server: tranzac ii distribuite i replicare. Este posibil s se men in mai multe copii n acela i mediu ale datelor actuale utilizand ambele metode. De asemenea, este posibil s se pun n aplicare una dintre aceste metode ntr-un mediu distribuit. n replicarea tranzactionala cu actualiz ri din coada de a teptare, putem transmite date utiliznd Microsoft Distributed Transaction Coordinator (MS DTC). De i, aceasta cercetare se bazeaza pe replicare , voi explica diferenta dintre cele doua metode. (am pus faza cu cercetarea ca am mai vazut-o la tine :D )

Tranzactiile datelor distribuite

Tranzac iile distribuite sunt tranzac ii care acoper dou sau mai multe servere. Aceste servere sunt denumite manageri de resurse, i coordonarea acestor tranzac ii se face de c tre managerii de tranzac ie. MS DTC este un manager de tranzac ie care coordoneaz prelucrarea cererilor de tranzac ie din bazele de date, cozi de mesaje, i sisteme de fi iere, fie pe o masina locala sau fie sunt distribuite n ntreaga re ea. Prin angajamentul celor dou faze (2PC), MS DTC garanteaza finalizarea tranzac iei la toate site-urile, n acela i timp. De exemplu, s presupunem c avem dou baze de date (prima incluzand conturile clien ilor i cealalta con inand arhiva vnz rilor facute de catre clienti ) ce au doua servere diferite. Tranzac iile distribuite n acest exemplu ar implica, executarea limbajului de manipulare a datelor (LMD) in ambele baze de date. Prin urmare, bazele de date precum cele din SQL Server sunt considerate ca fiind manageri de resurse atunci cnd o aplica ie devine, depoziteaz sau manipuleaz o tranzac ie distribuit . Configurarea diferitelor componente implicate in executarea unei tranzactii distribuite este demonstrata in figura de mai jos . De obicei cererea ini iaz o tranzac ie distribuit , i managerul de tranzac ie, dup cum s-a men ionat mai nainte, ac ioneaz n calitate de coordonator. Ea de ine o copie local a inregistrarii MS DTC , care p streaz identitatea tranzac iei i con ine informa ii cu privire la orice manageri de resurse nrolat cu managerul de tranzac ie. Jurnal ine, de asemenea, cont de tranzac iile care, provin din sau se ndreapt spre al i manageri tranzac ionali. SCHEMUTZA

Deci, n fapt, o tranzac ie distribuit poate parcurge mai multe noduri, unde fiecare nod const intr-un MS DTC. Acest lucru este ilustrat mai jos. SCHEMUTZA SQL Server gestioneaz tranzac iile distribuite pe plan intern. Atunci cnd aceste tranzac ii se conecteaza la dou sau mai multe servere, aceste servere sunt denumite manageri de resurse. Unui utilizator I se va parea ca tranzac ia este executata la nivel local. n primul rnd, aplicarea ini iaz o tranzac ie prin apelarea la metoda BeginTransaction DTC MS, care este un manager de tranzac ie. Un obiect tranzac ie este creat, i ac ioneaz ca reprezentant al tranzac iei. Fi ierul ( Log File) ine o eviden a tuturor tranzac iilor, i managerul de resurse - pentru fiecare control de noduri, dac exist o astfel de tranzac ie. Tranzac ia obiect, se leag de obiectul de conectare a interfetei bazei de date deschise Connectivity (ODBC),

SQLSet Connect Attr. ( UITA-TE AICI CA AI ZIS CA NU TREBUIE SA LASI TERMENII NEEXPLICATI) Stratul ODBC este
apelnd la metoda un strat intermediar care se a eaz pe partea de sus a stratului de baze de date. ODBC faciliteaz circula ia tranzac iei dintre managerul de tranzac ie i managerul de resurse. Tranzac ia ori va actualize ori va citi datele sau in cel mai bun mod vor fi evaluate ambele opera iuni. La sfr itul tranzac iei, n mod normal se va aplica metoda Rollback dar , de asemenea se poate incheia tranzactia in sine prin apelarea metodei Commit. SCHEMUTZA Dac cererea nu reu e te, DTC SM intrerupe comanda. Cu toate acestea, dac cererea emite o comanda COMMIT, MS DTC trebuie s se adapteze. De exemplu, unii dintre managerii de resurse ar putea finaliza cu succes tranzac ia, si unii nu. Sau ar putea exista o perturbare a traficului n re ea care mpiedic realizarea tranzac iei. Putem rezolva aceste probleme prin utilizarea celor dou faze Protocol (2PC). Managerul de tranzac ie se asigur c to i managerii de resurse, fie emit o comanda COMMIT ce executa pe deplin tranzactia, fie renunta. . Protocolul 2PC const in dou etape: preg tirea i angajarea. . Faza pregatitoare incepe cu DTC SM transmisia unui mesaj catre toti managerii de resurse, intrebandu-le dac acestea sunt preg tite s accepte tranzac ii. n acest stadiu, orice tranzac ii sunt scrise pe disc. Managerii de resurse le raspund prin trimiterea cu success sau nu a unei notificari la MS DTC. Dac unul dintre manageri de resurse raporteaz un e ec, DTC MS trimite o comand rollback la fiecare dintre manageri de resurse, incluzand acele opera iuni ale unei tranzactii de succes, iar tranzac ia este anulat . Procesul este afi at in urmatoarea figura.

SCHEMUTZA
Diagrama arata faza pregatitoare intr-un process

Dac toti managerii de resurse trimit preg tiri de succes la administrator (suna ciudat pregatiri de

success) , problemele managerului de tranzac ie sunt rezolvate de managerii de resurse. Apoi , managerii de resurse savarsesc comenzile asa cum ne arata figura de mai jos.

Schemutza 1-7

Cap 2 Replicarea
Acum, c tim ce este o tranzac ie de date distribuite , voi explica ce este replicarea si cate tipuri de replicare exista. Replicarea, este un "set de tehnologii", care pot muta date i obiecte de baze de date, de la o baz de date la alta i pot traversa n diferite locatii geografice. Aceasta permite utilizatorilor s lucreze cu o copie local a bazei de date, i toate modificarile facute de acestea sunt transferate la unul sau mai multe servere la distan sau la utilizatorii de telefonie mobila din ntreaga re ea. Coeren a bazei de date este men inut prin procesul de sincronizare. Avantajele replicarii unei baze de date sunt: separarea fizic a bazelor de date i laten a normal a datelor. De exemplu, personalul de vnz ri care lucreaz n domeniul lor, pot introduce comenzile sau modific rile pe dispozitivele lor portabile i transferul de date se face n mod automat la sediul central men innd n acela i timp coeren a bazelor de date la fiecare site. ntrebarea este cum se distribuie datele folosind replicarea, i r spunsul depinde de cnd, unde, i modul n care datele se propaga. Exist dou tipuri de replicare: dornica i lenesa.

Replicarea Dornica

Replicarea dornica este, de asemenea, cunoscuta sub numele de replicare sincron . n aceast metod , o cerere poate actualiza o copie local a unui tabel, i n aceea i tranzac ie se pot actualiza, de asemenea, alte copii din acela i tabel. Nu apar anomalii dar ,orice anomalie n concuren este detectata prin metoda de blocare. Dac oricare dintre noduri sunt deconectate, replicarea dornica mpiedic ca actualizarea sa aiba loc. n plus, rapiditatea tranzac iilor este garantat prin folosirea metodei 2PC.Cu toate acestea, exist un compromis n executie, ca urmare a tuturor actualiz rilor,efectuate ntr-o singur tranzac ie. Replicarea dornica const n urm toarele etape: executia, transmiterea, verificarea, O tranzactie executata este transmisa la noduri diferite i, n cazul esecului unui singur nod tranzac ia este anulat i toate celelalte noduri sunt notificate cu privire la e ec. Tranzac ia este apoi ntrerupt n toate nodurile. n cazul n care replicarea este de succes n toate nodurile,un angajament este difuzat i o copie a tranzactiei efectuate este trimisa tuturor nodurilor. Acest tip de replicare este ilustrat in figura urmatoare. SCHEMUTZA SQL Server 2005 BOL nu men ioneaz n mod explicit, replicarea dornica, astfel nct s ne putem intreba de ce amvrea sa o folosim. S presupunem c dorim s avem o copie n timp real a bazei de date master astfel nct s fim pregatiti n cazul unui e ec. Natura sincrona a transferului de date in replicarea dornica faciliteaz n timp real transferul de date, i n aceast situa ie ar fi utile. Cu toate

acestea, replicarea dornica nu este o alegere bun pentru un mediu la distan sau mobil, deoarece se reduce performan a. De asemenea, ntr-un mediu mobil nodurile nu sunt ntotdeauna conectate.

Replicarea Lenesa
Replicarea Lenesa este, de asemenea, cunoscuta sub numele de replicare asincron . n acest mod, n cazul n care tranzac iile sunt s vr ite, ele sunt trimise la site-uri diferite pentru ca actualiz rile s apar . Oricum, dac acestea sunt trimise inapoi , modific rile nu vor fi transmise c tre site-uri diferite. Astfel, ns i natura replicarii asincrone permite actualizarea tranzac iilor si ca acestea s fie trimise unor site-uri deconectate ca i n cazul unor seturi portabile sau dispozitive mobile. Acest lucru este prezentat n figura 1-10.

Schieema
Cu acest tip de replicare, este posibil pentru dou site-uri diferite sa actualizeze acelea i date pe acelasi site. Aceasta va conduce la un conflict n actualizarea datelor. Astfel de conflicte de actualizare trebuie s fie rezolvate n replicarea lene a, iar acest lucru se face prin asocierea

timestamp cu

fiecare dintre obiectele tranzac iei. Fiecare obiect poarta amprenta de timp asociata cu actualizarea precedent a acelor date. A a c atunci cnd o tranzac ie este trimisa la site-ul de destina ie, se verific mai nti pentru a vedea dac

timestamp-ul asociat cu copia local

a datelor se potriveste cu

timestampul

tranzac iei vechi . Numai n cazul n care se potrivesc cu schimbarile, incluzand timestamp-ul noii tranzactii. Dac timestamp-urile nu se potrivesc la faza initiala,actualizarea tranzactiei este respins .

Replicare n SQL Server

SQL Server urmeaz asincron replicarea (lenesa).. Aceasta permite trei tipuri diferite de replicare asincron : instant, tranzac ionala, i replicarea fuzionala. Replicarea Instant face o copie a datelor i propag schimb ri stabilite pentru ntregul set de date, mai degrab dect tranzac iile individuale, f cnd astfel un proces discontinuu i care implic un grad mai mare de laten . De exemplu, s presupunem c un lan de libr rii ofera reduceri o dat sau de dou ori pe an. Libr riile regionale doar trebuie s fie con tiente de modific rile ocazionale de pre , asa ca putem folosi replicarea instant pentru a transfera schimb rile de la sediul central la libr riile regionale. Replicarea tranzactionala permite schimb rile incrementale la date pentru a putea fi transferate, fie continuu, sau la anumite intervale de timp. Replicarea tranzactionala este utilizata n mod normal n cazul n care nu exist un volum mare de actualiz ri i tergeri. Acest tip de replicare este utilizat de obicei ntr-un mediu server-to-server. De exemplu, atelierele de repara ii auto au nevoie de date n timp real despre inventar n depozite i alte magazine. Prin utilizarea replicarii tranzactionale n toate magazinele, este posibil pentru fiecare dintre magazine s tie de inventarele actuale, i deficitul stocului poate fi anticipat in timp.

Re plicarea Fuzionala permite un grad mai mare de autonomie. Acesta permite serverelor semnatare sa faca modific ri i apoi sa propage acele modific ri la serverele de publicare, care, in schimb transmit modific rile la alte servere abonat . Vnz torii care lucreaza in domeniu pot introduce comenzile sau modific rile o dat ce tranzac iile sunt complete. Datele actualizate din diferiti vnz tori pot crea conflicte, care vor fi rezolvate prin instituirea unei politici de conflict in replicarea fuzionala. Politica conflictuala privita n SQL Server ne ajut s urm rim conflictele. Punctul de cereri de vnzare, cum ar fi automatizarea fortei de vanzari, sunt situa ii n care putem utiliza replicarea fuzionala

Beneficiile replicarii
Gestionarea replicarii poate fi o sarcin dificil chiar i pentru un administrator de baze de date; asadar de ce am vrea sa o folosim? Scalabilitate, toleran la erori, autonomia de site-uri, i compatibilitatea cu diferite platforme, cum ar fi dispozitive portabile, sunt unele din beneficiile de a utiliza replicarea ntr-un mediu de afaceri. Urm toarea ntrebare este : cnd ar trebui s utilizam replicarea.?  Aplicatii de date care trebuie s fie folosite n mediile online sau offline;  Situa ii n care avem nevoie sa copiem i sa distribuim date c tre site-uri diferite pe o baza programat ;  Mediile n care schimb rile sunt f cute de mai mul i utilizatori de la multe site-uri, si trebuie sa imbinam modificarea de date;  Aplicatii Web care permit utilizatorilor s r sfoiasc volume mari de date.

Deci, care sunt diferen ele dintre replicare i tranzac iile distribuite? n cazul replicarii, poate exista un decalaj de timp n propagarea de date, n func ie de tipul de replicare utilizat. n cazul tranzac iilor distribuite, toate copiile de date trebuie s fie sincronizate n orice moment. Fiecare server care este inclus n tranzac ie trebuie s fie disponibil tot timpul i trebuie s fie capabil s -si termine partea sa din tranzac ie. Nerespectarea tranzac iei in oricare dintre servere determina anularea tranzactiei . Prin urmare, tranzac iile distribuite au o latenta mai mica comparativ cu replicarea asincron. Spre deosebire de replicare, tranzac iile distribuite nu sunt scalabile. Cu replicarea, serverele nu sunt nevoite sa fie online tot timpul , astfel nct autonomia site-urilor este sus inut , si permite mai multa scalabilitate n acest proces. Figura arat gradul de autonomie i de laten n diferitele metode de distribuire a datelor. Dup cum putem vedea, tranzac iile distribuite au cea mai mic laten , n timp ce replicarea fuzionala are cea mai mare latenta i autonomie maxim . Figura

Replicarea tranzactionala are o laten si autonomie scazuta fin comparativ cu replicarea fuzionala si cea instant. n replicarea tranzactionala, schimb rile de date trebuie s fie actualizate att la surs cat i la destina ie. Replicarea Instant face o verificare a obiectelor si datelor intr-un anumit interval de timp si nu monitorizeaza schimbarile specifice din cadrul datelor. Autonomia si latenta replicarii instant se afla intre replicarea tranzactionala si cea fuzionala.

CAP. ||
Componentele replicarii : Acestea sunt diferitele componente de replicare:  Distribuitor;  Editor;  Semnatar;  Publicatie;  Articolul;  Subscriere;  Agen ii;

Distribuitor
Server-ul Distribuitor este link-ul comun, care permite tuturor componentelor implicate n replicare s interac ioneze unele cu altele. Acesta con ine baza de date de distribu ie, i este responsabil pentru trecerea buna de date ntre serverele Publisher i serverele abonatului. Dac serverul Distribuitor se afl pe aceea i ma in ca server-ul Publicatie, este cunoscut sub denumirea de server Distribuitor local, dar dac este pe o ma in separat de serverul Publicatie, este numit la distan server Distribuitor. n replicarea la scar larg , este mai bine sa g zduim server-ul Distribuitor de pe un server la distan . Acest lucru nu numai c va mbun t i performan a, dar, de asemenea, va reduce procesul I/O si va reduce si impactul de replicare pe serverul Publisher. Rolul server-ului Distribuitor variaz n func ie de tipul de replicare: n Replicarea Instant si cea Tranzactionala, in distributia bazelor de date n magazinele server Distribuitor ; in tranzac iile replicate temporar i, de asemenea, stocheaza arhiva locurilor de munca. Agen ii de replicare sunt, stocati n serverul Distribuitor, cu excep ia cazurilor n care agen ii sunt configurati de la distan sau este utilizata subscrierea trage . (Subscrierea- trage este cea in care server -ul abonat solicit actualiz ri periodice ale tuturor modific rilor aduse la server-ul de publicare.)  n Replicarea Fuzionala, spre deosebire de cea instantant i cea tranzac ional , distribu ia bazelor de date n server-ul Distribuitor stocheaza istoria sincronizarii. De asemenea, contine Agentul Instantant i Agentul Fuzional pentru subscrierea impinge ( push) . 

(O subscriere push este o subscriere n care server-ul Editor propag modific rile la serverele abonate , f r nicio solicitare specificata de catre server-ul subscriere). Distributia bazelor de date este un sistem de baze de date care este creat atunci cnd server-ul Distribuitor este configurat.

Editor
n timp ce server-ul Distribuitor gestioneaz fluxul de date, serverul Editor asigur ca datele sa fie disponibile pentru replicarea la alte servere. Editorul este server -ul care con ine datele pentru a fi replicate. Se pot identifica, de asemenea, i men ine modific ri n date. n func ie de tipul de replicare, modific rile de date sunt identificate i periodic

time-stamped.

Abonat
Server-ul Abonat stocheaza copiile i prime te actualiz ri de pe server-ul Editor. Periodic actualiz rile efectuate pe server-ul Abonat pot fi trimise napoi la server-ul Editor. Poate de asemenea, fi necesar pentru server-ul Abonat s ac ioneze ca un server Editor i sa reediteze datele pentru alte servere abonate.

Publicarea
Serverul Publicare con ine o colec ie de articole n baza de date de publicare. Aceast baz de date spune serverului Publicare care date trebuie s fie trimise la alte servere sau la serverele semnatare. Cu alte cuvinte, baza de date de publicare ac ioneaz ca surs de date pentru replicare. Orice baz de date care este folosita ca o surs de replicare, trebuie s fie activata ca un server de Publicare.. n SQL Server se poate realiza acest lucru prin utilizarea Creare Publicarea Wizard, Configurare publicare i distribu ie Wizard, sau sistemul de sp_ optiune db de replicare procedura stocata (sp_replicationdboption system stored procedure.). Baz de date care este publicata poate s con in una sau mai multe publica ii. O publica ie este o unitate care con ine unul sau mai multe articole ce sunt trimise la serverele abonate.

Un articol este orice grupare de date pregatite pentru a fi replicate; este o component a unei publicari. Acesta poate sa con in un set de tabele sau un subset de tabele. Articolele pot con ine, de asemenea, un set de coloane (vertical filtrate), un set de rnduri (orizontal filtrate), proceduri stocate, vizualizari, vizualizari indexate, func ii (FDU).

Articolul

Serverul Subscriere trebuie s -si defineasc subscrierile pentru un anumit set de publicari n vederea primirii instant (snapshot) de la server-ul Publicare . Pentru toate cele trei tipuri de replicare, fi ierele instant sunt realizate din schema i din fi ierele initiale de date ale public rii i sunt stocate n folderul instant( snapshot). Orice modificare ulterioar a datelor sau schemei sunt transferate de la server-ul Publicare la server-ul Subscriere. Acest proces este cunoscut sub numele de sincronizare.

Subscrierea

Subscrierile intocmesc articolele diferite la tabelele corespunz toare din server-ul Subscriere. Ele precizeaz atunci cnd serverele Subscriere trebuie s primeasc publicarile de la serverele publicare. Exist dou metode prin care modific rile datelor facute la publicare pot fi trimise la subscriere n SQL Server: subscrierile anonim si subscrierile denumite. ntr-o subscriere anonima nici o informa ie despre server-ul subscriere sau despre subscriere nu este stocata pe server-ul Publicare.. Este responsabilitatea serverelor Subscriere sa tina evident datelor i subscrierilor. Aceste detalii sunt apoi transmise Agentului de Distributie pentru a fi folosite la urmatoarea sincronizare. Subscrierile denumite sunt cele n care serverele Subscriere sunt activate n mod explicit la serverele Publicare. Exist dou tipuri de subscrieri denumite : subscrieri mpinge i subscrieri trage . (De fapt, subscrierile anonime sunt un fel de subscrieri trage). Ce tip de subscriere folosim depinde de locul in care vrem ca administrarea subscrierii si procesul agentilor sa aiba loc . Subscrierile- impinge , sunt create la server-ul de Publicare, a a cum se arat n figura de mai jos Server-ul Publicare detine controlul subscrierilor i poate propaga modific ri, fie la cerere, fie continuu, sau la intervale regulare. Cu toate acestea, sincronizarea in subscrierile- impinge, este de obicei transmisa n mod continuu, ori de cte ori apar modific ri n publicare, f r s mai a tepte ca server-ul Subscriere s fac o cerere. n acest caz, nu este nevoie s administram serverele Subscriere individual -Serverul Abonatul trebuie s fie n mod explicit activat n server-ul Publicare pentru ca acest tip de replicare sa functioneze. Pentru Subscrierea-trage, serverele Subscriere trebuie s fie activate la serverele Publicare , la fel ca pentru subscrierea- mpinge. n subscrierea- trage, subscrierile sunt create de serverele Subscriere . Server-ul Subscriere solicita modific ri n publicare de la server-ul de Publicare , iar datele sunt sincronizate, fie la cerere sau la o or programat .

Desen
Implementarea unei subscriei- trage este facuta de catre Distributie sau de catre Agentul Fuzional, dar sincronizarea agentului este facuta de Server-ul Subscriere. Schimbarile sunt administrate de Server-ul Subscriere. Acest lucru este demonstrat mai jos.

Unde se potrivesc agentii, i care este scopul lor? Ei lucreaza incontinuu si centralizeaz toate modific rile, imbunatatesc locuri de munc necesare pentru distribuirea datelor. Este necesar de retinut totu i c agentul server-ului SQL trebuie s se deruleze in ordine pentru ca lucratorii sa-si poata indeplini sarcinile. Executabilele se afl in Program Files \ Microsoft SQL Server \ 90 \ COM, iar acestea pot fi rulate din comenzi scurte si precise. Exist cinci tipuri diferite de agen i: Agentul Instant; Agentul de Citire a Jurnalului (Log Reader Agent) Coada pentru Agentul de Citire; Agentul de Distributie; Agentul Fuzional

Agentul

Numele executabil al Agentului Instant este snapshot.exe. Acest agent isi are locul intr-un server Dstribuitor . Agentul Snapshot este utilizat n toate replicarile, n special n momentul de sincronizare ini ial . Se face o copie a schemei i a tabelelor de date ce urmeaza a fi publicate, le stocheaz n fi ierul instant, si nregistreaza informa ii despre sincronizare n distribu ia bazelor de date.

Agentul Instant

Numele executabil al Agentului este logread.exe. Acest agent este utilizat n replicarea tranzactionala. Agentul de citire a jurnalului monitorizeaz tranzac ii de la toate bazele de date care sunt implicate n replicarea tranzactionala . Agentul copie orice schimbare a datelor care sunt marcate pentru replicare n jurnalul de tranzac ie a bazei de date de publicare i le trimite Serverului Distribuitor unde sunt stocate in baza de date de distribu ie. Tranzac iile sunt tinute acolo pn sunt gata de a fi trimise la serverele de Subscriere. PAGINA 386 : Agentul de citire a jurnalului r este responsabil pentru urm rirea jurnalului de tranzac ie n baza de date de publicare pentru orice modific ri marcate pentru replicare, apoi le impinge la baza de date de distribu ie, unde agentul de distributie, preia mesajele. Ca atare, Agentul este programat s fie difuzat continuu. Jurnalul de tranzac ie este eliminat de SQL Server numai dup ce toate mesajele au fost livrate la baza de date de distribu ie. Precum Agentul Instant i cel de Distribu ie, Agentul de citire a jurnalului ruleaza ca un loc de munc i este enumerat n sec iunea locurilor de munca a Server-ului SQL n SSMS. Pentru a ne uita la ea, deschidem obiectul locurilor de munc n Obiectul de SSMS Explorer, facem clic dreapta pe Agentul Log Reader i selectam Proprietati. Vom vedea pagina generala a ferestrei Propriet i de locuri de munc ,

Agentul de Citire a Jurnalului

Schema de la 386
Numele executabil al Agentului Coada de Citire este qrdsvc.exe. n replicarea tranzactionala, exist o op iune de actualizare imediata a mesajelor sau pastrarea lor ntr-o coad , folosind fie Server ul coada SQL sau coada Microsoft de mesaje. n cazul n care mesajele actualizate trebuie s fie trimise imediat, este necesar s existe o leg tur constant ntre editori i serverele Subscriere. Cu toate acestea, dac avem de gnd sa stocam mesajele din coad , nu avem nevoie de o conexiune constanta ; putem trimite mesaje ori de cte ori conexiunea devine disponibil . n astfel de cazuri, Coada pentru Agentul de Citire ia mesajele de la coad i le aplic server-ului de publicare.

Coada pentru Agentul de Citire

Replicare tranzac ional

cu actualizare imediat ( instanta? )

Nu este mare diferen ntre func ionarea intern a cozii de a teptare i actualizarea imediata a subscrierilor. n cazul actualizarii imediate a subscrierilor, cu toate acestea, conexiunea trebuie s fie men inut ntre editori i serverele Subscriere . De asemenea, nu avem nevoie de Coada pentru Agentul de Citire , din moment ce mesajele nu sunt plasate n coada pentru subscriere a bazei de date . Spre deosebire de publicarea standard, subscrierea are abilitatea de a actualiza datele.

Sincronizarea WEB cu Replicarea Fuzionala

Bazele Sincronizarii web
Cu sincronizarea web, putem utiliza protocolul HTTPS pentru a replica datele utilizatorilor de telefonie mobil pe Internet .Cu toate acestea, exist doua limit ri principale:

 

bazele de date de la distan trebuie s fie baze de date ale Server-ului SQL ; Numai replicarea fuzionala (nu instantant sau tranzactionala) este sus inut .

Serverul web este, de obicei Serviciul Informatiilor pe Internt (IIS), server care vine cu sistemul de operare Windows. Utilizarea diferitelor componente ale server-ului permite crearea unor topologii interesante pentru sincronizarea web. Acestea sunt op iunile : Un server Doua servere Mai multe servere IIS si Server-ul de Publicare SQL. Topologia un singur server este cea mai simpla : IIS, Server-ul de Publicare SQL, i Serverul Distribuitor rezida pe aceeasi masina. Topologia pe dou servere implic separarea fizic a server-ului web si a serverelor replicarii. n acest caz, ar trebui s configuram serverul de IIS pe o ma in , n timp ce plasam server-ul Publicare si server-ul Distribuitor pe un alt server. Ultima topologie implica utilizarea multipla de servere IIS . ntr-un astfel de scenariu, avem mai multe servere IIS pentru a facilita ,in acelasi timp, numarul mare de cereri ale serverelor subscribere. Pentru a ajuta n sarcina distribuirii ,putem folosi mai multe servere IIS care sunt trimise direct c tre server-ul Publicare. Acum, c tim despre topologiile diferite pe care le putem utiliza, ne vom uita la cum s infiintam sincronizarea web pentru serverele subscriber utilizand replicarea fuzionala. Sunt trei lucruri de setat :  O publicare pentru sincronizarea web;  Serverul IIS care se va sincroniza subscriberele  Subscriberele trage - care vor utiliza sincronizarea web

Configurarea Publicarii pentru o Sincronizare Web

Luam n considerare cazul n care un reprezentant de vnz ri care lucreaz n domeniu, cu un laptop trebuie s verifice numerele i descrierea articolelor, pe care vnz torul le are n stoc, i care sunt preturile. Folosind subscrierile- trage , reprezentantul de vnz ri se poate conecta la serever-ul de Publicare configurat pentru replicarea fuzionala prin IIS si actualizeaza copiile articolelor, stocului, listei de preturi si a tabelelor din laptop.

Pentru acest exemplu, o publicare numit pub_mysales_mobile a fost creata sa foloseasca urm toarele tabele, drept articole: Postul, lista de pre uri, detalii de cumparare, stocul. Odat ce am nfiin at aceast publicare pentru replicarea fuzionala o putem configura pentru sincronizarea web. Urmatoarea figura ne demonstreaza configurarea publicarii fuzionale pentru o sincronizare web

Configurarea IIS pentru sincronizarea web

Procesul de configurare pentru IIS este integrat cu sistemul de operare. n mod implicit, acesta este instalat ca una dintre componentele Windows atunci cnd este instalat sistemul de operare, i poate rula ca o ntreprindere de servicii n timpul interac iunii cu alte servicii cum ar fi Windows Active Directory. Pentru a folosi subscrierele-trage pentru replicarea fuzionala si ca s fie sincronizate pe Web, trebuie s urmam ace ti pa i astfel incat sa se configureze IIS: 1. Configurare SSL, care este necesar pentru comunicarea ntre serverele Subscribere i IIS. 2. Configurarea serverul-ui pe care se execut IIS pentru sincronizarea web folosind Sincronizarea Configurarii Web Wizard.

3. Atribuim permisiuni corespunz toare pentru Server-ul Replicarii Ascultate SQL. 4. Trebuie sa ne asiguram c SSL func ioneaz corect prin rularea n modul de diagnosticare IIS.

Pentru acest exemplu de configurare, vom folosi un singur server de topologie: att IIS cat i serverul componentelor de replicare sunt instalate pe aceeasi masina. Publicarea este configurata cum am explicat anterior. Pentru a configura serverul IIS, deschidem SSMS i extindem folderul de Publicare Locala (Local Publication) Click-dreapta pe publicare, pub_mysales_mobile, i selectam Configurarea Sincronizarii Web. Astfel , ni se va cere tipul de subscribere pe care il vom utiliza dupa cum ne arata si figura.

Configurarea SSL pentru sincronizarea web

SQL Server utilizeaz SSL pentru a facilita comunicarea ntre serverele Subscriber i IIS. SSL asigur autenticitatea, integritatea mesajelor, i transmisiile de re ea criptate, n timp ce utilizatorii sunt conectati printr-un browser de Internet. Pentru permiterea acestei forme de securitate, trebuie s configuram caracteristicile SSL de IIS. Configurarea SSL este realizata prin utilizarea de certificate. Un certificat, mai precis cunoscut ca un certificat digital, asigur autenticitatea identitattii titularului (titularul fiind computer-ul pe care se ruleaza cererea). Aceste certificate sunt emise de c tre autorit i cum ar fi o autoritate de certificare (CA), care ac ioneaz n calitate de giran i pentru ambele p r i implicate n transferul de date autentificate. Ce se ntmpl n mod normal, este c partea care trimite datele autentificate trimit si o cheie comuna care a fost certificat de c tre un CA si este acceptat de c tre partea care prime te datele. Astfel, autenticitatea, integritatea mesajelor si confiden ialitatea lor sunt men inute. Exist dou tipuri de certificate: certificate de server i de client. Putem utiliza numai certificatul pentru server-ul sincronizarii web a replicarii fuzionale. Trebuie sa ne asiguram ca avem doar un singur certificat de server asociat cu URL-ul Internetului care arata unde este instalata masinaIIS. Ma in care are server-ul web va con ine, de asemenea componentele de replicare. Subscriptiile vor selecta primul certificat disponibil, care ar putea s nu fie cel pe care il dorim. Oricum, primul lucru ce trebuiefacut este sa obtinem un certificat de la un CA.. Facem acest lucru prin selectarea Porne te inetmgr.exe a Din meniul Start. Aceasta va deschide site-ul central

administrativ al IIS.

Rolul Subsistemelor si Proxies

Un subsistem este un set predefinit de func ionalitate, care este disponibil la server-ul Agent proxy SQL. Un proxy poate accesa oricare dintre subsisteme i, prin oferirea unei garan ii n jurul functionarii sale, poate decide care dintre utilizatoriipot accesa subsistemului. Reamintesc faptul c exist trei etape n executarea Agentului de fuziune .Chiar dac un proxy, pentru un utilizator, este membru al server-ului de administrare a sistemului, (Sysadmin fixe server), aceasta nu nseamn c utilizatorul va avea acces deplin la subsisteme. Prin urmare, proxy trebuie s aib acces prealabil la subsistem inainte de utilizatorul sa-si poata rula pasii de locuri de munc . Dup cum putem vedea toti lucratorii folosesc proxy. n re elele de calculatoare, un server proxy este un server ( al unui sistem informatic sau al unui program de aplica ie) care ac ioneaz ca un intermediar pentru cererile din partea clien ilor si caut resurse de la alte servere. Un client se conecteaza la serverul proxy, solicitnd unele servicii, cum ar fi un fi ier, conexiune, pagina web, sau alte resurse, disponibile de la un alt server. Server proxy evalueaz cererea n conformitate cu normele sale de filtrare. De exemplu, ar putea filtra traficul prin adresa IP sau protocol. Un server proxy poate modifica op ional cererea clientului sau raspunsul serverului, iar uneori poate servi cerere, f r a contacta serverul specificat. n acest caz, "cache" de r spunsuri din partea server la distan , i returneaz cererile ulterioare de acela i con inut direct. Un server proxy are o mare varietate de scopuri poten iale, inclusiv:

 Pentru a p stra ma ini sub nume anonime (n principal pentru securitate).  Pentru a accelera accesul la resurse (folosind cache-ul). proxy-uri le Web  Sunt frecvent utilizate la pagini de web cache de pe un server web.  Pentru a aplica politica de acces la servicii de re ea sau de con inut, de exemplu, pentru a bloca site-urile nedorite.  Pentru a trece de securitate / control parental.  Pentru a scana con inutul extern, de exemplu, pentru protec ia datelor scurgere.  Pentru a evita restric iile regionale. Un server proxy care trece cereri i r spunsuri nemodificate este de obicei numit un gateway sau proxy tunel, uneori. Un server proxy poate fi plasat n calculatorul utilizatorului local sau la diferite puncte ntre utilizator i serverele de destina ie de pe Internet. Pentru a vizualiza o list de prerogative i proxy , deschidem SSMS i apoi Explorer obiect.n conformitate cu obiectul de securitate, vom vedea obiectul prerogativelor, i cu el o list de acredit ri, a a cum se arat n figura urmatoare. Pentru a vedea procuri, deschidem Agentul obiect al server-ului SQL (SQL Server Agent object), si sub Proxy vedem o list de subsisteme ce apar in proxies.

Optimizarea Replicarii Instant

Optimizarea performan elor

Monitorizarea executarii unei baze de date este o func ie-cheie n administrarea oric rui sistem de backend . Diferite componente, cum ar fi server-ul hardware, de procesoare, i de memorie; proiectarea bazelor de date i configurarerea contribuie la performanta optima a server-ului SQL . Introducerea replicarii n configura ie se adaug la complexitatea procesului de optimizare. n timp ce acelasi ingredient- cheie joaca un rol activ n optimizarea unui system replicat , s-au ad ugat factori cum ar fi proiectarea public rii, num rul de articole n publicare, existen a oric ror filtre, op iuni de subscribere (cum ar fi mpingere sau tragere) ce pot afecta n mod semnificativ modul n care sistemul func ioneaz . Din moment ce topologia replicata este la locul sau, monitorizarea constant a sistemului este justificat pentru func ionarea eficient , astfel putem stabili parametrii care permit sistemului s func ioneze n mod corespunz tor. O linie de baz poate fi tras mpotriva functionaraii sale, pe care o putem m sura - dac topologia replicarii func ioneaz partial sau deloc-. Componentele care trag sistemul mai jos de nivelul acceptat pot fi ajustate. Odat ce am nceput n mod constant sa urm rim regular m sur torile de performan pentru obiecte care afecteaza direct sistemul, putem utiliza instrumente de analiz statistic , cum ar fi llinia de regresie, pentru a prognoza comportamentul sistemului. Aceasta este o abordare mai proactiv de optimizare a sistemului de replicare. Detectarea din timp a problemelor poate duce la o rezolvare mai rapida. nainte de punerea n aplicare a replicarii intr- un mediu de produc ie, trebuie s ntocmim o executare initiala privind un mediu de testare i sa folosim aceasta referinta pe o schema de produc ie. Astefl vom avea o viziune mai buna asupra modului de lucru a procesului de replicare i cum poate s reproduc cazurile testate prin ncorporarea ntr-un mediu de produc ie.Un mediu distribuit precum replicarea are considerente diferite de performan dect un sistem care folose te o aplica ie client care acceseaz un sistem de baze de date tradi ionale. Eficacitatea unui mediu replicat const n laten , concurenta, debit, durata, sincronizare, precum i n resursele hardware. Latenta este cantitatea de timp necesara tranzactiilor astfel incat sa poata fi transmise, i este piatra de temelie care determin tipul de replicare ales. Capacitate determin num rul de comenzi care pot fi trimise de la un nod la altul. Concurenta indic num rul de replicare a proceselor pe care sistemul il poate suporta. Toti acesti factori trebuie s fie luati n considerare la stabilirea unui system de replicare. M sur torile de performan , a a cum am men ionat mai devreme, ar trebui s fie luate la intervale regulare de timp astfel:  Luam m sur tori la scurt timp dup punerea n aplicare a topologiei de replicare;De i nu va fi nici un impact semnificativ la scurt timp dup punerea n aplicare, vom sti nivelul de baz la care sistemul func ioneaz ;  Ob inerea de informa ii la intervale regulare, att n timpul orelor de vrf cat i in afara orelor de vrf pentru procesul interogat, agen ii de replicare, avertiz ri, precum i generarea instant;  Se m soar timpul necesar pentru restaurarea bazelor de date replicate i a sistemului de baze de date, cum ar fi distribu ia i bazele de date msdb. Caracterul autonom al sistemelor de replicat, mpreun cu resursele hardware diferite, poate face, uneori, dificil de identificat natura exact a unei probleme. Dac un server care mai devreme a fost capabil s se ocupe de 50 conexiuni , brusc nu se mai poate ocupa nici macar de 5 conexiuni, astefl stim c exist o problem cu hardware-ul, i vom lua n considerare cre terea

resurselor hardware .. Instrumente precum sistemului de operare System Monitor, SQL Server Profiler, motorul bazei de date Tuning Advisor, Monitorul Replicarii, Monitorul de activitate n SSMS, pot ajuta la gasirea tuturor problemelor, a colectarea de informa ii, i s monitorizeze procesele care afecteaz optimizarea sistemului.

Utilizarea Sistemului Monitor

Utilizarea Sistemului Monitor este un instrument de server la nivel global. Ea vine cu Sistemul de operare Windows i poate fi utilizat pentru a monitoriza i m sura performan a obiectelor server-ului SQL,. Prin monitorizarea activit ii discului,utilizarea memoriei, i activitatea procesorilor putem autentifica activitatea sistemului e replicare. Fiecare dintre aceste obiecte pot avea unul sau mai multe contoare pe care le putem folosi la monitorizarea performan ei. Cnd utilizam Sistemul de monitorizare,luam datele intr-un timp scurt; numele executabil pentru Sistem de monitorizare este perfmon. Putem ncepe Sistemul de monitorizare prin selectarea Executare din meniul Start, tastnd perfmon, i f cnd clic pe butonul OK. n fereastra de performan , selectam n conformitate cu Sistemul Monitor sub Consola Root a a cum se arat n figura urmatoare. Aceast figura arat fereastra de performan dup ce am ales unele obiecte de performan i contoare corespunz toare.

Cele mai bune practici pentru replicarea Instant

Pastrarea script-ului de configurare : Din moment ce publicarea i subscrierile sunt configurate pentru replicarea instant folosind GUI, generam un script i p stram pentru o utilizare ulterioar . Scriptul poate fi testat folosind fie SSMS sau utilitarul Sqlcmd. Crearea de duplicari regulare: Duplicarea publicatiei (back-up process), subscrierii, msdb, distributiei bazei de date i imediat dupa ce am ad ugat o publica ie nou , sau am facut modific ri ale schemei publicatiei. Trebuie s duplicam bazele de date msdb pe Publicare (Publisher), Distribuitor, i serverele Subscribere, separat. Generarea executarii unei baze de date : Elaborarea unei baze de date pentru executarea replicarii instant pe partea de server- pentru fiecare server- i a resurselor hardware, cum ar fi procesoare, memorie, i configura ia Distribuitor-ului. Putem , de asemenea, sa executam o baz de date pentru partea de client si pentru fiecare dintre op iunile de filtrare, parametrii agentului, op iunile de subscribere, generarea instant (snapshot), i pentru set rile de praguri i de avertizare.

Utilizarea instrumentelor de modelare de date pentru a proiecta baza de date: modelul de date fizice (PDM) ar trebui sa fie cel pu in pn la a treia forma normala. n proiectarea publica iei, ad ugam doar articolele care sunt necesare. Dac ad ugam articole care nu sunt necesare serverelor subscribere, Agentul Instant va necesita mai multe resurse dect este necesar de fiecare data cand ruleaza. n consecin , trebuie sa fim prudenti cand adaugam indicii la Server-ul Subscriber deoarece crearea de indici, in afara de de pe coloana principala poate afecta opera iunile LMD

Reducerea disputelor: Deoarece latenta este in conflict cu replicarea instant, trebuie sa luam n considerare ce trebuie f cute pentru a-l reduce. Acest lucru este deosebit att pentru activit ile utilizator-ului cat si pentru agentul de replicare. Activand op iunea READ_COMMITTED_SNAPSHOT pentru publicare i pentru bazele de date se poate reduce acest lucru.
Luarea n considerare a utilizareii anonime sau a subscrierilor trage : agentul de distributie sta pe server-ul Subscriber, si nu pe server-ul Distribuitor, astfel utilizand subscriberele anonime sau pe cele trage- va reduce volumul de munc pe server-ul Distribuitor. Programarea cu atentie a server-ului Instant : Generam server-ul instant n afara orelor de vrf i nu n timpul ore de vrf de afaceri,mai ales daca avem o re ea lenta . Planul locatiei datelor : Luam n considerare salvarea datelor i a fi ierelor datelor de distributie pe o unitate separat de undeAgentul Instant (Snapshot) este generat pentru a reduce conflictul dintre discuri Alocarea permisiunilor : Trebuie sa ne asiguram ca permisiunea este data de catre folderol Instant catre Server-ului Distribuitor. Utilizarea unui folder instantant: Generarea Instant se face doa la un folder, nu simultan deoarece aceasta necesit ca Agentul Instant s scrie n primul rnd pe dosarul implicit i apoi la folderul alternativ. n schimb, am putea salva instantaneu pe anumite medii de stocare i apoi s-l transferam la server-ul de abonare. Luarea in considerare a Compresarii Instant : Compresarea instant va face transferul de fi iere n ntreaga re ea u or i mai rapid. Trebuie retinut faptul ca mai mult are de lucru Agentul Instant pentru a genera comprimarea instant , i de c tre Agentul de Distributie pentru a

procesafisierele, iar acest lucru ar putea avea un impact negativ asupra executarii. Folosirea unui Sistem Monitor: Sistemul monitor poate urmari datele pentru opera iuni de server de la nivel na ional.Au contoare separate pentru fiecare dintre opera iunile care sunt monitorizate. De exemplu, au contoare separate pentru usi, Agenti Instant, precum i pentru agen ii de distribu ie. Utilizarea server-ului Profil SQL( SQL Server Profiler) : poate crea un ablon pentru a monitoriza urme pentru replicare instant, si salveaza urma intr-un fisier sau un tabel intr-o baza de date separat. Pragurile stabilite: Utilizeaza Replicarea Monitor pentru a seta un prag care sa avertizeze cand subscrierile expira.

Jurnalul de Tranzactie
Jurnalul de tranzac ie nu este doar o component esen ial a structurii bazei de date, dar, de asemenea si a replicarii tranzactionale. Intr rile de date sunt scrise n Jurnalul de tranzactie, apoi Agentul de Citire a Jurnalului ( LogReader Agent) cite te tranzac iile marcate pentru replicare de la jurnalul de tranzac ii i le trimite la baza de date de distribu ie, care apoi le trimite la serverele de abonare. Modul in care sunt stabiliti parametrii profilului i listele de angajamente ale agen ilor, pot afecta executarile. De exemplu, dac Agentul de Citire a Jurnalului execut n mod continuu, nu este oprit i repornit, nefunc ionarea lui poate fi evitat . Cu toate acestea, acest lucru poate fi compensat daca timpul Agentului citind tranzactiile este mare n timpul perioadelo rcand se executa tranzactia n baza de date de publicare. Cu toate acestea, nainte de a discuta n continuare acele aspecte ale agen ilor, care pot fi ajustate pentru a mbun t i executia, s ne uit m la ceea ce putem face cu jurnalul pentru a optimiza n mod semnificativ procesul. Un jurnal de tranzac ie este facut din fisierul jurnalul - logic i fi ierul jurnal - fizic. jurnalul - logic este cel ce tine eviden a num rului de ordine( log

sequence number) (LSN); tranzac iile ncheiate n jurnal sunt identificate prin LSN. De fapt, att
procesul de restaurare i transmiterea de mesaje replicat din baza de date de publicare la baza de date Subscriber se bazeaz pe LSN. Orice nregistrare n registrul- tranzac ie este identificat prin LSN, ceea ce reprezinta un num r unic. nregistr rile din jurnal sunt stocate secven ial - fiecare nregistrare se adaug la jurnalului de tranzac ie. Fiecare dintre nregistr rile jurnal n jurnalul de tranzac ii sunt identificate prin ID, i nregistr rile jurnal con in ID-urile pentru tranzac ii. Ele sunt aranjate astfel incat numerele de reu ita sunt mai mari dect cele anterioare, iar acestea sunt legate ntr-un lan care pentru a mbun t i viteza de recuperare.

Figura de la 825

Cele mai bune practici pentru replicare tranzactionala (pg. 881)

Pastrarea scipt-urilor: Odat ce o publica ie i subscriere sunt configurate pentru replicarea tranzac ionala , stocam script-ul pentru o utilizare ulterioar . Asigurarea duplicarilor regulare : Duplicarea publicatiei (back-up process), subscrierii, msdb, distributiei bazei de date i imediat dupa ce am ad ugat o publica ie nou , sau am facut modific ri ale schemei publicatiei. Trebuie s duplicam bazele de date msdb pe Publicare (Publisher), Distribuitor, i serverele Subscribere, separat. Luarea in considerare a modului de automat de crestere (autogrowth) : Daca sunt situatii in care Agentul Jurnalului de Citire execut sau distribu ia bazelor de date este temporar cazuta , tranzac iajurnal va continua sa creasca pana cand tranzactiile au fost livrate. In astfel de situatii, cel mai bine este sa sa logam fisierul la modul crestere automata. Validarea subscrierilor : Dupa duplicarea i restaurare bazelor de date utilizate n replicarea tranzactionala, ar trebui s validam subscriberele utiliznd fie SSMS sau script-ul subscriber de validare. Verificarea cheilor primare: Pentru tabelele utilizate ca publica ii n replicarea tranzactionala, vtrebuie sa verificam ca ele au chei- primare. Crearea unei baze executabile: dezvoltarea unei asemenea baze pentru duplicarea replicarii tranzac ionale pe partea de server pentru fiecare dintre server i pentru resursele hardware cum ar fi procesoare, memorie, precum i configura ia Distribuitor. Trebuie s dezvoltam, de asemenea, o baz de duplicare pe partea de client pentru fiecare dintre op iunile de filtrare, parametrii agentului , op iunile de subscriere.

Utilizarea instrumentelor de modelare de date pentru a proiecta baza de date: Precum replicarea instant modelul de date fizice (PDM) ar trebui sa fie cel pu in pn la a treia forma normala. n proiectarea publica iei, ad ugam doar articolele care sunt necesare. Dac ad ugam articole care nu sunt necesare serverelor subscribere, Agentul Instant va necesita mai multe resurse dect este necesar de fiecare data cand ruleaza
Folosirea unui Sistem Monitor: Sistemul monitor poate urmari datele pentru opera iuni de server de la nivel na ional.Au contoare separate pentru fiecare dintre opera iunile care sunt monitorizate. De exemplu, au contoare separate pentru usi, Agenti Instant, precum i pentru agen ii de distribu ie. Salvarea scripturilor pentru profiluri: Trebuie pastrat un script pentru profiluri pentru fiecare dintre agen ii utilizati n replicarea tranzactionala. Folosi i jetoane de marcare: Deoarece latenta este o problem n replicare tranzactionala, monitorizam latent folosind jetoanele trasor n Replicarea Monitor. Planul de modific ri de volum mare: Dac avem de gnd s utilizam un volum mare de insertii sau actualiz ri (opera iuni lot), scriem o procedur stocat care va efectua aceste opera iuni. Procedura

de stocat va fi executata o dat pentru a livra insertii sau actualiz ri. n caz contrar, un sistem de generat va fi executat pentru fiecare opera iune de actualizare, care va avea un impact asupra duplicarii.

Cele mai bune practici pentru Replicarea Fuzionala

Pastrarea script-ului de configurare : Din moment ce publicarea i subscrierile sunt configurate pentru replicarea instant folosind GUI, generam un script i p stram pentru o utilizare ulterioar Crearea de duplicari regulare: Duplicarea publicatiei (back-up process), subscrierii, msdb, distributiei bazei de date i imediat dupa ce am ad ugat o publica ie nou , sau am facut modific ri ale schemei publicatiei. Trebuie s duplicam bazele de date msdb pe Publicare (Publisher), Distribuitor, i serverele Subscribere, separat. Optimizarea timpului de retentie a publicarii : Ori de cte ori este posibil, trebuie sa reglam timpul retentiei pentru continuarea afacerii . Setarea nivelului de compatibilitate: Setam compatibilitatea nivelului de publicare a serverului SQL astfel nct noile caracteristici ale replicarii fuzionale sunt activate. Salvarea scripturilor pentru profiluri: Trebuie pastrat un script pentru profiluri pentru fiecare dintre agen ii utilizati n replicarea tranzactionala. Folosirea unui Sistem Monitor: Sistemul monitor poate urmari datele pentru opera iuni de server de la nivel na ional.Au contoare separate pentru fiecare dintre opera iunile care sunt monitorizate. De exemplu, au contoare separate pentru usi, Agenti Instant, precum i pentru agen ii de distribu ie. Salvarea seiunilorde testare tuning : salvam sesiunea de tuning pentru volume de lucru care ndeplinesc cerin ele deexecutare , i apoi transmitcerintele altui sever. Revizuirea rapoartelor tuning: Utilizam tab-ul Raport n motorul bazei de date Tuning pentru a revizui diversele utilizari ale raporturilor , cum ar fi raportul de utilizare Index. Ajustarea parametrilor agentilor: Dup parametrii Agentului de fuziune . ce configurarea s-a terminat trebuie schimbati

Contoarul Monitorului de executare: Monitorizam contoarele pentru agentul de fuziune prin utilizarea Sistemuui Monitor.Putem monitoriza Merge: Conflicte / sec, Merge: descarcate Modific ri / Modific ri sec i mbinare: nc rcat / contoare sec. Urmarirea cu Sistemul de Monitorizare (Trace with System Monitor) : Ca i n replicarea instant,se utilizeaza Sistemul de monitorizare a datelor pentru opera iuni la nivel de server si au contoare separate