Konflikterkennung und -lösung beim verzögerten Aktualisieren über eine Warteschlange

  • Artikel

Da die verzögerte Aktualisierung von Abonnements über eine Warteschlange Änderungen an denselben Daten an mehreren Standorten zulässt, können Konflikte auftreten, wenn die Daten auf dem Verleger synchronisiert werden. Die Replikation erkennt alle Konflikte, wenn Änderungen mit dem Verleger synchronisiert werden, und löst die Konflikte anhand der Richtlinie zur Konfliktlösung, die Sie beim Erstellen der Publikation ausgewählt haben.

Die Konflikterkennung und -lösung kann ein zeitaufwändiger und ressourcenintensiver Prozess sein. Daher sollten Konflikte in der Anwendung, sofern möglich, minimiert werden, indem Sie Datenpartitionen erstellen, sodass die unterschiedlichen Abonnenten andere Datenteilmengen ändern.

Erkennen von Konflikten

Beim Erstellen einer Publikation und beim Aktivieren des verzögerten Aktualisierens über eine Warteschlange fügt die Replikation eine uniqueidentifier-Spalte (msrepl_tran_version) mit dem Standardwert newid() der zugrunde liegenden Tabelle hinzu. Werden veröffentlichte Daten auf dem Verleger oder dem Abonnenten geändert, erhält die Zeile einen neuen Globally Unique Identifier (GUID), um anzuzeigen, dass eine neue Zeilenversion vorhanden ist. Der Warteschlangenlese-Agent verwendet diese Spalte während der Synchronisierung, um zu bestimmen, ob ein Konflikt vorhanden ist.

Eine Transaktion in einer Warteschlange behält die alten und neuen Zeilenversionswerte bei. Wird die Transaktion auf dem Verleger angewendet, werden die GUIDs von der Transaktion und der GUID in der Publikation verglichen. Wenn der alte in der Transaktion gespeicherte GUID mit dem GUID in der Publikation übereinstimmt, wird die Publikation aktualisiert, und der Zeile wird der neue GUID zugewiesen, der vom Abonnenten generiert wurde. Durch Aktualisieren der Publikation mit dem GUID der Transaktion finden Sie übereinstimmende Zeilenversionen in der Publikation und der Transaktion.

Wenn der alte in der Transaktion gespeicherte GUID nicht mit dem GUID in der Publikation übereinstimmt, wird ein Konflikt erkannt. Der neue GUID in der Publikation zeigt an, dass zwei verschiedene Zeilenversionen vorhanden sind: eine in der Transaktion, die vom Abonnenten gesendet wird, und eine neuere, die beim Verleger vorhanden ist. In diesem Fall hat ein anderer Abonnent oder der Verleger dieselbe Zeile in der Publikation aktualisiert, bevor diese Abonnententransaktion synchronisiert wurde.

Im Gegensatz zur Mergereplikation wird eine GUID-Spalte nicht zur Identifikation der eigentlichen Zeile verwendet, sondern um zu überprüfen, ob sich die Zeile geändert hat.

Lösen von Konflikten

Beim Erstellen einer Publikation über eine verzögerte Aktualisierung wählen Sie einen Konfliktlöser aus, der verwendet werden soll, wenn Konflikte erkannt werden. Durch den Konfliktlöser wird bestimmt, wie der Warteschlangenlese-Agent unterschiedliche Versionen derselben Zeile behandelt, die während der Synchronisierung auftreten. Sie können die Vorgehensweise zur Konfliktlösung nach dem Erstellen der Publikation ändern, sofern keine Abonnements der Publikation vorhanden sind. Die Wahlmöglichkeiten für den Konfliktlöser sind Folgende:

  • Verleger gewinnt (Standardeinstellung)
  • Verleger gewinnt, und das Abonnement wird erneut initialisiert
  • Abonnent gewinnt

Konflikte werden aufgezeichnet und können mithilfe des Konflikt-Viewers angezeigt werden.

So legen Sie die Vorgehensweise zur Konfliktlösung für das verzögerte Aktualisieren über eine Warteschlange fest

So zeigen Sie Datenkonflikte an

Verleger gewinnt

Wenn die Konfliktlösung auf das Gewinnen des Verlegers festgelegt ist, wird die Transaktionskonsistenz basierend auf den Daten auf dem Verleger beibehalten. Es wird ein Rollback für die konfliktverursachende Transaktion auf dem Abonnenten ausgeführt, der die Transaktion initialisiert hat.

Der Warteschlangenlese-Agent erkennt einen Konflikt, und kompensierende Befehle werden generiert und an den Abonnenten weitergegeben, indem sie in der Verteilungsdatenbank bereitgestellt werden. Der Verteilungs-Agent wendet die kompensierenden Befehle dann auf den Abonnenten an, von dem die konfliktverursachende Transaktion stammt. Durch die kompensierenden Aktionen werden die Zeilen auf dem Abonnenten so aktualisiert, dass sie mit den Zeilen auf dem Verleger übereinstimmen.

Bis zum Anwenden der kompensierenden Befehle können die Ergebnisse einer Transaktion gelesen werden, für die schließlich ein Rollback auf dem Abonnenten ausgeführt wird. Dies entspricht einem Dirty Read (Isolationsstufe Read uncommitted). Eine Kompensation für die nachfolgenden abhängigen Transaktionen, die auftreten können, ist nicht vorhanden. Die Transaktionsgrenzen werden jedoch berücksichtigt, und für alle Aktionen in einer Transaktion wird ein Commit oder bei einem Konflikt ein Rollback ausgeführt.

Verleger gewinnt, und das Abonnement wird erneut initialisiert

Das erneute Initialisieren des Abonnenten zur Konfliktlösung behält eine strenge Transaktionskonsistenz auf dem Abonnenten bei, kann jedoch zeitaufwändig sein, wenn die Publikation viele Daten enthält.

Erkennt der Warteschlangenlese-Agent einen Konflikt, werden alle restlichen Transaktionen in der Warteschlange (einschließlich der Transaktion mit dem Konflikt) zurückgewiesen, und der Abonnent wird zur erneuten Initialisierung markiert. Der nächste Snapshot, der für die Publikation generiert wird, wird vom Verteilungs-Agent auf den Abonnenten angewendet.

Abonnent gewinnt

Die Konflikterkennung unter der Richtlinie Abonnent gewinnt bedeutet, dass die letzte Abonnententransaktion gewinnt, die den Verleger aktualisiert. Wird ein Konflikt erkannt, wird in diesem Fall die vom Abonnenten gesendete Transaktion weiterhin verwendet, und der Verleger wird aktualisiert. Diese Vorgehensweise eignet sich für Anwendungen, in denen die Datenintegrität durch diese Änderungen nicht gefährdet wird.

Siehe auch

Konzepte

Aktualisierbare Abonnements für die Transaktionsreplikation

Hilfe und Informationen

Informationsquellen für SQL Server 2005