Welcome to Sign in | Help
in Search

Sincronizare SQLServer Express

Last post 10-26-2009, 8:03 PM by BGeo. 60 replies.
Page 1 of 5 (61 items)   1 2 3 4 5 Next >
Sort Posts: Previous Next
  •  06-27-2007, 6:56 PM 2155

    Sincronizare SQLServer Express

    Sa repostez de unde vreau sa reincep cu intrebarile

    rremus:

    Bah, ar trebuii sa citesc de doua ori inainte sa postez... Am fost derutat de folosirea termenului 'sincronizare' in titlu, dar e vorba de o folosire creativa a unui termen consacrat ;)

     Modul ideal de trimitere de date dinspre/spre SQL Express este Service Broker. Creeaza un serviciu in SQL Express si unul in baza de date centrala, foloseste tool-ul de la www.codeplex.com/slm pentru configurare, si urmeaza pattern-ul descris in http://blogs.msdn.com/remusrusanu/archive/2007/04/24/reusing-conversations.aspx pentru a trimite mesajele. Mesajele in general sint create intr-un trigger si processate ca XML.

    Stiu ca in general e o chestia destul de noua si putzina lume are know-how in domeniu, asa ca mai bine pun un exemple. O sa creez doua tabele, a si b, si vreau ca orice operatie in a sa fie replicata in b (pentru simplificare o s a fact totul local in tempdb).

    use tempdb

    GO

    -- sender service, will be used by trigger to send FROM

    --

    create queue q

    create service s on queue q

    GO

    -- 'replicated' table

    --

    create table a (a int primary key);

    go

    -- 'replication' trigger. creates a datagram from the INSERTED and DELETED pseudotables

    -- uses a dumb one message per dialog

    -- see http://blogs.msdn.com/remusrusanu/archive/2007/04/24/reusing-conversations.aspx

    -- for a proper way of using dialogs

    --

    create trigger a_t

          on a for insert, update, delete

    as

    BEGIN

    DECLARE @payload XML, @h UNIQUEIDENTIFIER;

          WITH XMLNAMESPACES (DEFAULT 'htpp://tempuri.org/2007/05/04/sqlserver.ro/rremus')

          SELECT @payload = (SELECT    

                (SELECT * FROM DELETED FOR XML PATH('DELETED'), TYPE),

                (SELECT * FROM INSERTED FOR XML PATH('INSERTED'), TYPE)

                FOR XML PATH('DATAGRAM'), TYPE);

          BEGIN DIALOG CONVERSATION @h

                FROM SERVICE s

                TO SERVICE 't'

                WITH ENCRYPTION = OFF;

          SEND ON CONVERSATION @h (@payload);

    END  

    GO

    -- Test the trigger

    --

    insert into a values (1)

    go

    -- We sent but the target doesn't yet exists.

    -- message is pending in xmit queue

    --

    select cast(message_body as xml),* from sys.transmission_queue

    go

    -- create a target service

    --

    create queue qt

    create service t on queue [qt] ([DEFAULT]);

    go

    -- create a 'replica' table

    --

    create table b (a int);

    GO

    -- this procedures shreds the XML datagrams into

    -- deletes/inserts into the 'replica' table

    -- a proper SSB procedure needs to take care

    -- of properly ending the dialogs:

    -- see http://blogs.msdn.com/remusrusanu/archive/2007/05/02/recycling-conversations.aspx

    -- Also this procedure is highly inneficient,

    -- see http://blogs.msdn.com/remusrusanu/archive/2006/10/14/writing-service-broker-procedures.aspx

    --

    create procedure usp_t

    AS

    BEGIN

    DECLARE @h UNIQUEIDENTIFIER, @mt SYSNAME, @mb XML;

    SET NOCOUNT ON;

    BEGIN TRANSACTION;

          RECEIVE TOP(1)

                @h = conversation_handle,

                @mt = message_type_name,

                @mb = CAST(message_body as XML)

          FROM qt;

          IF @@ROWCOUNT>0

          BEGIN

                IF @mt = N'DEFAULT'

                BEGIN

                      WITH XMLNAMESPACES (DEFAULT 'htpp://tempuri.org/2007/05/04/sqlserver.ro/rremus')

                      DELETE FROM b

                      WHERE b.a IN (

                            SELECT t.n.value('a[1]',      'int') as a

                                  FROM @mb.nodes('//DATAGRAM/DELETED') T(n));

                      WITH XMLNAMESPACES (DEFAULT 'htpp://tempuri.org/2007/05/04/sqlserver.ro/rremus')

                      INSERT INTO b (a)

                            SELECT t.n.value('a[1]',      'int') as a

                                  FROM @mb.nodes('//DATAGRAM/INSERTED') T(n);

                END

          END

    COMMIT

    END

    go

    -- Associate the procedure with the queue

    --

    alter queue qt

          with activation (

                status = on,

                max_queue_readers = 1,

                procedure_name = [usp_t],

                execute as owner);

    go

    Odata ce functioneaza scenariul local, potzi muta serviciul target pe serverul central, configura securitate si transport (cu www.codeplex.com/slm). Evident, procesarea de XMl trebuie sa corespunda cu schema tabelelor tale.

    Acest pattern este foarte des folosit de customeri pentru real-time ETL (Extraction-Transfomation-Load) ca sa incarce datele din OLTP in DW pentru analiza si reporting. In general se interpune si un pas de SSIS pentru transformare, dar in cazul tau ai intrebat cum sa trimitzi efectiv replicare de date, fara transformare.

  •  06-27-2007, 7:00 PM 2156 in reply to 2155

    Re: Sincronizare SQLServer Express

    Am spart asta intre 2 baze de date...

    use db2 l-am pus inainte de asta (da db 2 creat etc)

    create queue qt

    create service t on queue [qt] ([DEFAULT]);

     

    Mi-am prins urechile la configurarilecu Service Listing Manager. Care ar fi pasii corecti? De mers merge daca totul e intr-o singura baza de date, si Service Listing Manager acolo mi-a iesit...

    Multumesc

     

  •  06-27-2007, 8:21 PM 2157 in reply to 2156

    Re: Sincronizare SQLServer Express

    Cind treci de la o singura baza de date la doua baze de date, in general singurul pas necesar este ALTER DATABASE [<initiatordb>] SET TRUSTWORTHY ON;. Detaliile despre de ce acest pas este necesar sint explicate aici: http://msdn2.microsoft.com/en-us/library/ms188304.aspx

    Daca vrei sa faci totul 'de mina', cea mai simpla configurare este urmatoarea. Sa consideram doua instanze de SQL Server: host1 (initiator sau client) si host2 (target sau server)

    1. creaza mesajele si contractul dorit  (CREATE MESSAGE TYPE/CREATE CONTRACT) in baza de date din host2
    2. creeaza queue si service in baza de date din host2. Service trebuie sa fie 'bound' la contractul folosit
    3. GRANT SEND ON SERVICE::[<targetservicename>] TO [public]; in host2
    4. creeaza mesajele si contractul in host1 (definitia trebuie sa fie identica ca in host2)
    5. creeaza queue si service in host1. Nu este necesar 'bound' la contract
    6. in host2.master creeaza un database master key
    7. in host2.master creeaza un certificat (CREATE CERTIFICATE [host2_cert] WITH SUBJECT = 'host2_cert')
    8. creeaza un endpoint pentru service broker in host2 folosind authenticare pe baza de certificate: CREATE ENDPOINT [broker] STATE=STARTED AS TCP (LISTENER_PORT=4022) FOR SERVICE_BROKER (AUTHENTICATION = CERTIFICATE [host2_cert])
    9. GRANT CONNECT ON ENDPOINT::[BROKER] TO [public]
    10. repeta pasii 6-9 pe host1
    11. creeaza un route pe host1 (in baza de date unde este service-ul) pentru service-ul de pe host2: CREATE ROUTE [routeToTarget] WITH SERVICE_NAME = '<target_service_name>', ADDRESS = 'tcp://host2:4022'
    12. creeaza un route pe host 2 (in baza de date unde este service-ul) pentru service-ul de pe host1: CREATE ROUTE [routeToInitiator] WITH SERVICE_NAME ='<initiator_service_name>', ADDRESS = 'tcp://host1:4022'

    Acum potzi initzia dialoguri intre host1 si host2, trebuie sa specifici WITH ENCRYPTION = OFF in BEGIN DIALOG pentru ca nu sa setat securitate la nivel de dialog intre cele doua service.

    Daca vrei sa folosesti contractul [DEFAULT], potzi omite pasii 1 si 4.

    Configurarea aceasta itzi asigura in trafic authenticare TLS intre host1 si host2 (folosind cele doua certificate din master), dar fara authorizare (pentru ca permisiunea de connect este acordata la 'public'). Traficul este incriptat (RC4).

    Pentru troubleshooting, primul lucru la care trebuie sa te uitzi totdeauna este sys.transmission_queue.transmission_status in baza de date de unde trimitzi mesajele. Urmatorul pas in troubleshooting este sa atasezi Profiler si sa monitorizezi totate evenimentele din categoria 'Broker' si in plus 'Security Audit/Audit Broker Login' si 'Security Audit/Audit Broker Conversation'. Asigurate ca selectezi toate coloanele in Profiler, fii atent ca daca nu pornesti de la un template 'blank' in mod normal ascunde majoritatea coloanelor, inclusiv citeva absolut necesare.

    Porneste de la doua baze de date noi, ca sa nu ai ceva obiecta ramase de la incercari anterioare (remote service bindings, routes). Atentie daca folosesti acelasi nume de service de mai multe ori in baze de date diferite, in mod normal toate sint valide ca target si se poate ca traficul sa faca automat load-balancing intre ele (fiecare nou BEGIN DIALOG va alege un target aleator intre cele posibile).

     Cu Service Listing Manager potzi face totzi pasii 6-12 de mai sus intr-un singur pas:

    ssbslm exchange initiator "<numeserviceinhost1>" -S <host1> -d <host1db> -E /masterdbmkpwd Secret#123 /dbmkpwd Secret#123 target "<numeserviceinhost2>" -S <host2> -d <host2db> -E /masterdbmkpwd Secret#123 /dbmkpwd Secret#123

     

     


    http://rusanu.com
  •  06-28-2007, 12:49 PM 2158 in reply to 2157

    Re: Sincronizare SQLServer Express

    Multumesc!
    Incerc si daca iara imi prind urechile, intreb. BTW daca bazele de date sint pe calculatoare diferite nu e neaprat VPN nu?
    Si acuma vad ce diferenta e intre teoria de service broker de care mai auzisem, si practica....

  •  06-28-2007, 6:59 PM 2165 in reply to 2158

    Re: Sincronizare SQLServer Express

    Nu e nevoie de VPN. Doua server se pot authentica si authoriza folosind certificate (TLS, care este 99% identic cu SSL). VPN este necesar doar daca, din variate motive, este necesara sau dorita authenticare NTLM sau Kerberos intre instantele de SQL Server.

    Dupa cum a replicat si rsocol la postul original (inainte de site crash), doua instantze de SQL Server Express nu pot comunica Service Broker direct, mesajele trebuiesc sa 'treaca' printr-o instanta de alta editie (Workstation, Enterprise) folosind mecanismul de forwarding. In caz ca experimentele tale sint intre doua instante de Express....


    http://rusanu.com
  •  06-28-2007, 8:47 PM 2170 in reply to 2165

    Re: Sincronizare SQLServer Express

    S-a notat chestia cu forwarding de atunci Smile.
    Scenariul care cred ca va fi e un enterprinse sau workgroup  central si expresse care trimit date pe el.
  •  06-29-2007, 5:10 PM 2175 in reply to 2170

    Re: Sincronizare SQLServer Express

    Astazi mi s-a mai explicat despre ce e vorba. Din baza de date se vor tinute la zi vreo 50 de tabele din baza de date (nu toate).
    Si mi-au pus o intrebare incuietoare, "de ce nu replication?" Chiar de ce nu? 
    Mai spuneau ca la replication nu trebuie sa isi bata capul cu schimbarea structurii tabelelor.
  •  06-29-2007, 6:44 PM 2176 in reply to 2175

    Re: Sincronizare SQLServer Express

    Nu mai tzin minte cerintele din postul original. Daca ce se doreste este intr-adevar replicare a datelor atunci evident replication ofera o solutzie 'la cheie'. SQL Express are citeva restrictzii in replicare, vezi http://technet.microsoft.com/en-us/library/ms165686.aspx, dar nu e nimic care sa blocheze proiectul.

    Scenariile cind multa lume foloseste replication dar nu e o replicare a datelor au citeva simptome clasice:

    • datele sint scrise intr-o tabela de catre subscriber si niciodata citite. Publisher-ul le  citeste si le sterege. Acesta e un scenariu de 'data-push' pentru care Service Broker e o alegere mai buna.
    • subsriber-ul scrie intr-o tabela, publisher-ul face un update la acelasi row si apoi subscriberul reactioneaza la acest update. Acest scenariu este de fapt un schimb de mesaje intre subscriber si publisher, din nou Service Broker 'face sens'
    • exista diferentze majore de schema intre subscriber si publisher.

    In cazurile de mai sus replication este folosit ca un mechanism de comunicare intre aplicatzii. De ce Service Broker este mai bun in acest caz pentru ca semantica SSB este explicit de comunicare (SEND, RECEIVE, sesiune etc) si permite developer-ului sa gindeasca in termeni de comunicatzii, nu de insert/update/delete. Sa folosesti replication in acest caz este ca si cum ai folosi in loc de sockets API un API bazat pe copiere de fisiere in share-uri.

    Un alt motiv pentru care SSB poate fi preferat este daca numarul de subscriberi scapa de sub control. Pe la 200-300 de subscriberi devine practic imposibil sa mai potzi face replicare (in primul rind din punct de vedere administrare si monitorizare, apoi performantza). SSB are suport pentru a scala mult mai sus (zeci si sute de mii de clienti) prin mechanisme ca routing si forwarding (fan-in si fan-out al conexiunilor).

    Upgrade-urile la aplicatzie sint un alt factor (adesea neglijat). Versiunea v+next a aplicatzie aduce schimbari ale schemei datelor, care sint replicate imediat. Totzi subscriberi trebuie sa aiba noul cod al aplicatzie, pentru ca altfel nu pot citi noua schema. Deci pentru instalarea noii versiuni, intreaga infrastructura trebuie oprita, noul cod trebuie deployat, apoi re-pornita. Cind firma a crescut si acuma sint zeci poate chiar sute de subscriberi, in locatzii geografice indepartate, aceasta procedura nu poate fi practic implementata. Tehnologia folosita (replication) devine practic a frina care blocheaza orice upgrade, sau intirzie un upgrade pentru foarte lunga durata. Suna oarecum abstract si teoretic, dar am vazut asta in practica de nenumarate ori. Soultzia este sa izolezi aplicatzia intr-un 'fiefdom' care controleaza datele si resursele proprii si comunica cu alte aplicatzii (inclusiv alte instantze ale aceleasi aplicatzii) folosind mesaje definite in contracte formale. Cu alte cuvinte, SOA. Ceea ce ma duce la urmatorul criteriu:

    Conteaza de asemenea viziunea de lunga durata. Pentru cine intzelege filozofia SOA si poate sa citeasca printre rinduri in tonele de maculatura care fac confuzie intre SOA si variatele standarde XML pentru bule de sapun... SSB transforma aplicatzia intr-un serviciu, impune comunicatzii definite intr-un contract formal intre aplicatzii, izoleaza folosirea si definirea resurselor  pentru fiecare aplicatzie individual (data schema, sers and security, locks etc. etc.).

    Un factor care favorizeaza replication este experientza existenta. Developerii pot sa prefere o tehnologie cu care sint mai familiari, customer-ul poate sa refuze sa faca deployment la o tehnologie noua etc etc.
     


    http://rusanu.com
  •  06-29-2007, 8:33 PM 2177 in reply to 2176

    Re: Sincronizare SQLServer Express

    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.

    Multumesc mult!
    Din thread asta am invatat o tona despre aplicatii SQL, (mai) stiam termenii, dar nu vedeam (si inca nu vad tot) cum sa folosesc toate tehnologiile din spate la maxim...

  •  06-30-2007, 11:01 PM 2181 in reply to 2155

    Re: Sincronizare SQLServer Express

    MrSmersh:

    Sa repostez de unde vreau sa reincep cu intrebarile

    rremus:

    Bah, ar trebuii sa citesc de doua ori inainte sa postez... Am fost derutat de folosirea termenului 'sincronizare' in titlu, dar e vorba de o folosire creativa a unui termen consacrat ;)

     Modul ideal de trimitere de date dinspre/spre SQL Express este Service Broker. Creeaza un serviciu in SQL Express si unul in baza de date centrala, foloseste tool-ul de la www.codeplex.com/slm pentru configurare, si urmeaza pattern-ul descris in http://blogs.msdn.com/remusrusanu/archive/2007/04/24/reusing-conversations.aspx pentru a trimite mesajele. Mesajele in general sint create intr-un trigger si processate ca XML.

    Stiu ca in general e o chestia destul de noua si putzina lume are know-how in domeniu, asa ca mai bine pun un exemple. O sa creez doua tabele, a si b, si vreau ca orice operatie in a sa fie replicata in b (pentru simplificare o s a fact totul local in tempdb).

    use tempdb

    GO

    -- sender service, will be used by trigger to send FROM

    --

    create queue q

    create service s on queue q

    GO

    -- 'replicated' table

    --

    create table a (a int primary key);

    go

    -- 'replication' trigger. creates a datagram from the INSERTED and DELETED pseudotables

    -- uses a dumb one message per dialog

    -- see http://blogs.msdn.com/remusrusanu/archive/2007/04/24/reusing-conversations.aspx

    -- for a proper way of using dialogs

    --

    create trigger a_t

          on a for insert, update, delete

    as

    BEGIN

    DECLARE @payload XML, @h UNIQUEIDENTIFIER;

          WITH XMLNAMESPACES (DEFAULT 'htpp://tempuri.org/2007/05/04/sqlserver.ro/rremus')

          SELECT @payload = (SELECT    

                (SELECT * FROM DELETED FOR XML PATH('DELETED'), TYPE),

                (SELECT * FROM INSERTED FOR XML PATH('INSERTED'), TYPE)

                FOR XML PATH('DATAGRAM'), TYPE);

          BEGIN DIALOG CONVERSATION @h

                FROM SERVICE s

                TO SERVICE 't'

                WITH ENCRYPTION = OFF;

          SEND ON CONVERSATION @h (@payload);

    END  

    GO

    -- Test the trigger

    --

    insert into a values (1)

    go

    -- We sent but the target doesn't yet exists.

    -- message is pending in xmit queue

    --

    select cast(message_body as xml),* from sys.transmission_queue

    go

    -- create a target service

    --

    create queue qt

    create service t on queue [qt] ([DEFAULT]);

    go

    -- create a 'replica' table

    --

    create table b (a int);

    GO

    -- this procedures shreds the XML datagrams into

    -- deletes/inserts into the 'replica' table

    -- a proper SSB procedure needs to take care

    -- of properly ending the dialogs:

    -- see http://blogs.msdn.com/remusrusanu/archive/2007/05/02/recycling-conversations.aspx

    -- Also this procedure is highly inneficient,

    -- see http://blogs.msdn.com/remusrusanu/archive/2006/10/14/writing-service-broker-procedures.aspx

    --

    create procedure usp_t

    AS

    BEGIN

    DECLARE @h UNIQUEIDENTIFIER, @mt SYSNAME, @mb XML;

    SET NOCOUNT ON;

    BEGIN TRANSACTION;

          RECEIVE TOP(1)

                @h = conversation_handle,

                @mt = message_type_name,

                @mb = CAST(message_body as XML)

          FROM qt;

          IF @@ROWCOUNT>0

          BEGIN

                IF @mt = N'DEFAULT'

                BEGIN

                      WITH XMLNAMESPACES (DEFAULT 'htpp://tempuri.org/2007/05/04/sqlserver.ro/rremus')

                      DELETE FROM b

                      WHERE b.a IN (

                            SELECT t.n.value('a[1]',      'int') as a

                                  FROM @mb.nodes('//DATAGRAM/DELETED') T(n));

                      WITH XMLNAMESPACES (DEFAULT 'htpp://tempuri.org/2007/05/04/sqlserver.ro/rremus')

                      INSERT INTO b (a)

                            SELECT t.n.value('a[1]',      'int') as a

                                  FROM @mb.nodes('//DATAGRAM/INSERTED') T(n);

                END

          END

    COMMIT

    END

    go

    -- Associate the procedure with the queue

    --

    alter queue qt

          with activation (

                status = on,

                max_queue_readers = 1,

                procedure_name = [usp_t],

                execute as owner);

    go

    Odata ce functioneaza scenariul local, potzi muta serviciul target pe serverul central, configura securitate si transport (cu www.codeplex.com/slm). Evident, procesarea de XMl trebuie sa corespunda cu schema tabelelor tale.

    Acest pattern este foarte des folosit de customeri pentru real-time ETL (Extraction-Transfomation-Load) ca sa incarce datele din OLTP in DW pentru analiza si reporting. In general se interpune si un pas de SSIS pentru transformare, dar in cazul tau ai intrebat cum sa trimitzi efectiv replicare de date, fara transformare.

    Din cate am inteles ca transport se foloseste udp care e un protocol conectionless adica nu se garanteaza ca se primesc toate datagramele si nici oridinea lor,asta trebuie facuta la nivel de aplicatie.

    Service broker garanteaza asta adica sa zicem la momentul t imi pica linia si nu se poate transmite datagrama ce se intampla cu ea ramane in coada locala urmand ca apoi sa fie transmisa toata coada de server broker.

    Si cum gestioneaza acknolegmentul adica de unde stiu eu de pe sender ca datagrama a fost transmisa ok -din ce stiu eu udp nu face chestia asta fiind protocol conectionless.

    Multumesc


    Secolul XXI ori va fi religios ori nu va fi deloc
  •  07-02-2007, 7:43 PM 2185 in reply to 2181

    Re: Sincronizare SQLServer Express

    crestinul:

    Din cate am inteles ca transport se foloseste udp care e un protocol conectionless adica nu se garanteaza ca se primesc toate datagramele si nici oridinea lor,asta trebuie facuta la nivel de aplicatie.

    Service broker garanteaza asta adica sa zicem la momentul t imi pica linia si nu se poate transmite datagrama ce se intampla cu ea ramane in coada locala urmand ca apoi sa fie transmisa toata coada de server broker.

    Si cum gestioneaza acknolegmentul adica de unde stiu eu de pe sender ca datagrama a fost transmisa ok -din ce stiu eu udp nu face chestia asta fiind protocol conectionless.

    Multumesc

    Protocolul folosit este TCP, nu UDP. Insa asta e irelevant, pentru ca SSB trebuie sa ofere garantzii intre baze de date, nu intre socket-uri. Cum SSB garanteaza livrarea mesajelor in baza de date, confirmarea oferita de TCP nu este suficienta. Pe deasupra mesajele pot traversa mai multe hop-uri (prin forwarding, vezi mai sus) si in acest caz din nou garantziile oferite de TCP nu sint suficiente. Ca urmare mesajele sint impartzite in fragmente (de 90k marime) si sint sint tratate foarte mult ca o datagrama UDP: SSB retine fiecare mesaj trimis pina cind este confirmat de destinatar. Confirmarea (acknowledgement) este trimisa de destinatar doar dupa ce mesajul este inscris in queue-ul final si transactia este comisa. Ssender-ul foloseste un sliding window cite mesaje sa trimita si fae retry periodic la mesajele ne-confirmate. Pentru cine este familiar cu cum functioneaza TCP intern, este exact acelasi mecanism.
     


    http://rusanu.com
  •  07-02-2007, 8:36 PM 2186 in reply to 2177

    Re: Sincronizare SQLServer Express

    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. 


    http://rusanu.com
  •  07-03-2007, 9:23 AM 2187 in reply to 2185

    Re: Sincronizare SQLServer Express

    rremus:
    crestinul:

    Din cate am inteles ca transport se foloseste udp care e un protocol conectionless adica nu se garanteaza ca se primesc toate datagramele si nici oridinea lor,asta trebuie facuta la nivel de aplicatie.

    Service broker garanteaza asta adica sa zicem la momentul t imi pica linia si nu se poate transmite datagrama ce se intampla cu ea ramane in coada locala urmand ca apoi sa fie transmisa toata coada de server broker.

    Si cum gestioneaza acknolegmentul adica de unde stiu eu de pe sender ca datagrama a fost transmisa ok -din ce stiu eu udp nu face chestia asta fiind protocol conectionless.

    Multumesc

    Protocolul folosit este TCP, nu UDP. Insa asta e irelevant, pentru ca SSB trebuie sa ofere garantzii intre baze de date, nu intre socket-uri. Cum SSB garanteaza livrarea mesajelor in baza de date, confirmarea oferita de TCP nu este suficienta. Pe deasupra mesajele pot traversa mai multe hop-uri (prin forwarding, vezi mai sus) si in acest caz din nou garantziile oferite de TCP nu sint suficiente. Ca urmare mesajele sint impartzite in fragmente (de 90k marime) si sint sint tratate foarte mult ca o datagrama UDP: SSB retine fiecare mesaj trimis pina cind este confirmat de destinatar. Confirmarea (acknowledgement) este trimisa de destinatar doar dupa ce mesajul este inscris in queue-ul final si transactia este comisa. Ssender-ul foloseste un sliding window cite mesaje sa trimita si fae retry periodic la mesajele ne-confirmate. Pentru cine este familiar cu cum functioneaza TCP intern, este exact acelasi mecanism.
     

    ok.

    Daca e tcp se foloseste un protcol de aplicatie cunoscut pe un port cunoscut http/soap de ex functioneaza cumva ca niste servicii de web serviciile service broker sau sb are propriile lui porturi ,propriul lui protocol la nivel de aplicatie?

    Multumesc


    Secolul XXI ori va fi religios ori nu va fi deloc
  •  07-03-2007, 9:44 AM 2188 in reply to 2187

    Re: Sincronizare SQLServer Express

    Protocol binar proprietar. Este folosit un singur port TCP, configurat prin CREATE/ALTER ENDPOINT.

    La momentul cind SSB a fost creat standardele WS nu aveau protocoalele necesare (authenticare, authorizare, sessiuni persistenete etc). Majoritatea acestor protocoale (WS-Security, WS-Authentication, WS-ReliableMessaging etc) au fost definitivate dupa ce SQL Server 2005 era deja 'locked down', iar unele nu sint definitivate nici azi. In plus, criteriile de performanta pentru un enterprise-message-bus nu prea se impaca cu formatele text/XML.

    Dar ca idee generala interoperabilitatea cu standardele WS este dorita de catre/pentru SSB.


    http://rusanu.com
  •  07-03-2007, 6:32 PM 2195 in reply to 2188

    Re: Sincronizare SQLServer Express

    Am intrebat mai departe si am primit un refresh al scenariului (da iara o tona de citi Smile).

    1. Pe termen scurt vor fi 6 baze de date.
    2. Momentan bazele de date se duc la centru dar nu se unifica. La centru bazele de date exista separat, una pentru fiecare punct de lucru. Momentan se fac analize independente, pe fiecare punct de lucru in parte. Momentan copiile de la centru sunt identice(1 la 1) cu cele de la punctele de lucru atat ca structura cat si ca continut(numar de rowuri) (deci se face restore si nimic mai mult)
    3. Datele de la centru se folosesc exclusiv pentru analiza. Deci nu se modifica si nu se trimit inapoi la punctele de lucru. Exista o singura exceptie ceva stil catalog de produse care teoretic se editeaza la centru si trebuie distribuit...dar pentru acesta exista momentan o solutie de import/export.
    4. Cam 1-2% maxim din volumul unei bazei de date poate fi modificat zilnic si trebuie sincronizat la centru.
    5. Se are in vedere crearea la centru a unei baze de date centralizate care sa contina datele din toate bazele de date din punctele de lucru. Aici trebuie sa detaliez:
                  a) urgenta momentan consta in sincronizarea bazelor de date neunificate pentru a nu mai transmite backup-uri de sute de mega zilnic sau la cateva zile
                 b) structura bazelor de date este aceiasi si este conceputa pentru centralizare(si baza de date centralizata va avea exact aceeasi structura) .
    6. In principiu conexiunea e(va fi) permanenta si relativ sigura. Poate cadea doar in cazuri foarte exceptionale....

    Exista 3 tipuri de tabele:
    1. Tabele globale care trebuie sa fie cu continut identic in toate bazele de date inclusiv cea centralizata (Ex. Produse)
    2. Tabele cu date ce trebuiesc centralizate (acestea au fiecare o coloana GUID si o coloana ID punct de lucru) (Ex. Facturi - va cumula toate facturile de la toate punctele de lucru)
    3. Tabele cu date locale care nu urmeaza a fi sincronizate ele fiind folosite exclusiv la punctul de lucru local (ex. setari sau useri)

    Multumesc!

Page 1 of 5 (61 items)   1 2 3 4 5 Next >
View as RSS news feed in XML
Powered by Community Server (Commercial Edition), by Telligent Systems