Funktionsweise von aktualisierbaren Abonnements
Durch aktualisierbare Abonnements können Abonnenten bei der Transaktionsreplikation Änderungen auf dem Verleger replizieren. Den veröffentlichten Tabellen in der Abonnementdatenbank werden Trigger hinzugefügt, die bei Änderungen auf dem Abonnenten folgende Aktionen auslösen:
Bei Abonnements mit sofortiger Aktualisierung wird die Änderung direkt an den Verleger weitergegeben und mithilfe des Microsoft Distributed Transaction Coordinator (MSDTC) angewendet.
Bei Abonnements mit verzögerter Aktualisierung über eine Warteschlange wird die Änderung zunächst an eine Warteschlange weitergegeben, bevor sie mithilfe des Warteschlangenlese-Agents auf dem Verleger angewendet wird.
Die auf dem Verleger erfolgten Änderungen werden auf den Abonnenten in derselben Weise repliziert wie Transaktionsveröffentlichungen auf schreibgeschützten Abonnenten. Weitere Informationen finden Sie unter Funktionsweise der Transaktionsreplikation.
Sofortiges Aktualisieren
Abonnements mit sofortiger Aktualisierung verwenden folgende Komponenten:
Nachverfolgungsspalte in jeder veröffentlichten Tabelle
Wenn eine Tabelle in einer Veröffentlichung veröffentlicht wird, die aktualisierbare Abonnements zulässt, wird die msrepl_tran_version-Spalte zu der Tabelle hinzugefügt. Diese Spalte wird für die Änderungsnachverfolgung sowie die Konflikterkennung verwendet. Bei der sofortigen Aktualisierung können Konflikte auftreten, wenn der Abonnent eine als veraltet markierte Kopie der Daten aktualisiert.
MSDTC
Für jede auf dem Abonnenten ausgeführte Änderung verwaltet MSDTC einen Zweiphasencommit-Vorgang zwischen dem Verleger und dem Abonnenten, der das Commit der Änderung ausführt. Diese Vorgehensweise unterliegt nicht den Verfügbarkeitseinschränkungen eines Zweiphasencommits mit allen beteiligten Standorten, da lediglich der Verleger verfügbar sein muss. Wenn die Änderung über das Zweiphasencommit am Verleger vorgenommen wurde, wird sie durch den Verteilungs-Agent auf den anderen Abonnenten repliziert.
Trigger in Tabellen der Abonnementdatenbank
INSERT-, UPDATE- und DELETE-Trigger werden jeder veröffentlichten Tabelle in der Abonnementdatenbank hinzugefügt. Die Trigger werden mithilfe des NOT FOR REPLICATION-Parameters der CREATE TRIGGER-Anweisung erstellt, sodass vom Verteilungs-Agent übernommene Änderungen nicht dazu führen, dass die Trigger ausgelöst werden. Weitere Informationen finden Sie unter Steuern von Einschränkungen, Identitäten und Triggern mithilfe von NOT FOR REPLICATION.
Bei Abonnements mit sofortiger Aktualisierung verwalten die Trigger auch Werte für die identity- und timestamp-Spalten auf dem Abonnenten. Die Werte für diese Spaltentypen werden auf dem Verleger generiert und als Teil des Zweiphasencommit-Vorgangs an den Abonnenten weitergegeben.
Gespeicherte Prozeduren
Wenn Sie eine Veröffentlichung erstellen und für Abonnenten mit sofortiger Aktualisierung aktivieren, werden INSERT-, UPDATE- und DELETE-Prozeduren für jede veröffentlichte Tabelle in der Veröffentlichungsdatenbank erstellt. Wenn eine Änderung auf dem Abonnenten erfolgt, gibt ein Replikationstrigger über MSDTC einen Remoteprozeduraufruf an die entsprechende Remoteprozedur auf dem Verleger aus, welcher die Änderung dann anwendet.
Die gespeicherten Prozeduren auf dem Verleger wenden Änderungen nur dann an, wenn sie keinen Konflikt mit den auf dem Verleger vorgenommenen Änderungen hervorrufen, nachdem der Abonnent zuletzt seine Kopie der geänderten Zeilen empfangen hat. Wird ein Konflikt erkannt, wird die Transaktion zurückgewiesen und auf dem Verleger und dem Abonnenten ein Rollback ausgeführt.
In der folgenden Abbildung werden die Hauptkomponenten einer Topologie gezeigt, in der Abonnements mit sofortiger Aktualisierung verwendet werden.
.gif "Komponenten und Datenfluss für sofortiges Update")
Eine Änderung wird auf dem Abonnenten vorgenommen und von einem Trigger in der Abonnententabelle aufgezeichnet.
Der Trigger ruft über MSDTC die entsprechende gespeicherte Prozedur auf dem Verleger auf.
Die gespeicherte Prozedur führt die INSERT-, UPDATE- oder DELETE-Anweisung aus, es sei denn, ein Konflikt ist vorhanden. Ist ein Konflikt vorhanden, wird auf dem Verleger und dem Abonnenten ein Rollback ausgeführt.
Änderungen, die aufgrund von Änderungen eines Abonnenten auf dem Verleger vorgenommen wurden, werden gemäß dem Zeitplan des Verteilungs-Agents an alle anderen Abonnenten weitergegeben.
Verzögertes Aktualisieren über eine Warteschlange
Abonnements mit verzögerter Aktualisierung über eine Warteschlange verwenden folgende Komponenten:
Nachverfolgungsspalte in jeder veröffentlichten Tabelle
Wenn eine Tabelle in einer Veröffentlichung veröffentlicht wird, die aktualisierbare Abonnements zulässt, wird die msrepl_tran_version-Spalte zu der Tabelle hinzugefügt. Diese Spalte wird für die Änderungsnachverfolgung sowie die Konflikterkennung verwendet.
Trigger in Tabellen der Abonnementdatenbank
INSERT-, UPDATE- und DELETE-Trigger werden jeder veröffentlichten Tabelle in der Abonnementdatenbank hinzugefügt. Die Trigger werden mithilfe des NOT FOR REPLICATION-Parameters der CREATE TRIGGER-Anweisung erstellt, sodass vom Verteilungs-Agent übernommene Änderungen nicht dazu führen, dass die Trigger ausgelöst werden. Weitere Informationen finden Sie unter Steuern von Einschränkungen, Identitäten und Triggern mithilfe von NOT FOR REPLICATION.
Gespeicherte Prozeduren
Wenn Sie eine Veröffentlichung erstellen und für Abonnenten mit verzögerter Aktualisierung über eine Warteschlange aktivieren, werden INSERT-, UPDATE- und DELETE-Prozeduren für jede veröffentlichte Tabelle in der Veröffentlichungsdatenbank erstellt.
Die gespeicherten Prozeduren werden vom Warteschlangenlese-Agent aufgerufen, um Transaktionen auf dem Verleger anzuwenden, Konflikte zu erkennen und gegebenenfalls kompensierende Befehle zu generieren, die an die Verteilungsdatenbank gesendet und dann an den Abonnenten übermittelt werden.
Außerdem wird eine gespeicherte Prozedur zum Protokollieren von Konfliktinformationen beim Verleger und optional zum Senden von Konfliktinformationen an betroffene Abonnenten auf dem Verleger erstellt. Diese wird vom Warteschlangenlese-Agent aufgerufen, wenn ein Konflikt erkannt wird.
Microsoft SQL Server-Warteschlange
Jede Abonnementdatenbank enthält die Systemtabelle MSreplication_queue, in der die Änderungen der Abonnenten gespeichert werden.
SQL Server-Warteschlangenlese-Agent
Der Warteschlangenlese-Agent liest die Änderungen in der MSreplication_queue-Tabelle und wendet sie auf dem Verleger an. Weitere Informationen finden Sie unter Warteschlangenlese-Agent der Microsoft SQL Server-Replikation.
In der folgenden Abbildung werden die Hauptkomponenten einer Topologie gezeigt, in der Abonnements mit verzögerter Aktualisierung über eine Warteschlange verwendet werden.
.gif "Komponenten und Datenfluss für verzögertes Update über eine Warteschlange")
Aktualisierungen, die auf dem Abonnenten vorgenommen wurden, werden von Triggern in den Abonnententabellen aufgezeichnet. Die Trigger speichern diese Aktualisierungen in der MSreplication_queue-Tabelle.
Der Warteschlangenlese-Agent liest die Aktualisierungen in der MSreplication_queue-Tabelle und wendet die Transaktionen in der Warteschlange mithilfe von gespeicherten Prozeduren auf die entsprechende Veröffentlichung an.
Beim Anwenden der Transaktionen in Warteschlangen werden Konflikte gegebenenfalls gemäß einer Vorgehensweise zur Konfliktlösung erkannt und gelöst, die beim Erstellen der Veröffentlichung festgelegt wird. Als Ergebnis können kompensierende Befehle generiert werden, um einen Rollback für eine Transaktion auf einem Abonnenten mithilfe des standardmäßigen Transaktionsreplikations-Verteilungsprozesses auszuführen; sie werden jedoch ausschließlich an den konfliktverursachenden Abonnenten gesendet. Weitere Informationen finden Sie unter Konflikterkennung und -lösung beim verzögerten Aktualisieren über eine Warteschlange.
Änderungen, die aufgrund von Änderungen eines Abonnenten auf dem Verleger vorgenommen wurden, werden gemäß dem Zeitplan des Verteilungs-Agents an alle anderen Abonnenten weitergegeben.