Aktualisierbare Abonnements – für die Transaktionsreplikation

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 Warteschlangen Der Verleger und der Abonnent müssen nicht verbunden sein, um Daten beim Abonnenten zu aktualisieren. 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. Wenn die Aktualisierung über Warteschlangen verwendet wird, werden die Änderungen in einer Warteschlange gespeichert; die in die Warteschlange eingereihten Transaktionen werden dann asynchron beim Publisher angewendet, sobald eine Netzwerkverbindung verfügbar ist. 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 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.

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 Erstellen eines aktualisierbaren Abonnements für eine Transaktionsveröffentlichung (Management Studio).

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 beispielsweise angeben, dass für ein Abonnement die sofortige Aktualisierung verwendet werden soll, bei Verlust der Netzwerkverbindung aufgrund eines Systemfehlers jedoch zur Aktualisierung über eine Warteschlange gewechselt wird.

Wenn Sie von der sofortigen Aktualisierung zur Aktualisierung über Warteschlangen wechseln, können Sie erst dann wieder zur sofortigen Aktualisierung zurückkehren, wenn der Abonnent und der Verleger verbunden sind und der Warteschlangenlese-Agent alle ausstehenden Nachrichten in der Warteschlange beim Verleger verarbeitet 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 aktualisierbare Abonnements oder warteschlangengesteuerte aktualisierbare Abonnements aktiviert wurde, kann diese Option für die Veröffentlichung nicht deaktiviert werden (obwohl die Abonnements diese Option 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 zu Nachverfolgungszwecken hinzugefügt. Aufgrund dieser zusätzlichen Spalte sollten alle INSERT Anweisungen eine Spaltenliste enthalten.

• Um Schemaänderungen an einer Tabelle in einer Veröffentlichung vorzunehmen, die die Aktualisierung von Abonnements unterstützt, müssen sämtliche Aktivitäten für die Tabelle beim Publisher und bei den Abonnenten beendet werden, und ausstehende Datenänderungen müssen an alle Knoten weitergeleitet werden, bevor Schemaänderungen vorgenommen 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 beim Publisher hinzugefügt werden.

• Transaktionsreplikation mit aktualisierbaren Abonnenten in der Warteschlange kann die Leistung beeinträchtigen, wenn eindeutige, gefilterte Indizes verwendet werden. Wenn bei einem Artikel mit eindeutigen gefilterten Indizes ein Konflikt auftritt, führt die Konfliktlösung beim Abonnenten zu zusätzlichen Löschvorgängen und Einfügungen bei den Zeilen, die nicht von dem eindeutigen gefilterten Index abgedeckt werden.

Updates beim Abonnenten

• Änderungen beim Subscriber werden auch dann an den Publisher übertragen, wenn eine Subscription abgelaufen ist oder inaktiv ist. Stellen Sie sicher, dass Abonnements dieser Art gelöscht oder erneut initialisiert werden.

• Wenn TIMESTAMP oder IDENTITY Spalten verwendet werden und sie als Basisdatentypen repliziert werden, sollten die Werte in diesen Spalten nicht beim 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 bei einem Abonnenten die Datentypen varchar(max), nvarchar(max) und varbinary(max) jeweils anstelle von 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 liegt daran, dass satzbasierte Aktualisierungen, die beim Abonnenten vorgenommen werden, 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 beim Abonnenten benötigt, sollten die Trigger mit der NOT FOR REPLICATION-Option auf dem Verleger und dem Abonnenten definiert werden. 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 beim Abonnenten an den Publisher weitergegeben und mithilfe von Microsoft Distributed Transaction Coordinator (MS DTC) übernommen. 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 Abonnements für sofortige Aktualisierung zulässt und ein Artikel in der Veröffentlichung einen Spaltenfilter enthält, können Sie Spalten, die NULL nicht zulassen und keinen Standardwert haben, nicht herausfiltern.

Aktualisierung in Warteschlange

• In einer Mergeveröffentlichung enthaltene Tabellen können nicht auch als Teil einer Transaktionsveröffentlichung veröffentlicht werden, die Warteschlangenaktualisierungsabonnements ermöglicht.

• Aktualisierungen von Primärschlüsselspalten werden bei der Aktualisierung über eine Warteschlange nicht empfohlen, da der Primärschlüssel bei allen Abfragen zur Lokalisierung von Datensätzen verwendet wird. Wenn die Vorgehensweise zur Konfliktlösung so festgelegt ist, dass der Abonnent gewinnt, sollten Updates an Primärschlüsseln mit Vorsicht vorgenommen werden. Wenn sowohl beim Publisher als auch beim Subscriber Änderungen am Primärschlüssel vorgenommen werden, führt dies zu zwei Zeilen mit unterschiedlichen Primärschlüsseln.

• Für Spalten des Datentyps SQL_VARIANT gilt: Wenn Daten beim Abonnenten eingefügt oder aktualisiert werden, ordnet der Warteschlangenlese-Agent sie beim Kopieren vom Abonnenten in die Warteschlange wie folgt zu:

  • BIGINT, DECIMAL, NUMERIC, MONEYund SMALLMONEY werden NUMERICzugeordnet.

  • BINARY und VARBINARY werden VARBINARY -Daten zugeordnet.

Konflikterkennung und -lösung

• Für die Konfliktlösungsrichtlinie „Abonnent gewinnt“: Die Konfliktlösung wird für Aktualisierungen von 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 sind und die Daten gut partitioniert sind (Subscriber aktualisieren nicht dieselben Zeilen), können Sie Fremdschlüsselbeschränkungen beim Publisher und bei den Subscribern verwenden.

  • Wenn Konflikte zu erwarten sind: Sie sollten beim Publisher oder Subscriber keine Fremdschlüsselconstraints verwenden, wenn Sie die Konfliktlösung „Subscriber gewinnt“ verwenden; Sie sollten beim Subscriber keine Fremdschlüsselconstraints verwenden, wenn Sie die Konfliktlösung „Publisher gewinnt“ verwenden.

Zugehöriger Inhalt

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