UPDATE-Anweisungen können als DELETE/INSERT-Paare repliziert werden

In diesem Artikel wird beschrieben, dass Update-Anweisungen als DELETE/INSERT-Paare repliziert werden können.

Ursprüngliche Produktversion: SQL Server
Ursprüngliche KB-Nummer: 238254

Zusammenfassung

Wenn eine Spalte, die Teil einer Unique-Einschränkung ist, aktualisiert wird, implementiert SQL Server das Update als "verzögertes Update", d. h. als Paar von DELETE/INSERT Vorgängen. Dieses "verzögerte Update" bewirkt, dass die Replikation ein Anweisungspaar DELETE/INSERT an die Abonnenten sendet. Es gibt auch andere Situationen, die zu einem verzögerten Update führen können. Daher sollte jede Geschäftslogik, die Sie in Ihren UPDATE Triggern oder benutzerdefinierten gespeicherten Prozeduren auf dem Abonnenten implementieren, auch in die DELETE/INSERT Trigger oder benutzerdefinierten gespeicherten Prozeduren einbezogen werden.

Weitere Informationen

Das Standardverhalten bei der Transaktionsreplikation besteht darin, und UPDATEDELETE benutzerdefinierte gespeicherte Prozeduren zu verwendenINSERT, um Änderungen an den Abonnenten anzuwenden.

INSERT -Anweisungen auf dem Verleger werden über einen Aufruf einer INSERT gespeicherten Prozedur auf Abonnenten angewendet. Auf ähnliche Weise wird eine DELETE -Anweisung über einen Aufruf einer DELETE gespeicherten Prozedur angewendet.

Wenn eine UPDATE Anweisung jedoch als "verzögertes Update" ausgeführt wird, platziert der Logreader-Agent ein Paar von Aufrufen gespeicherter DELETE/INSERT Prozeduren in der Verteilungsdatenbank, die auf die Abonnenten angewendet werden sollen, anstatt einen Aufruf der gespeicherten Prozedur zu aktualisieren. Angenommen, Sie verfügen über eine Veröffentlichungstabelle namens TABLE1mit den folgenden drei Spalten:

• col1 int
• col2 int
• col3 varchar(30)

Die einzige unique-Einschränkung für TABLE1 wird für über eine Primärschlüsseleinschränkung definiert col1 . Angenommen, Sie verfügen über einen Datensatz (1,1,'Dallas').

Wenn Sie diesen Code ausführen:

UPDATE TABLE1 set col1 = 3 where col3 = 'Dallas'

Die UPDATE Anweisung wird von SQL Server als Paar vonINSERTDELETE/Anweisungen implementiert, da Sie aktualisierencol1, für die ein eindeutiger Index definiert ist. Daher platziert der Logreader ein Paar von DELETE/INSERT Aufrufen in der Verteilungsdatenbank. Dies kann sich auf jede Geschäftslogik auswirken, die in den Triggern oder benutzerdefinierten gespeicherten Prozeduren auf dem Abonnenten vorhanden ist. Sie sollten die zusätzliche Geschäftslogik in DELETE Trigger und INSERT oder gespeicherte Prozeduren integrieren, um diese Situation zu behandeln.

Wenn Sie eine einzelne Logik verwenden möchten und alle Befehle UPDATE als DELETE/INSERT Paare repliziert werden sollen, können Sie ein Ablaufverfolgungsflag aktivieren.

Wenn Sie einen horizontalen Filter in Ihrer Publikation verwenden und die aktualisierte Zeile keine Filterbedingung erfüllt, wird nur ein DELETE Prozeduraufruf an die Abonnenten gesendet. Wenn die aktualisierte Zeile zuvor nicht die Filterbedingung erfüllt, aber die Bedingung nach dem Update erfüllt, wird nur der INSERT Prozeduraufruf über den Replikationsprozess gesendet.

Gehen Sie im vorherigen Beispiel davon aus, dass sie auch einen horizontalen Filter für TABLE1definiert haben: where col3 = 'Dallas'. Wenn Sie diesen Code ausführen:

UPDATE table1 set col3 = 'New York' where col1 = 3

Der Logreader-Agent platziert nur einen Aufruf einer DELETE gespeicherten Prozedur, der auf die Abonnenten angewendet wird, da die aktualisierte Zeile die horizontalen Filterkriterien nicht erfüllt.

Wenn Sie nun diesen Code ausführen:

UPDATE table1 set col3 = 'Dallas' where col1 = 3

der logreader generiert nur den Aufruf der INSERT gespeicherten Prozedur, da die Zeile zuvor die Filterbedingung nicht erfüllt hat.

Obwohl ein UPDATE Vorgang auf dem Verleger ausgeführt wurde, werden nur die entsprechenden Befehle auf den Abonnenten angewendet.