Instrukcje UPDATE mogą być replikowane jako pary DELETE/INSERT

W tym artykule opisano, że instrukcje Update mogą być replikowane jako pary DELETE/INSERT.

Oryginalna wersja produktu: SQL Server
Oryginalny numer KB: 238254

Podsumowanie

Jeśli zostanie zaktualizowana dowolna kolumna będąca częścią unikatowego ograniczenia, program SQL Server implementuje aktualizację jako "odroczoną aktualizację", co oznacza parę DELETE/INSERT operacji. Ta "odroczona aktualizacja" powoduje, że replikacja wysyła parę instrukcji DELETE/INSERT do subskrybentów. Istnieją również inne sytuacje, które mogą spowodować odroczenie aktualizacji. W związku z tym każda logika biznesowa implementowana w UPDATE wyzwalaczach lub niestandardowych procedurach składowanych na subskrybentu powinna być również uwzględniona w DELETE/INSERT wyzwalaczach lub niestandardowych procedurach składowanych.

Więcej informacji

Domyślnym zachowaniem replikacji transakcyjnej jest użycie INSERTniestandardowych procedur składowanych , UPDATEi DELETE w celu stosowania zmian u subskrybentów.

INSERT instrukcje dokonane w wydawcy są stosowane do subskrybentów za pośrednictwem INSERT wywołania procedury składowanej. DELETE Podobnie instrukcja jest stosowana za pomocą wywołania DELETE procedury składowanej.

Jednak gdy UPDATE instrukcja jest wykonywana jako "odroczona aktualizacja", agent czytnika dzienników DELETE/INSERT umieszcza parę wywołań procedury składowanej w bazie danych dystrybucji, które mają być stosowane do subskrybentów, a nie do wywołania procedury składowanej aktualizacji. Załóżmy na przykład, że masz tabelę publikowania o nazwie TABLE1, z następującymi trzema kolumnami:

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

Jedynym unikatowym ograniczeniem TABLE1 jest definiowane col1 za pomocą ograniczenia klucza podstawowego. Załóżmy, że masz jeden rekord (1,1,'Dallas').

Po wykonaniu tego kodu:

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

Instrukcja UPDATE jest implementowana przez program SQL Server jako parę instrukcjiINSERTDELETE/, ponieważ aktualizujesz col1element , który ma zdefiniowany unikatowy indeks. W związku z tym czytnik dzienników umieszcza parę wywołań DELETE/INSERT w bazie danych dystrybucji. Może to mieć wpływ na dowolną logikę biznesową, która jest obecna w wyzwalaczach lub niestandardowych procedurach składowanych na subskrybenta. Aby obsłużyć tę sytuację, należy uwzględnić dodatkową logikę biznesową w DELETE wyzwalaczach i INSERT wyzwalaczach lub procedurach składowanych.

Jeśli wolisz replikować aktualizacje z jednym wierszem jako UPDATE instrukcje zamiast DELETE lub INSERT pary, możesz włączyć flagę śledzenia 8207.

Ponadto jeśli używasz filtru poziomego w publikacji i jeśli zaktualizowany wiersz nie spełnia warunku filtru, do subskrybentów jest wysyłane tylko DELETE wywołanie procedury. Jeśli zaktualizowany wiersz wcześniej nie spełnia warunku filtru, ale spełnia warunek po aktualizacji, INSERT tylko wywołanie procedury jest wysyłane przez proces replikacji.

W poprzednim przykładzie przyjęto założenie, że istnieje również filtr poziomy zdefiniowany w pliku TABLE1: where col3 = 'Dallas'. Jeśli wykonasz ten kod:

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

Agent czytnika dzienników umieszcza DELETE wywołanie procedury składowanej, które ma zostać zastosowane do subskrybentów, ponieważ zaktualizowany wiersz nie spełnia kryteriów filtrowania poziomego.

Teraz, jeśli wykonasz ten kod:

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

Czytnik dzienników generuje tylko INSERT wywołanie procedury składowanej, ponieważ wiersz wcześniej nie spełniał warunku filtru.

UPDATE Mimo że operacja została wykonana w wydawcy, na subskrybenta są stosowane tylko odpowiednie polecenia.