[SQL Server 2005] Replicatie

[Verwijderd]

Ik zit met de volgende situatie: ik heb een centrale server en verschillende losstaande computers. Op deze losstaande pc's draait SQL Server 2005 en op de centrale server ook. De applicatie op deze losstaande PC moet ook kunnen draaien wanneer de database verbinding naar de centrale danwel lokale server wegvalt.

In de ideale situatie worden alle cliënten ten alle tijde voorzien van de laatste informatie van de centrale server. Bij wijzigingen op 1 client worden de wijzigingen doorgestuurd naar de centrale server. Deze server relayed de wijzingen vervolgens weer naar alle andere cliënten.

Uiteraard is hier een softwareoplossing voor de bedenken welke dit ondervangt. Echter heb ik begrepen dat dit ook te ondervangen met SQL Server merge replication. Ik heb hier zelf geen ervaring mee en heb hierbij nog een aantal vraagtekens. Ik hoop dan ook dat er mede-tweakers zijn die er wel ervaring mee hebben en deze ook willen delen .

VRAAG 1:
- Om te repliceren is men een duurdere SQL Server licentie nodig? Is deze licentie enkel benodigd op de centrale server of ook op alle cliënten? Als ik voor iedere cliënt 25k$ neer moet leggen dan is deze hele optie niet interessant . Het betreft natuurlijk wel two-way replicatie dus zou ikzelf vermoeden dat de duurdere licentie op zowel de centrale server als cliënten aanwezig moet zijn.

VRAAG 2:
Omdat alle cliënten onafhankelijk van elkaar data in hun lokale database schieten houden ze dus geen rekening met hun primary keys. Wat gebeurt wanneer er bij het replicatieproces twee rijen (afkomstig van twee verschillende cliënten) bij elkaar komen met dezelfde primary key? Worden beide rijen verworpen? Wordt de primary van een van de rijen veranderd (uiteraard zouden dan alle PK's en relevante FK's op de cliënt ook moeten worden hernummerd). Voeg hierbij een internetverbinding toe die niet altijd beschikbaar zal zijn en ik vraag me af in hoe verre me dit problemen op zou leveren . Iemand ideeën of ervaringen hiermee?

[whoami]

Om op vraag2 te beantwoorden: lees eens de Books Online mbt de replication problematiek. Als je dat doet, zal je zien dat je replication werkt met een ROWGUIDCOL om een record te identificeren.

Microsoft® SQL Server™ 2000 identifies a unique column for each row in the table being replicated. This allows the row to be identified uniquely across multiple copies of the table. If the table already contains a column with the ROWGUIDCOL property that has a unique index or primary key constraint, SQL Server will use that column automatically as the row identifier for the publishing table.

Otherwise, SQL Server adds a uniqueidentifier column, titled rowguid, which has the ROWGUIDCOL property and an index, to the publishing table. Adding the rowguid column increases the size the publishing table. The rowguid column and the index are added to the publishing table the first time the Snapshot Agent executes for the publication.

Wat je kan doen om het probleem mbt dubbele PK's op te lossen is:
zorgen dat je PK een GUID is (wat niet handig is als je PK een clustered index is, tenzij je een 'sequentiele GUID' gebruikt, waarvan ik dacht dat SQL Server 2005 dat ondersteund.

[Verwijderd]

Oke, feitelijk gezien hoef ik me dus geen zorgen te maken dat de replicatie in het honderd loopt? Ik kan dus vanaf 3 cliënten dezelfde rij repliceren naar de centrale server en vervolgens vanaf een cliënt deze 3 rijen queryen op de server en 3 verschillende rijen ophalen zonder PK-problemen? Heb ik dat goed begrepen?

Verder heb ik ook nog een derde vraag bedacht .

VRAAG 3:
Hoe schaalbaar is het replicatiesysteem achter SQL Server 2005? Kan ik in alle rust 1500 cliënten los laten beuken op één centrale server zonder dat ik replicatieproblemen krijg? (Er van uitgaande dat de hardware van de server dit allemaal prima vind )

[whoami]

Verwijderd schreef op vrijdag 08 juni 2007 @ 11:03:
Oke, feitelijk gezien hoef ik me dus geen zorgen te maken dat de replicatie in het honderd loopt? Ik kan dus vanaf 3 cliënten dezelfde rij repliceren naar de centrale server en vervolgens vanaf een cliënt deze 3 rijen queryen op de server en 3 verschillende rijen ophalen zonder PK-problemen? Heb ik dat goed begrepen?

Je kan altijd conflicten hebben natuurlijk; het kan zijn dat op de 3 sites hetzelfde record aangepast wordt, en dat de conflict-resolver niet weet welke wijziging nu uiteindelijk de goede is.
Ik heb hier een SP'tje geschreven die geregeld automatisch uitgevoerd wordt, en checkt of er dergelijke conflicten zijn; en zoja, dan krijg ik een mailtje.

VRAAG 3:
Hoe schaalbaar is het replicatiesysteem achter SQL Server 2005? Kan ik in alle rust 1500 cliënten los laten beuken op één centrale server zonder dat ik replicatieproblemen krijg? (Er van uitgaande dat de hardware van de server dit allemaal prima vind )

Ik heb geen ervaring met dergelijke aantallen (ik heb 3 servers die in merge replicatie staan), maar ik vraag me toch echt af of merge replication de oplossing is voor hetgeen jij wilt bereiken.
Ik bedoel: hoe vaak gaat het voorkomen dat je centrale server niet beschikbaar is ?
Waar staan die 1500 clients ? Allemaal op dezelfde site, op verschillende sites ?

[Verwijderd]

whoami schreef op vrijdag 08 juni 2007 @ 11:22:
[...]
Je kan altijd conflicten hebben natuurlijk; het kan zijn dat op de 3 sites hetzelfde record aangepast wordt, en dat de conflict-resolver niet weet welke wijziging nu uiteindelijk de goede is.
Ik heb hier een SP'tje geschreven die geregeld automatisch uitgevoerd wordt, en checkt of er dergelijke conflicten zijn; en zoja, dan krijg ik een mailtje.

Je hebt zeker geen interesse om deze SP te delen? .

whoami schreef op vrijdag 08 juni 2007 @ 11:22:
[...]
Ik heb geen ervaring met dergelijke aantallen (ik heb 3 servers die in merge replicatie staan), maar ik vraag me toch echt af of merge replication de oplossing is voor hetgeen jij wilt bereiken.
Ik bedoel: hoe vaak gaat het voorkomen dat je centrale server niet beschikbaar is ?
Waar staan die 1500 clients ? Allemaal op dezelfde site, op verschillende sites ?

De 1500 cliënts staan door heel Nederland. Het wegvallen van de centrale server zal niet al te vaak voorkomen (afhankelijk van de internetverbinding die aanwezig is). De cliënts halen hun informatie voornamelijk lokaal weg. Ik ben met je eens dat merge replication wellicht niet de oplossing is voor mijn probleem. Het werd me echter aangedragen en ik wil toch graag alle opties bekijken voordat ik een gigantisch ingewikkeld systeem ga ontwikkelen en dat het later blijkt dat het niet nodig was geweest. Heb ik dan voor niets al mijn haren uit mijn kop getrokken .

[whoami]

Is het niet beter dat je een klein aantal verschillende servers hebt , die onder merge replication staan, en dat je clients naar één van deze 3 servers connecteren (niet allemaal op dezelfde).
Als er één server wegvalt, kan je dan naar een andere laten connecteren.