Freigeben über

Updatable Subscriptions for Transactional Replication

  • Artikel

Gilt für: SQL Server 2008 (und höher)

Hinweis

Dieses Feature wird in einer künftigen Version von Microsoft SQL Server entfernt. Nutzen Sie diese Funktionen bei Neuentwicklungen nicht mehr, und planen Sie die Änderung von Anwendungen, die diese Funktion zurzeit verwenden.

In SQL Server 2014 unterstützt die Transaktionsreplikation Updates bei Abonnenten durch aktualisierbare Abonnements und Peer-to-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.

  • Verzögertes Aktualisieren über eine Warteschlange. Verleger und Abonnent müssen nicht verbunden sein, damit Daten auf dem Abonnenten aktualisiert werden können. Updates können ausgeführt werden, während der Verleger oder der Abonnent offline ist.

Wenn Daten auf einem Abonnenten aktualisiert werden, werden sie zuerst an den Verleger und dann an andere Abonnenten weitergegeben. Beim sofortigen Aktualisieren werden die Änderungen sofort mithilfe des Zweiphasencommit-Protokolls weitergegeben. Beim verzögerten Aktualisieren über eine Warteschlange werden die Änderungen in einer Warteschlange gespeichert und dann immer, wenn eine Netzwerkverbindung verfügbar ist, asynchron auf dem Verleger angewendet. Da die Updates asynchron an den Verleger weitergegeben werden, wurden die gleichen Daten möglicherweise vom Verleger oder von einem anderen Abonnenten aktualisiert. Daher können Konflikte auftreten, wenn die Updates angewendet werden. Konflikte werden nach einer Vorgehensweise zur Konfliktlösung erkannt und gelöst, die beim Erstellen der Veröffentlichung festgelegt wird.

Wenn Sie im Assistenten für neue Veröffentlichung eine Transaktionsveröffentlichung mit aktualisierbaren Abonnements erstellen, werden sowohl das sofortige Aktualisieren als auch das verzögerte Aktualisieren über eine Warteschlange 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.

Informationen zum Aktivieren aktualisierbarer Abonnements für Transaktionsveröffentlichungen finden Sie unter Aktivieren des Aktualisierens von Abonnements für Transaktionsveröffentlichungen.

Informationen zum Erstellen aktualisierbarer Abonnements für Transaktionsveröffentlichungen finden Sie unter Create an Updatable Subscription to a Transactional Publication.

Wechseln des Updatemodus

Bei der Verwendung aktualisierbarer Abonnements können Sie den Updatemodus für ein Abonnement angeben und dann bei Bedarf in den anderen Modus wechseln. Sie können z. B. angeben, dass das sofortige Aktualisieren für ein Abonnement verwendet wird. Wenn dann jedoch die Netzwerkverbindung aufgrund eines Systemfehlers unterbrochen wird, können Sie auf das verzögerte Aktualisieren über eine Warteschlange wechseln.

Hinweis

Bei der Replikation erfolgt kein automatischer Wechsel zwischen den Updatemodi. Sie müssen den Updatemodus über SQL Server Management Studio festlegen, oder Ihre Anwendung muss sp_setreplfailovermode (Transact-SQL) aufrufen, um zwischen den Modi zu wechseln.

Wenn Sie vom sofortigen Aktualisieren zum verzögerten Aktualisieren über eine Warteschlange wechseln, können Sie erst wieder zum sofortigen Aktualisieren wechseln, wenn der Abonnent und der Verleger verbunden sind und der Warteschlangenlese-Agent alle ausstehenden Nachrichten in der Warteschlange auf den Verleger angewendet hat.

So wechseln Sie den Updatemodus

Zum Wechseln des Updatemodus müssen Sie die Veröffentlichung und das Abonnement für beide Modi aktivieren und zwischen beiden nach Bedarf wechseln. Weitere Informationen finden Sie unter
Umschalten zwischen Updatemodi für ein aktualisierbares Transaktionsabonnement

Überlegungen zur Verwendung von aktualisierbaren Abonnements

  • Nachdem eine Veröffentlichung für Abonnements mit sofortigem Update oder Abonnements mit verzögertem Update über eine Warteschlange aktiviert wurde, kann die Option nicht für die Veröffentlichung deaktiviert werden (obwohl die Abonnements sie nicht verwenden müssen). Zum Deaktivieren der Option muss die Veröffentlichung gelöscht und dann eine neue Veröffentlichung erstellt werden.

  • Das erneute Verö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 sollten alle INSERT-Anweisungen eine Spaltenliste enthalten.

  • Wenn Sie das Schema einer Tabelle in einer Veröffentlichung ändern möchten, die das Aktualisieren von Abonnements unterstützt, müssen alle Aktivitäten an der Tabelle auf dem Verleger und dem Abonnenten angehalten werden. Außerdem müssen ausstehende Datenänderungen vor einer Schemaänderung an alle Knoten weitergegeben werden. Dadurch wird sichergestellt, dass unbeendete Transaktionen keinen Konflikt mit der ausstehenden Schemaänderung auslösen. Nach der Weitergabe der Schemaänderungen an alle Knoten können die Aktivitäten an den veröffentlichten Tabellen fortgesetzt werden. Weitere Informationen finden Sie unter Versetzen einer Replikationstopologie in einen inaktiven Status (Replikationsprogrammierung mit Transact-SQL).

  • Wenn Sie den Updatemodus wechseln möchten, muss der Warteschlangenlese-Agent nach der Initialisierung des Abonnements mindestens einmal ausgeführt werden (standardmäßig wird der Warteschlangenlese-Agent fortlaufend ausgeführt).

  • Ist die Abonnentendatenbank horizontal partitioniert und die Partition enthält Zeilen, die auf dem Abonnenten, aber nicht auf dem Verleger vorhanden sind, kann der Abonnent die bereits vorhandenen Zeilen nicht aktualisieren. Bei dem Versuch, diese Zeilen zu aktualisieren, wird ein Fehler zurückgegeben. Die Zeilen sollten aus der Tabelle gelöscht und dann auf dem Verleger hinzugefügt werden.

Updates auf dem Abonnenten

  • Updates auf dem Abonnenten werden auch dann an den Verleger weitergegeben, wenn ein Abonnement abgelaufen oder inaktiv ist. Stellen Sie sicher, dass Abonnements dieser Art gelöscht oder erneut initialisiert werden.

  • Wenn die Spalten TIMESTAMP oder IDENTITY verwendet und als Basisdatentypen repliziert werden, sollten die Werte in diesen Spalten nicht auf dem Abonnenten aktualisiert werden.

  • Abonnenten können keine text-, ntext- oder image-Werte aktualisieren oder einfügen, da das Lesen eingefügter oder gelöschter Tabellen innerhalb der Änderungsprotokollierungstrigger der Replikation nicht möglich ist. Ebenso können Abonnenten keine text- oder image-Werte mithilfe von WRITETEXT oder UPDATETEXT aktualisieren oder einfügen, da die Daten vom Verleger überschrieben werden. Stattdessen können Sie die text- und image-Spalten in eine separate Tabelle partitionieren und die beiden Tabellen in einer Transaktion ändern.

    Verwenden Sie zum Aktualisieren großer Objekte für einen Abonnenten die Datentypen varchar(max), nvarchar(max), varbinary(max) anstelle der Datentypen text, ntext, und image.

  • Updates an eindeutigen Schlüsseln (einschließlich Primärschlüssel), die Duplikate generieren (z. B. ein Update der Form UPDATE <column> SET <column> =<column>+1 ), sind nicht zulässig und werden aufgrund eines Verstoßes gegen die Eindeutigkeit abgelehnt. Dies ist darin begründet, dass Updates von Zeilengruppen auf dem Abonnenten durch die Replikation als einzelne UPDATE-Anweisungen für jede betroffene Zeile weitergegeben werden.

  • Ist die Abonnentendatenbank horizontal partitioniert und die Partition enthält Zeilen, die auf dem Abonnenten, aber nicht auf dem Verleger vorhanden sind, kann der Abonnent die bereits vorhandenen Zeilen nicht aktualisieren. Bei dem Versuch, diese Zeilen zu aktualisieren, wird ein Fehler zurückgegeben. Die Zeilen sollten aus der Tabelle gelöscht und erneut eingefügt werden.

Benutzerdefinierte Trigger

  • Wenn die Anwendung Trigger auf dem Abonnenten erfordert, definieren Sie die Trigger mithilfe der NOT FOR REPLICATION -Option auf dem Verleger und dem Abonnenten. Dadurch wird sichergestellt, dass Trigger nur für die ursprüngliche Datenänderung und nicht bei der Replikation dieser Änderung ausgelöst werden.

    Stellen Sie sicher, dass der benutzerdefinierte Trigger nicht ausgelöst wird, wenn der Replikationstrigger die Tabelle aktualisiert. Dies wird erreicht, indem die sp_check_for_sync_trigger-Prozedur im Rumpf des benutzerdefinierten Triggers aufgerufen wird. Weitere Informationen finden Sie unter sp_check_for_sync_trigger (Transact-SQL).

Sofortige Updates

  • Für sofort aktualisierbare Abonnements werden Änderungen auf dem Abonnenten an den Verleger weitergegeben und mithilfe von MS DTC (Microsoft Distributed Transaction Coordinator) 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 für sofort aktualisierbare Abonnements verwendet werden, erfordern eine Verbindung mit dem Verleger, damit Änderungen repliziert werden können.

  • Wenn die Veröffentlichung sofort aktualisierbare Abonnements zulässt und ein Artikel in der Veröffentlichung einen Spaltenfilter aufweist, können Sie Spalten ungleich NULL ohne Standardwerte nicht herausfiltern.

Verzögerte Updates über eine Warteschlange

  • In einer Mergeveröffentlichung eingeschlossene Tabellen können nicht als Teil einer Transaktionsveröffentlichung veröffentlicht werden, die Abonnements mit verzögertem Update über eine Warteschlange zulässt.

  • Updates an Primärschlüsselspalten werden beim Verwenden des verzögerten Aktualisierens über eine Warteschlange nicht empfohlen, da der Primärschlüssel verwendet wird, um Datensätze für alle Abfragen zu suchen. Wenn die Vorgehensweise zur Konfliktlösung so festgelegt ist, dass der Abonnent gewinnt, sollten Updates an Primärschlüsseln mit Vorsicht vorgenommen werden. Wenn Updates am Primärschlüssel auf dem Verleger und dem Abonnenten vorgenommen werden, handelt es sich beim Ergebnis um zwei Zeilen mit unterschiedlichen Primärschlüsseln.

  • Für Spalten des Datentyps SQL_VARIANT: Daten werden beim Einfügen oder Aktualisieren auf dem Abonnenten vom Warteschlangenlese-Agent auf die folgende Weise zugeordnet, wenn sie vom Abonnenten in die Warteschlange kopiert werden:

    • BIGINT, DECIMAL, NUMERIC, MONEY und SMALLMONEY werden NUMERIC zugeordnet.

    • BINARY und VARBINARY werden VARBINARY-Daten zugeordnet.

Konflikterkennung und -lösung

  • Für die Konfliktlösungsrichtlinie Abonnent gewinnt gilt: Die Konfliktlösung wird bei Updates an Primärschlüsselspalten nicht unterstützt.

  • Konflikte aufgrund von Fehlern der FOREIGN KEY-Einschränkung werden durch die Replikation nicht aufgelöst:

    • Wenn Konflikte nicht zu erwarten und die Daten optimal partitioniert sind (Abonnenten aktualisieren nicht dieselben Zeilen), können Sie FOREIGN KEY-Einschränkungen auf dem Verleger und den Abonnenten verwenden.

    • Wenn Konflikte zu erwarten sind, gehen Sie folgendermaßen vor: Verwenden Sie keine FOREIGN KEY-Einschränkungen auf dem Verleger oder dem Abonnenten, wenn Sie die Konfliktlösung "Abonnent gewinnt" verwenden; verwenden Sie keine FOREIGN KEY-Einschränkungen auf dem Abonnenten, wenn Sie die Konfliktlösung "Verleger gewinnt" verwenden.

Weitere Informationen

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