MrSmersh:

OK cred ca e bine sa mai zic o data scenariul cum stiu ca e acum.
Exista un numar de vreo 10 SQL Server Express ale caror date se vrea sa ajunga pe un SQL Central. Baza de date ca backup full este de vreo 1 GB. Din baza de date locala doar vreo 50 de tabele contin informatii interesante pentru centru, restul setari ale userilor si din astea. Datele modificate (si interesante) sint cam 2% volumul bazei de date. Acuma ei pur si simplu plimba backupul (totdeauna full, da stiu ca nicicum nu e optim). Mai lucreaza din cind in cind la structura tabelelor. Conexiunea la net nu este permanenta si vrea sa se faca cit mai putin.

Daca acuma plimba back-up-ul inseamna ca la centru trebuie cumva sa se execute o consolidare a datelor, pentru ca au 10 baze de date. Exsita un process (SSIS?) care consolideaza datele? Sau se ruleaza rapoarte customizate ca sa consolideze datele (ie. se ruleaza 10 queryuri identice in 10 baze de date in fiecare raport)? Apropos, folosirea unui backup full este recomandata in asemena caz, pentru ca altfel fiecare backup devine dependent de cel anterior (ie. chiar daca am back-up-ul de azi, nu-l pot instala pentru ca cel de ieri este ratacit pe drum).

Deasemenea inseamna ca nu exista nici un fele de trafic de date de la centru spre periferie.

• Cele 50 de tabele cit de des sint datele adaugate/sterse/schimbate?
• Exista un algoritm de pastrare a unicitatzii cheilor primare intre punctele de lucru? (range-uri rezervate, compunerea cheii prin adaugarea unui ID pentru fiecare punct de lucru etc etc)
• Ai access/control asupra aplicatziei sau doar la datele rezultate?
• Aplicatiza manipuleaza datele direct sau apeleaza proceduri pentru a executa DML?
  
• Exista un mod de a descoperi ce date sau schimbat in tabele (e.g. un timestamp, un LSN, o tabela care pastreaza log al schimbarilor?)
• cum se rezolva conflictele intre puncte de lucru si centru? Intzeleg ca cuma nu pot exista pentru ca intreaga baza de date este mutata fizic, dar cum se planifica rezolvarea lor in viitor, cind este garantat ca vor apare.
  

Recomandarea SSB vs. replication depinde mult de raspunsurile la intrebarile astea.

• daca aplicatia nu este controlata de tine si face operatzii DML direct (UPDATE/INSERT/DELETE) atunci singurul mod de a intercepta aceste schimbari este folosind un trigger. Replication poate folosi transactional replication si citi LDF-ul.
• daca controlezi aplicatza potzi inlocui codul care face INSERT cu un SEND catre centru, si potzi controla exact ce se trimite la centru (ce date/coloane, format etc.)

Controlul conexinii la net nu este factor de diferentiere intre SSB si replication. Pentru ca in Express nu ai SQL Agent, va trebuii sa controlezi tu cind ruleaza agentzii de replicare. Cu SSB potzi controla cind se pot trimite/receptziona datele (ALTER ENDPOINT ... STATE = STARTED/STOPPED). ambele solutzii implica un timer care sa activeze/dezactiveze (eg. AT.EXE, sau BEGIN CONVERSATION TIMER pentru SSB)

Apropos toate schemele care le-am vazut in care 'conexiunea nu este permanenta si vrea sa se faca cit mai putzin' au rezultat in catastrofe operatzionale: cind se conecteaza punctele de lucru nu e centrul online, daca e online se conecteaza toate punctele deodata si centrul nu faca fatza la trafic, dependentza de script-uri care conecteaza statzile la net si care nu sint robuste, daca se pierde o fereastra de conexiune (eg. azi intre 6am si 8am) trebuie sa se intervina manual pentru a fortza sincronizarea etc etc. Daca mai exista si un pas manual in protocol, in mod sigur va veni o zi cind operatorul uman va face o eroare. Ce latency intre punctele de lucru si centru este ideal/dorit/tolerat? Poate centrul sa fie online permanent?

Stiu ca ma pus mai multe intrebari decit am data raspunsuri, dar sper ca aceste intrebari sa te ajute sa alegi solutzia cea mai convenabila.