SQL Server - merge replication

[whoami]

De situatie is als volgt:

Ik heb 3 SQL Server2000 databanken, die in een merge-replication staan. Nu is het zo dat ik database aanpassingen moet kunnen doorvoeren op die databases (kolommen bijvoegen, tabellen bijvoegen).
Ik weet dat er hiervoor speciale stored procedures bestaan, waarmee je dus de structuur van bv een tabel kunt wijzigen terwijl die deel uit maakt van een 'publication'.
Echter, ik 'kan' deze procedures in dit geval niet gebruiken; het moet dus mbhv een gewoon 'alter table' statement gaan.
Dit kan ik echter niet zo maar doen als de databases onder replicatie staan; SQL Server laat me dit niet toe.
Ik heb dus zitten denken, dat een mogelijke oplossing zou zijn om m'n replicatie af te breken, DB aanpassingen doorvoeren, replicatie opnieuw opzetten.
Echter, ik kan dit niet zomaar doen; ik wil nl. geen data verliezen. Ik kan dus pas m'n replicatie afbreken op het moment dat ik er zeker van ben, dat m'n 3 databases 'in sync' zijn, en daar zit m'n probleem. Hoe kan ik dit te weten komen ?
Ik weet wel dat er een stored procedure is in SqlServer die mij dit zou kunnen vertellen, maar deze SP werkt niet als je gebruik maakt van merge-replication.

Heeft er iemand ideeën hoe ik ervoor kan zorgen dat ik zeker kan zijn of m'n DB's 'in sync' zijn ?

[whoami]

Hmm, ik denk dat ik me maar eens ga inlezen over de backup en restore strategies voor databases die in merge - replication staan.
Wellicht kan dit me verderhelpen.

Als er iemand ideeën / opmerkingen / tips heeft, houd ik me altijd aanbevolen.

[whoami]

Misschien kan ik wel iets doen met de sp_MSenumchanges stored procedure, maar die is niet echt gedocumenteerd.

[whoami]

Mijn databases kunnen normaal gezien enkel benaderd worden via IIS. De componenten die de DB access verzorgen, zijn remoted .NET objecten, die in IIS gehost zijn.

Ik zit nu te denken: als ik mijn IIS servers stop, dan kan er normaal gezien niemand meer aan de database. Op die manier kan ik dan wel verhinderen dat er dus (tijdelijk) data gewijzigd wordt.

Als ik dan de merge agent zelf nog eens laat synchronizen, dan moet ik er toch quasi zeker van kunnen zijn dat mijn 3 databases in sync zijn, wat gegevens betreft. Ik moet dan wel nog zien uit te vissen of er ergens merge-conflicten opgetreden zijn.

Eens dit gedaan is, zou ik m'n replicatie afbreken, m'n db aanpassingen doen, en de replicatie opnieuw opzetten.

Zitten er nog graten in deze denkwijze ? Heeft er iemand andere / betere ideeën om dit te werk te kunnen stelligen ?

[sanfranjake]

Op verzoek van wiebenik een aliasje in PW

[JaQ]

Ik heb persoonlijk wenig tot geen ervaring met sql-server. Wel veel ervaring met Oracle, dus ik kan je vanuit die hoek misschien helpen

whoami schreef op zondag 18 september 2005 @ 12:23:
Mijn databases kunnen normaal gezien enkel benaderd worden via IIS. De componenten die de DB access verzorgen, zijn remoted .NET objecten, die in IIS gehost zijn.

Ik zit nu te denken: als ik mijn IIS servers stop, dan kan er normaal gezien niemand meer aan de database. Op die manier kan ik dan wel verhinderen dat er dus (tijdelijk) data gewijzigd wordt.

Als ik dan de merge agent zelf nog eens laat synchronizen, dan moet ik er toch quasi zeker van kunnen zijn dat mijn 3 databases in sync zijn, wat gegevens betreft. Ik moet dan wel nog zien uit te vissen of er ergens merge-conflicten opgetreden zijn.

Eens dit gedaan is, zou ik m'n replicatie afbreken, m'n db aanpassingen doen, en de replicatie opnieuw opzetten.

lk zou niet voor deze sync oplossing kiezen. Waarom stop je de databases niet na de laatste data wijzigingen, start alleen de master database (in restrict modus, dus alleen toegangkelijk voor sysdba's) en voert je wijzigingen door? Vervolgens maak je een full backup en bouwt daarmee je slaves opnieuw op. Je maakt daarmee wel de aanname dat je master database 100% correct is (maar dat doe je toch al door voor de replicatie methode te kiezen).

Zitten er nog graten in deze denkwijze ? Heeft er iemand andere / betere ideeën om dit te werk te kunnen stelligen ?

Verder klinkt het als een helder verhaal. Uiteraard wel zorgen voor een goede backup

[whoami]

DrFrankenstoner schreef op zondag 18 september 2005 @ 20:22:

lk zou niet voor deze sync oplossing kiezen. Waarom stop je de databases niet na de laatste data wijzigingen, start alleen de master database (in restrict modus, dus alleen toegangkelijk voor sysdba's) en voert je wijzigingen door? Vervolgens maak je een full backup en bouwt daarmee je slaves opnieuw op. Je maakt daarmee wel de aanname dat je master database 100% correct is (maar dat doe je toch al door voor de replicatie methode te kiezen).

Als de databases 'gestopt' zijn, dan ik ook niet repliceren. Aangezien het hier ook over merge-replication gaat, kan ik er niet zeker van zijn dat m'n 'master' (publisher in sql server) 100% 'correct' is. Bij merge-replication kunnen er wijzigingen gebeuren op de 'publisher' en op de 'subscribers'. Door de merge-agent worden deze databases dan echter synchroon gehouden (data-changes worden doorgevoerd op de andere db's).

Ik heb ook wel even gedacht om m'n 'subscribers' (slaves) dan volledig opnieuw op te bouwen, maar dat gaat gewoon teveel tijd in beslag nemen. De DB heeft nu zo'n 1.7GB aan content, en om de DB 's op de subscribers zo vanaf 'scratch' opnieuw op te bouwen, zou teveel tijd in beslag nemen.

Uiteraard wel zorgen voor een goede backup

Uiteraard.

[megamuch]

Whoami, Kan je op een bepaald moment wel zien welke van de DB's 100% correct is?

[whoami]

megamuch schreef op maandag 19 september 2005 @ 01:12:
Whoami, Kan je op een bepaald moment wel zien welke van de DB's 100% correct is?

Nee, dat is een beetje het probleem. Ik weet dat er een stored procedure is, waarmee je kan opvragen of de DB's gesynched zijn, maar die werkt niet met merge-replication.

[megamuch]

whoami schreef op maandag 19 september 2005 @ 14:01:
[...]


Nee, dat is een beetje het probleem. Ik weet dat er een stored procedure is, waarmee je kan opvragen of de DB's gesynched zijn, maar die werkt niet met merge-replication.

Hmm vreemd. Ik bedoel, het kan nooit de bedoeling geweest zijn van de ontwerpers van SQLserver dat als er een merge replication draait, je geen colommen meer kan toevoegen.

[whoami]

Je kan columns toevoegen, maar dan met de stored procedure sp_repladdcolumn. Op die manier zorg je er dan ook voor dat de schema-changes gepropageerd worden naar de subscribers.
Mbhv een gewoon alter statement kan je de tables niet aanpassen.

Nu is het zo dat ik die stored procedures eigenlijk liever niet wil gebruiken....

[JaQ]

whoami schreef op maandag 19 september 2005 @ 16:58:
Je kan columns toevoegen, maar dan met de stored procedure sp_repladdcolumn. Op die manier zorg je er dan ook voor dat de schema-changes gepropageerd worden naar de subscribers.
Mbhv een gewoon alter statement kan je de tables niet aanpassen.

Nu is het zo dat ik die stored procedures eigenlijk liever niet wil gebruiken....

Klinkt als een vertrouwenskwestie Heb je hier een gefundeerde reden voor?

Vertrouwen is trouwens wel het keyword in dit verhaal. Aangezien je op geen enkele wijze er echt zeker van zijn dat een van de databases 100% in sync is, blijf je altijd twijfelen. Als ik je verhaal echter aanhoor lijkt het me wel zeer aannemelijk dat je publisher in sync is, nadat je IIS hebt gestopt (en er dus geen connecties met de database meer gemaakt worden) en een laatste maal de sync agent hebt aangeroepen.

Als je handmatig kolommen gaat aanmaken in zowel je publisher, als je subscribers, krijg je dan geen problemen met je sync agents ivm timestamps (of houd sql-server deze niet bij)?

[Gé Brander]

Als je het handmatig doet, dan worden de triggers die voor de replicatie zorgen (de update, delete en insert triggers die voor elke gerepliceerde tabel aangemaakt worden) niet bijgewerkt volgens mij. Dus dan werkt de replicatie niet en moet je de replicatie opnieuw opbouwen.
Ik zou gewoon de daarvoor bedoelde sp's gebruiken.
Heb je geen testsysteem? Je kan merge replicatie op een machine met drie instances op die manier gewoon testen.

[ Voor 15% gewijzigd door Gé Brander op 20-09-2005 07:30 . Reden: Sp's vervangen door triggers. Was niet helemaal bij de les ;) ]

[whoami]

DrFrankenstoner schreef op maandag 19 september 2005 @ 23:04:
[...]


Klinkt als een vertrouwenskwestie Heb je hier een gefundeerde reden voor?

M'n DB model zit in Visio, en mbhv red-gate tools worden er patches aangemaakt om DB-updates te maken. Die patches bevatten dus enkel de 'gewone' alter table statements ed.

Vertrouwen is trouwens wel het keyword in dit verhaal. Aangezien je op geen enkele wijze er echt zeker van zijn dat een van de databases 100% in sync is, blijf je altijd twijfelen. Als ik je verhaal echter aanhoor lijkt het me wel zeer aannemelijk dat je publisher in sync is, nadat je IIS hebt gestopt (en er dus geen connecties met de database meer gemaakt worden) en een laatste maal de sync agent hebt aangeroepen.

Het is helemaal niet aannemelijk dat m'n publisher in sync is; ik heb 3 databases. Per locatie staat er één database. Mensen die werken op locatie A, gebruiken die database, mensen die werken op locatie B gebruiken de DB op locatie B. Als er dus iemand op locatie B iets wijzigt, dan gebeurt dat in eerste instantie op de database die op locatie B staat. Die wijzigingen moeten dan dmv merge replication ook naar locatie A gestuurd worden. Hetzelfde geldt voor locatie A en C.

Als je handmatig kolommen gaat aanmaken in zowel je publisher, als je subscribers, krijg je dan geen problemen met je sync agents ivm timestamps (of houd sql-server deze niet bij)?

Ik kan pas handmatig kolommen bijmaken, als ik de replicatie afbreek. Daarna kan ik ze terug opbouwen.

[P_de_B]

Volgens mij heb je nooit zekerheid zonder de uitgebreide checks die in de system sp staan die je noemt. Daarnaast wil je gewone statements gebruiken, en heb je niet de ruimte om checks te doen (immers je alter statement is gegenereerd). Als ik dit zo bekijk is volgens mij je enige mogelijkheid de applicatie buiten werking te zetten, een synchronisatie te forceren daarna de update uit te voeren en ten slotte weer een synchronisatie te forceren.

[ Voor 1% gewijzigd door P_de_B op 20-09-2005 09:15 . Reden: typo's ]