Przyspieszone odzyskiwanie bazy danych

Dotyczy: SQL Server 2019 (15.x) i nowsze wersje Azure SQL DatabaseAzure SQL Managed InstanceSQL Database w usłudze Microsoft Fabric

Przyspieszone odzyskiwanie bazy danych (ADR) zwiększa dostępność bazy danych, zwłaszcza w przypadku długotrwałych transakcji, poprzez przeprojektowanie procesu odzyskiwania silnika bazy danych.

Adr wprowadzono w programie SQL Server 2019 (15.x) i ulepszono go w programie SQL Server 2022 (16.x). Reguła ADR jest również dostępna w usługach Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (tylko dedykowana pula SQL) i w bazie danych SQL w usłudze Microsoft Fabric.

Notatka

Reguły ADR są zawsze włączone w usługach Azure SQL Database, Azure SQL Managed Instance i SQL Database w usłudze Fabric.

Ten artykuł zawiera omówienie reguły ADR. Aby pracować z usługą ADR, przejrzyj Zarządzanie przyspieszonym odzyskiwaniem bazy danych.

Aby uzyskać więcej informacji na temat dziennika transakcji i odzyskiwania bazy danych, zapoznaj się z Przewodnikiem po architekturze i zarządzaniu dziennikiem transakcji SQL Server oraz z Omówieniem procesu przywracania i odzyskiwania danych w SQL Server.

Przegląd

Podstawowe korzyści wynikające z reguły ADR to:

• szybkie i spójne odzyskiwanie bazy danych

  Długotrwałe transakcje nie mają wpływu na ogólny czas odzyskiwania, umożliwiając szybkie i spójne odzyskiwanie bazy danych niezależnie od liczby aktywnych transakcji w systemie lub ich rozmiarze.

• natychmiastowe wycofywanie transakcji

  Wycofywanie transakcji jest natychmiastowe, niezależnie od czasu, w jaki transakcja została aktywna lub liczba aktualizacji, które zostały wprowadzone.

• Agresywne przycinanie dziennika

  Dziennik transakcji jest agresywnie obcinany, nawet w obecności aktywnych długotrwałych transakcji, co uniemożliwia jego wyrastanie z kontroli.

Tradycyjny proces odzyskiwania bazy danych

Bez mechanizmów ADR, odzyskiwanie bazy danych jest zgodne z modelem odzyskiwania ARIES i składa się z trzech faz, które zilustrowano i szczegółowo wyjaśniono na poniższym diagramie:

• faza analizy

  Silnik bazy danych przeprowadza przeszukiwanie w przód dziennika transakcji, zaczynając od początku ostatniego pomyślnego punktu kontrolnego (lub najstarszego wpisu w dzienniku o zmienionych stronach (LSN)) do końca, aby określić stan każdej transakcji w momencie zatrzymania silnika.

• faza powtórna

  Silnik bazy danych wykonuje skanowanie w przód dziennika transakcji od najstarszej niezatwierdzonej transakcji do końca. Ten proces ponownie wykonuje wszystkie zatwierdzone operacje, aby przywrócić bazę danych do stanu w momencie awarii.

• fazy cofania

  Dla każdej transakcji która była aktywna w momencie awarii aparat bazy danych przechodzi przez dziennik do tyłu, cofając operacje wykonywane przez tę transakcję.

• W przypadku tradycyjnego procesu odzyskiwania bazy danych odzyskiwanie po awarii może zająć dużo czasu, jeśli długotrwała transakcja była aktywna.

  Okres odzyskiwania przez aparat bazy danych po nieoczekiwanym ponownym uruchomieniu jest (w przybliżeniu) wprost proporcjonalny do wielkości najdłużej aktywnej transakcji w systemie w momencie awarii. Odzyskiwanie wymaga wycofania wszystkich niekompletnych transakcji. Wymagany czas jest proporcjonalny do pracy wykonanej przez transakcję i czasu jego aktywności.

• Anulowanie lub wycofywanie dużej transakcji może zająć dużo czasu, ponieważ używa tej samej fazy cofania danych, która została opisana wcześniej.

• Silnik bazy danych nie może skracać dziennika transakcji, gdy istnieją długotrwałe transakcje, ponieważ odpowiednie rekordy dziennika są potrzebne do procesów odzyskiwania i cofania. W rezultacie dziennik transakcji może bardzo się powiększyć i zużywać dużo miejsca na przechowywanie.

Przyspieszony proces odzyskiwania bazy danych

ADR rozwiązuje poprzednie problemy z tradycyjnym modelem odzyskiwania przez całkowite przeprojektowanie procesu odzyskiwania mechanizmu bazy danych:

• Ustaw czas odzyskiwania jako stałą, ponieważ nie ma już potrzeby skanowania dziennika transakcji od początku najstarszej aktywnej transakcji. W przypadku ADR dziennik transakcji jest przetwarzany tylko od ostatniego pomyślnego punktu kontrolnego (lub najstarszej 'brudnej' strony LSN). W rezultacie długotrwałe transakcje nie wpływają na czas odzyskiwania, który jest zazwyczaj natychmiastowy.

• Zminimalizuj wymagane miejsce dziennika transakcji, ponieważ nie ma już potrzeby przechowywania dziennika dla całej transakcji. W związku z tym dziennik transakcji można obcinać agresywnie w miarę jak występują punkty kontrolne i kopie zapasowe.

Ogólnie rzecz biorąc, ADR umożliwia szybkie odzyskiwanie bazy danych przez wersjonowanie wszystkich modyfikacji fizycznej bazy danych i cofanie tylko operacji niewersjonowanych, które są ograniczone i można je cofnąć niemal natychmiast. Wszystkie transakcje, które były aktywne w momencie awarii, są oznaczone jako przerwane i dlatego wszystkie wersje generowane przez te transakcje mogą być ignorowane przez współbieżne zapytania użytkowników.

Proces odzyskiwania ADR ma te same trzy fazy, co tradycyjny proces odzyskiwania. Jak te fazy działają z ADR, zilustrowano na poniższym diagramie:

• faza analizy

  Proces pozostaje taki sam jak tradycyjny model odzyskiwania z dodatkiem odtworzenia pomocniczego strumienia dziennika (SLOG) i kopiowania rekordów dziennika dla operacji niewersyjnych.

• Faza ponownego wykonania

  Podzielone na dwa podfazy

  • Podfaza 1

    Wykonaj ponownie z poziomu protokołu SLOG (najstarsza niezatwierdzona transakcja do ostatniego punktu kontrolnego). Ponowne uruchomienie jest szybką operacją, ponieważ może wymagać tylko przetworzenia kilku rekordów z dziennika SLOG.

  • Podfaza 2

    Ponowne uruchomienie dziennika transakcji rozpoczyna się od ostatniego pomyślnego punktu kontrolnego (zamiast najstarszej niezatwierdzonej transakcji).

• fazy cofania

  Faza cofania z ADR kończy się niemal natychmiast dzięki użyciu SLOG do cofania operacji niewersyjnych oraz trwałego magazynu wersji (PVS) poprzez logiczne przywracanie do wykonania cofania na poziomie wiersza.

Aby uzyskać wyjaśnienie przyspieszonego odzyskiwania bazy danych, obejrzyj ten ośmiominutowy film wideo:

Składniki odzyskiwania ADR

Cztery kluczowe składniki reguły ADR to:

• Magazyn wersji trwałej (PVS)

  Mechanizm magazynu wersji trwałych (PVS) to część aparatu bazy danych służąca do utrwalania wersji wierszy bezpośrednio w tej bazie, zamiast w tradycyjnym magazynie wersji w bazie danych tempdb. PVS umożliwia izolację zasobów i zwiększa dostępność czytelnych replik baz danych.

• przywracanie logiczne

  Przywracanie logiczne to asynchroniczny proces odpowiedzialny za cofanie na poziomie wiersza oparte na wersjach — zapewniając natychmiastowe wycofywanie transakcji i cofanie wszystkich operacji wersjonowanych.

  • Śledzi wszystkie przerwane transakcje
  • Wykonuje wycofywanie przy użyciu pvS dla wszystkich transakcji użytkownika
  • Zwalnia wszystkie blokady natychmiast po przerwaniu transakcji

• SLOG

  SLOG to pomocniczy strumień dziennika w pamięci, który przechowuje zapisy dziennika dla operacji niewersjonowanych (takich jak unieważnianie pamięci podręcznej metadanych, nabywanie blokad itp.). Dziennik SLOG to:

  • Niska głośność i w pamięci
  • Zapisane na dysku podczas procesu punktu kontrolnego
  • Okresowo przycinane w miarę zatwierdzania transakcji
  • Przyspiesza ponowne wykonywanie i cofanie, przetwarzając tylko operacje niewersjowane
  • Umożliwia agresywne skracanie dzienników transakcji przez zachowanie tylko wymaganych rekordów dziennika

• Cleaner

  Proces czyszczenia jest asynchronicznym procesem, który okresowo się budzi i usuwa przestarzałe wersje wierszy z PVS.

Obciążenia, które korzystają z ADR

Reguły ADR są szczególnie korzystne w przypadku obciążeń, które mają:

• Długotrwałe transakcje.
• Aktywne transakcje, które powodują znaczny wzrost dziennika transakcji.
• Długie okresy niedostępności bazy danych z powodu długotrwałego odzyskiwania (na przykład z nieoczekiwanego ponownego uruchomienia usługi lub wycofywania transakcji ręcznych).

Najlepsze rozwiązania dotyczące reguły ADR

• Unikaj niepotrzebnych długotrwałych transakcji. Chociaż ADR przyspiesza odzyskiwanie bazy danych nawet w przypadku długotrwałych transakcji, takie transakcje mogą opóźnić czyszczenie wersji i zwiększyć rozmiar PVS.

• Unikaj dużych transakcji obejmujących operacje DDL. ADR używa mechanizmu strumienia drugorzędnego dziennika (SLOG) do śledzenia operacji DDL używanych w odzyskiwaniu. Protokół SLOG jest używany tylko wtedy, gdy transakcja jest aktywna. Punkt kontrolny SLOG jest sprawdzany, więc unikanie dużych transakcji korzystających z protokołu SLOG może pomóc w ogólnej wydajności. Te scenariusze mogą spowodować, że protokół SLOG zajmie więcej miejsca:

  • Wiele instrukcji DDL jest wykonywanych w jednej transakcji. Na przykład w jednej transakcji, szybkie tworzenie i usuwanie tabel tymczasowych.
  • Tabela ma bardzo dużą liczbę partycji/indeksów, które są modyfikowane. Na przykład operacja DROP TABLE w takiej tabeli wymaga znacznej ilości pamięci SLOG, co spowoduje opóźnienie skrócenia dziennika transakcji oraz operacji cofania/ponownego wykonania. Aby obejść ten problem, upuść indeksy indywidualnie i stopniowo, a następnie upuść tabelę.

  Aby uzyskać więcej informacji na temat SLOG, zobacz składniki odzyskiwania ADR.

• Zapobiegaj lub zmniejszaj niepotrzebne przerwane transakcje. Wysoki współczynnik przerwania transakcji wywiera presję na proces czyszczenia PVS i prowadzi do niższej wydajności ADR. Przerwania mogą pochodzić z wysokiego wskaźnika zakleszczeń, zduplikowanych kluczy, naruszeń ograniczeń lub przekroczonych limitów czasu wykonania zapytania. DMV sys.dm_tran_aborted_transactions pokazuje wszystkie przerwane transakcje w wystąpieniu silnika bazy danych. Kolumna nested_abort wskazuje, że transakcja została zatwierdzona, ale istnieją jej części, które zostały przerwane (np. „savepoints” lub transakcje zagnieżdżone), co może również opóźnić proces czyszczenia PVS.

• Upewnij się, że w bazie danych jest wystarczająca ilość miejsca, aby uwzględnić użycie usługi PVS. Jeśli baza danych nie ma wystarczającej ilości miejsca na rozwój pvS, usługa ADR może nie wygenerować wersji, co powoduje niepowodzenie instrukcji DML.

• W przypadku włączenia funkcji ADR przy intensywnych operacjach zapisu szybkość generowania dziennika transakcji może znacznie wzrosnąć, ponieważ wersje wierszy zapisywane w PVS są rejestrowane. Może to zwiększyć rozmiar kopii zapasowych dziennika transakcji.

• W przypadku używania replikacji transakcyjnej, replikacji migaweklub przechwytywania zmian danych (CDC), agresywne przycinanie dziennika przez ADR jest wyłączone, aby umożliwić czytnikowi dzienników zbieranie zmian z dziennika transakcji. Upewnij się, że dziennik transakcji jest wystarczająco duży.

  W usłudze Azure SQL Database może być konieczne zwiększenie warstwy usługi lub rozmiaru obliczeniowego, aby upewnić się, że wystarczająca ilość miejsca w dzienniku transakcji jest dostępna dla wszystkich Twoich obciążeń. Podobnie, w usłudze Azure SQL Managed Instance może być konieczne zwiększenie maksymalnego rozmiaru przestrzeni przechowywania wystąpienia.

• W przypadku programu SQL Server izoluj magazyn wersji PVS w grupie plików na wyższej klasie magazynu, na przykład na wysokiej klasy SSD, zaawansowanych SSD lub Pamięci Trwałej (PMEM), czasami nazywanej pamięcią klasy magazynu (SCM). Aby uzyskać więcej informacji, zobacz Zmienianie lokalizacji serwera PVS na inną grupę plików.

• W przypadku programu SQL Server monitoruj dziennik błędów dla wpisów PreallocatePVS. Jeśli wpisy PreallocatePVS są obecne, może być konieczne zwiększenie zdolności ADR do wstępnego przydzielania stron przy użyciu zadania w tle. Wstępne przydzielanie stron PVS w tle poprawia wydajność ADR przez zmniejszenie potrzeby kosztownych alokacji PVS na pierwszym planie. Aby zwiększyć tę ilość, możesz użyć konfiguracji serwera ADR Preallocation Factor. Aby uzyskać więcej informacji, zapoznaj się z Server configuration: ADR Preallocation Factor.

• W przypadku programu SQL Server 2022 (16.x) i nowszych rozważ włączenie czyszczenia wielowątkowego PVS, jeśli wydajność czyszczenia jednowątkowego jest niewystarczająca. Aby uzyskać więcej informacji, zobacz Konfiguracja serwera: Liczba wątków ADR Cleaner.

• Jeśli zauważysz problemy takie jak wysokie użycie miejsca w bazie danych przez PVS lub powolne czyszczenie PVS, zobacz Rozwiązywanie problemów z przyspieszonym odzyskiwaniem bazy danych.

Ulepszenia ADR w programie SQL Server 2022

Istnieje kilka ulepszeń dotyczących magazynu trwałych wersji (PVS) i poprawy ogólnej skalowalności. Aby uzyskać więcej informacji na temat nowych funkcji programu SQL Server 2022 (16.x), zobacz Co nowego w programie SQL Server 2022.

Te same ulepszenia są również dostępne w Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (tylko dedykowana pula SQL) i bazie danych SQL w Microsoft Fabric.

• czyszczenie transakcji użytkownika

  Wyczyść strony, których nie można wyczyścić przez zwykły proces z powodu niepowodzenia pozyskiwania blokady.

  Ta funkcja umożliwia transakcjom użytkowników uruchamianie czyszczenia na stronach, które nie mogły być przetworzone przez standardowy proces czyszczenia z powodu konfliktów blokad na poziomie tabeli. To ulepszenie pomaga zapewnić, że proces oczyszczania ADR nie kończy się niepowodzeniem przez czas nieokreślony, ponieważ obciążenia użytkowników nie mogą uzyskać blokad na poziomie tabeli.

• Zmniejsz pamięć dla monitora stron PVS

  To ulepszenie śledzi strony PVS na poziomie zakresu, aby zmniejszyć ilość pamięci potrzebnej do utrzymania stron w wersji.

• ulepszenia czyszczenia PVS

  PVS cleaner zwiększył wydajność czyszczenia wersji, aby poprawić sposób, w jaki silnik bazy danych śledzi i rejestruje wersje wierszy dla wycofanych transakcji. Prowadzi to do poprawy użycia pamięci i przechowywania.

• trwały magazyn wersji na poziomie transakcji (PVS)

  To ulepszenie umożliwia ADR oczyszczanie wersji należących do zatwierdzonych transakcji niezależnie od obecności przerwanych transakcji w systemie. Dzięki temu ulepszeniu można zwolnić strony PVS, nawet jeśli oczyszczanie nie może zakończyć pomyślnego przeglądu, aby przyciąć mapę przerwanych transakcji.

  Wynikiem tej poprawy jest zmniejszenie wzrostu PVS, nawet jeśli czyszczenie PVS jest powolne lub kończy się niepowodzeniem.

• czyszczenie wersji wielowątkowej

  W SQL Server 2019 (15.x) proces oczyszczania jest jednowątkowy w ramach wystąpienia aparatu bazy danych.

  Od wersji SQL Server 2022 (16.x) obsługiwane jest wielowątkowe czyszczenie wersji. Dzięki czemu możliwe jest równoległe czyszczenie wielu baz danych w tym samym wystąpieniu silnika bazy danych lub szybsze czyszczenie pojedynczej bazy danych. Aby uzyskać więcej informacji, zobacz Konfiguracja serwera: ADR Cleaner Thread Count.

  Dodano nowe zdarzenie rozszerzone, tx_mtvc2_sweep_stats, do monitorowania wielowątkowego czyszczenia wersji ADR PVS.

Powiązana zawartość

• Zarządzanie przyspieszonym odzyskiwaniem bazy danych
• Rozwiązywanie problemów z przyspieszonym odzyskiwaniem bazy danych