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?
Odpowiedzi:
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.
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
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