[SQL 2000] Replication & naderhand aanpassen van constraints

[cavey]

Goedemiddag,

Ik zit met het volgende:

Al enige tijd draait er een replicatie tussen twee databases.
In den beginne waren er nogal wat problemen met verdwijnende records, deze problemen werden stuk voor stuk opgelost.

Het betreft trouwens een merge replication.

- Primary keys op not for replication gezet
- Ranges ingesteld
- DTS job aangepast zodat de NULL values tenminste ook werden overgebliept bij initialisatie van de data
- Triggers aan lopen passen zodat deze ook geen roet in het eten gingen gooien tijdens replicatie.

Afijn, denk je eindelijk klaar te zijn met alle ellende op te lossen........ strompel ik per toeval achter de reden waarom er toch nog steeds wat gegevens pleite gaan:
foreign key constraints!

Alleen, nu draait de replicatie dus al, dus wordt het wat ellendiger om de tabel schema's aan te passen.

Goed, heb ondertussen al een heel script in mekaar gebakken om de offending foreign key constraints te droppen en weer toe te voegen aan die tabellen die gepubliceerd worden, maar zit ik met het volgende:

Wat is de beste manier om die schema changes te doen, die het minste impact heeft op het productie systeem?

Ik heb al wel wat ideeën, maar ben er niet echt blij mee:

1) Subscription deleten, publication deleten, script met alter table statements draaien, publication maken, subscription maken, snapshot over ftp'n en gaan met die banaan.

Nadeel: bewerkelijk, en ik ben m'n tussen liggende merge data kwijt (aangezien ik bij de subscription zeg dat ik alle data al heb staan op de subscriber kant... de snapshot is vrij nutteloos zeg maar afgezien dan voor schema changes zoals extra kolommen aan tabellen over bliepen).

2) Gewoon de alter statements draaien en hopen dat ze terecht komen in de snapshot, de snapshot over bliepen en hopen dat het op de subscriber komt.

Nadeel: groot gapend gat van vragen.
Voordeel: niet zo bewerkelijk

3) Subscription stoppen, alle articles uit de publicatie halen, alter statements draaien, articles weer toevoegen aan de publicatie, re-init met datachanges terug laten voeren op de publisher...... en gaan.


Tja, goed, heb natuurlijk niet alle ideetjes even goed beschreven (enkele "stappen" niet beschreven... zoals re-init met datachanges zoals ik wel bij stap 3 heb gedaan.)

Maar goed, wie heeft dit al eens eerder moeten doen, en wat waren de genomen stappen?

Re-cap: Draaiende replicatie, waarbij nu dus naderhand constraints aangepast moeten worden naar "not for replication" omdat de volgorde van binnenkomst zorgde voor conflicten....... en dus deleted records (en boze medewerkers omdat ze weer eens wat gegevens kwijt waren).

[cavey]

ok, bump

Is het mogelijk om gewoon de foreign keys aan te passen zonder de hele boel (publication, subscription, replication) opnieuw op te zetten?

Ik weet dat je met schema changes in de vorm van kolom-toevoegen/verwijderen de boel eerst even uit de publicatie moet halen, schema aanpassen, toevoegen en het propageert door...... (of naja, voor het wijzigen van een kolom althans... toevoegen van een kolom gaat makkelijker in sql 2000).

Zou het graag gaan uittesten op een test systeem, ware het niet dat we die niet hebben helaas (en ook even niet de resources in de vorm van man-uren om die op te gaan zetten).

Dus, wie heeft hier al eens eerder mee lopen stoeien?

Draaiende replicatie en dan erachter komen dat je de foreign keys moet aanpassen?

[edit]
Want tot nu toe kom ik op groups.google.com alleen maar dingen tegen als "You need to set NOT FOR REPLICATION option on your foreign keys" maar verder geen WOORD over herinitialiseren van de boel. En daar is het mij nou net om te doen. Heb geen zin om het productie systeem helemaal lam te leggen door een foute actie. Het ligt nu al aardig lam (op z'n tijd even een sp_adjustpublisheridentityrange @table_name=' ... ' )

[ Voor 23% gewijzigd door cavey op 03-08-2004 12:06 ]

[zneek]

ik heb dit laatst aangepast zonder de replicatie er af te halen. Nog geen probleem ontdekt. Je moet er volgens mij wel ff aan denken dat je het aan beide kanten doet. Ik heb gewoon dat "NOT FOR REPLICATION" bij de relaties er af gehaald. Ik vind het eigenlijk een beetje raar dat dit fout gaat. Word de gerepliceerde data niet in dezelfde transactie structuur ge-insert op de andere server als waar het op de bronserver in ge-insert is?

Als je twijfelt kun je het toch ff proberen in test omgeving? Maak je even een test dbtje en probeer of het goed gaat.

[cavey]

Ok, final bump...

Heb uiteindelijk een test-omgeving op kunnen zetten op 1 server met replicatie aan (merge replication on demand).

Heb geprobeerd de insert-fk conflict te simuleren, was niet gelukt.

Toen de rollen omgedraaid: Wat als ik nou een record delete?

Algoed, northwind DB gepakt, shipper toegevoegd, wat orders toegevoegd, FK_Orders_Shippers constraint eraf gehaald, shipper weg gehaald, FK constraint weer toegevoegd met WITH NOCHECK.... gesynchroniseerd -> 1 conflict...

MAar nog geen updates.... weer een merge -> 1 insert... en de shipper was weer terug. (Dit alles trouwens op de gepubliceerde database).

Goed, toen maar de alter statemenst gedraaid voor de FK's met "NOT FOR REPLICATION", weer het zelfde liedje herhaald -> shipper weg gegooid, maar verwijzingen laten staan..

mergen --> en 1 delete aan subscriber kant.

Prima.........

Ofwel: Je hoeft niet moeilijk te doen met merge replication als je de foreign key constraints wil aanpassen naar "NOT FOR REPLICATION".

Draadje mag wat mij betreft op slot dan, of houd het open voor nut van algemeen... hopelijk hebben mensen hier wat aan.

Vele uren google, BOL, groups.google.com / microsoft.public.sqlserver.replication nieuwsgroep afstruinen hadden me niet veel geholpen.

[edit]
hah, of anders refresh ik m'n page eens.

Hehe, thanks Zneek, was er ondertussen zelf al achter gekomen dus dat je gewoon de foreign key constraints kon aanpassen zonder de replicatie er af te halen.


Normaal gesproken ging het updaten inderdaad goed, maar omdat de subscriber in Manila staat wil die verbinding er nog wel eens uitvliegen....... als de merge daarna weer wordt hervat worden eerst de nieuwe generations (als ik me niet vergis.. heb zoveel gelezen de laatste tijd) over gestuurd...... en die kunnen best verwijzingen bevatten naar records die bij de vorige merge nog niet tegevoegd waren.

Gevolg een conflict op de subscriber kant omdat er niet wordt voldaan aan de foreign key constraint. Dus worden ze gescheduled voor delete... bij de volgende merge actie worden de correcte records aan beide kanten verwijderd... wat niet echt prettig is als je daardoor contacten, aanvragen, aanbiedingen etc kwijt raakt.

Tnx!

[ Voor 29% gewijzigd door cavey op 03-08-2004 17:24 ]