Updateierbare Abonnements – Für transaktionale Replikation

Gilt für:SQL Server

Die Transaktionsreplikation unterstützt Aktualisierungen bei Abonnenten durch aktualisierbare Abonnements und die Peer-zu-Peer-Replikation. Es gibt zwei Arten von aktualisierbaren Abonnements:

• Sofortiges Aktualisieren. Verleger und Abonnent müssen verbunden sein, damit Daten auf dem Abonnenten aktualisiert werden können.

• Aktualisierung in der Warteschlange: Der Publisher und der Abonnent müssen nicht verbunden sein, um Daten auf dem Abonnenten zu aktualisieren. Sie können Daten aktualisieren, solange der Abonnent oder Publisher offline ist.

Wenn du Daten bei einem Abonnenten aktualisierst, geht das Update zuerst an den Publisher und dann an andere Abonnenten. Wenn du ein sofortiges Update verwendest, werden die Änderungen sofort durch das Zweiphasen-Commit-Protokoll durchgeführt. Wenn du die Aktualisierung über eine Warteschlange verwendest, werden die Änderungen in eine Warteschlange eingereiht. Die in der Warteschlange stehenden Transaktionen gelangen asynchron zum Publisher, sobald Netzwerkverbindung verfügbar ist. Da die Updates asynchron an den Publisher gesendet werden, können dieselben Daten vom Publisher oder einem anderen Abonnenten aktualisiert werden, und bei der Anwendung der Updates können Konflikte auftreten. Das System erkennt und löst Konflikte gemäß einer Konfliktlösungsrichtlinie, die Sie bei der Erstellung der Veröffentlichung festlegen.

Wenn Sie mit dem Assistenten für neue Veröffentlichungen eine transaktionale Veröffentlichung mit aktualisierbaren Abonnements erstellen, werden sowohl die sofortige Aktualisierung als auch die Aktualisierung in Warteschlangen aktiviert. Beim Erstellen einer Veröffentlichung mit gespeicherten Prozeduren können Sie eine oder beide Optionen aktivieren. Wenn Sie ein Abonnement für die Veröffentlichung erstellen, geben Sie an, welcher Updatemodus verwendet wird. Sie können dann gegebenenfalls den Updatemodus wechseln. Weitere Informationen finden Sie im folgenden Abschnitt zum Wechseln des Updatemodus.

Um aktualisierbare Abonnements für transaktionale Publikationen zu aktivieren, siehe Aktualisierung von Abonnements für transaktionale Publikationen aktivieren.

Um updatable Abonnements für transaktionale Publikationen zu erstellen, siehe Create an Updateable Subscription to a Transactional Publication (Management Studio).

Wechsel zwischen Update-Modi

Wenn du updatierbare Abonnements verwendest, kannst du einen Update-Modus für ein Abonnement festlegen und dann in den anderen Modus wechseln, wenn die Anwendung das verlangt. Man kann zum Beispiel festlegen, dass für ein Abonnement die sofortige Aktualisierung verwendet wird, aber zur Aktualisierung über Warteschlangen gewechselt wird, wenn ein Systemausfall zu einem Verlust der Netzwerkverbindung führt.

Wenn Sie von sofortiger Aktualisierung auf Warteschlangenaktualisierung wechseln, können Sie erst wieder auf sofortige Aktualisierungen umschalten, wenn Subscriber und Publisher verbunden sind und der Queue Reader Agent alle ausstehenden Nachrichten in der Warteschlange auf den Publisher anwendet.

So wechseln Sie den Updatemodus

Um zwischen den Update-Modi zu wechseln, aktivieren Sie die Veröffentlichung und das Abonnement für beide Update-Modi und wechseln Sie dann bei Bedarf zwischen ihnen. Weitere Informationen finden Sie unter
Umschalten zwischen Updatemodi für ein aktualisierbares Transaktionsabonnement

Überlegungen zur Verwendung updateierbarer Abonnements

• Nachdem du eine Publikation für aktualisierbare Abonnements oder Abonnements mit Warteschlangenaktualisierung aktiviert hast, kannst du diese Option für die Publikation nicht mehr deaktivieren (obwohl die Abonnements sie nicht verwenden müssen). Um die Option zu deaktivieren, löschen Sie die Veröffentlichung und erstellen Sie eine neue.

• Das Wiederveröffentlichen von Daten wird nicht unterstützt.

• Bei der Replikation wird die msrepl_tran_version -Spalte veröffentlichten Tabellen für das Nachverfolgen hinzugefügt. Wegen dieser zusätzlichen Spalte fügen Sie in allen INSERT-Anweisungen eine Spaltenliste hinzu.

• Um Schemaänderungen in einer Tabelle in einer Publikation vorzunehmen, die das Aktualisieren von Abonnements unterstützt, stoppen Sie alle Aktivitäten auf der Tabelle bei Publisher und Subscribers und leiten ausstehende Datenänderungen an alle Knoten weiter, bevor Sie Schemaänderungen vornehmen. Dieser Prozess stellt sicher, dass ausstehende Transaktionen nicht mit der ausstehenden Schemaänderung kollidieren. Nachdem die Schemaänderungen auf alle Knoten ausgebreitet sind, kann die Aktivität an den veröffentlichten Tabellen wieder aufgenommen werden. Weitere Informationen finden Sie unter Versetzen einer Replikationstopologie in einen inaktiven Status (Replikationsprogrammierung mit Transact-SQL).

• Um zwischen den Aktualisierungsmodi zu wechseln, muss der Queue Reader Agent mindestens einmal nach der Initialisierung des Abonnements ausgeführt werden (standardmäßig läuft der Queue Reader Agent kontinuierlich).

• Wenn die Subscriber-Datenbank horizontal partitioniert ist und es Zeilen in der Partition gibt, die zwar beim Subscriber existieren, aber nicht beim Publisher, kann der Subscriber die bereits bestehenden Zeilen nicht aktualisieren. Bei dem Versuch, diese Zeilen zu aktualisieren, wird ein Fehler zurückgegeben. Lösche die Zeilen aus der Tabelle und füge sie dann im Publisher hinzu.

• Die transaktionale Replikation mit warteschlangenaktualisierbaren Abonnenten kann zu Leistungsproblemen führen, wenn eindeutige gefilterte Indizes verwendet werden. Wenn ein Konflikt bei einem Artikel auftritt, der eindeutig gefilterte Indizes hat, führt die Konfliktlösung zu zusätzlichen Löschungen und Einfügungen beim Abonnenten für die Zeilen, die nicht vom eindeutig gefilterten Index abgedeckt sind.

Updates beim Abonnenten

• Updates beim Subscriber werden auch dann an den Publisher weitergeleitet, wenn ein Abonnement abgelaufen oder inaktiv ist. Stellen Sie sicher, dass Sie solche Abonnements kündigen oder neu initialisieren.

• Wenn du TIMESTAMP oder IDENTITY Spalten verwendest und sie als Basisdatentypen replizierst, aktualisiere die Werte in diesen Spalten nicht beim Abonnenten.

• Abonnenten können keinen Text, ntext oder Bildwert aktualisieren oder einfügen, da Replikationsänderungs-Tracking-Trigger nicht aus den eingefügten oder gelöschten Tabellen lesen können. Ebenso können Abonnenten keine Text- oder Bildwerte durch WRITETEXT oder UPDATETEXT aktualisieren oder einfügen, da der Publisher die Daten überschreibt. Stattdessen könnten Sie die Text - und Bildspalten in eine separate Tabelle partitionieren und beide Tabellen innerhalb einer Transaktion modifizieren.

  Um große Objekte bei einem Abonnenten zu aktualisieren, verwenden Sie die Datentypen varchar(max),nvarchar(max) und varbinary(max) anstelle von Text-, nText- und Bilddatentypen .

• Aktualisierungen eindeutiger Schlüssel (einschließlich Primärschlüssel), die Duplikate erzeugen, wie etwa eine Aktualisierung des Formulars UPDATE <column> SET <column> =<column>+1, sind nicht erlaubt und werden wegen einer Eindeutigkeitsverletzung abgelehnt. Satzbasierte Aktualisierungen, die auf dem Subscriber vorgenommen werden, werden bei der Replikation als einzelne UPDATE-Anweisungen für jede betroffene Zeile weitergegeben.

• Wenn die Subscriber-Datenbank horizontal partitioniert ist und die Partition Zeilen enthält, die beim Subscriber existieren, aber nicht beim Publisher, kann der Subscriber die bereits bestehenden Zeilen nicht aktualisieren. Bei dem Versuch, diese Zeilen zu aktualisieren, wird ein Fehler zurückgegeben. Lösche und füge diese Zeilen wieder ein.

Benutzerdefinierte Trigger

• Wenn die Anwendung Trigger beim Subscriber benötigt, definieren Sie die Trigger mit der NOT FOR REPLICATION Option bei Publisher und Subscriber. Diese Option stellt sicher, dass Trigger nur bei der ursprünglichen Datenänderung ausgelöst werden, nicht jedoch, wenn die Replikation die Änderung weitergibt.

  Stellen Sie sicher, dass der benutzerdefinierte Trigger nicht ausgelöst wird, wenn der Replikationstrigger die Tabelle aktualisiert. Rufen Sie das Verfahren sp_check_for_sync_trigger im Körper des benutzerdefinierten Triggers auf. Weitere Informationen finden Sie unter sp_check_for_sync_trigger (Transact-SQL).

Sofortige Updates

• Für sofortige Aktualisierungen von Abonnements werden Änderungen am Subscriber an den Publisher weitergeleitet und über den Microsoft Distributed Transaction Coordinator (MS DTC) angewendet. Stellen Sie sicher, dass MS DTC auf dem Verleger und Abonnenten installiert und konfiguriert ist. Weitere Informationen finden Sie in der Windows-Dokumentation.

• Die Trigger, die sofortige Aktualisierungen von Abonnements verwenden, erfordern eine Verbindung zum Publisher, um Änderungen zu replizieren.

• Wenn die Publikation die sofortige Aktualisierung von Abonnements zulässt und ein Artikel in der Publikation einen Spaltenfilter hat, können Spalten, die keine NULL-Werte zulassen und für die keine Standardwerte definiert sind, nicht herausgefiltert werden.

Aktualisierung in Warteschlange

• Man kann keine Tabellen veröffentlichen, die in einer Merge-Publikation enthalten sind, als Teil einer transaktionalen Publikation, die Warteschlangen-Updates von Abonnements erlaubt.

• Aktualisieren Sie die Primärschlüsselspalten nicht, wenn Sie Warteschlangen-Updates verwenden, da der Primärschlüssel als Record Locator für alle Abfragen dient. Wenn die Konfliktlösungsrichtlinie auf „Abonnent hat Vorrang“ festgelegt ist, seien Sie beim Aktualisieren von Primärschlüsseln vorsichtig. Wenn sowohl der Publisher als auch der Subscriber den Primärschlüssel aktualisieren, entstehen zwei Zeilen mit unterschiedlichen Primärschlüsseln.

• Für Spalten des Datentyps SQL_VARIANT: Wenn Daten beim Abonnenten eingefügt oder aktualisiert werden, ordnet der Queue Reader Agent sie folgendermaßen zu, wenn er Daten vom Abonnenten in die Warteschlange kopiert:

  • BIGINT, DECIMAL, NUMERIC, MONEY und SMALLMONEY werden auf NUMERIC abgebildet.

  • BINARY und VARBINARY werden auf VARBINARY-Daten abgebildet.

Konflikterkennung und -lösung

• Bei der Konfliktrichtlinie „Subscriber Wins“ werden Aktualisierungen von Primärschlüsselspalten bei der Konfliktauflösung nicht unterstützt.

• Replikation löst keine Konflikte aufgrund von Ausfällen bei Fremdschlüsselbeschränkungen:

  • Wenn du keine Konflikte erwartest und die Daten gut partitioniert sind (Abonnenten aktualisieren nicht dieselben Zeilen), verwende Fremdschlüssel-Constraints für Publisher und Abonnenten.

  • Wenn du Konflikte erwartest: Verwende keine Fremdschlüssel-Einschränkungen beim Publisher oder Subscriber, wenn du "Subscriber gewinnt" Konfliktlösung benutzt. Verwenden Sie keine Fremdschlüssel-Einschränkungen beim Subscriber, wenn Sie "Publisher wins" Konfliktlösung verwenden.

Zugehöriger Inhalt

• Peer-to-Peer - Transactional Replication
• Transaktionsreplikation
• Veröffentlichen von Daten und Datenbankobjekten
• Abonnieren von Veröffentlichungen