Replikation auf einem Microsoft SQLServer 2000

Transkript

1 Replikation auf einem Microsoft SQLServer 2000 Johann Murauer, 6.September 2004 (Private technische Notiz ohne irgendwelche Gewährleistung, Support etc. es wird die Einrichtung einer Replikation für eine Datenbank beschrieben. Die DB selbst dient nur als Beispiel ihr interner Aufbau und ihr Zweck ist hierfür ohne Bedeutung ) Diese Replikation unterscheidet sich wesentlich von einer Oracle-Replikation. Neben all den verschiedenen Einstellungen ist folgender Unterschied der wichtigste: Während bei Oracle an jedem Standort eine (leerer) Datenbankinhalt (Tabellen, Views, etc.) eingerichtet werden muss, um sie dann in die Replikation aufnehmen zu können ist dies beim SQL-Server nicht zulässig! Beim SQL-Server richtet der Replikationsmechanismus die sekundären Datenbankeninhalte ein. In diesem Dokument wird eine von vielen Möglichkeiten gezeigt, wie man eine Replikation aufsetzt. Eine Vielzahl anderen Möglichkeiten und Replikationsverfahren existieren noch zusätzlich. Hinweis: zum Einrichten / Löschen von Tabellen gibt es das Tool CreateTables.exe. Dieses Tool kann aber nicht arbeiten, wenn die betreffende Datenbank eine aktive Publikation ist (also: nicht verwirren lassen). Grundlegende Vorgangsweise: Auf jedem Server mit Microsoft-Tools eine leere Datenbank erzeugen (z.b. Enterprise Manager) Eine bestimmten Server auswählen, der zum Master (Publisher) gemacht werden soll Auf diesem Server die LanCrypt-Daten (Tabellen, Views, etc. erzeugen) mittels CreateTables oder der Applikation Mit den Replikationstools diese Datenbank als Publikation wählen. Hierbei ist zu beachten: neben Tabellen müssen auch Views repliziert werden und die Nummerverwaltung ist durch den SQLServer durchzuführen! Alle Abonnenten der Publikation einrichten (um gleich hier Fehlinterpretationen vorzubeugen: Abonnenten können bei entsprechender Konfiguration Publikationen verändern der Datenaustausch funktioniert also in beiden Richtungen). Hinweis: die Einrichtung der Replikation geschieht mit dem Enterprise Manager. Wenn man diesen auf dem Publisher laufen lässt und dann auch die Abonnentenserver einbindet, sollte eigentlich alles möglich sein. Ich hatte aber mitunter Probleme mit den Abonnentenrechnern. Dies kann darauf zurückzuführen sein, dass meine Server sich nicht in einer gemeinsamen Domäne befinden und daher eventuell ein paar Rechte fehlen. In solchen Fällen habe ich einfach zu den betreffenden Abonnentenrechner gewechselt und ich konnte dort die Arbeiten jedes Mal ohne Probleme durchführen. Seite 1 von 16

2 Das Einrichten einer neuen Publikation Die Datenbank und alle ihre Tabellen, Views etc. müssen exitieren. Unter Replication / Publication wählt man New... aus. Darauf erscheint ein Wizard. Hier ist es wichtig, dass man Show advanced options... auswählt. Wir wählen die zu replizierende Datenbank aus, hier LC310EC Seite 2 von 16

3 Welche Typ der Replikation man auswählt, hängt vom Anwendungsfall ab. Wir entscheiden uns einmal für die Transactional publication. Ich habe auch mit Merged Publications ohne Probleme gearbeitet. Die Auswahl ist dem Endanwender überlassen wichtig ist aber, dass der Abonnent den Publisherinhalt verändern kann und dass der Publisher die Nummernverwaltung übernimmt. Im nächsten Dialog ist es wichtig, dass man zumindest ein Updateverfahren auswählt. Seite 3 von 16

4 Nach einem Zwischenschritt kommen wir zu dieser Dialogbox. Diese Einstellungen sind ganz wichtig! Es müssen sowohl Tables als auch Views ausgewählt werden. Sollten wir eine eigene Datenbank nur für LanCrypt haben (wie hier), dann können wir Publish All anwählen, ansonsten sollten wir nur jene Tabellen und Views auswählen, die zu LanCrypt gehören. Jetzt noch nicht Next drücken sondern noch diese wichtige Konfiguration vornehmen. Seite 4 von 16

5 Für jede Tabelle ist folgendes zu tun. Ein Doppelclick führt zu: Seite 5 von 16

6 Hier haben wir die Möglichkeit, bei den Abonnenten Tabellen zu zerstören (!!!!): Diese Einstellung ist ein großes Problem: Wegen der Replikation müssen die Tabellen verändert werden. Würde man Keep the existing table unchanged und die Tabelle wäre vorn einer früheren Installation ohne Replikation würden die Änderungen nicht durchgeführt werden und die Replikation würde nicht funktionieren. Alle anderen Einstellungen zustören Daten. Man müsste also alte Daten in temporäre Tabelle sichern und sie dann in der replizierten Tabelle integrieren und dabei die referentielle Integrität gewährleisten. Gehen wir nun zur Seite Identity Range. Wir wählen die automatische Zuweisung von Nummern an und legen die Range-Größen fest (100 als Default ist sicher sehr knapp bemessen, ich würde eher vorschlagen). Seite 6 von 16

7 Anmerkung: anscheinend hat der SQL Server manchmal Probleme mit der automatischen Nummerbereichsvergabe. In diesem Fall muss man bei den Abonnenten (Tabellen) manuell korrigieren. Diese Probleme scheinen eher bei einer Transactional Replication (und weniger bei einer Merge Replication) aufzutreten. Man beachte, dass bei den IDENTITY Spalten unbedingt Not for replication verwendet wird und dass auch der Constraint stimmt. Was hat es mit Not for replication auf sich? Eine Tabelle eines Standortes besitzt ihren eigenen Nummernbereich. Nur Sätze aus diesem Bereich können eingefügt werden Sätze mit anderen Nummern werden abgewiesen. Nun wird es aber vorkommen (Replikation!), dass Sätze aus anderen Tabellen mit anderen Nummerbereichen eingefügt werden sollen. Wenn dies mit Mechanismen der Replikation geschieht, dann werden Sätze mit fremden Nummern nicht abgewiesen. In der Folge kommen wir nun zu dieser Dialogbox, die sehr interessant ist. Wir sehen, wie die Tabellen verändert werden: es werden GUID-Spalten hinzugefügt und IDENTITY Spalten erhalten ein weiteres Attribut. Seite 7 von 16

8 Wir können den Namen der Publikation ändern (was ich hier nicht mache). In der nächsten Dialogbox entscheide ich mich für den ersten Punkt. Seite 8 von 16

9 Und ich erlaube der Einfachheit halber eine anonyme Subskription. Wir können noch einen Zeitplan für die Durchführung der Replikation definieren: Seite 9 von 16

10 Noch ein paar Clicks und etwas Geduld und fertig ist die Publikation. Seite 10 von 16

11 Man könnte nun die Subscriptions auch an dieser Stelle (Publication Properties -...) erstellen. Allerdings hatte ich damit manchmal seltsame Probleme. Daher wechseln wir im Enterprise Manager zu einem Server, der Abonnent werden soll und macht es von dort aus. Das Einrichten einer neuen Subskription Die Datenbank soll bereits existieren aber ohne LanCrypt-Tabellen etc. Unter Replication Subscriptions wählen wir New Pull Subcription. Auch hier wollen wir die Advanced Options sehen. Seite 11 von 16

12 Natürlich wählen wir die eben erst erstellte Publikation aus. Wir werden gefragt, in welche Datenbank wir die Subcription übernehmen wollen. Wir entscheiden uns für die eigenen (an dieser Stelle könnten wir auch eine DB erstellen!). Seite 12 von 16

13 Nun suchen wir uns einen Update-Mechanismus aus. Und wir lassen uns alle DB-Objekte erzeugen. Seite 13 von 16

14 Wieder hätten wir die Möglichkeit einen Zeitplan festzulegen (oder kontinierlich zu arbeiten). Noch ein paar Clicks, etwas Geduld und fertig ist die Sache. Seite 14 von 16

15 Ab nun kann mit der LanCrypt - Administration gearbeitet werden. Problembehandlung Hinweis: Manchmal zeigt der Enterprise Manager ein erstaunliches Update-Verhalten. Wenn also bestimmte Dinge angezeigt werden sollten und sich der Status aber nicht ändert, dann bitte mit F5 und Refresh herumspielen das hilft oft. Im Fall von Problemen hat sich gezeigt, dass manchmal ein Service nicht läuft. Dies kontrolliert man am einfachsten über die Properties (so wie man es unten sieht, wird es nicht gehen Status: Unknown): Seite 15 von 16

16 Das ist (zumindest in meiner Testumgebung) ein typisches Problem, welches auftritt, wenn der Enterprise Manager auf einem anderen Rechner läuft als der SQLServer (dürfte ein Rechte-Problem sein). Seite 16 von 16