Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:
SQL Server
Da Warteschlangenaktualisierungsabonnements Änderungen an denselben Daten an mehreren Orten zulassen, kann es zu Konflikten kommen, wenn die Daten beim Publisher 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 Veröffentlichung ausgewählt haben. Die folgenden Konflikte sind möglich:
Aktualisierungs- und Einfügekonflikte. Diese Konflikte treten auf, wenn dieselben Daten an zwei verschiedenen Speicherorten geändert werden. Eine Änderung gewinnt, und die andere verliert.
Löschkonflikte. Diese Konflikte treten auf, wenn dieselbe Zeile an einem Speicherort gelöscht und an einem anderen bearbeitet wird.
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 Veröffentlichung und beim Aktivieren der Aktualisierung über Warteschlange fügt die Replikation der zugrunde liegenden Tabelle eine uniqueidentifier-Spalte (msrepl_tran_version) mit dem Standardwert newid() hinzu. Wenn veröffentlichte Daten entweder beim Verleger oder beim Abonnenten geändert werden, erhält die Datenzeile einen neuen global eindeutigen Bezeichner (GUID), um anzuzeigen, dass es eine neue Zeilenversion gibt. 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. Wenn die Transaktion beim Publisher angewendet wird, werden die GUIDs aus der Transaktion und die GUID in der Publikation verglichen. Wenn der alte in der Transaktion gespeicherte GUID mit dem GUID in der Veröffentlichung übereinstimmt, wird die Veröffentlichung aktualisiert, und der Zeile wird der neue GUID zugewiesen, der vom Abonnenten generiert wurde. Wenn Sie die Veröffentlichung mit der GUID aus der Transaktion aktualisieren, liegen in der Veröffentlichung und in der Transaktion übereinstimmende Zeilenversionen vor.
Wenn der alte in der Transaktion gespeicherte GUID nicht mit dem GUID in der Veröffentlichung übereinstimmt, wird ein Konflikt erkannt. Die neue GUID in der Veröffentlichung weist darauf hin, dass zwei verschiedene Versionen derselben Zeile vorhanden sind: eine in der Transaktion, die vom Subscriber übermittelt wird, und eine neuere, die auf dem Publisher vorhanden ist. In diesem Fall hat ein anderer Abonnent oder der Verleger dieselbe Zeile in der Veröffentlichung 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 Veröffentlichung über ein verzögertes Update wählen Sie einen Konfliktlöser aus, der verwendet werden soll, wenn Konflikte erkannt werden. Der Konfliktlöser bestimmt, wie der Queue Reader-Agent mit unterschiedlichen Versionen derselben Zeile umgeht, auf die er während der Synchronisierung stößt. Sie können die Vorgehensweise zur Konfliktlösung nach dem Erstellen der Veröffentlichung ändern, sofern keine Abonnements der Veröffentlichung 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 Update über eine Warteschlange fest
SQL Server Management Studio: Optionen zur Konfliktlösung bei Aktualisierung in der Warteschlange festlegen (SQL Server Management Studio)
Replikationsprogrammierung mit Transact-SQL: Aktivieren des Aktualisierens von Abonnements für Transaktionsveröffentlichungen
So zeigen Sie Datenkonflikte an
- SQL Server Management Studio: Anzeigen von Datenkonflikten für Transaktionsveröffentlichungen (SQL Server Management Studio)
Verleger gewinnt
Wenn die Konfliktlösung auf „Publisher gewinnt“ festgelegt ist, wird die Transaktionskonsistenz anhand der Daten des Publishers aufrechterhalten. Die konfliktbehaftete Transaktion wird bei dem Abonnenten zurückgesetzt, der sie gestartet hat.
Der Queue Reader-Agent erkennt einen Konflikt, und Kompensationsbefehle werden erzeugt und an den Abonnenten weitergeleitet, indem sie in die Verteilungsdatenbank eingetragen werden. Der Verteilungs-Agent wendet die kompensierenden Befehle dann auf den Abonnenten an, von dem die konfliktverursachende Transaktion stammt. Durch die Ausgleichsaktionen werden die Zeilen beim Subscriber so aktualisiert, dass sie an die Zeilen beim Publisher angeglichen werden.
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 eingehalten, und alle Aktionen innerhalb einer Transaktion werden entweder festgeschrieben oder im Falle eines Konflikts zurückgesetzt.
Verleger gewinnt, und das Abonnement wird erneut initialisiert
Die Neuinitialisierung des Abonnenten zur Behebung von Konflikten gewährleistet eine strikte Transaktionskonsistenz beim Abonnenten, kann jedoch zeitaufwändig sein, wenn die Veröffentlichung große Datenmengen 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. Die nächste Momentaufnahme, die für die Veröffentlichung generiert wird, wird vom Verteilungs-Agent auf den Abonnenten angewendet.
Abonnent gewinnt
Die Konflikterkennung unter der Richtlinie „Abonnent gewinnt“ bedeutet, dass sich die letzte Subscriber-Transaktion, die den Publisher aktualisiert, durchsetzt. 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.