Mergereplikation (Übersicht)
Die Mergereplikation beginnt in der Regel, wie die Transaktionsreplikation auch, mit einer Momentaufnahme der Veröffentlichungsdatenbankobjekte und -daten. Spätere Daten- und Schemaänderungen, die auf dem Verleger und den Abonnenten vorgenommen werden, werden mit Triggern nachverfolgt. Ist eine Verbindung mit dem Netzwerk vorhanden, nimmt der Abonnent eine Synchronisierung mit dem Verleger vor und tauscht alle Zeilen aus, die sich seit der letzten Synchronisierung auf dem Verleger und dem Abonnenten geändert haben.
Die Mergereplikation wird typischerweise in Server-und-Client-Umgebungen verwendet. Ihre Verwendung empfiehlt sich in den folgenden Situationen:
Mehrere Abonnenten aktualisieren dieselben Daten zu verschiedenen Zeitpunkten und geben diese Änderungen an den Verleger und an andere Abonnenten weiter.
Abonnenten müssen Daten empfangen, Änderungen offline vornehmen und Änderungen später mit dem Verleger und anderen Abonnenten synchronisieren.
Jeder Abonnent benötigt eine andere Datenpartition.
Es kann zu Konflikten kommen, und Sie müssen in der Lage sein, die Konflikte zu erkennen und zu lösen.
Die Anwendung muss nicht auf die einzelnen Zwischenstufen von Datenänderungen, sondern nur auf das endgültige Ergebnis der Datenänderung zugreifen können. Wenn sich eine Zeile auf dem Abonnenten z. B. fünfmal ändert, bevor sie mit einem Verleger synchronisiert wird, ändert sich die Zeile auf dem Verleger lediglich einmal und übernimmt so nur die endgültige Änderung (in diesem Fall also den fünften Wert).
Die Mergereplikation ermöglicht es verschiedenen Standorten, autonom zu arbeiten und die Aktualisierungen zu einem späteren Zeitpunkt zu einem einzelnen, einheitlichen Ergebnis zusammenzuführen. Da Aktualisierungen auf mehr als einem Knoten ausgeführt werden, sind dieselben Daten möglicherweise vom Verleger und von mindestens einem Abonnenten aktualisiert worden. Daher kann es beim Zusammenführen von Aktualisierungen zu Konflikten kommen, für deren Lösung die Mergereplikation aber eine Reihe von Möglichkeiten bietet.
Damit Änderungen nachverfolgt werden können, müssen Mergereplikationen (und Transaktionsreplikationen mit Abonnements mit verzögertem Update) jede Zeile in jeder veröffentlichten Tabelle eindeutig identifizieren können. Um dies zu erreichen, fügt die Mergereplikation jeder Tabelle die rowguid-Spalte hinzu, es sei denn, die Tabelle verfügt bereits über eine Spalte vom Datentyp uniqueidentifier mit festgelegter ROWGUIDCOL-Eigenschaft (in diesem Fall wird diese Spalte verwendet). Beim Löschen der Tabelle aus der Veröffentlichung wird auch die rowguid-Spalte entfernt. Wurde eine vorhandene Spalte zur Nachverfolgung verwendet, wird die Spalte nicht entfernt. Ein Filter darf keine rowguidcol enthalten, die von der Replikation zum Identifizieren von Zeilen verwendet wird. Die newid()-Funktion wird standardmäßig für die rowguid-Spalte bereitgestellt, die Kunden können bei Bedarf jedoch eine GUID für jede Zeile angeben. Der Wert 00000000-0000-0000-0000-000000000000 darf nicht angegeben werden.
Informationen zum Implementieren der Mergereplikation finden Sie unter Entwerfen und Implementieren (Replikation).
Informationen zu häufigen Szenarien im Zusammenhang mit der Mergereplikation finden Sie unter Replizieren von Daten zwischen einem Server und Clients.
Siehe auch