Udostępnij za pomocą

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

Ten artykuł zawiera rozwiązania problemów związanych z kolejkowaniem odzyskiwania.

Co to jest kolejkowanie odzyskiwania?

Zmiany wprowadzone w replice podstawowej w bazie danych grupy dostępności są wysyłane do wszystkich replik pomocniczych zdefiniowanych w tej samej grupie dostępności. Po nadejściu tych zmian do replik pomocniczych są one najpierw zapisywane w pliku dziennika transakcji bazy danych grupy dostępności. Program Microsoft SQL Server następnie używa operacji odzyskiwania lub ponownego wykonania w celu zaktualizowania plików bazy danych.

Jeśli zmiany w grupie dostępności docierają i wzmacniają zabezpieczenia pliku dziennika transakcji bazy danych szybciej niż można je odzyskać, zostanie utworzona kolejka odzyskiwania. Ta kolejka składa się ze wzmocnionych transakcji dziennika transakcji, które nie zostały odzyskane i przywrócone do bazy danych.

Objawy i efekt odzyskiwania (powtórzenie) kolejkowania

Wykonywanie zapytań względem replik podstawowych i pomocniczych zwraca różne wyniki

Obciążenia tylko do odczytu, które wysyłają zapytania do replik pomocniczych, mogą wysyłać zapytania dotyczące nieaktualnych danych. Jeśli wystąpi kolejkowanie odzyskiwania, zmiany danych w podstawowej bazie danych repliki mogą nie zostać odzwierciedlone w pomocniczej bazie danych podczas wykonywania zapytań dotyczących tych samych danych.

Mimo że zmiany docierają do pomocniczej bazy danych i są zapisywane w pliku dziennika bazy danych, zmiany nie będą odpytywane, dopóki nie zostaną odzyskane i przywrócone do plików bazy danych. Operacja odzyskiwania powoduje, że te zmiany można odczytać.

Aby uzyskać więcej informacji, zobacz sekcję Opóźnienie danych w repliki pomocniczej w temacie "Różnice między trybami dostępności dla zawsze włączonej grupy dostępności".

Czas pracy w trybie failover jest dłuższy lub przekroczono cel czasu odzyskiwania

Cel czasu odzyskiwania (RTO) to maksymalny przestój bazy danych, który organizacja może obsłużyć. Cel czasu odzyskiwania opisuje również, jak szybko organizacja może odzyskać dostęp do bazy danych po awarii. Jeśli w replice pomocniczej występuje znaczna kolejka odzyskiwania, odzyskiwanie może trwać dłużej. Po odzyskaniu baza danych przejdzie do roli podstawowej i będzie reprezentować stan bazy danych, która istniała przed przejściem w tryb failover. Dłuższy czas odzyskiwania może opóźnić szybkość wznowienia produkcji po przejściu w tryb failover.

Różne funkcje diagnostyczne zgłaszają kolejkowanie odzyskiwania grupy dostępności

W przypadku kolejkowania odzyskiwania pulpit nawigacyjny Always On w programie SQL Server Management Studio (SSMS) może zgłosić złą kondycję grupy dostępności.

Jak sprawdzić kolejkowanie odzyskiwania (powtórzenie)

Kolejka odzyskiwania to pomiar dla bazy danych, który można sprawdzić przy użyciu pulpitu nawigacyjnego Always On w replice podstawowej lub przy użyciu widoku zarządzania dynamicznego (DMV) sys.dm_hadr_database_replica_states w replice podstawowej lub pomocniczej. monitor wydajności liczniki sprawdzają kolejkowanie odzyskiwania i szybkość odzyskiwania. Te liczniki muszą być sprawdzane względem repliki pomocniczej.

Następne kilka sekcji zawiera metody aktywnego monitorowania kolejki odzyskiwania bazy danych grupy dostępności.

Sys.dm_hadr_database_replica_states 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 raporcie to redo_queue_size. Ta wartość to rozmiar kolejki odzyskiwania mierzony w kilobajtach. Możesz skonfigurować zapytanie podobne do poniższego zapytania, aby monitorować dowolny trend w rozmiarze kolejki odzyskiwania co 30 sekund. Zapytanie jest uruchamiane w repliki podstawowej. Używa is_local=0 predykatu do raportowania danych dla repliki pomocniczej, gdzie redo_queue_size i redo_rate są istotne.

WHILE 1=1
BEGIN
SELECT drcs.database_name, ars.role_desc, drs.redo_queue_size, drs.redo_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.

Zrzut ekranu przedstawiający dane wyjściowe zapytania raportu dotyczące danych repliki pomocniczej, w których redo_queue_size i redo_rate są istotne.

Przejrzyj kolejkę odzyskiwania na pulpicie nawigacyjnym zawsze włączonym

Aby przejrzeć kolejkę odzyskiwania, wykonaj następujące kroki:

  1. Otwórz pulpit nawigacyjny Always On Dashboard w programie SSMS, klikając prawym przyciskiem myszy grupę dostępności w programie SSMS Eksplorator obiektów.

  2. 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 ponownej (KB) i częstotliwość ponownego wdrażania (KB/s) nie są domyślnie wyświetlane, można dodać je do tego widoku, jak pokazano na zrzucie ekranu w następnym kroku.

  3. Aby dodać te liczniki, kliknij prawym przyciskiem myszy nagłówek nad raportami bazy danych i wybierz z listy dostępnych kolumn.

  4. Aby dodać rozmiar kolejki ponownej instalacji (KB) i częstotliwość ponownego wdrażania (KB/s), kliknij prawym przyciskiem myszy nagłówek wyświetlany na czerwono na poniższym zrzucie ekranu.

    Zrzut ekranu przedstawiający dodawanie liczników Rozmiar ponownie kolejki (KB) i Częstotliwość ponownego wdrażania (KB/s).

    Domyślnie pulpit nawigacyjny Zawsze włączone automatycznie odświeża ponownie rozmiar kolejki (KB) i częstotliwość ponownego odświeżania (KB/s) co 60 sekund.

    Zrzut ekranu przedstawiający liczniki odświeżania ustawione na co 60 sekund.

Przejrzyj kolejkę odzyskiwania w monitor wydajności

Rozmiar kolejki odzyskiwania jest unikatowy dla każdej pomocniczej repliki i bazy danych. W związku z tym, aby przejrzeć kolejkę odzyskiwania bazy danych grupy dostępności, wykonaj następujące kroki:

  1. Otwórz monitor wydajności w repliki pomocniczej.

  2. Wybierz przycisk Dodaj (licznik).

  3. W obszarze Dostępne liczniki wybierz pozycję SQLServer:Database Replica, a następnie wybierz pozycję Kolejka odzyskiwania i Ponownie wykonaj liczniki bajtów/s.

  4. W polu Lista wystąpienia wybierz bazę danych grupy dostępności, którą chcesz monitorować pod kątem kolejkowania odzyskiwania.

  5. Wybierz pozycję Dodaj>OK.

    Oto, jak może wyglądać zwiększenie kolejkowania odzyskiwania.

    Zrzut ekranu przedstawiający wzrost kolejkowania odzyskiwania.

Interpretowanie wartości kolejkowania odzyskiwania

W tej sekcji wyjaśniono, jak interpretować wartości związane z kolejkowaniem odzyskiwania określonym w poprzedniej sekcji.

Kiedy problem występuje w kolejce odzyskiwania? Ile kolejek odzyskiwania należy tolerować?

Można założyć, że jeśli kolejka odzyskiwania zgłasza wartość 0, oznacza to, że w momencie tego raportu nie ma kolejkowania odzyskiwania. Jednak gdy środowisko produkcyjne jest zajęte, należy oczekiwać, że kolejka odzyskiwania 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 kolejkowania odzyskiwania 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 odzyskiwania, następujące pomiary są przydatne do rozwiązywania problemów:

  • Częstotliwość ponownego rejestrowania (KB/s) (pulpit nawigacyjny AlwaysOn)
  • Redo_rate w sys.dm_hadr_database_replica_states DMV

Pobieranie stawek bazowych dla częstotliwości ponownego wdrażania

Podczas prawidłowej wydajności funkcji AlwaysOn monitoruj częstotliwość ponownego wykonywania dla zajętych baz danych grup dostępności. Jak wyglądają w typowych godzinach pracy? Jakie są te stawki w okresach konserwacji, gdy duże transakcje (ponowne kompilowanie indeksów, procesy ETL) napędzają większą przepływność transakcji w systemie? Te wartości można porównać podczas obserwowania wzrostu kolejki odzyskiwania, aby określić, co się zmieniło. Obciążenie może być większe niż zwykle. Jeśli wskaźnik ponownego wykonania jest niższy, konieczne może być dalsze badanie w celu ustalenia przyczyny.

Woluminy obciążeń mają znaczenie

Jeśli masz duże obciążenia (takie jak instrukcja UPDATE względem miliona wierszy, ponowne kompilowanie indeksu w tabeli 1 terabajtów, a nawet partii ETL, która wstawia miliony wierszy), należy oczekiwać, że będzie widoczny wzrost kolejki odzyskiwania, natychmiast lub z upływem czasu. Jest to oczekiwane, gdy w bazie danych grupy dostępności zostanie wprowadzona duża liczba zmian.

Jak zdiagnozować kolejkowanie odzyskiwania (wykonaj ponownie)

Po zidentyfikowaniu kolejkowania odzyskiwania dla określonej pomocniczej bazy danych grupy dostępności repliki połącz się z repliką pomocniczą, a następnie wykonaj zapytanie sys.dm_exec_requests w celu określenia wait_type wątków odzyskiwania i wait_time . Oto zapytanie, które można uruchomić w pętli. Szukasz wysokiej częstotliwości co najmniej jednego typu oczekiwania, a nawet czasu oczekiwania dla tych typów oczekiwania. Oto przykładowe zapytanie uruchamiane co sekundę i zgłasza typy oczekiwania i czas oczekiwania dla grupy dostępności "agdb":

WHILE (1=1)
BEGIN
SELECT db_name(database_id) AS dbname, command, session_id, database_id, wait_type, wait_time,
os.runnable_tasks_count, os.pending_disk_io_count FROM sys.dm_exec_requests der JOIN sys.dm_os_schedulers os
ON der.scheduler_id=os.scheduler_id
WHERE command IN('PARALLEL REDO HELP TASK', 'PARALLEL REDO TASK', 'DB STARTUP')
AND database_id= db_id('agdb')
waitfor delay '00:00:05.000'
END

Ważne

W przypadku znaczących danych wyjściowych typu oczekiwania należy zaobserwować zwiększenie kolejkowania odzyskiwania w przypadku używania jednej z opisanych wcześniej metod monitorowania tego warunku.

W tym przykładzie niektóre typy oczekiwania związane z we/wy są zgłaszane (PAGEIOLATCH_UP, PAGEIOATCH_EX). Monitoruj, aby sprawdzić, czy te typy oczekiwania nadal mają największe wait_times wartości, jak zgłoszono w następnej kolumnie.

Zrzut ekranu przedstawiający największy czas oczekiwania zgłoszony w następnej kolumnie.

Typy oczekiwania ponownego wdrażania programu SQL Server

Po zidentyfikowaniu typu oczekiwania zapoznaj się z następującym artykułem SQL Server 2016/2017: Model i wydajność repliki pomocniczej grupy dostępności — Społeczność techniczna firmy Microsoft jako odwołanie krzyżowe dla typowych typów oczekiwania, które powodują kolejkowanie odzyskiwania, i aby uzyskać pomoc w rozwiązaniu problemu.

Zablokowane ponowne wątki na pomocniczych serwerach raportowania

Jeśli Rozwiązanie kieruje raportowanie (wykonywanie zapytań) względem baz danych grup dostępności w repliki pomocniczej, te zapytania tylko do odczytu uzyskują stabilność schematu (Sch-S). Te blokady Sch-S mogą blokować ponowne wątki od uzyskiwania blokad modyfikacji schematu (Sch-M) (znanych również jako "blokady modyfikacji schematu" lub LCK_M_SCH_M) w celu wprowadzenia zmian w języku definicji danych (DDL, data definition language), takich jak ALTER TABLE lub ALTER INDEX. Zablokowany wątek ponownego wysyłania nie może stosować rekordów dziennika, dopóki nie zostanie odblokowany. Może to spowodować kolejkowanie odzyskiwania.

Aby sprawdzić historyczne dowody zablokowanego ponownego użycia, otwórz AlwaysOn_health pliki śledzenia Xevent w repliki pomocniczej przy użyciu programu SSMS. Poszukaj zdarzeń lock_redo_blocked .

Zrzut ekranu przedstawiający sprawdzanie pod kątem historycznych dowodów na zablokowane ponowne utworzenie.

Użyj monitor wydajności, aby aktywnie monitorować zablokowany wpływ na kolejkę odzyskiwania. Dodaj liczniki repliki bazy danych SQL Server::D atabase Replica::Redo blocked/sec i SQL Server::D atabase Replica::Recovery Queue counters. Poniższy zrzut ekranu przedstawia ALTER TABLE ALTER COLUMN polecenie uruchamiane względem repliki podstawowej, podczas gdy długotrwałe zapytanie jest uruchamiane względem tej samej tabeli w repliki pomocniczej. Licznik Powtórz zablokowane/s wskazuje, że ALTER TABLE ALTER COLUMN polecenie jest uruchamiane. Podczas gdy długotrwałe zapytanie jest uruchomione w tej samej tabeli w replice pomocniczej, wszelkie kolejne zmiany w podstawowej tabeli spowodują wzrost kolejki odzyskiwania.

Zrzut ekranu przedstawiający monitor dla typu oczekiwania blokady modyfikacji schematu.

Monitoruj typ oczekiwania na blokadę modyfikacji schematu, który próbuje uzyskać wątek ponownego tworzenia. W tym celu użyj opisanego wcześniej zapytania, aby sprawdzić typy oczekiwania zgłaszane dla operacji ponownego wykonania względem sys.dm_exec_requestselementu . Możesz obserwować rosnący czas oczekiwania na LCK_M_SCH_M trwające ponowne blokowanie.

Zrzut ekranu przedstawiający rosnący czas oczekiwania na LCK_M_SCH_M.

Powtórzenie pojedynczego wątku

Program SQL Server wprowadził równoległe odzyskiwanie dla pomocniczych baz danych repliki w programie Microsoft SQL Server 2016. Jeśli podczas uruchamiania programu SQL Microsoft Server 2012 lub Microsoft SQL Server 2014 występuje kolejkowanie odzyskiwania, możesz przeprowadzić uaktualnienie do nowszej wersji programu, aby zwiększyć wydajność ponownego wykonania w środowisku produkcyjnym.

Ponowne ponowne utworzenie pojedynczego wątku może wystąpić jeszcze później, bardziej zaawansowane wersje programu SQL Server, w których jest używana architektura odzyskiwania równoległego. W tych wersjach wystąpienie programu SQL Server może używać maksymalnie 100 wątków na potrzeby ponownego uruchamiania równoległego. W zależności od liczby procesorów i baz danych grup dostępności równoległe wątki ponownego uruchamiania są przydzielane do maksymalnie 100 wątków całkowitych. Jeśli osiągnięto limit ponownego utworzenia 100 wątków, niektóre bazy danych w grupie dostępności mają przypisany pojedynczy wątek ponownego utworzenia.

Aby określić, czy baza danych grupy dostępności korzysta z odzyskiwania równoległego, połącz się z repliką pomocniczą i użyj następującego zapytania, aby określić liczbę wierszy (wątków), które stosują odzyskiwanie dla bazy danych grupy dostępności. W poniższym przykładzie, jeśli baza danych "agdb" jest pojedynczym wątkiem, a jego poleceniem jest DB STARTUP, obciążenie odzyskiwania może korzystać z odzyskiwania równoległego.

SELECT db_name(database_id) AS dbname, command, session_id, database_id, wait_type, wait_time,
os.runnable_tasks_count, os.pending_disk_io_count FROM sys.dm_exec_requests der JOIN sys.dm_os_schedulers os
ON der.scheduler_id=os.scheduler_id
WHERE command IN ('PARALLEL REDO HELP TASK', 'PARALLEL REDO TASK', 'DB STARTUP')
AND database_id= db_id('agdb')

Zrzut ekranu przedstawiający sposób określania, czy baza danych grupy dostępności korzysta z odzyskiwania równoległego.

Jeśli sprawdzisz, czy baza danych używa pojedynczego wątku, przejrzyj algorytm opisany wcześniej, aby ustalić, czy program SQL Server przekracza liczbę 100 wątków roboczych przeznaczonych do odzyskiwania równoległego. Taki warunek może być powodem, dla którego baza danych "agdb" używa tylko jednego wątku do odzyskiwania.

Program SQL Server 2022 używa teraz nowego algorytmu odzyskiwania równoległego, dzięki czemu wątki procesów roboczych są przypisywane do odzyskiwania równoległego na podstawie obciążenia. Eliminuje to prawdopodobieństwo, że zajęta baza danych pozostanie w odzyskiwaniu pojedynczego wątku. Aby uzyskać więcej informacji, zobacz sekcję Użycie wątków według grup dostępności w sekcji "Wymagania wstępne, ograniczenia i zalecenia dotyczące zawsze włączonych grup dostępności".

  • Last updated on