Czy uruchomienie dużego zapytania w dodatkowej bazie danych w grupie dostępności wpłynie na wydajność transakcji w podstawowej bazie danych?

Muszę dostarczyć dane w czasie rzeczywistym lub prawie w czasie rzeczywistym dla raportów SSRS i Tableau. Nie chcę, aby na produkcyjny system OLTP negatywnie wpływały długotrwałe zapytania. Czy uruchomienie dużego zapytania w dodatkowej bazie danych w grupie dostępności wpłynie na wydajność transakcji w podstawowej bazie danych?

Czy uruchomienie dużego zapytania w dodatkowej bazie danych w grupie dostępności wpłynie na wydajność transakcji w podstawowej bazie danych?

Zależy to od trybu synchronizacji użytego podczas konfigurowania grupy dostępności - Synchronizacja lub Asynchronizacja!

Na replice wtórnej , wszystkie transakcje użyciu poziom izolacji migawka TYLKO i wszystkie podpowiedzi blokujące są ignorowane, jak również. Dlatego ważne jest, aby przetestować obciążenie pracą podczas korzystania z AlwaysON.

Od: Minimalizowanie blokowania wątku REDO podczas uruchamiania obciążenia raportowaniem w replice dodatkowej

Podczas gdy mapowanie obciążenia raportowania na izolację migawki eliminuje blokowanie między obciążeniem DML stosowanym przez wątek REDO w replice wtórnej a obciążeniem odczytu lub raportowania, nie eliminuje potencjalnego blokowania wątku REDO podczas wykonywania operacji DDL .

Jeśli używasz

• Tryb synchroniczny

  • Problem z blokowaniem wtórnej repliki wpłynie na wydajność zapytań w głównej replice. W związku z tym obciążenie odczytu (wybierz) uruchomione na serwerze pomocniczym może zablokować zastosowanie przez wątek ponownej zmiany do zmian pochodzących z repliki podstawowej. Oznacza to, że główna replika musi poczekać, aż zmiany zostaną zastosowane do wszystkich drugorzędnych replik SYNC, zanim uruchomi się lokalnie i może skończyć się przekroczeniem limitu czasu, blokowaniem lub zakleszczeniem.

    Wątek REDO można zobaczyć w Readable Secondary jako DB STARTUPpolecenie w sys.dm_exec_requests. Jeśli ten wątek jest blokowany, obciążenie pracą odczytu na serwerze pomocniczym może mieć wpływ na serwer główny.

    Aby uzyskać więcej informacji, sprawdź - Scenariusz 1: Zablokowane REDO z powodu dużego zapytania w replice dodatkowej

• Tryb asynchroniczny

  • Główny nie czeka na potwierdzenie z drugiego. Problem blokowania drugorzędnego jest po prostu izolowany do drugorzędnego, w którym kolejka ponawiania będzie rosła na drugorzędnym, dopóki blokady nie zostaną wyczyszczone, a wątek ponawiania będzie mógł zastosować bloki dziennika. Nie wpłynie to na replikę podstawową.

Twoja definicja „w czasie rzeczywistym lub prawie w czasie rzeczywistym” wymaga głębszego przemyślenia, biorąc pod uwagę zastosowaną metodę synchronizacji, opóźnienie sieci i stopień zajętości repliki podstawowej oraz aktywność dziennika, którą należy przetransportować jako dodatkową.

SQL Server 2016 wprowadził kilka istotnych ulepszeń w dziedzinie AlwaysON, np

• Ulepszone algorytmy kompresji i równoległa kompresja danych bloku dziennika
• 4x do 5-krotna poprawa przepustowości transportu bloków kłód
• i wiele innych - po prostu działa szybciej !