[MS-SQL2000] replication db-schema vraag

Pagina: 1
Acties:

  • cavey
  • Registratie: Augustus 2000
  • Laatst online: 17-02 19:31
[aargh, topic titel is onjuist. Niet MySQL maar MS-SQL 2000 ... foutje! kan iemand dit aanpassen? En er klopt wel meer niet lees ik net in het over topictitels in P&W draadje. ... * cavey is noob ;) ]

Hoi!

In mijn eerdere zoektochten over replication ben ik het nog niet echt tegen gekomen.

Mijn vraag is eigenlijk vrij simpel, maar kan zo 1 2 3 niet bedenken hoe ik die vraag makkelijk om kan zetten naar nuttige queries in google of de BOL.


Moet de database schema aan de subscriber kant precies hetzelfde zijn als aan de publisher kant? Inclusief rowguidcol kolom....

Op het moment zijn ze niet geheel gelijk merk ik. Ja ja, voor mensen open deuren in trappen, laat mij die even dicht doen door wat uitleg te geven over m'n gevolgde stappen.

1) De te repliceren database heb ik omgezet naar scripts, echter voor ik er een publicatie + snapshot van heb gemaakt.
2) De publicatie opgezet
3) De server voor aan de andere kant van de wereld (ja serieus) opgezet met de gescripte database files
4) Erachter komen dat de snapshots niet goed gemaakt zijn en dat er daardoor geen rowguidcol aanwezig was in de tabellen op de publicatie database. Snapshot gedraaid dus en de tabellen werden automagically aangepast
5) De subscriber laten initialiseren, snapshot via ftp over het vpn binnen laten halen ...... maar nu komt het: Error. De tabel bevat geen "rowguidcol".

Ofwel, de data is nog niet overgezet.

Mijn vraag is nu:

MOET de subscriber kant OOK de rowguidcol hebben? Zo ja, dan houdt dat dus in dat ik eerst de publicatie had moeten aanmaken inclusief snapshot...... en DAN pas de gehele database moest scripten voor ik deze aanmaakte aan de subscriber kant.

Goed, vrij simpele vraag met hopelijk het simpele antwoord van "Ja, je bent een dom rund geweest en je had eerst de publicatie moeten aanmaken voor je de boel ging scripten en overzetten". Maar ik kon het niet zo 1 2 3 vinden, dus wend ik mij tot jullie.

[ Voor 8% gewijzigd door cavey op 09-03-2004 09:26 . Reden: titel klopt niet... ]


  • zneek
  • Registratie: Augustus 2001
  • Laatst online: 08-02-2025
Je hebt gelijk. Tenminste, als je het over merge replicatie hebt. Daarnaast bevat een merge replicatie database veel meer dan alleen een rowguidcol. Kijk in je publication database maar eens naar je sp's (system objects weergeven!). Daarnaast zijn alle gerepliceerde articles voorzien van de nodige triggers.

Een snapshot subscriptie kan zonder veel van dit spul, maar een merge replicatie kun je eigenlijk alleen opzetten door eerst volledig je publicatie database te configuren. Daarna pas je subscriptie database initialiseren, op basis van je publicatie database. Ik doe er altijd een stap tussen, als het om bestaande databases gaat, om controle over de IDENT kolommen te houden. Ik moet nog eens uitzoeken hoe ik SQL Server dat zelf kan laten regelen. Voor nieuwe databases is daar een voorziening voor (ident per location) maar voor bestaande niet geloof ik.

  • cavey
  • Registratie: Augustus 2000
  • Laatst online: 17-02 19:31
Het gaat idd om een merge replicatie, foutje.

Ahja, die IDENT ranges heb ik al ingesteld, dan moet je alle tabellen die je wilt repliceren even na lopen en de ID columns zetten op "YES (NOT FOR REPLICATION)". Dan kan je bij het aanmaken van je publicatie ranges instellen zodat ze niet aan beide kanten in de war gaan lopen. (Publication properties -> Articles -> "range tabje" als je op dat ... blokje klikt voor de arcticle properties).

Nu wilde ik eigenlijk de boel via scripts opzetten, omdat alle tabellen wel nodig zijn aan beide kanten, maar niet alle tabellen moeten gemerged worden. Maar moet ik nu ook alle sp's en dergelijke opnieuw gaan scripten? Probably dat MS-SQL dat dan automagisch doet?

Ik heb iig de tabellen opnieuw laten scripten, inclusief alle indexes, triggers, rechten etc. De views, sp's etc nog niet... maar dat zou niet zo'n punt meer moeten zijn als dat de enige "aanpassingen" zijn (user defined functions, user defined datatypes, user defined defaults en views zullen vast geen rare replication dingen nodig hebben).

Naja, ik heb nu problemen dat ik m'n snapshot niet via ftp op de database kan krijgen, en een RDP sessie naar de machine in Manila wil ook niet echt vlotten. Die vraag heb ik gelukkig even door kunnen spelen naar systeem beheer.


[toevoeging]
De pest is ook, dat MS-SQL pas al die rowguidcol en sp's heeft toegevoegd NA het succesvol maken van een snapshot ......

[ Voor 8% gewijzigd door cavey op 09-03-2004 12:33 ]


  • zneek
  • Registratie: Augustus 2001
  • Laatst online: 08-02-2025
ik heb het laatst als volgt gedaan:

1. Creeer de publicatie
2. SQL Server creeert alle meuk nodig voor merge replicatie (sp's, triggers enz.)
3. Publicatie eraf gehaald (alle merge meuk blijft bestaan)
4. Middels "Export data" de hele db overgezet naar subscription server
5. Op publicatie en subscriptie server id ranges goed gezet (dmv identity seed en inc)
6. Publicatie en Push Subscription gemaakt (Subscription db exists en has all data).
7. Go Go Go

(Altans, zo meen ik het me te herinneren :) )

Zal wel niet helemaal volgens de regels zijn, maar het werkt. Ik moest ook eigenlijk wel zo, omdat bijv ordernummers een specifieke range moeten hebben, en er al 100.000+ orders in de db aanwezig waren.

  • cavey
  • Registratie: Augustus 2000
  • Laatst online: 17-02 19:31
Hehe

Is ook een manier. Ik keek net in de server logs en het toepassen van de snapshot leek zowaar gelukt, echter, er staat geen data in de subscription database. Niet echt fijn.

Probeer het nu nog een keer, maar deze keer geen compressed snapshot. Om de 3 uur draait de merge agent, maar iedere keer no data to merge, terwijl de database toch echt leeg is en toch echt wel gevuld moet worden.

Maar goed, ik ga hier wel voor google'n straks. Een dik handig boekwerk over replicatie zou nu wel heel erg goed uitkomen ...

  • Peetman
  • Registratie: Oktober 2001
  • Laatst online: 27-05 15:27

Peetman

Tjah....

In de books online by SQL server staat de replicatie zeer uitvoerig beschreven.

  • cavey
  • Registratie: Augustus 2000
  • Laatst online: 17-02 19:31
Daar ben ik me van bewust.

De vragen die ik er over heb worden echter niet duidelijk behandeld in de BOL.

Maar ik ben er nu wel achter dat m'n subscription de snapshot data niet heeft overgenomen omdat ik had aangegeven dat de subscription database alle schema's en data al bevatte (mede uitgevogeld met dank aan de BOL inderdaad, over wat die optie nou preciezer deed).

Probleem alleen is nu, dat de snapshot slechts 75% van de database is, alle overige tabellen bevatten wel data, maar hoeven niet gemerged te worden.

Nu zoek ik alleen nog naar een handige manier om alle data over te zetten. DTS lijkt een optie, maar wat ik net geprobeerd heb klopte niet helemaal.

  • cavey
  • Registratie: Augustus 2000
  • Laatst online: 17-02 19:31
@Zneek

Tnx! Ik doe het nu bijna op dezelfde manier als dat jij het doet ...

1) Publicatie maken + snapshot
2) De hele boel scripten
3) De scripts uitvoeren op de subscriber kant
4) met DTS Export Wizard een package gemaakt, die de inhoud van alle tabellen overbliept naar de subscriber
5) Subsrciption aanmaken
6) SQL2000 replication, good to go!

  • zneek
  • Registratie: Augustus 2001
  • Laatst online: 08-02-2025
Mooi zo! :)

Ik blijf het echter vaag vinden. De keren dat ik probeerde documentatie te volgen had ik ook wat problemen. Onder SQL Server 7 al en nu dus nog.

Nah ja, als het maar werkt :)
Pagina: 1