Zatrzymaj replikację dużej transakcji w SQL Server

Question

Mam pytanie dotyczące próby wstrzymania dużej transakcji u wydawcy dystrybuowanego do subskrybentów. Powiedzmy, że ktoś przypadkowo aktualizuje każdy rekord w tabeli z 50 milionami rekordów, a następnie, po popełnieniu błędu, przywraca wszystkie rekordy. W tym przypadku zmiany zostaną rozdzielone między dwóch subskrybentów w konfiguracji replikacji transakcyjnej. W systemie mówi, że będzie 2 dni, aby replikować do subskrybentów, ale jaki jest najlepszy sposób na pokonanie tego?

Widziałem, że jest możliwe i w rzeczywistości bardzo łatwo pominąć polecenie, korzystając z transakcji: xact_seqno, sp_helpsubscriptionerrors i sp_setsubscriptionxactseqno. Co się jednak stanie, jeśli zostanie to użyte w transakcji, która była aktywnie dystrybuowana? Czy należy coś zatrzymać?

Jeśli to nie jest najlepszy sposób na rozwiązanie problemu, co by to było?

Answer 1

Nie testowałem tego jednak w szczególności: Zatrzymanie transakcji w toku, samo w sobie, niekoniecznie spowoduje problemy i zostanie wycofane - wszelkie transakcje, w tym replikowane transakcje na subskrybencie wydawcy . Wynika to z właściwości ACID, które zawsze mają zastosowanie do transakcji, w szczególności: albo wszystko w transakcji występuje, albo nic się nie dzieje. Tak więc zatrzymana lub nieudana transakcja zostanie całkowicie wycofana.

Nie znam innego sposobu zatrzymania replikacji transakcji, jednak ostrożnie, należy zachować ostrożność nie tylko przy korzystaniu z sp_setsubscriptionxactseqno, ale cokolwiek się stanie, będzie to oznaczać, że jesteś wydawcą a subskrybent nie jest już w pełni zsynchronizowany. W praktyce może to nie mieć znaczenia, ale powinno to być brane pod uwagę.

Jeśli nie masz jeszcze rzucić okiem na Technet/MSDN (mniej więcej ten sam artykuł zależy czy wolisz TNET z DevNet), jeśli jeszcze nie masz, a this blog post on MSDN, że pomogę. N.B. sp_setsubscriptionxactseqno należy uruchomić na subskrybencie (i każdym, na którym chcesz go pominąć).

Alternatywą i bez żadnych innych informacji, polecam tylko pozwolić jej działać. To może nie być idealne, ale jest to najbezpieczniejsza i najmniejsza praca. Czy ten system, który jest krytyczny i zależny od czasu, powoduje, że 2 dni wywołają poważne problemy?

Wreszcie, jako ogólna porada, jeśli nie jesteś pewien, co zrobić - odbierz decyzję swojemu przełożonemu lub innym wyższym. Przedstaw opcje, pracę i ryzyko/wpływ (w tym opcję nie robienia niczego) i obwiniaj (subtelnie i biurowo-politycznie uzasadnione) osobę, która dokonała początkowego "wypadku" (chyba że to ty, to może ty nie wiesz) t chcesz powiedzieć wyższym).

Answer 2

bez wpływu na jakichkolwiek zastrzeżeń transakcja aktywny lub not.since nie wpłynie to w jaki sposób działa transakcję, to tylko pomija tę transakcję i powoduje problemy z integralnością danych ..

dziennika agenta Czytnik odczytuje wszystkie rekordy aktualizowane w wydawca i dystrybutor aktualizacje je w DB, koniec zaznacza je jako popełnione ...

teraz Agent dystrybucji następnie stosuje wszystkie polecenia, które mają wyższe niż timestamp kolumna transaction_timestamp w msreplication_subscriptions tabeli

select publisher_database_id, xact_id, xact_seqno, entry_time from msrepl_transactions order by publisher_database_id 

Tak więc w zasadzie mówimy o tym, jak sprawić, aby subskrybent zaczął od innego polecenia, a nawet je pominąć.Można skorzystać z poniższego polecenia w bazie danych abonentów, aby pominąć tę transakcję ..

sp_setsubscriptionxactseqno [ @publisher = ] 'publisher' 
     , [ @publisher_db = ] 'publisher_db' 
     , [ @publication = ] 'publication' 
     , [ @xact_seqno = ] xact_seqno 

Answer 3

Jak ważna jest integralność danych i jaka jest twoja zdolność do odzyskania? Z jakim rozmiarem partycji ustawiłeś replikację? Możesz zatrzymać harmonogramy i po prostu pozwolić, aby bieżący xact się zakończył, aby nie wprowadzać wycofania subskrybentów. Możesz uzyskać dostęp do tabel wydawcy i zrzucić transakcje, ale usunie również wszelkie inne zmiany, które zostały zarejestrowane. Może być konieczne ponowne dostosowanie danych. Sam proces replikacji powinien podzielić aktualizacje na mniejsze numery transakcji (xact_seqno). Następnie możesz usunąć rekordy z kolejek. Upewnij się, że nie ma zaległości w kolejkach. 50M może przesuwać ograniczenia pamięci, które dałeś tabelom kolejki dystrybucyjnej, więc gdy rozpoczniesz usuwanie przez xact_secno, sprawdź, czy nie ma żadnych, które są jeszcze zapisywane. Możesz sprawdzić, jakie komendy są dostępne, i sprawdzić, czy pochodzą z tej samej ogromnej aktualizacji lub z nowej aktywności. I przygotuj się na utratę wszystkich innych replik danych z innych tabel lub z tego, co robisz (w zależności od tego, jak skonfigurujesz transakcje). Przygotuj abonament po abonamencie, zanim zrestartujesz replikację.

Answer 4

W zależności od wielkości tabeli upuszczenie/ponowne dodanie tego artykułu może być szybsze. Ponieważ migawka wykorzystuje masową kopię do przeniesienia wierszy do subskrybenta, powinna być dość szybka.