O intrebare mai mult teoretica deoarece sunt convins ca nu exista o solutie care sa acopere tot ... pana la urma tot trebuie sa se faca un compromis.

Pentru o aplicatie (economica - 5% write - 95% read) distribuita, care este cea mai buna solutie pentru sincronizare de informatii. Comunicarea cu baza poate sa fie orice ... incepand cu ODBC ...

cerinta este:
toata lumea sa vada informatiile (de la toata lumea) - adica sa se replice tot - nu numai anumite tabele sau parti din ele.

sa nu fie restrictii de viteza

sa fie actualizare in timp real (stocuri si alte prostii).

sa se poata folosi aplicatia in mare masura a timpului.

nu conteaza ce versiune de MSSQL folosim.

V1: 1 server SQL - pe care il folosesc toti (prin intranet, internet sau ce se mai gaseste)
- avantaj: datele sunt tot timpul reale.
- dezavantaj: pentru operatii cu cantitati mari de date avem bottleneck. Daca "pica" legatura la "slave" - nu poate folosi aplicatia.

V2: mai multe servere SQL care se replica intre ele.
- avantaj: viteza mare
- dezavantaj: replicarea (ma refer numai la merge) este dificila pentru rata mare de modificare ale aceleasi informatii.

V3: mai multe servere - si trigger CRUD pe tabele care sa aplice modificarie pe toate
- avantaj: viteza ok, date in real time.
- dezavantaj: daca "pica" legaturile - toata lumea sta.

V4: mai multe servere - trigger CRUD care logheaza modificarile - si pe care le aplica pe restul serverelor (asincron daca e nevoie).
- avantaj: viteza ok, date real time (cat e sus conexiunea).
- dezavantaj: complicat dpdv al codului si al stocarii modificarilor. Pot sa apara neconcordante in momentul in care se foloseste aceeasi resursa.

Altele ? ...

---

www.fagadar.ro

Citeva intrebari:
Citi utilizatori acceseaza aplicatia ?Citi sunt in internet si citi in intranet ?Dintre cei in internet, citi dintre ei au nevoie de date "real time" si nu de niste tabele cu situatia pe ziua precedenta ? Dintre cei in internet, citi fac write ? Citi au nevoie sa faca write "real time" ? Citi pot utiliza PDA ?

Ca raspuns posibil, fara sa stiu raspunsul :
Pentru 5% write eu nu m-as obosi cu replicare. E bine ca lumea vrea sa faca avioane - dar s-ar putea sa ai nevoie de un tractor ...

As face BD astfel incit sa tina seama de MergeReplication(sunt niste coloane in plus pe care le pune MS), dar as face aplicatia sa mearga cu o singura BD. Apoi, in functie de cerintele pentru vers. 2, as sti ce sa fac...

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

chestia e ca problemele particulare au solutii particulare. Eu caut o generalizare care sa imi rezolve cat de cat treaba ca sa nu fie nevoie sa implementez specific pentru fiecare in parte.
Exemple de utilizare:
2 locatii (20 + 10) utilizatori
2 locatii (20+20) utilizatori
6 locatii (10 + 2 + 2 + 2+ 2 + 2) utilizatori.


PDA-ul nu ma incurca pe moment deoarece se incarca.descarca tot prin aplicatie si nu independent. Si chiar daca ar fi el este mai mult pe Write.

Intradevar toti vor avion ... si pana acum le-am dat altceva. Merge Replication e ok, dar ce ma fac cu conflictele (cazurile in care se schimba datele de pe aceeasi linie - ex: actualizari de solduri, stocuri).

---

www.fagadar.ro

fgbogdan:

cerinta este: toata lumea sa vada informatiile (de la toata lumea) - adica sa se replice tot - nu numai anumite tabele sau parti din ele

In cazul acesta (daca excludem V1 care este cea mai simpla solutie dpdv al dezvoltarii sistemului informatic, probleme pot apare daca iti pica serverul sau o conexiune de la un punct de lucru catre centrala) o posibila solutie ar fi sa apelezi la o topologie peer to peer cu replicare tranzactionala cu un nod (server,bd) pentru fiecare punct de lucru. La fiecare punct de lucru se pot realiza R/W independent de celelante noduri iar datele pot fi replicate catre celelante noduri. Daca iti pica un nod celelante isi pot schimba/replica datele fara probleme ... coafura rezistă. Cand nodul revine online isi poate schimba/replica datele din nou cu celelante noduri. In cazul tau, asta ar insemna 10 noduri, fiecare nod fiind nevoit sa gestioneze 9 publicatii (cate una pentru fiecare din celelante noduri). Se spune ca replicarea sta prost la capitolul scalabilitate. In cazul tau mentinerea a 9 publicatii pe server nu cred ca va prezenta probleme dpdv al volumul datelor din publicatii pt. ca volumul lor va fi relativ mic din moment ce iti propui ca frecventa replicarii sa fie mare ( => pseudo timp real). Diminuarea performantelor ar putea apare la W datelor in bd din fiecare nod (teoretic).

Nu am folosit o astfel de arhitectura pana in prezent, asa ca acest mesaj nu este decat teorie. Nici nu vreau sa intelegi eronat ca acest mesaj este un sfat. Este doar o prezentare a unei arhitecturii pe care nu ai enumerat-o in primul mesaj.

fgbogdan:

chestia e ca problemele particulare au solutii particulare. Eu caut o generalizare care sa imi rezolve cat de cat treaba ca sa nu fie nevoie sa implementez specific pentru fiecare in parte. Exemple de utilizare: 2 locatii (20 + 10) utilizatori 2 locatii (20+20) utilizatori 6 locatii (10 + 2 + 2 + 2+ 2 + 2) utilizatori
.

Cum sunt conectate locatiile astea?

fgbogdan:

Merge Replication e ok, dar ce ma fac cu conflictele (cazurile in care se schimba datele de pe aceeasi linie - ex: actualizari de solduri, stocuri)
.

Ce pot sa zic ... decit ca trebuie sa le explici problemele - de ce se intimpla - si apoi sa le explici solutiile posibile( rezolvate automat -o locatie cistiga, rezolvate cu mina omului - optiuni...)

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

fgbogdan:

dar ce ma fac cu conflictele (cazurile in care se schimba datele de pe aceeasi linie - ex: actualizari de solduri, stocuri).

De multe ori solutia este "by design". Proiectezi bd aî stocurile sa fie gestionate la nivel de punct de lucru iar punctul de lucru A nu trebuie sa poate scădea produse din gestiunea punctului de lucru B,C,D ... . Daca vrei cantitatea totala in stoc atunci SELECT SUM(CantStoc) FROM Stoc ... GROUP IDPunctLucru, IDProdus, ... .Alta solutie este sa nu folosesti o tabela derivata Stoc, ci o tabela virtuala (view) care sa-ti calculeze stocurile pornind de la intrari si de la iesiri.

Chiar şi atunci când foloseşti câte o singură înregistrare pentru fiecare produs, daca doreşti sa sincronizezi inregstrarea 21(ID) 212(CantStoc) 23.32(PretUnitar) de la A cu 21(ID) 76(CantStoc) 21.01(PretUnitar) de la B poti aduna stocurile obtinand 21(ID) 288(CantStoc) ... insa preturile te obliga sa recurgi la o solutie anterioara.

"Cum sunt conectate locatiile astea?"

In momentul de fata sunt cu VPN iar serverul de baze de date este acolo unde ponderea de folosire este mai mare.

"Stocuri"

Problema delimitarii cine cu ce informatii lucreaza este rezolvabila - impartirea din punct de vedere al stocurilor este similara cu impartirea locatiilor - informatiile comune insa ma impiedica - transferuri de la unii la altii de exemplu.
Sincer acum vreo 4 ani cand am incercat partea de replicare de la SQL 2000 m-am dezumflat deoarece nu se potrivea cu logica aplicatiei (nu am prea mult Busines Logic in baza de date) ... si m-am resemnat - dar acum necesitatea revine - si suntem dispusi sa schimbam si in aplicatie.
Cunosc aplicatii economice care "merg" pe replicare la nivel de prezentare, dar nu am ajuns sa discut cu cineva concret despre problema.

Ce ma gandesc eu in momentul de fata este o solutie in care serverele de date sunt in "Cerc" (S1->S2->S3->...->Sn->S1). Fiecare avand rutina de a "face in oglinda" ceea ce se intampla pe el (ceva cu triggere after Create,Update,Delete) dar cu posibilitatea de la "Loga" aceste comenzi in cazul in care "Destinatia" este offline si de a le aplica la revenire. Pe partea de online am inceput ceva ... mai am probleme la campurile Text si fratii lui, iar la off ... avem o implementare mai veche ... unde nu exista conexiune intre 2 locatii si se trimitea cu CD-ul fisierul SQL de comenzi (foarte primitiv - dar eficient la acel moment).

---

www.fagadar.ro

In concluzie, pentru replicare datelor de la S3 la S2, datele vor trebui sa fie replicate S3 -> S4 -> ... -> Sn -> S1 -> S2 -> S3 ?

Deci tu vrei o aplicatie foolproof in conditiile in care poti avea legatura internet bushita ?

De ex., sa zicem ca in stoc ai doar 1 CD de vinzare si locatiile L1 si L2 care stiu ca exista 1 singur CD. Legatura internet pica, L1 vinde CD-ul, L2 vinde CD-ul ... Nu poti face  nimic sa impiedici asta... cel mult sa faci un "backup stoc" si sa interzici vinzarea sub "backup stoc" daca legatura pica...

Asa incit parerea mea este ca un merge replication este OK...sau sa definesti mai clar ce se intimpla in cazul de online/offline si businessul sa faca "agree"

O situatie asemanatoare la care ma duce gindul este "backup plan" . Poti sa faci backup-ul astfel incit locatia "backup plan" sa fie pe luna, in centrul NASA, sau sa fie un usb pe care sa il iei acasa .... Asa si aplicatia ta...e in functie de ceea ce se considera necesar ... ca poti sa inchiriezi un modem de la Vodafone/Orange/Romtelecom/Zapp/etc sa functioneze ca solutie de backup pentru internet ...

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

"In concluzie, pentru replicare datelor de la S3 la S2, datele vor trebui sa fie replicate S3 -> S4 -> ... -> Sn -> S1 -> S2 -> S3 ?"

Da, din punct de vedere al costurilor de trafic nu e cea mai buna varianta.

Si pana la "foolProof" cred ca mai e mult ... de la genul de utilizatori te astepti la cele mai curioase probleme.

"1 CD - de 2 ori" - se intampla ... si nu pot sa opresc asta decat prin oprirea aplicatiei (ex Scala) Pe de alta parte si utilizatorii trebuie sa fie constienti de deciziile pe care le iau.

Pana la urma asta cu opritul cred ca e cea mai simpla varianta.

Eu o sa incerc si o sa va dau rezultatele cand reusesc.

---

www.fagadar.ro

fgbogdan:

Eu o sa incerc si o sa va dau rezultatele cand reusesc.

Tine-ne la curent...chiar sunt curios...

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

ok ... am pentru varianta online solutia cu triggere ... din pacate nu pot sa fac upload la fisiere (poate puneti o vorba buna la admin).
Restrictiile "pe moment" sunt:
- definitie de tabela sa fie mai mica de 8000 (suma dimensiuni campuri)
-daca tabela are key ... sa fie pe prima coloana
- coloanele autoincrement sa se stie (ca sa le elimin din lista de replicare)
- nu se folosesc campuri text, ntext image

Am realizat un "template" de trigger pe care apoi l-am "aplicat" pe toate tabelele din bazele de pe 2 servere cu ajutorul unei aplicatii care citeste structura tabelelor si seteaza variabilele din template.

Pun un exemplu pentru o tabela banci.

CREATE TRIGGER [REPLBANCI] ON [dbo].[BANCI]
FOR INSERT, UPDATE, DELETE
AS

DECLARE @strAction AS VARCHAR(10)
DECLARE @STRTABLENAME AS VARCHAR (100)
DECLARE @STRCMD AS NVARCHAR (1000), @STRCMD1 AS NVARCHAR (1000)
DECLARE @Column_Name AS VARCHAR (50), @Type_Name AS VARCHAR (50)
DECLARE @DeletedRows AS INT
DECLARE @InsertedRows AS INT
DECLARE @nIndex AS INT

SELECT * INTO #inserted FROM inserted
SET @InsertedRows = @@rowcount


SELECT * INTO #deleted FROM deleted
SET @DeletedRows = @@rowcount

IF @InsertedRows > 0
BEGIN
IF @DeletedRows > 0
SET @strAction = 'UPDATE'
ELSE
SET @strAction = 'INSERT'
END
ELSE
BEGIN
SET @strAction = 'DELETE'
END

-- DELETE
IF 'DELETE' = @strAction
BEGIN
SET @STRCMD = ' delete from [SRVDB2\SQL4].bcMainM2008.dbo.BANCI where BANCAID in (select BANCAID from #deleted)'
-- disable trigger
SET @strCMD1 = 'ALTER TABLE BANCI DISABLE TRIGGER REPLBANCI'
EXECUTE [SRVDB2\SQL4].bcMainM2008.DBO.SP_EXECUTESQL @strCMD1
--
EXECUTE(@STRCMD)
-- enable trigger
SET @strCMD1 = 'ALTER TABLE BANCI ENABLE TRIGGER REPLBANCI'
EXECUTE [SRVDB2\SQL4].bcMainM2008.DBO.SP_EXECUTESQL @strCMD1
END

-- INSERT
IF 'INSERT' = @strAction
BEGIN
SET @STRCMD = ' INSERT INTO [SRVDB2\SQL4].bcMainM2008.dbo.BANCI select BANCAID,NUME,CODBANCA,CODSWIFT,LOCALITID,LOCALIT,JUDETID,TARAID,TIPBANCA,ISANULAT,ISTEMPORAR,NTIPEXPORT,ADRESA from #inserted '
-- disable trigger
SET @strCMD1 = 'ALTER TABLE BANCI DISABLE TRIGGER REPLBANCI'
EXECUTE [SRVDB2\SQL4].bcMainM2008.DBO.SP_EXECUTESQL @strCMD1
--
EXECUTE(@STRCMD)
-- enable trigger
SET @strCMD1 = 'ALTER TABLE BANCI ENABLE TRIGGER REPLBANCI'
EXECUTE [SRVDB2\SQL4].bcMainM2008.DBO.SP_EXECUTESQL @strCMD1
END

-- UPDATE
IF 'UPDATE' = @strAction
BEGIN

DECLARE @ColumnID int, @Columns nvarchar(4000), @ObjectID int, @LastColumnID int

SET @ObjectID=(SELECT id FROM sysobjects WHERE name='BANCI')
SET @LastColumnID=(SELECT MAX(colid) FROM syscolumns WHERE id=@ObjectID)
SET @ColumnID=1
WHILE @ColumnID
IF (SUBSTRING(COLUMNS_UPDATED(),(@ColumnID - 1) / 8 + 1, 1)) &
POWER(2, (@ColumnID - 1) % 8) = POWER(2, (@ColumnID - 1) % 8)
SET @Columns = ISNULL(@Columns+',','') + COL_NAME(@ObjectID,@ColumnID) + ' = #inserted.' + COL_NAME(@ObjectID,@ColumnID) + ' '
SET @ColumnID=@ColumnID+1
END

-- disable trigger
SET @strCMD1 = 'ALTER TABLE BANCI DISABLE TRIGGER REPLBANCI'
EXECUTE [SRVDB2\SQL4].bcMainM2008.DBO.SP_EXECUTESQL @strCMD1

-- trebuie sa inlocuiesc IN tabela tinta ... coloana @Column_Name
SET @STRCMD = 'UPDATE [SRVDB2\SQL4].bcMainM2008.dbo.BANCI SET ' + @Columns + ' FROM [SRVDB2\SQL4].bcMainM2008.dbo.BANCI C, #inserted WHERE C.BANCAID = #inserted.BANCAID'
EXECUTE(@STRCMD)

-- enable trigger
SET @strCMD1 = 'ALTER TABLE BANCI ENABLE TRIGGER REPLBANCI'
EXECUTE [SRVDB2\SQL4].bcMainM2008.DBO.SP_EXECUTESQL @strCMD1


END
DROP TABLE #inserted
DROP TABLE #DELETED

---

www.fagadar.ro

Dezactivarea trigger-ului din cealalta baza de date poate cauza probleme daca se adauga simultan doua inregistrari (diferite) in doua server-e. E posibil ca inregistrarea adaugata in al doilea server sa nu mai declanseze trigger-ul (fiind dezactivat) si astfel sa nu se mai copieze pe celelalte server-e. In mod normal, in loc de dezactivarea trigger-ului, as scrie ceva cod in trigger (folosind TRIGGER_NESTLEVEL, CONTEXT_INFO() sau @@SPID) sa faca RETURN daca e apelat dintr-un alt trigger de acest gen. Din pacate, daca e vorba de alt server, cred ca aceste solutii nu prea sunt aplicabile si as face RETURN-ul in functie de HOST_NAME() si/sau SUSER_SNAME() (eventual, facand un login dedicat doar pentru linked server-urile folosite pentru "replicare").

O alta problema ar fi ca datele din coloanele identity ar trebui copiate (folosind SET IDENTITY_INSERT ON), nu trebuie generat un nou ID, deoarece ar fi probabil diferit, iar la stergere te bazezi pe faptul ca are aceeasi valoare. Pe de alta parte, poti sa afli daca tabela are o coloana identity (folosind functia OBJECTPROPERTY cu parametrul 'TableHasIdentity') si poti sa afli care este coloana identity (folosind functia COLUMNPROPERTY cu parametrul 'IsIdentity').

In afara de limitarile pe care le-ai mentionat, ar mai fi si faptul ca valoarea din coloana primary key nu trebuie sa se modifice niciodata. E adevarat ca in 99% din cazuri, oricum nu se poate modifica, pentru ca e identity (si chiar si daca n-ar fi, probabil exista foreign key-uri care nu au cascade update). Dar asa, ca idee, ar fi interesant sa analizezi ce ar face trigger-ul daca ID-ul nu este identity si ai 3 inregistrari in tabela BANCI (cu ID-urile 1, 2 si 3) si faci un "UPDATE BANCI SET ID=ID+1, DENUMIRE=DENUMIRE+DENUMIRE".

O ultima observatie ar fi la linia "WHILE @ColumnID", care probabil ar trebui sa fie "WHILE @ColumnID<=@LastColumnID". Este interesant de stiut ca valorile din colid pot sa nu fie consecutive (daca a fost stearsa o coloana din tabela), dar cred ca e OK codul din acest punct de vedere.

Razvan

O alta metoda de sincronizare neamintita aici este data de tehnologia service broker din SQL:

1.Cu ea poti face sincronizare prin mesaje asincrone;spuneti ca trebuie replicate toate informatiile, insa in mod real tabelele nomenclatoare se misca mai rar si mai mult datele care se modifica in tranzactii, deci ar fi sanse sa nu fie traficul foarte mare si sa duca la gatuiri;

2.Daca folosirea service broker ca mijloc de replicare este greoaie o puteti macar folosi in triggerii de care vorbiti aici: sa spunem ca un trigger este fired de 1000 de ori (adica de 1000 de ori sa zicem ca se face un insert pe tabela care lanseaza un trigger ), punand mesajele de raspuns ale triggerului intr-o coada service broker acestea vor curge asincron catre serverele target neblocand aplicatia care gazduieste triggerul de fata.

3.Un motiv in plus sa apelati la aceasta tehnologie (ca vad ca sunteti la etapa de arhitectura si inca nu e decis nimic) este acela ca service broker vine gratuit la SQL Server Express 2005 care este la randul lui gratuit insa are limitarile stiute

Iata o discutie de a mea cu unul dintre taticii tehnologiei, Remus Rusanu despre service broker.

 

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

Cum tzi-a placut matematica in scoala?

fgbogdan:

 5% write - 95% read
adica sa se replice tot - nu numai anumite tabele sau parti din ele.

Problema cu replicatul tot este urmatoarea: read-urile sint locale, dar write-urile sint globale. Adica un write trebuie replicat intre toate nodurile.
Hai sa zicem ca ai 5 noduri. Sa luam 1000 de operatii, 50 sint write si 950 sint read. Indiferent care este tehnologia folosita, in conditii ideale (nici un retry)  ca sa replici cel 50 de write-uri trebuie sa adaugi 50 de read-uri (cit citesti write-urile ca sa le shipezi la celelate noduri) si 200 de write-uri (cele 50 de write-uri de la cele 4 noduri partenere). Deci deodata ai 1000 de readuri si 250 de writeuri, ceea ce inseamna 80% read si 20% write. In plus, tu suportzi 1250 de operatii din care doar 1000 sint locale. Hai sa zicem ca firma are un success nebun (cel mai periculos lucru care se poate intimpla aplicatiei tale!) si deschide 20 de filiale/depozite sau ce sint nodurile tale. Acuma cele 1000 de tranzactii locale sau transformat, dupa aceasi formula, in 2000 de tranzacti, 50% read 50% write si doar 50% si doar 50% din capacitatea locala serveste cererile locale, restul este folosit doar sa shipeze si sa primeasca replici. Si 20 de noduri nu sint deloc o cifra serioasa, daca iei pur si simplu judetele din Romania ajungi repede la cifre mai mari.

Si ia in considerare ca acestea sint cele mai optimiste calcule. In realitate nici odata nu o sa ai success 100% si vor exista retry-uri, care vor altera si mai rau aceste calcule. In plus o aplicatzie optimizata pentru 95% read evident ca va avea o schema si indexsi pentru 95% read, si va avea problem serioase cind de fapt se fac 50% read-50% write.

Facind aceste calcule simple potzi usor demonstra ca cerintele originale sint exagerate. Ma indoiesc ca este chiar nevoie sa se replice tot la totzi.

fgbogdan:

actualizare in timp real (stocuri si alte prostii)
sa se poata folosi aplicatia in mare masura a timpului

Orice design sincron trebuie sa ia in considerare ca practic daca un nod e picat intreaga aplicatie e picata. Hai sa zicem ca organizatia ta poate sa mentina un up-time de 98% (incluzind toate opririle pentru aplicare de patch-uri, toate problemele de hardware, si mai ales toate erorile de administrare/operare). Si sa consideram ca ISP-urile folosite au un uptime de 99.9% (putem cu totzii sa ne oprim din ris acuma). 5 noduri vor avea un uptime de (.98*.999)^^5 care inseamna 90% (ne putem juca cu formula, unii pot zice ca este (.98*.999)^^(5-1), altzii ca este .98^^5*.999, dar tot pe la aceleasi cifre ajungi). Adica 10% din timp aplicatia nu merge. 10 noduri e 80% uptime, iar 20 de noduri inseamna doar 65% uptime. Acuma sint convins ca orice beneficiar caruia ii prezintzi un timp de functionare de 65% in conditzii ideale are toate motivele sa te dea afara pe usa.

Deci din start potzi exclude orice solutzie sincrona care cere ca celelate noduri sa fie online pentru a putea face un write local.
In momentul care treci de la sincron la asincron, cam tot ce stii despre operatzii in baza de date sau despre CRUD devine obsolete. Trebuie sa gindesti intermeni de cozi, mesaje, latenta, update conflict si asa mai departe.

Astea ar fi citeva idei de start ca sa-tzi dai seama de fapt ce ai in fatza. Sa obtzii ce vrei tu este extrem de complicat, chiar si dupa ce ai relaxat bine de tot din cerintele care le-ai pus.

---

http://rusanu.com