Aktualizowalne subskrypcje – do replikacji transakcyjnej

Dotyczy:SQL Server

Replikacja transakcyjna obsługuje aktualizacje w subskrybentach za pośrednictwem subskrypcji z możliwością aktualizacji i replikacji równorzędnej. Poniżej przedstawiono dwa typy subskrypcji, które można aktualizować:

• Natychmiastowe aktualizowanie. Wydawca i subskrybent muszą być połączeni, aby zaktualizować dane u subskrybenta.

• Aktualizowanie w kolejce Wydawca i Subskrybent nie muszą być połączeni, aby aktualizować dane u Subskrybenta. Możesz aktualizować dane, gdy Subskrybent lub Publisher jest offline.

Gdy aktualizujesz dane u subskrybenta, najpierw trafiają do Publisher, a następnie do innych subskrybentów. Jeśli używasz natychmiastowej aktualizacji, zmiany zachodzą natychmiast za pomocą protokołu dwufazowego zatwierdzania. Jeśli używasz aktualizacji w kolejce, zmiany trafiają do kolejki. Kolejkowe transakcje trafiają do Publisher asynchronicznie, gdy dostępna jest łączność sieciowa. Ponieważ aktualizacje trafiają do Publisher asynchronicznie, te same dane mogą być aktualizowane przez Publisher lub innego Subskrybenta i mogą wystąpić konflikty podczas ich wdrażania. System wykrywa i rozwiązuje konflikty zgodnie z polityką rozwiązywania konfliktów, którą ustawiasz podczas tworzenia publikacji.

W przypadku utworzenia publikacji transakcyjnej z aktualizowalnymi subskrypcjami w Kreatorze nowej publikacji włączono zarówno natychmiastowe aktualizowanie, jak i aktualizowanie w kolejce. Jeśli tworzysz publikację z procedurami składowanymi, można włączyć jedną lub obie opcje. Podczas tworzenia subskrypcji publikacji należy określić tryb aktualizacji do użycia. W razie potrzeby można przełączać się między trybami aktualizacji. Aby uzyskać więcej informacji, zobacz następującą sekcję "Przełączanie między trybami aktualizacji".

Aby umożliwić aktualizowalne subskrypcje dla publikacji transakcyjnych, zobacz Włączenie aktualizacji subskrypcji dla publikacji transakcyjnych.

Aby utworzyć aktualizowalne subskrypcje publikacji transakcyjnych, zobacz Utwórz aktualizowalną subskrypcję dla publikacji transakcyjnej (Management Studio).

Przełączanie się między trybami aktualizacji

Gdy korzystasz z subskrypcji aktualizowalnych, możesz określić jeden tryb aktualizacji dla subskrypcji i przełączyć się na drugi, jeśli aplikacja tego wymaga. Na przykład możesz określić, że subskrypcja korzysta z natychmiastowej aktualizacji, ale przełączyć się na aktualizacje w kolejce, jeśli awaria systemu spowoduje utratę łączności sieciowej.

Jeśli przełączysz się z aktualizowania natychmiastowego na aktualizowanie kolejkowane, nie możesz wrócić do aktualizowania natychmiastowego, dopóki Subskrybent i Publikujący nie nawiążą połączenia, a Agent czytnika kolejki nie zastosuje do Publikującego wszystkich oczekujących komunikatów z kolejki.

Aby przełączać się między trybami aktualizacji

Aby przełączać się między trybami aktualizacji, włącz publikację i subskrypcję dla obu trybów, a następnie przełączaj się między nimi, jeśli to konieczne. Aby uzyskać więcej informacji, zobacz
Przełączanie między trybami aktualizacji dla aktualizowalnej subskrypcji transakcyjnej.

Uwagi dotyczące korzystania z subskrypcji z możliwością aktualizacji

• Po włączeniu publikacji do aktualizacji subskrypcji lub aktualizacji subskrypcji w kolejce nie możesz wyłączyć tej opcji publikacji (choć subskrypcje nie muszą z niej korzystać). Aby wyłączyć tę opcję, usuń publikację i stwórz nową.

• Ponowne publikowanie danych nie jest obsługiwane.

• Replikacja dodaje kolumnę msrepl_tran_version do opublikowanych tabel na potrzeby śledzenia. Ze względu na tę dodatkową kolumnę uwzględnij listę kolumn we wszystkich instrukcjach INSERT.

• Aby wprowadzić zmiany schematu w tabeli w publikacji obsługującej subskrypcje z możliwością aktualizacji, należy zatrzymać całą aktywność dotyczącą tej tabeli u Wydawcy i Subskrybentów oraz rozpropagować wszystkie oczekujące zmiany danych do wszystkich węzłów przed wprowadzeniem jakichkolwiek zmian schematu. Proces ten zapewnia, że zaległe transakcje nie kolidują z oczekującą zmianą schematu. Po rozprzestrzenieniu się zmian schematu do wszystkich węzłów, aktywność może wznowić się na opublikowanych tabelach. Aby uzyskać więcej informacji, zobacz Quiesce a Replication Topology (Replication Transact-SQL Programming).

• Aby przełączać się między trybami aktualizacji, Agent Reader Queue musi uruchomić się co najmniej raz po inicjalizacji subskrypcji (domyślnie Agent Reader Queue działa nieprzerwanie).

• Jeśli baza danych Subskrybentów jest podzielona poziomo i w partycji istnieją wiersze istniejące u Subskrybenta, ale nie u Publisher, Subskrybent nie może zaktualizować istniejących wierszy. Próba zaktualizowania tych wierszy zwraca błąd. Usuń wiersze z tabeli, a następnie dodaj je w Publisher.

• Replikacja transakcyjna z kolejkowymi subskrybentami z możliwością aktualizacji może doświadczać spowolnienia wydajności, gdy używa się unikalnych indeksów filtrowanych. Jeśli w artykule mającym unikalne indeksy filtrowane wystąpi konflikt, jego rozwiązywanie powoduje dodatkowe operacje usuwania i wstawiania u subskrybenta dla wierszy, które nie są objęte unikalnymi indeksami filtrowanymi.

Aktualizacje dla subskrybenta

• Aktualizacje na Subscriber trafiają do Publisher nawet jeśli subskrypcja wygasła lub jest nieaktywna. Upewnij się, że rezygnujesz lub ponownie inicjalizujesz takie subskrypcje.

• Jeśli używasz kolumn TIMESTAMP lub IDENTITY i replikujesz je jako ich bazowe typy danych, nie aktualizuj wartości w tych kolumnach na subskrybencie.

• Subskrybenci nie mogą aktualizować ani wstawiać wartości tekstowych, ntextowych ani obrazów , ponieważ wyzwalacze śledzenia zmian replikacji nie mogą odczytywać z wstawianych lub usuniętych tabel. Podobnie subskrybaci nie mogą aktualizować ani wstawiać wartości tekstu lub obrazów za pomocą WRITETEXT lub UPDATETEXT, ponieważ Publisher nadpisuje dane. Zamiast tego można podzielić kolumny tekstu i obrazu na osobną tabelę i zmodyfikować obie tabele w ramach transakcji.

  Aby zaktualizować duże obiekty u subskrybenta, użyj odpowiednio typów danych varchar(max), nvarchar(max) i varbinary(max) zamiast typów danych text, ntext i image.

• Aktualizacje unikalnych kluczy (w tym kluczy głównych), które generują duplikaty, takie jak aktualizacja formularza UPDATE <column> SET <column> =<column>+1, nie są dozwolone i są odrzucane z powodu naruszenia unikalności. Aktualizacje zbiorcze wprowadzone u subskrybenta są propagowane przez replikację jako pojedyncze instrukcje UPDATE dla każdego wiersza, którego dotyczy aktualizacja.

• Jeśli baza danych Subskrybentów jest podzielona poziomo, a partycja zawiera wiersze istniejące u Subskrybenta, ale nie u Publisher, Subskrybent nie może zaktualizować istniejących wierszy. Próba zaktualizowania tych wierszy zwraca błąd. Usuń i wstaw je ponownie.

Wyzwalacze zdefiniowane przez użytkownika

• Jeśli aplikacja wymaga triggerów u Subskrybenta, zdefiniuj je za pomocą opcji NOT FOR REPLICATION u Publikatora i Subskrybenta. Ta opcja zapewnia, że wyzwalacze są uruchamiane tylko dla pierwotnej zmiany danych, a nie wtedy, gdy replikacja propaguje tę zmianę.

  Upewnij się, że trigger zdefiniowany przez użytkownika nie uruchamia się, gdy wyzwalacz replikacji aktualizuje tabelę. Wywołaj procedurę sp_check_for_sync_trigger w ciele wyzwalacza zdefiniowanego przez użytkownika. Aby uzyskać więcej informacji, zobacz sp_check_for_sync_trigger (Transact-SQL).

Natychmiastowe aktualizowanie

• Aby uzyskać natychmiastową aktualizację subskrypcji, zmiany na Subscriber są przekazywane do Publisher i stosowane za pomocą Microsoft Distributed Transaction Coordinator (MS DTC). Upewnij się, że usługa MS DTC jest zainstalowana i skonfigurowana w wydawcy i subskrybenta. Aby uzyskać więcej informacji, zobacz dokumentację systemu Windows.

• Wyzwalacze używane przez subskrypcje z natychmiastową aktualizacją wymagają połączenia z Publikatorem, aby replikować zmiany.

• Jeśli publikacja zezwala na subskrypcje z natychmiastową aktualizacją, a artykuł w tej publikacji ma filtr kolumnowy, nie można za pomocą filtru wykluczyć kolumn niedopuszczających wartości NULL i niemających wartości domyślnych.

Aktualizacja w kolejce

• Nie można publikować tabel zawartych w publikacji merge jako części publikacji transakcyjnej, która pozwala na kolejkowe aktualizacje subskrypcji.

• Nie aktualizuj kolumn klucza głównego podczas aktualizacji w kolejce, ponieważ klucz główny służy jako lokalizator rekordów dla wszystkich zapytań. Gdy polityka rozwiązywania konfliktów jest ustawiona na Subscriber Wins, należy zachować ostrożność przy aktualizowaniu kluczy głównych. Jeśli zarówno Publisher, jak i Subskrybent zaktualizują klucz główny, wynik to dwa wiersze z różnymi kluczami głównymi.

• Dla kolumn danych typu SQL_VARIANT: gdy dane są wstawiane lub aktualizowane w Subscriber, Agent Reader Queue mapuje je w następujący sposób, gdy kopiuje dane od Abonenta do kolejki:

  • BIGINT, DECIMAL, NUMERIC, MONEY i SMALLMONEY są mapowane na NUMERIC.

  • BINARY i VARBINARY są mapowane na typ danych VARBINARY.

Wykrywanie i rozwiązywanie konfliktów

• W przypadku zasady rozstrzygania konfliktów Subscriber Wins: mechanizm rozstrzygania konfliktów nie obsługuje aktualizacji kolumn klucza głównego.

• Replikacja nie rozwiązuje konfliktów spowodowanych awariami ograniczeń klucza obcego:

  • Jeśli nie spodziewasz się konfliktów, a dane są dobrze podzielone (subskrybenci nie aktualizują tych samych wierszy), użyj ograniczeń kluczy obcych u wydawcy i subskrybentów.

  • Jeśli spodziewasz się konfliktów: nie używaj ograniczeń kluczy obcych u Publikującego ani u Subskrybenta, jeśli używasz mechanizmu rozwiązywania konfliktów „Subskrybent wygrywa”. Nie używaj ograniczeń kluczy obcych u subskrybenta, jeśli stosujesz mechanizm rozwiązywania konfliktów „Wygrywa wydawca”.

Treści powiązane

• Peer-to-Peer – replikacja transakcyjna
• Replikacja transakcyjna
• Publikowanie danych i obiektów bazy danych
• Subskrybowanie publikacji