Przyspieszone odzyskiwanie bazy danych w usłudze Azure SQL

Artykuł
07/31/2023

Dotyczy: Azure SQL Database Azure SQL Managed Instance

Przyspieszone odzyskiwanie bazy danych (ADR) to funkcja aparatu bazy danych programu SQL Server, która znacznie poprawia dostępność bazy danych, szczególnie w przypadku występowania długotrwałych transakcji przez przeprojektowanie procesu odzyskiwania aparatu bazy danych programu SQL Server.

Usługa ADR jest obecnie dostępna dla usług Azure SQL Database, Azure SQL Managed Instance, baz danych w usłudze Azure Synapse Analytics i programu SQL Server na maszynach wirtualnych platformy Azure, począwszy od programu SQL Server 2019. Aby uzyskać informacje na temat reguły ADR w programie SQL Server, zobacz Zarządzanie przyspieszonym odzyskiwaniem bazy danych.

Uwaga

Reguła ADR jest domyślnie włączona w usługach Azure SQL Database i Azure SQL Managed Instance. Wyłączenie reguły ADR w usłudze Azure SQL Database i usłudze Azure SQL Managed Instance nie jest obsługiwane.

Omówienie

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

Szybkie i spójne odzyskiwanie bazy danych

W przypadku reguły ADR 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 rozmiarach.
Natychmiastowe wycofywanie transakcji

W przypadku reguły ADR wycofywanie transakcji jest natychmiastowe, niezależnie od czasu, w jaki transakcja została aktywna lub liczba aktualizacji, które zostały wykonane.
Agresywne obcinanie dziennika

W przypadku reguły ADR dziennik transakcji jest agresywnie obcięty, nawet w obecności aktywnych długotrwałych transakcji, co uniemożliwia jej wyrastanie z kontroli.

Standardowy proces odzyskiwania bazy danych

Odzyskiwanie bazy danych jest zgodne z modelem odzyskiwania ARIES i składa się z trzech faz, które przedstawiono na poniższym diagramie i wyjaśniono bardziej szczegółowo na diagramie.

current recovery process

Faza analizy

Przekaż skanowanie dziennika transakcji od początku ostatniego pomyślnego punktu kontrolnego (lub najstarszej zanieczyszczonej strony LSN) do końca, aby określić stan każdej transakcji w momencie zatrzymania bazy danych.
Faza ponownego wdrażania

Przekaż skanowanie dziennika transakcji z najstarszej niezatwierdzonej transakcji do końca, aby przenieść bazę danych do stanu, w momencie awarii, ponownie wykonując wszystkie zatwierdzone operacje.
Cofanie fazy

Dla każdej transakcji, która była aktywna w momencie awarii, przechodzi wstecz dziennika, cofa operacje wykonywane przez tę transakcję.

W oparciu o ten projekt czas potrzebny aparatowi bazy danych programu SQL Server do odzyskania po nieoczekiwanym ponownym uruchomieniu jest (w przybliżeniu) proporcjonalny do rozmiaru 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. W związku z tym proces odzyskiwania może zająć dużo czasu w obecności długotrwałych transakcji (takich jak duże operacje wstawiania zbiorczego lub operacje kompilacji indeksu względem dużej tabeli).

Ponadto anulowanie/wycofywanie dużej transakcji opartej na tym projekcie może również zająć dużo czasu, ponieważ używa tej samej fazy cofania odzyskiwania, jak opisano powyżej.

Ponadto aparat bazy danych programu SQL Server nie może obcinać dziennika transakcji, gdy istnieją długotrwałe transakcje, ponieważ odpowiednie rekordy dziennika są potrzebne do odzyskiwania i wycofywania procesów. W wyniku tego projektu aparatu bazy danych programu SQL Server niektórzy klienci napotykali problem, że rozmiar dziennika transakcji rośnie bardzo duży i zużywa ogromne ilości miejsca na dysku.

Proces przyspieszonego odzyskiwania bazy danych

Adr rozwiązuje powyższe problemy przez całkowite przeprojektowanie procesu odzyskiwania aparatu bazy danych programu SQL Server w celu:

Stałe czas/natychmiastowe, unikając konieczności skanowania dziennika od/do początku najstarszej aktywnej transakcji. W przypadku reguły ADR dziennik transakcji jest przetwarzany tylko z ostatniego pomyślnego punktu kontrolnego (lub najstarszego zanieczyszczonego numeru sekwencji dziennika strony (LSN)). W związku z tym czas odzyskiwania nie ma wpływu na długotrwałe transakcje.
Zminimalizuj wymagane miejsce dziennika transakcji, ponieważ nie ma już potrzeby przetwarzania dziennika dla całej transakcji. W związku z tym dziennik transakcji można obcinać agresywnie w miarę występowania punktów kontrolnych i kopii zapasowych.

Na wysokim poziomie adr zapewnia szybkie odzyskiwanie bazy danych przez przechowywanie wersji wszystkich modyfikacji fizycznej bazy danych i cofanie tylko operacji logicznych, które są ograniczone i można je cofnąć niemal natychmiast. Każda transakcja, która była aktywna w momencie awarii, jest oznaczona jako przerwana i dlatego wszystkie wersje wygenerowane przez te transakcje mogą być ignorowane przez współbieżne zapytania użytkowników.

Proces odzyskiwania ADR ma te same trzy fazy co bieżący proces odzyskiwania. Jak te fazy działają z adr, przedstawiono na poniższym diagramie i wyjaśniono bardziej szczegółowo na diagramie.

ADR recovery process

Faza analizy

Proces pozostaje taki sam jak poprzednio z dodatkiem odtworzenia protokołu SLOG i kopiowania rekordów dziennika dla operacji nienależących do wersji.
Faza ponownego wdrażania

Podzielone na dwie fazy (P)
- Faza 1
  
  Wykonaj ponownie z poziomu protokołu SLOG (najstarsza niezatwierdzona transakcja do ostatniego punktu kontrolnego). Ponowne uruchomienie jest szybką operacją, ponieważ wymaga tylko przetworzenia kilku rekordów z dziennika SLOG.
- Faza 2
  
  Ponowne uruchomienie z dziennika transakcji rozpoczyna się od ostatniego punktu kontrolnego (zamiast najstarszej niezatwierdzonej transakcji)
Cofanie fazy

Faza Cofania z adr kończy się niemal natychmiast za pomocą protokołu SLOG w celu cofnięcia operacji nieodpartych na wersji i utrwalonego magazynu wersji (PVS) z przywracaniem logicznym w celu wykonania cofania na poziomie wiersza.

Składniki odzyskiwania ADR

Cztery kluczowe składniki reguły ADR to:

Magazyn wersji utrwalonej (PVS)

Magazyn wersji utrwalonej to nowy mechanizm aparatu bazy danych programu SQL Server do utrwalania wersji wierszy generowanych w samej bazie danych zamiast tradycyjnego tempdb magazynu wersji. PvS umożliwia izolację zasobów, a także zwiększa dostępność czytelnych sekund.
Przywracanie logiczne

Przywracanie logiczne to asynchroniczny proces odpowiedzialny za wykonywanie cofania opartego na wersji na poziomie wiersza — zapewniając natychmiastowe wycofywanie transakcji i cofanie wszystkich operacji w wersji. Przywracanie logiczne jest realizowane przez:
- Śledzenie wszystkich przerwanych transakcji i oznaczanie ich niewidocznymi dla innych transakcji.
- Wycofywanie przy użyciu pvS dla wszystkich transakcji użytkownika, a nie fizyczne skanowanie dziennika transakcji i cofanie zmian pojedynczo.
- Zwalnianie wszystkich blokad natychmiast po przerwaniu transakcji. Ponieważ przerwanie polega po prostu na oznaczaniu zmian w pamięci, proces jest bardzo wydajny i dlatego blokady nie muszą być przechowywane przez długi czas.
WALIĆ

SLOG jest pomocniczym strumieniem dziennika w pamięci, który przechowuje rekordy dziennika dla operacji innych niż wersje (takich jak unieważnienie pamięci podręcznej metadanych, pozyskiwanie blokad itd.). Dziennik SLOG to:
- Mała ilość i ilość w pamięci
- Utrwalone na dysku przez serializację podczas procesu punktu kontrolnego
- Okresowe obcinanie jako zatwierdzenie transakcji
- Przyspiesza ponowne wykonywanie i cofanie, przetwarzając tylko operacje bez wersji
- Umożliwia obcinanie dzienników transakcji agresywnych przez zachowanie tylko wymaganych rekordów dziennika
Cleaner

Środek czyszczący jest procesem asynchronicznym, który okresowo wznawia i czyści wersje stron, które nie są potrzebne.

Wzorce przyspieszonego odzyskiwania bazy danych (ADR)

Następujące typy obciążeń korzystają najbardziej z reguły ADR:

Reguły ADR są zalecane w przypadku obciążeń z długotrwałymi transakcjami.
Zalecana jest metoda ADR w przypadku obciążeń, w których aktywne transakcje powodują znaczny wzrost dziennika transakcji.
Zalecana jest metoda ADR w przypadku obciążeń, które doświadczyły długich okresów niedostępności bazy danych z powodu długotrwałego odzyskiwania (na przykład nieoczekiwanego ponownego uruchomienia usługi lub ręcznego wycofywania transakcji).

Najlepsze rozwiązania dotyczące przyspieszonego odzyskiwania bazy danych

Unikaj długotrwałych transakcji w bazie danych. Chociaż jednym z celów adr jest przyspieszenie odzyskiwania bazy danych z powodu długich aktywnych transakcji, długotrwałe transakcje mogą opóźnić czyszczenie wersji i zwiększyć rozmiar pvS.
Unikaj dużych transakcji ze zmianami definicji danych lub operacjami DDL. Adr używa mechanizmu SLOG (strumienia dziennika systemowego) do śledzenia operacji DDL używanych w odzyskiwaniu. Dziennik SLOG jest używany tylko podczas aktywnej transakcji. 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 list DDLs jest wykonywanych w jednej transakcji. Na przykład w jednej transakcji szybko tworząc i upuszczając tabele tymczasowe.
- Tabela ma bardzo dużą liczbę partycji/indeksów, które są modyfikowane. Na przykład operacja DROP TABLE w takiej tabeli wymaga dużej rezerwacji pamięci SLOG, co spowoduje opóźnienie obcięcia dziennika transakcji i opóźnienia operacji cofania/ponownego wykonania. Obejście można usunąć pojedynczo i stopniowo, a następnie usunąć tabelę. Aby uzyskać więcej informacji na temat protokołu SLOG, zobacz Składniki odzyskiwania ADR.
Zapobiegaj niepotrzebnym przerywanym sytuacjom lub ograniczaj je. Wysoki współczynnik przerwania wywiera presję na czystszą i niższą wydajność ADR PVS. Przerwania mogą pochodzić z dużej liczby zakleszczeń, zduplikowanych kluczy lub innych naruszeń ograniczeń.
- Widok sys.dm_tran_aborted_transactions DMV pokazuje wszystkie przerwane transakcje w wystąpieniu programu SQL Server. Kolumna wskazuje, że transakcja nested_abort została zatwierdzona, ale istnieją części przerwane (punkty zapisywania lub transakcje zagnieżdżone), które mogą blokować proces oczyszczania PVS. Aby uzyskać więcej informacji, zobacz sys.dm_tran_aborted_transactions (Transact-SQL).
- Aby ręcznie aktywować proces oczyszczania PVS między obciążeniami lub w oknach obsługi, użyj polecenia sys.sp_persistent_version_cleanup. Aby uzyskać więcej informacji, zobacz sys.sp_persistent_version_cleanup.
Jeśli zaobserwujesz problemy z użyciem magazynu, wysoką przerwą transakcji i innymi czynnikami, zobacz Rozwiązywanie problemów z przyspieszonym odzyskiwaniem bazy danych (ADR) w programie SQL Server.