[SQL Server] Merge Replication

[whoami]

Ik ben bezig met het opzetten (en uitzoeken) van merge replication op SQL Server 2000.
Ik heb 3 databases op verschillende sites die dmv merge replication gesynchroniseerd zullen moeten worden.
Deze 3 databases hebben identiek dezelfde structuur.

Nu is mijn vraag: wat moet er gebeuren met die replicatie als de structuur van m'n database veranderd ?
Hoe moet ik dan m'n replication gaan afhandelen? Moet ik de structuur-wijzigingen zelf gaan doen in alle 3 de databanken ?
Moet ik de replication opnieuw gaan opzetten ?
Etc....

Heeft er hier iemand ervaring mee ?

[Alex]

Volgens mij repliceert SQL Server 2000 ook tabel wijzigingen.
Ik vond op deze link het volgende in een ALTER-query:

SQL:

ALTER TABLE table
{ [ ALTER COLUMN column_name
    { new_data_type [ ( precision [ , scale ] ) ]
        [ COLLATE < collation_name > ]
        [ NULL | NOT NULL ]
        | {ADD | DROP } ROWGUIDCOL }
    ]
    | ADD
        { [ < column_definition > ]
        |  column_name AS computed_column_expression
        } [ ,...n ]
    | [ WITH CHECK | WITH NOCHECK ] ADD
        { < table_constraint > } [ ,...n ]
    | DROP
        { [ CONSTRAINT ] constraint_name
            | COLUMN column } [ ,...n ]
    | { [ WITH CHECK | WITH NOCHECK ] CHECK | NOCHECK } CONSTRAINT
        { ALL | constraint_name [ ,...n ] }
    | { ENABLE | DISABLE } TRIGGER
        { ALL | trigger_name [ ,...n ] }
}

< column_definition > ::=
    { column_name data_type }
    [ [ DEFAULT constant_expression ] [ WITH VALUES ]
    | [ IDENTITY [ (seed , increment ) [ NOT FOR REPLICATION ] ] ]
        ]
    [ ROWGUIDCOL ]
    [ COLLATE < collation_name > ]
    [ < column_constraint > ] [ ...n ]

< column_constraint > ::=
    [ CONSTRAINT constraint_name ]
    { [ NULL | NOT NULL ]
        | [ { PRIMARY KEY | UNIQUE }
            [ CLUSTERED | NONCLUSTERED ]
            [ WITH FILLFACTOR = fillfactor ]
            [ ON { filegroup | DEFAULT } ]
            ]
        | [ [ FOREIGN KEY ]
            REFERENCES ref_table [ ( ref_column ) ]
            [ ON DELETE { CASCADE | NO ACTION } ]
            [ ON UPDATE { CASCADE | NO ACTION } ]
            [ NOT FOR REPLICATION ]
            ]
        | CHECK [ NOT FOR REPLICATION ]
            ( logical_expression )
    }

< table_constraint > ::=
    [ CONSTRAINT constraint_name ]
    { [ { PRIMARY KEY | UNIQUE }
        [ CLUSTERED | NONCLUSTERED ]
        { ( column [ ,...n ] ) }
        [ WITH FILLFACTOR = fillfactor ]
        [ ON {filegroup | DEFAULT } ]
        ]
        |    FOREIGN KEY
            [ ( column [ ,...n ] ) ]
            REFERENCES ref_table [ ( ref_column [ ,...n ] ) ]
            [ ON DELETE { CASCADE | NO ACTION } ]
            [ ON UPDATE { CASCADE | NO ACTION } ]
            [ NOT FOR REPLICATION ]
        | DEFAULT constant_expression
            [ FOR column ] [ WITH VALUES ]
        |    CHECK [ NOT FOR REPLICATION ]
            ( search_conditions )
    }

Dat stukje [ NOT FOR REPLICATION ] zou erop wijzen dat hij het direct doorvoert.
In februari moet ik waarschijnlijk samen met een collega een grote eerder bedrijfs/websitekritische merge replication opzetten dus ik ben vrij geïnteresseerd in de uitkomst van je 'onderzoek'.

[ Voor 7% gewijzigd door Alex op 04-01-2005 21:17 . Reden: M'n collega tikt me ff op m'n vingers, 't blijkt geen merge te zijn :P ]

[wasigh]

Merge replication gaat aan de hand van Log's toch?
Volgens mij komen veranderingen aan de structuur ook in de logs terecht. Als dat zo is zou het dus automagisch kunnen gaan.

Alleen weet ik het niet, het lijkt mij dat hij hetzelfde doet als wanneer je een backup maakt, de structuur wijzigt daarna een incremental backup maakt en dan een DB met beide backup's restored..

maar eigenlijk weet ik het gewoon niet ik zou zeggen: probeer het eens uit!

[whoami]

Hmmm, die NOT FOR REPLICATION wil niet zeggen dat hij structuur-wijziging direct doorvoert.

Bij een trigger wil het zeggen dat de trigger niet mag gefired worden als de data op de onderliggende tabel aangepast wordt dmv een replication.
Op column niveau wordt het vooral gebruikt voor identity columns (voor als je partitionering op je tabellen toepast).

[whoami]

wasigh schreef op dinsdag 04 januari 2005 @ 21:14:
maar eigenlijk weet ik het gewoon niet ik zou zeggen: probeer het eens uit!

Dat ben ik nu aan het doen....
Eigenlijk ben ik gek; gewoon thuis ff verder wat onderzoek doen voor m'n werk...

Hah, als ik gewoon de structuur van een tabel wil veranderen van een DB die onder merge replication staat in een 'publisher database', dan krijg ik de melding dat de tabel niet kan gewijzigd worden omdat ze 'gepublished wordt' voor merge-replication

[ Voor 30% gewijzigd door whoami op 04-01-2005 21:18 ]

[wasigh]

whoami schreef op dinsdag 04 januari 2005 @ 21:16:
[...]


Dat ben ik nu aan het doen....
Eigenlijk ben ik gek; gewoon thuis ff verder wat onderzoek doen voor m'n werk...

Dat noemen ze vakidioot/workaholic (streep door wat niet van toepassing is )

[whoami]

Ik denk dat ik morgen deze link eens ga doornemen.

[whoami]

Ik heb trouwens zo'n donkerbruin vermoeden dat de enige optie zal zijn om m'n subscribers van m'n publication te halen, m'n publication opnieuw te initializeren of whatever, en dan m'n subscribers opnieuw aan te maken..... Hopelijk is er een andere optie...

[whoami]

Het ziet er naar uit dat ik 2 opties heb.
Ik zal eerst ff de situatie schetsen:

Ik heb dus 3 locaties waar m'n databank komt te staan. Deze databases moeten synchroon gehouden worden.
Veranderingen aan de data kunnen normaal gezien enkel gebeuren via core components die we geschreven hebben, en die core-components worden via .NET remoting gehost in IIS.
De applicaties die access hebben tot deze databank, zullen dus normaal gezien via deze core components (via IIS dus) toegang verkrijgen tot de DB.

Optie 1 om database-structuur wijzigingen door te voeren:
- de database-wijzigigen doorvoeren dmv system stored procedures. Deze SP's laten het toe om een tabel-strcutuur te veranderen van een database die onder replicatie staat, en deze zou er ook moeten voor zorgen dat de structuurwijzigingen doorgevoerd worden naar de andere sites.

Optie 2:
- Een procedure maken die ervoor zorgt dat de DB - patches op alle 3 de sites automatisch doorgevoerd worden, en dat op een velige manier: daarvoor zullen de DB's eerst uit replicatie moeten gehaald worden, IIS zal op de 3 sites moeten gestopt worden, de DB patches op de 3 sites laten uitvoeren, replicatie opnieuw opzetten en IIS opnieuw starten.

Beide opties hebben zo wel hun nadelen:
Optie 1 is vrijwel onbruikbaar aangezien we structuurwijzigingen aan de DB doen via scripts. Deze scripts schrijven we niet zelf, maar laten we genereren door een vergelijking te maken van de oude versie van de DB en de nieuwe versie. (We gebruiken Visio voor het DB model bij te houden, en RedGate SQL Bundle om 2 db's te vergelijken).
Deze scripts die gegenereerd worden, zijn 'gewone' scripts die gewone ALTER TABLE statements etc... bevatten.
Het is ook niet altijd noodzakelijk dat een script toegepast wordt op een DB die onder replicatie staat. (Bv, een DB op een development WS / Server).

Optie 2 kan gevaarlijk zijn, wat als er toch iemand op een of andere manier een wijziging kan doen aan de data terwijl de replicatie offline is. Het is geen goed idee om iedere keer dat er een DB patch toegepast wordt, de initiele snapshot opnieuw te laten genereren en te propageren naar de andere sites. De DB zal, eens hij in productie gaat, ongeveer 4 GB aan data bevatten, en het is niet werkbaar om de databases opnieuw van 0 te synchronizeren iedere keer dat er een DB patch toegepast wordt.

Weet iemand of er nog andere opties zijn, of een manier om optie 2 veiliger te maken ?

[whoami]

*kick*

[Verwijderd]

Er zijn stored procedures in SQL Server die daar voor zorgen

Probeer dit is: sp_repladdcolumn

Kijk maar ff in de help voor uitleg hier over.

[whoami]

Verwijderd schreef op zaterdag 08 januari 2005 @ 11:23:
Er zijn stored procedures in SQL Server die daar voor zorgen

Probeer dit is: sp_repladdcolumn

Kijk maar ff in de help voor uitleg hier over.

Als je mijn vorige post gelezen hebt, zou je gezien hebben dat ik dat wel al wist, maar dat dit niet echt een optie is in mijn geval.

[Verwijderd]

Sorry,

kun je dan zelf niet iets maken, dat de gegenereerde scripts omschrijft?

Verder kun je op je dev. server toch aangeven dat structuur wijzigingen niet doorgevoerd mogen worden?