| |
| |
|
|
| |
|
Merge Replikation (Teil 2)
Im
ersten Teil dieses Artikels zur Replikation mit dem Microsoft SQL
Server 2000 wurde die Transaktionale Replikation vorgestellt. Bei
diesem Verfahren werden erfolgreich abgeschlossene Transaktionen einer
zentralen Datenbank (Publisher) in den Replikaten (Abonnenten)
rekonstruiert. Einsatzschwerpunkt dieser Technik ist die Verteilung der
Leselast auf mehrere Server, das Bereitstellen und regelmäßige
Aktualisieren einer Datenbankkopie über eine langsame
Kommunikationsverbindung ohne immer die ganze Datenbank kopieren zu
müssen oder Standby-Lösungen um Störfälle aufzufangen.
Allerdings
werden mit der Transaktionalen Replikation die Daten nur für Lesezwecke
bereitgestellt. Dies sichert zwar die Transaktionskonsistenz, aber
einige Anwendungsfälle können damit nicht realisiert werden. Dazu
gehören etwa. „mobile Datenbanken" auf Notebooks von
Außendienstmitarbeitern oder Datenbanken in Niederlassungen, deren
regelmäßiger Abgleich mit einer Zentrale beziehungsweise untereinander
erfolgen muß.
Zwar bietet der SQL Server mit der Variante der
Transaktionalen Replikation mit aktualisierbaren Abonnenten eine
Technik, um Änderungen auch in den Replikaten durchzuführen, allerdings
sind dabei stabile und schnelle Kommunikationsverbindungen notwendig,
da die Datenänderungen über ein Zweiphasen-Synchronisationsprotokoll
über den Distributed Transaction Coordinator laufen.
Inhalt:
1. Merge Replikation
2. Mergereplikation beim SQL Server
a. Funktionsweise der Mergereplikation beim SQL Server
b. Konflikterkennung und Auflösung (Reconcilation)
c. Komponenten der Merge Replikation
d. Mögliche Topologien 3. Bewertung der Merge Replikation 4. Fallbeispiel „Merge-Replikation"
1. Merge Replikation
Ziel
der Merge Replikation ist die Bereitstellung von Datenbankreplikaten,
die ein autonomes Arbeiten ohne Einschränkung der Funktionalität
(Datenänderungen) und unabhängig von der Verfügbarkeit von
Kommunikationsverbindungen ermöglicht.
Der Preis dafür ist aber
der Verlust der Datenkonsistenz, da eine Änderung des gleichen
Datensatzes zwischen zwei Synchronisationsvorgängen möglich ist. Man
spricht dann von einem Repikationskonflikt, dessen Auflösung notwendig
wird.
Diesem Sachverhalt muss beim Anwendungsdesign Rechnung
getragen werden. Dafür gibt es zwei Ansätze: Konfliktvermeidung durch
Partitionierung Implementierung von KonfliktauflösungsverfahrenBei der
Partitionierung sind Änderungen eines Datensatzes nur in der Datenbank
möglich, in der er erzeugt wurde. Dadurch bleibt auch die
Transaktionskonsistenz erhalten. Viele Anwendungsfälle können durch
diese Strategie gut abgebildet werden: Beispielsweise ein Auftrag in
einem Auftragsabwicklungssystem, dessen Änderung nur vom zuständigen
Kundenbetreuer beziehungsweise der zuständigen Niederlassung zulässig
ist. Allerdings kann bei übergreifenden Geschäftsprozessen die
Konfliktvermeidung sehr komplex werden. Sind Konflikte zulässig, so
kommt es zwangsläufig zu so genannten „Lost Updates" und anderen
Anomalien.
Die Merge Replikation führt Änderungen periodisch
zusammen. Dadurch konvergiert der Datenbestand zu einem uniformen
Zustand. Da die Synchronisation immer paarweise zwischen zwei
Datenbanken erfolgt, wird in Szenarien mit vielen Datenbanken dieser
uniforme Datenbestand unter Umständen nie erreicht.
2. Mergereplikation beim SQL Server
a. Funktionsweise der Mergereplikation beim SQL Server
Die
Merge-Replikation basiert auf Trigger, die Änderungen an Datensätzen
protokollieren und einem Synchronisationsvorgang, der die Änderungen
aufgrund dieses Protokolls paarweise zwischen zwei Datenbanken
zusammenführt.
Um Datensätze eindeutig identifizieren zu können
werden so genannte Row Global Unique Identifiers (ROWGUID) benötigt.
Diese basieren auf einem speziellen SQL-Server Datentyp namens
UNIQUEIDENTIFIER. Die Systemfunktion NEWID generiert solche Werte mit
Hilfe der eindeutigen Netzwerkkarten-Identifikation (NIC-Adresse) und
der Systemuhr. Normale Zählerfelder (Identity Columns) sind hierfür
nicht geeignet, da die Eindeutigkeit nicht gewährleistet werden kann
(paralleles Hochzählen, Identity-INSERTS).
Soll eine bestehende
Datenbank replikationsfähig gemacht werden, so ist es nicht zwingend
notwendig, bestehende Primärschlüsselfelder durch UNIQUEIDENTIFIERS zu
ersetzen. Es reicht, wenn eine solche Spalte hinzugefügt und als Row
Global Unique Identifier markiert wird. Autoinkrement- Schlüsselfelder
(Zählerfelder, Identity Columns) in der Replikation werden seit SQL
Server 2000 durch Definition von Identitätsbereichen (Identity Ranges)
unterstützt. Dabei kann pro Replikat ein Bereich für Zählerwerte und
ein Schwellwert für die automatische Bereitstellung eines neuen
Bereichs definiert werden.
Jede replizierte Tabelle verfügt über
drei Systemtrigger für jeweils eine der Operationen INSERT, UPDATE und
DELETE. Darüber werden Änderungsoperationen erkannt und die Row Global
Unique Identifiers der betroffenen Datensätze in Systemtabellen
protokolliert.
Abb. 1: Änderungsverfolgung durch Systemobjekte
In
der Tabelle MS merge_contents stehen die Row Global Unique Identifiers
der neu eingefügten und geänderten Datensätze. MSmerge_tombstone
(Tombstone = Grabstein) enthält die entsprechenden Werte von gelöschten
Datensätze.
Der Synchronisationsprozess selbst ist zum Großteil in
Form von Systemprozeduren realisiert. Das Kernprinzip dabei ist simpel:
es werden paarweise die Inhalte der beiden Systemtabellen verglichen
und Differenzen zeigen zu replizierende Daten an.
Die Merge
Replikation unterstützt auch eine Filterung der replizierten Daten.
Dabei kann sowohl eine vertikale (Ausblenden von Spalten) als auch eine
horizontale Filterung (Ausblenden von Datensätzen) erfolgen. Die
horizontale Filterung kann statisch in Form einer hart codierten
Bedingung implementiert werden. Bei einer dynamischen Filterung
wird
das Filterkriterium während des Synchronisationsvorgangs ermittelt.
Dabei können alle skalaren Systemfunktionen wie etwa der Servername
oder der Benutzername aber auch skalare benutzerdefinierte Funktionen
verwendet werden. Implementiert werden diese Filter in Form von
Systemsichten pro replizierter Tabelle.
Die Realisierung der Merge
Replikation über Transact SQL Systemobjekte kann sowohl als Nachteil
als auch als Vorteil gesehen werden: nachteilig ist sicherlich das
Performanceverhalten, von Vorteil die Möglichkeit, interne Abläufe im
Problemfall mit Hilfe des Profilers genauer zu analysieren.
b. Konflikterkennung und Auflösung (Reconcilation)
Die
Konflikterkennung erfolgt über einen Prüfsummenvergleich im Rahmen des
Synchronisationsvorgangs. Dabei stehen die Methoden Konflikterkennung
auf Zeilenebene und Konflikterkennung auf Spaltenebene zur Verfügung.
Die
zweite Variante ist die flexiblere, da hier nur dann ein Konflikt
auftritt, wenn im gleichen Datensatz das gleiche Feld geändert wurde.
Allerdings erfordert die Konflikterkennung auf Spaltenebene einen
höheren Kommunikationsaufwand, da zusätzliche Informationen benötigt
werden und ist deshalb etwas langsamer. Die Konfliktauflösung auf
Zeilenebene transferiert 281 Bytes pro abzugleichenden Datensatz
während die Konfliktauflösung auf Spaltenebene hierfür 2.048 Bytes
benötigt. Man sollte sich bei der Entscheidung von der Anwendungslogik
und nicht zu von der Performance leiten lassen. Beispielweise führen
die meisten Anwendungen bei einer Feldänderung Blindupdates auf den
gesamten Datensatz durch. Es werden also alle Felder aus einer Maske
beim Update geschrieben, auch wenn nur eines geändert wurde. Hier macht
dann eine Konflikterkennung auf Spaltenebene wenig Sinn.
Wird ein
Konflikt erkannt, so muss einer der beiden Datensätze (Looser)
verworfen werden. Die Entscheidung kann anhand eines der von Microsoft
vorimplementierten Verfahren erfolgen.
Hier eine Auswahl möglicher
vorimplementierter Verfahren:Prioritätenverfahren. Dabei gewinnt die
Datenbank mit der höheren Priorität. Verleger gewinnt immer Abonnent
gewinnt immer Uhrzeitgesteuerte Verfahren. Dabei gewinnt der ältere
oder jüngere Datensatz Spaltenprioritätsverfahren. Damit können
Änderungen an wichtigeren Spalten gewinnen. Interaktive Verfahren. Die
Konfliktauflösung erfolgt manuell.Unterstützt werden auch
selbstimplementierte Verfahren. Die Programmierung kann mit Transact
SQL oder in Form von COM-Objekten erfolgen, wobei erstere einfacher zu
implementieren aber nicht ganz so perforrmant sind.
Der durch die
Konfliktauflösung ausgewählte „Looser" wird nicht vollständig aus der
Datenbank gelöscht sondern in eine so genannte Konflikttabelle
geschrieben. Jede replizierte Tabelle verfügt in der Verlegerdatenbank
über eine solche Tabelle. Man erkennt diese Tabellen am Prefix
„conflict_".
c. Komponenten der Merge Replikation
Hauptkomponente
der Merge Replikation ist die Publikation am Verleger. Diese definiert,
was und wie repliziert wird. Eine Publikation besteht aus einem oder
mehreren so genannter Artikel. Dabei handelt es sich um Tabellen, die
optional horizontal oder vertikal gefiltert werden können, Sichten
(Views) oder Prozeduren.
Allerdings werden Sichten und Prozeduren nur während der Erstsynchronisation übertragen, Änderungen muss man manuell einspielen.
Beim
Erstellen der Publikation generiert der SQL Server automatisch die
notwendigen Systemobjekte am Verleger. Gleichzeitig wird ein Snapshot
der Datenbank erzeugt und in einem Verzeichnis abgelegt
(Snapshotfolder). Das Snapshot enthält die Struktur der Datenbank, die
in den replizierten Tabellen enthaltenen Daten sowie die am Abonnenten
benötigten Systemobjekte. Mit Hilfe des Snapshots werden später die
Abonnenten erzeugt.
Abb. 2: Komponenten der Merge-Replikation
Zur
Durchführung der Synchronisation wird der so genannte Merge Agent
benötigt. Dieser leitet Änderungen weiter und führt sie mit der
Abonnentendatenbank zusammen. Bei der Erstsynchronisation kann er
überdies das Snapshot in der Abonnentendatenbank einspielen.
Der Start des Merge Agenten kann durch den SQL Server Agent zeitgesteuert erfolgen.
Die
Synchronisation wird immer paarweise zwischen einem Verleger und einem
Abonnenten ausgeführt. Allerdings mehrere Synchronisationen
gleichzeitig möglich. Daten fließen nur während des
Synchronisationsvorgangs. Eine Store and Forward Datenbank wie bei der
Transaktionalen Replikation gibt es nicht.
Zuerst werden die
Änderungen vom Abonnenten zum Verleger transferiert und mit den
dortigen Daten verglichen. Es erfolgt die automatische
Konflikterkennung und dann werden die Änderungen in der
Verlegerdatenbank zum Abonnenten geschoben.
Während des Synchronisationsvorgangs können optional weitere Aktionen wie Datenvalidierungen und Skripteinspielungen erfolgen.
d. Mögliche Topologien
Mit
der Merge Replikation des SQL Servers sind nicht nur sternförmige
Topologien möglich. Unterstützt wird auch eine Republizierung über Hubs
oder sogar vermaschte Strukturen. Außerdem kann zum Auffangen von
Verlegerausfällen für jeden Abonnenten ein alternativer Verleger
definiert werden.
Abb. 3: Mögliche Topologien
3.
Bewertung der Merge Replikation Generell ist die Merge Replikation des
SQL Servers eine flexible, stabile und beherrschbare Möglichkeit zur
Realisierung von verteilten Anwendungen.
Durch den Einsatz
der MSDE- und CE Editionen des Microsoft SQL Servers 2000 ist
insbesondere der Aufbau von können mobile Lösungen kostengünstig
möglich.
Ein paar Besonderheiten, die in diesen Zusammenhang zu beachten sind:
a. Komplexität Leider ist wenig Literatur zur Datenbankreplikation mit Microsoft SQL Server 2000 verfügbar.
Die
besten Quellen sind die Onlinedokumentation sowie zahlreiche Artikel in
der Microsoft Knowledge Base. Sollten Sie den Einsatz von Replikation
in Ihren Anwendungen in Erwägung ziehen, so ist eine genaue Studie
dieser Quellen dringend anzuraten. Zwar bietet der Enterprise Manager
komfortable Assistenten zum Aufsetzen und Warten der Replikation. Aber
diese Assistenten können die Komplexität der Merge Replikation nicht
vollständig verbergen und gerade im Problemfall ist eine genaue
Kenntnis der internen Abläufe notwendig.
b. Schemaänderungen
Die
größte Funktionale Einschränkung der Merge Replikation sind die
rudimentären Möglichkeiten zur Propagierung von Schemaänderungen vom
Verleger zu den Abonnenten. Zwar besteht die Möglichkeit, eine
Publikation um neue Tabellen und Felder zu erweitern oder Tabellen und
Felder zu entfernen. Dies reicht jedoch nicht aus und ist überdies noch
störanfällig. In vielen Fällen muss deshalb die Replikation neu
aufgesetzt werden. Es wird deshalb dringend empfohlen, dies in einer
Entwicklungsumgebung ausführlich zu testen und jederzeit auf ein
Neuaufsetzen der Replikation vorbereitet zu sein.
c.
Performanceprobleme Performanceprobleme können im Zusammenhang mit
dynamischen Filtern und / oder großen Replikatiossystemtabellen
auftreten.
Generell sollten Replikationsfilter möglichst
einfach sein. Idealerweise wird bereits beim Erzeugen der Datensätze
ein indiziertes Filterfeld mit dem notwendigen Filterkriterium gesetzt.
Dies vermeidet aufwändige SQL Abfragen während der Synchronisation.
Um
ein Anwachsen der Replikationssystemtabellen zu begrenzen besteht die
Möglichkeit, diese Daten nach einer definierten Zeit zu verwerfen
(Retention Period). Grundsätzlich werden diese Daten benötigt, um
ausgefallene Abonnenten wiederherzustellen. Allerdings kann in
Kombination mit einer geeigneten Sicherungsstrategie nach einer
gewissen Zeit auf diese Daten verzichtet werden.
5. Unsere Leistungen im Bereich Replikation:
Unser Partner hat bereits mehrere Softwarelösungen mit Replikations-Anforderungen realisiert.
Gerne beraten wir Sie bei der Konzeption und Realisation von Replikationslösungen.
In unseren Seminaren und individuellen Workshops vermitteln wir Ihnen das notwendige Know-how.
· Replikationsberatung
· Individual-Seminare
· Firmenseminare
· Microsoft-Kurs 2591 Implementing Replication Using Microsoft SQL Server 2000
|
|
