Dacă soluţia cu "backup/restore" răspunde momentan la cerinţe şi singura ei problemă este volumul mare de date care trebuie transferate în fiecare zi, atunci eu aş sugera o strategie cu differential backups (backup full în fiecare săptămână sau în fiecare lună şi backup-uri diferenţiale în fiecare zi). Backup-urile de transaction log ar putea să fie o soluţie şi mai bună dpdv al dimensiunii datelor transferate, dacă e acceptabil din punctul de vedere al siguranţei ca backup-urile de log să se facă doar odată pe zi (în mod normal, eu aş face backup-uri de log mai dese, dar asta ar însemna că sunt mai greu de restaurat dincolo).

Răzvan

rremus:

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

 

 

Ma joc si eu un pic cu service broker adica vreau sa fac o replicare la o tabela de pe un sql standard la un sql express aflat pe alt host,Singurul lucru care nu prea il inteleg e accesul la end point folosing certificate am definit pe ambele servere un master key identic inteleg ca e keya cu sunt cryptate datele cand sunt trimise in retea ,dar nu inteleg care e treaba cu certifcatele alea.

Multumesc

---

Secolul XXI ori va fi religios ori nu va fi deloc

crestinul:

Ma joc si eu un pic cu service broker adica vreau sa fac o replicare la o tabela de pe un sql standard la un sql express aflat pe alt host,Singurul lucru care nu prea il inteleg e accesul la end point folosing certificate am definit pe ambele servere un master key identic inteleg ca e keya cu sunt cryptate datele cand sunt trimise in retea ,dar nu inteleg care e treaba cu certifcatele alea.

Cele doua instante/endpoint-uri folosesc TLS pentru autentificare. In mod normal TLS/SSL (Schannel.dll) folosesc certificatele din 'NT certificates store' atunci cind se autentifica (IE cu IIS de exemplu). Insa folosirea 'store-ului' NT nu permite autentificarea de useri SQL (deoarece NT nu are nici un concept despre ei), nu functioneaza corect in context de backup/restore al bazei de date ('store-ul' NT nu va fi facut restore), nu functioneaza intr-un mediu cluster si nu functioneaza corect daca baza de date este mutata. In plus in modelul IE/ISS authorizarea se face pe baza verificarii semnaturilor (certificatul trebuie sa fie semnat de un 'trusted authority'), un process care nu implica in nici un fel dba/sysadmin-ul instantei de SQL.

Din cauza tuturor acestor probleme am decis sa folosim certificatele din baza de date (acela specificat in AUTHENTICATION = CERTIFICATE ...).

 Sper ca acuma lucrurile sint un pic mai clare :)

---

http://rusanu.com

Multumesc pt lamuriri Remus.

EU aici ma joc cu sb sa vad cum mere practic.Incerc sa fac o replicare simpla folosind sb de pe o instanta de standard pe un de express,afalate pt hosturi diferite.

AM facut pasii aia care i-ai zis tu si nu merge replicarea.

AM incercat sa fac troublesuting cum scrie acolo dar pe baza de datew AdventureWorks de pe standard de unde trimit mesaje nu am view-ul asta sys.transmission_queue.transmission_status ,iar in profiler la events nu-mi apare nimic legat de sb.

Ce e de facut in situatia asta?

Multumesc

 

---

Secolul XXI ori va fi religios ori nu va fi deloc

Viewl se numeste sys.transmission_queue si contine o coloana transmission_status. Nu se poate ca view-ul asta sa nu existe, ar insemna ca nu esti pe SQL Server 2005. Daca in Profiler nu apare nimic legat de SSB, inseamna ca sau nu ai selectat nici un eveniment SSB (evenimentele din categoria Broker/*) sau... nu efectuezi nici o operatzie SSB (BEGIN DIALOG/SEND).

---

http://rusanu.com

Da scuze asa este am mai facut ceva modficari si mesaju de eroare din view-ul acela ultima coloana e:

Connection handshake failed. The certificate used by the peer is invalid due to the following reason: Certificate not found. State 89.

pe serviciu initiator (sender i-am  zis ) am definit asa:

CREATE CERTIFICATE [host2_cert] WITH SUBJECT = 'host1_cert'

create endpoint broker state=started as tcp(LISTENER_PORT =50) for service_broker( AUTHENTICATION =CERTIFICATE [host1_cert])

GRANT SEND ON SERVICE::[sender] TO [public]

pe target (i-am zis receptor) as asa

CREATE CERTIFICATE [host2_cert] WITH SUBJECT = 'host2_cert'

create endpoint broker state=started as tcp(LISTENER_PORT =50) for service_broker( AUTHENTICATION =CERTIFICATE [host2_cert])

GRANT CONNECT ON ENDPOINT ::[broker] TO [public]

Imi poti spune te rog unde ar fi greseala?

Multumesc

---

Secolul XXI ori va fi religios ori nu va fi deloc

Authenticarea intre endpoint-uri e mutuala, asa ca trebuie sa-i faci grant connect to public si pe 'sender'

---

http://rusanu.com

oh, si GRANT SEND ON SERVICE::... TO Public trebuie pe serviciul 'receptor', nu pe sender.

---

http://rusanu.com

rremus:

oh, si GRANT SEND ON SERVICE::... TO Public trebuie pe serviciul 'receptor', nu pe sender.

Multumesc da imiu poti explica si de ce dupa mintea mea serviciul care trimite ar trebui sa aiba drept de send pe endpointul ala ,nu cel ce primeste date, targetul

---

Secolul XXI ori va fi religios ori nu va fi deloc

Dreptul de SEND este pe un serviciu, pe endpoint se acorda dreptul de CONNECT.

Dreptul de CONNECT este mutual (ambele instante de SQL Server trebuie sa-si acorde una alteia acest drept) pentru ca odata deschisa o conexiune intre doua instante de SQL (doua endpoint-uri) prin aceasta conexiune circula mesaje in ambele directzii pe o durata nederminata (mai exact pina ce trec 90 de secunde fara trafic). Orice mesaje de la/pentru servicii aflate in oricare din cele doua instante de la capetele conexiunii vor fi trimise/primite folosind aceasta conexiune.

Dreptul de SEND este acordat totdeauna de serviciul care accepta un dialog ('target') serviciului care solicita un dialog ('initiator'). Serviciul solicitant este identificat prin cheia publica a certificatului folosit (mai exact de catre user-ul care detine aceasta cheie) si dreptul de SEND se acorda acestui user pe serviciul acceptor.

Mai exista un drept implicat si anume RECEIVE pe un queue. Acesta insa nu controleaza comunicatzia intre servicii ci numai dreptul unui utilizator de a 'folosi' un serviciu, mai exact de a manipula conversatiile detinute de acest serviciu (BEGIN DIALOG, SEND, RECEIVE). Chiar daca dreptul de RECEIVE se acorda pe un queue nu pe un serviciu, logic poate fi privit ca si cum ar acorda acces la serviciu (si in general este recomandat ca relatia queue-service sa fie 1:1)

Sper ca acuma este mai clar :)
 

---

http://rusanu.com

Multumesc mult remus pentru efortul de a ma lamuri din pacate certificatele si cryptografia nu sunt punctul meu forte,asta mai trebuie sa sap aici.Am dat drepturile alea connect la endpointul pe sender si si pe receiver dreptul de send la serviciul receptor.

SI acu optin eroarea asta o coloana de transmission status pe sender cand fac select * from

sys.transmission_queue

Service Broker received an error message on this conversation. Service Broker will not transmit the message; it will be held until the application ends the conversation.

M-am uitat si in profiler la evenimentele de broker dar nu scrie decat un error la broker:: conversation

 

Multumesc mult inca o data

---

Secolul XXI ori va fi religios ori nu va fi deloc

Vestea buna e a ai comunicatzie, probabil mesajul tau a ajuns la 'receptor' si receptorul a raspuns cu o eroare. In queue-ul 'sender'-ului o sa ai un messaj de erroare care va spune care-i problema: SELECT CAST(message_body AS XML), * FROM <sender_queue>. Ce trebuie sa faci depinde de ce eroare ai acolo.

 

---

http://rusanu.com

MA rulat asta e eroarea

<Error xmlns="http://schemas.microsoft.com/SQL/ServiceBroker/Error">

<Code>-8425</Code>

<Description>The service contract 'repl1' is not found.</Description>

</Error>

Mi se pare ciudat pt ca eu am contractul repl1 in baza de date pe sender

Multumesc

---

Secolul XXI ori va fi religios ori nu va fi deloc

Inseamna ca serviciul target nu implementeaza respectivul contract. Adauga contractul la serviciul target:

ALTER SERVICE [targetservice] (ADD CONTRACT [repl1]);

---

http://rusanu.com

Multumesc dinnou

AM facut asa pe caLCULATORUL CU serviciu target unde vreau replicarea:

CREATE MESSAGE TYPE [insertie] AUTHORIZATION [dbo] VALIDATION = WELL_FORMED_XML

CREATE CONTRACT [repl1] AUTHORIZATION [dbo] ([insertie] SENT BY INITIATOR)

alter service receptor (add contract repl1,drop contract repl)

Dar nu merge obtin aceasi eroare pe sender

---

Secolul XXI ori va fi religios ori nu va fi deloc