Rozwiązywanie problemów z kolejkowaniem dzienników w zawsze włączonej grupie dostępności

Ten artykuł zawiera rozwiązania problemów związanych z kolejkowaniem wysyłania dzienników.

Co to jest kolejkowanie wysyłania dzienników?

Zmiany wprowadzone w bazie danych grupy dostępności w repliki podstawowej (na przykład INSERT, UPDATEi DELETE) są zapisywane w dzienniku transakcji i wysyłane do replik pomocniczych grupy dostępności. Kolejka wysyłania dziennika definiuje liczbę rekordów dziennika w plikach dziennika podstawowej bazy danych, które nie zostały wysłane do replik pomocniczych.

Objawy i efekt wysyłania dziennika w kolejce

Kolejka wysyłania dzienników przechowuje wszystkie dane podatne na zagrożenia

Jeśli replika podstawowa zostanie utracona w nagłej awarii i przełączysz ją w tryb failover do repliki pomocniczej, w której te zmiany nie zostały jeszcze wprowadzone, te zmiany nie pojawią się w nowej podstawowej kopii bazy danych. Wyklucza to wszelkie zmiany przechowywane podczas uruchamiania pełnej bazy danych i kopii zapasowych dziennika.

Rosnąca kolejka wysyłania dziennika powoduje wzrost wzrostu pliku dziennika transakcji

W przypadku bazy danych zdefiniowanej w grupie dostępności program Microsoft SQL Server musi zachować w replice podstawowej wszystkie transakcje w dzienniku transakcji, które nie zostały jeszcze dostarczone do replik pomocniczych. Kolejka wysyłania dziennika reprezentuje ilość zarejestrowanych zmian w repliki podstawowej, których nie można obciąć podczas normalnych zdarzeń obcinania dziennika (na przykład podczas tworzenia kopii zapasowej dziennika bazy danych). Duża i rosnąca kolejka wysyłania dziennika może wyczerpać wolne miejsce na dysku, który hostuje plik dziennika bazy danych lub może przekroczyć skonfigurowany maksymalny rozmiar pliku dziennika transakcji. Aby uzyskać więcej informacji, zobacz Błąd 9002, gdy dziennik transakcji jest duży.

Różne funkcje diagnostyczne zgłaszają kolejkowanie dzienników grup dostępności

Pulpit nawigacyjny Always On w programie SQL Server Management Studio raportuje kolejkowanie wysyłania dzienników. Może zgłosić, że grupa dostępności jest w złej kondycji.

Jak sprawdzić kolejkowanie wysyłania dzienników

Kolejka wysyłania dzienników jest miarą dla poszczególnych baz danych. Tę wartość można sprawdzić przy użyciu pulpitu nawigacyjnego Always On w repliki podstawowej lub przy użyciu sys.dm_hadr_database_replica_states dynamicznych widoków zarządzania (DMV) w repliki podstawowej lub pomocniczej. monitor wydajności liczniki służą do sprawdzania kolejkowania wysyłania dzienników względem repliki pomocniczej.

Następne kilka sekcji zawiera metody aktywnego monitorowania kolejki wysyłania dziennika bazy danych grupy dostępności.

Sys.dm_hadr_database_replica_state zapytań

Dynamiczny sys.dm_hadr_database_replica_states widok zarządzania raportuje wiersz dla każdej bazy danych grupy dostępności. Jedna kolumna w tym raporcie to log_send_queue_size. Ta wartość to rozmiar kolejki wysyłania dziennika w kilobajtach (KB). Możesz skonfigurować zapytanie, takie jak następujące zapytanie, aby monitorować dowolny trend w rozmiarze kolejki wysyłania dziennika. Zapytanie jest uruchamiane w repliki podstawowej. Używa is_local=0 predykatu do raportowania danych dla repliki pomocniczej, gdzie log_send_queue_size i log_send_rate są istotne.

WHILE 1=1
BEGIN
  SELECT drcs.database_name, ars.role_desc, drs.log_send_queue_size, drs.log_send_rate,
ars.recovery_health_desc, ars.connected_state_desc, ars.operational_state_desc, ars.synchronization_health_desc, *
  FROM sys.dm_hadr_availability_replica_states ars JOIN sys.dm_hadr_database_replica_cluster_states drcs ON ars.replica_id=drcs.replica_id
  JOIN sys.dm_hadr_database_replica_states drs ON drcs.group_database_id=drs.group_database_id
  WHERE ars.role_desc='SECONDARY' AND drs.is_local=0
  waitfor delay '00:00:30'
END

Oto jak wyglądają dane wyjściowe.

Przeglądanie kolejki wysyłania dziennika na pulpicie nawigacyjnym Always On

Aby przejrzeć kolejkę wysyłania dziennika, wykonaj następujące kroki:

Otwórz pulpit nawigacyjny Always On w programie SQL Server Management Studio (SSMS), klikając prawym przyciskiem myszy grupę dostępności w programie SSMS Eksplorator obiektów.
Wybierz pozycję Pokaż pulpit nawigacyjny.

Bazy danych grupy dostępności są wymienione na ostatniej liście i istnieją pewne dane zgłaszane w bazach danych. Mimo że rozmiar kolejki wysyłania dziennika (KB) i szybkość wysyłania dziennika (KB/s) nie są domyślnie wyświetlane, można dodać je do tego widoku, jak pokazano na zrzucie ekranu w następnym kroku.
Aby dodać te kolumny, kliknij prawym przyciskiem myszy nagłówek kolumny bazy danych grupy dostępności i wybierz z listy dostępnych kolumn.
Aby dodać rozmiar kolejki wysyłania dziennika, kliknij prawym przyciskiem myszy nagłówek wyświetlany na czerwono na poniższym zrzucie ekranu.

Domyślnie pulpit nawigacyjny Zawsze włączone automatycznie odświeża te dane co 60 sekund.

Przejrzyj kolejkę wysyłania dziennika w monitor wydajności

Kolejka wysyłania dziennika jest specyficzna dla każdej pomocniczej bazy danych repliki. W związku z tym, aby przejrzeć kolejkę wysyłania dziennika bazy danych grupy dostępności, wykonaj następujące kroki:

Otwórz monitor wydajności w repliki pomocniczej.
Wybierz przycisk Dodaj (licznik).
W obszarze Dostępne liczniki wybierz liczniki SQLServer:Database Replica i Log Send Queue.
W polu Lista wystąpienia wybierz bazę danych grupy dostępności, którą chcesz sprawdzić pod kątem kolejkowania wysyłania dzienników.
Wybierz pozycję Dodaj i OK.

Oto, jak może wyglądać rosnąca kolejka wysyłania dzienników.

Interpretowanie wartości kolejkowania wysyłania dziennika

W tej sekcji wyjaśniono, jak interpretować wartości rozmiaru kolejki wysyłania dziennika.

Kiedy wysyłanie dziennika jest nieprawidłowe? Ile kolejkowania wysyłania dzienników powinno być tolerowane?

Można założyć, że jeśli kolejka wysyłania dziennika zgłasza wartość 0, oznacza to, że w momencie tego raportu nie ma kolejkowania wysyłania dziennika. Jednak gdy środowisko produkcyjne jest zajęte, należy oczekiwać, że kolejka wysyłania dziennika często zgłasza wartość inną niż zero nawet w zdrowym środowisku AlwaysOn. Podczas typowej produkcji należy oczekiwać, że ta wartość waha się z zakresu od 0 do wartości innej niż zero.

Jeśli zauważysz zwiększenie liczby kolejek wysyłania dzienników w czasie, uzasadnione jest dalsze badanie. To dodatkowe działanie oznacza, że coś się zmieniło. Jeśli zauważysz nagły wzrost w kolejce wysyłania dziennika, następujące pomiary są przydatne do rozwiązywania problemów:

Szybkość wysyłania dziennika (KB/s) (pulpit nawigacyjny AlwaysOn)
sys.dm_hadr_database_replica_states (DMV)
Replika bazy danych::Dublowane transakcje na sekundę (monitor wydajności)

Pobieranie stawek bazowych dla szybkości wysyłania dziennika i dublowanych transakcji na sekundę

Podczas dobrej wydajności funkcji AlwaysOn monitoruj częstotliwość wysyłania dzienników i zdublowane wartości transakcji/s dla zajętych baz danych grup dostępności. Jak wyglądają w typowych godzinach pracy? Jak wyglądają w okresach konserwacji, gdy duże transakcje powodują większą przepływność transakcji w systemie? Te wartości można porównać podczas obserwowania wzrostu kolejki wysyłania dziennika, aby określić, co się zmieniło. Obciążenie może być większe niż zwykle. Jeśli szybkość wysyłania dziennika jest mniejsza niż zwykle, dalsze badanie może być wymagane, aby ustalić, dlaczego.

Woluminy obciążeń mają znaczenie

Jeśli masz duże obciążenia (takie jak UPDATE instrukcja względem 1 miliona wierszy, ponowne kompilowanie indeksu w tabeli 1 terabajtów, a nawet partii ETL, która wstawia miliony wierszy), należy oczekiwać, że niektóre wzrosty kolejki wysyłania dziennika będą widoczne natychmiast lub w czasie. Jest to oczekiwane, gdy w bazie danych grupy dostępności zostanie wprowadzona duża liczba zmian.

Jak zdiagnozować kolejkowanie wysyłania dzienników

Po zidentyfikowaniu kolejkowania wysyłania dzienników dla określonej bazy danych grupy dostępności należy sprawdzić kilka różnych głównych przyczyn problemu, jak opisano w poniższych sekcjach.

Ważne

W przypadku znaczących danych wyjściowych typu oczekiwania sprawdź wzrost kolejki wysyłania dziennika przy użyciu jednej z metod opisanych w poprzednich sekcjach podczas monitorowania następujących warunków.

System jest zbyt zajęty

Sprawdź, czy obciążenie repliki podstawowej przeciąża procesory CPU systemu. Jeśli widzisz wzrost kolejki wysyłania dziennika, wykonaj zapytanie dotyczące sys.dm_os_schedulers widoku DMV i monitora dla elementu high runnable_tasks_count. Ta liczba wskazuje na zaległe zadania uruchomione w tym czasie.

SELECT scheduler_address, scheduler_id, cpu_id, status, current_tasks_count, runnable_tasks_count, current_workers_count, active_workers_count
FROM sys.dm_os_schedulers

Poniższa tabela zawiera przykładowe wyniki. Wzrost runnable_tasks_count wartości wskazuje, że duża liczba zadań czeka na czas procesora CPU.

scheduler_address	scheduler_id	cpu_id	status	current_tasks_count	runnable_tasks_count	current_workers_count	active_workers_count
0x000002778D 200040	0	0	WIDOCZNE W TRYBIE OFFLINE	1	0	2	1
0x000002778D 220040 r.	1	1	WIDOCZNE W TRYBIE ONLINE	108	12	210	107
0x000002778D 240040	2	2	WIDOCZNE W TRYBIE ONLINE	113	2	123	113
0x000002778D 260040	3	3	WIDOCZNE W TRYBIE ONLINE	105	11	116	105
0x000002778D 480040	4	4	WIDOCZNE W TRYBIE ONLINE	108	15	117	108
0x000002778D 4A0040	5	5	WIDOCZNE W TRYBIE ONLINE	100	25	110	99
0x000002778D 4C0040	6	6	WIDOCZNE W TRYBIE ONLINE	105	23	113	105
0x000002778D 4E0040	7	7	WIDOCZNY	109	25	116	109
0x000002778D 700040	8	8	WIDOCZNE W TRYBIE ONLINE	98	10	112	98
0x000002778D 720040	9	9	WIDOCZNE W TRYBIE ONLINE	114	1	130	114
0x000002778D 740040	10	10	WIDOCZNE W TRYBIE ONLINE	110	25	120	110
0x000002778D 760040	11	11	WIDOCZNE W TRYBIE ONLINE	83	8	93	83
0x000002778D A00040	12	12	WIDOCZNE W TRYBIE ONLINE	104	4	117	104
0x000002778D A20040	13	13	WIDOCZNE W TRYBIE ONLINE	108	32	118	108
0x000002778D A40040	14	14	WIDOCZNE W TRYBIE ONLINE	102	12	113	102
0x000002778D A60040	15	15	WIDOCZNE W TRYBIE ONLINE	104	16	116	103

Rozwiązanie: W przypadku wykrycia wysokiego runnable_task_countpoziomu należy zmniejszyć obciążenie systemu lub zwiększyć liczbę procesorów, które są dostępne dla systemu.

Opóźnienie sieci

Ten warunek jest szczególnie powszechny, jeśli replika pomocnicza jest fizycznie zdalna z repliki podstawowej. Grupy dostępności obejmujące wiele lokacji umożliwiają klientom wdrażanie kopii danych biznesowych w wielu lokacjach na potrzeby odzyskiwania po awarii i raportowania. Dzięki temu zmiany niemal w czasie rzeczywistym są dostępne dla kopii danych produkcyjnych w lokalizacjach zdalnych.

Jeśli replika pomocnicza jest hostowana daleko od repliki podstawowej, kolejkowanie wysyłania dzienników może być spowodowane opóźnieniem sieci i brakiem możliwości wysyłania zmian do zdalnego pomocniczego tak szybko, jak są tworzone w podstawowej bazie danych repliki.

Ważne

Program SQL Server używa jednego połączenia do synchronizowania zmian z replik podstawowych do replik pomocniczych. W związku z tym, jeśli replika pomocnicza jest zdalna, szerokość potoku nie wpłynie na ilość danych, które może wysyłać program SQL Server. Zamiast tego ta ilość jest bardziej zależna od opóźnienia sieci w potoku (szybkość połączenia).

Testowanie opóźnienia sieci

Sprawdzanie, czy ustawienia sterowania przepływem przyczyniają się do opóźnienia sieci

Grupy dostępności programu Microsoft SQL Server używają bram sterowania przepływem, aby uniknąć nadmiernego zużycia zasobów sieciowych, pamięci i innych zasobów we wszystkich replikach dostępności. Te bramy sterowania przepływem nie mają wpływu na stan kondycji synchronizacji replik dostępności. Mogą one jednak mieć wpływ na ogólną wydajność baz danych dostępności, w tym cel punktu odzyskiwania.

Nowsze wersje programu SQL Server zmieniają progi, w których wprowadzono sterowanie przepływem. Może to pomóc złagodzić efekt, jaki kontrolka przepływu ma na objawy, takie jak kolejkowanie wysyłania dzienników. Aby uzyskać więcej informacji na temat sterowania przepływem i historii zmian progów sterowania przepływem, zobacz Bramy sterowania przepływem.

Sterowanie przepływem można monitorować przy użyciu monitor wydajności do przechwytywania danych w repliki podstawowej. Aby monitorować sterowanie przepływem bazy danych, dodaj liczniki SQLServer:Database Replica i wybierz liczniki Opóźnienia przepływu bazy danych i Kontrolki przepływu bazy danych/s . W oknie dialogowym Wystąpienie wybierz bazę danych grupy dostępności, którą chcesz sprawdzić pod kątem kontroli przepływu bazy danych. Aby wykryć i monitorować kontrolę przepływu repliki dostępności, dodaj liczniki SQLServer:Availability Replica i wybierz liczniki Czas sterowania przepływem (ms/s) i Sterowanie przepływem/s .
Sprawdź, czy przeciążenie ponownego uruchamiania systemu Windows przyczynia się do opóźnienia sieci

Problemy z wydajnością sieci, które powodują kolejkowanie wysyłania dzienników, mogą być wyzwalane przez ustawienie Przeciążenie systemu Windows Uruchom ponownie TCP ustawione na wartość True. To było ustawienie domyślne w systemie Windows Server 2016. Upewnij się, że ustawienie Ponowne uruchamianie okna przeciążenia ma wartość Fałsz na serwerach z systemem Windows hostujących repliki grupy dostępności, na których zaobserwowano kolejkowanie wysyłania dzienników.

PS C:\WINDOWS\system32> Get-NetTCPSetting | Select SettingName, CwndRestart

Aby uzyskać więcej informacji na temat ustawiania właściwości Ponowne uruchamianie systemu Windows przeciążenia TCP na false, zobacz Set-NetTCPSetting (NetTCPIP).

Zobacz również Monitorowanie wydajności zawsze włączonych grup dostępności, aby uzyskać informacje o procesie synchronizacji. W tym artykule przedstawiono również sposób obliczania niektórych kluczowych metryk oraz linki do niektórych typowych scenariuszy rozwiązywania problemów z wydajnością.

Użyj polecenia ping, aby uzyskać przykład opóźnienia

W wierszu polecenia w węźle Node1 (replika podstawowa), ping node2 (replika pomocnicza):

C:\Users\customer>ping node2
Pinging node2.customer.corp.company.com [<ip address>] with 32 bytes of data:
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=94ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=97ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=94ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=119ms

Ping statistics for 2<ip address>:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 94ms, Maximum = 119ms, Average = 101ms

Testowanie przepływności sieci z podstawowej do pomocniczej przy użyciu niezależnego narzędzia

Użyj narzędzia, takiego jak NTttcp, aby niezależnie wykrywać przepływność sieci między replikami podstawowymi i pomocniczymi przy użyciu jednego połączenia. Opóźnienie sieci jest częstą przyczyną kolejkowania wysyłania dzienników. W poniższych krokach pokazano, jak używać niezależnego narzędzia, takiego jak NTttcp, do mierzenia przepływności sieci.

Ważne

Program SQL Server wysyła zmiany z repliki podstawowej do repliki pomocniczej przy użyciu jednego połączenia. W poniższej sekcji skonfigurujemy i uruchomimy narzędzie NTttcp , aby używać pojedynczego połączenia (w taki sam sposób jak program SQL Server), aby dokładnie porównać przepływność.

Narzędzie NTttcp można pobrać z witryny Github — microsoft/ntttcp.

Aby uruchomić narzędzie NTttcp, wykonaj następujące kroki:
1. Pobierz i skopiuj narzędzie do serwerów podstawowych i pomocniczych opartych na programie SQL Server.
2. Na pomocniczym serwerze repliki otwórz okno wiersza polecenia z podwyższonym poziomem uprawnień, zmień katalog na folder narzędzia NTttcp , a następnie uruchom następujące polecenie:
  
  ntttcp.exe -r -m 1,0,<secondaryipaddress>-a 16 -t 60
  
  Uwaga 16.
  
  W tym poleceniu <secondaryipaddress> jest symbolem zastępczym rzeczywistego adresu IP pomocniczego serwera repliki.
3. Na serwerze repliki podstawowej otwórz okno wiersza polecenia z podwyższonym poziomem uprawnień, zmień katalog na folder narzędzia NTttcp, a następnie uruchom następujące polecenie, ponownie określając rzeczywisty adres IP serwera repliki pomocniczej:
  
  ntttcp.exe -s -m 1,0,<secondaryipaddress>-a 16 -t 60
  
  Na poniższych zrzutach ekranu przedstawiono serwer NTttcp uruchomiony w replikach pomocniczych i podstawowych. Ze względu na opóźnienie sieci narzędzie może wysyłać tylko 739 KB/s danych. To właśnie można oczekiwać, że program SQL Server będzie mógł wysyłać.
  
  NTttcp w repliki pomocniczej
  
  NTttcp w repliki podstawowej

Przeglądanie liczników monitor wydajności

Sprawdź, jakie raporty NTttcp. Duża transakcja jest uruchamiana w programie SQL Server w repliki podstawowej. Po uruchomieniu monitor wydajności w repliki podstawowej dodaj licznik Interfejs sieciowy::Bajty wysłane/s. Ten licznik potwierdza, że replika podstawowa może wysyłać około 777 KB/s danych. Jest to podobne do wartości 739 KB/s zgłoszonej przez test NTttcp.

Warto również porównać wartość SQL Server::D atabases::Log Bytes Flushed/sec w replice podstawowej do programu SQL Server::D atabase Replica::Log Bytes Received/sec dla tej samej bazy danych w replice pomocniczej. Średnio obserwujemy około 20 MB/s zmian utworzonych w bazie danych "agdb". Jednak replika pomocnicza odbiera średnio tylko 5,4 MB zmian. Spowoduje to kolejkowanie dzienników w replice podstawowej zaległych zmian w dzienniku transakcji bazy danych, które nie zostały jeszcze wysłane do repliki pomocniczej.

Bajty dziennika repliki podstawowej opróżnione/s dla bazy danych "agdb"

Odebrane/s bajty dziennika repliki pomocniczej dla bazy danych agdb

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-04-08