przyspieszone odzyskiwanie bazy danych w programie Azure SQL

dotyczy: Azure SQL Database wystąpienia zarządzanego usługi Azure SQL

przyspieszone odzyskiwanie bazy danych (ADR) to funkcja aparatu bazy danych usługi SQL Server, która znacznie zwiększa dostępność bazy danych, szczególnie w obecności długotrwałych transakcji, przez przeprojektowanie procesu odzyskiwania aparatu bazy danych SQL Server database.

Usługa ADR jest obecnie dostępna dla Azure SQL Database, Azure SQL Managed Instance, baz danych w usługach Azure Synapse Analytics i SQL Server na platformie Azure, począwszy od SQL Server 2019 r.

Uwaga

Reguły ADR są domyślnie włączone w Azure SQL Database i Azure SQL Managed Instance a wyłączenie reguły ADR dla każdego produktu nie jest obsługiwane.

Omówienie

Główne zalety 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 rozmiarów.

  • Natychmiastowe wycofywanie transakcji

    W przypadku funkcji ADR wycofywanie transakcji jest natychmiastowe, niezależnie od czasu aktywności transakcji lub liczby wykonanych aktualizacji.

  • Agresywne przycinanie dzienników

    W przypadku reguły ADR dziennik transakcji jest agresywnie obcinany, nawet w obecności aktywnych długotrwałych transakcji, co zapobiega utracie kontroli.

Standardowy proces odzyskiwania bazy danych

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

bieżący proces odzyskiwania

  • Faza analizy

    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 czasie zatrzymania bazy danych.

  • Faza ponownego wytłaniania

    Przekazywanie skanowania dziennika transakcji od najstarszej niezatwierdzonych transakcji do końca, aby przywrócić bazę danych do stanu w czasie awarii przez ponowne zakończenie wszystkich operacji zatwierdzone.

  • Faza cofania

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

Na podstawie tego projektu czas odzyskiwania aparatu bazy danych usługi SQL Server po nieoczekiwanym ponownym uruchomieniu jest (w przybliżeniu) proporcjonalny do rozmiaru najdłuższej aktywnej transakcji w systemie w czasie awarii. Odzyskiwanie wymaga wycofywania wszystkich nieukończonych transakcji. Wymagany czas jest proporcjonalny do pracy wykonanej przez transakcję i czasu jej 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 na podstawie tego projektu może również zająć dużo czasu, ponieważ używa tej samej fazy cofania odzyskiwania, co opisano powyżej.

Ponadto aparat bazy danych SQL Server nie może obcinać dziennika transakcji, jeśli istnieją długotrwałe transakcje, ponieważ odpowiednie rekordy dziennika są wymagane dla procesów odzyskiwania i wycofywania. W wyniku tego projektu aparatu bazy danych usługi SQL Server niektórzy klienci kiedyś mierzyli się z problemem, że rozmiar dziennika transakcji jest bardzo duży i zużywa ogromne ilości miejsca na dysku.

Proces przyspieszone odzyskiwanie bazy danych danych

Adr rozwiązuje powyższe problemy, całkowicie przeprojektując proces odzyskiwania SQL Server bazy danych w celu:

  • Niech będzie to stały czas/moment dzięki uniknięciu 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 numeru sekwencji dziennika zanieczyszczonej strony (LSN). W związku z tym długotrwałe transakcje nie wpływają na czas odzyskiwania.
  • Zminimalizuj wymagane miejsce dziennika transakcji, ponieważ nie ma już potrzeby przetwarzania dziennika dla całej transakcji. W związku z tym dziennik transakcji może być obcinany agresywnie w przypadku tworzenia punktów kontrolnych i kopii zapasowych.

Na wysokim poziomie reguły ADR osiągają szybkie odzyskiwanie bazy danych przez wersjonowanie wszystkich modyfikacji fizycznej bazy danych i cofnięcie 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 oznaczana jako przerwana i dlatego wszystkie wersje generowane przez te transakcje mogą być ignorowane przez zapytania współbieżne użytkowników.

Proces odzyskiwania ADR ma te same trzy fazy co bieżący proces odzyskiwania. Sposób działania tych faz za pomocą reguły ADR został zilustrowany na poniższym diagramie i bardziej szczegółowo objaśniony na poniższym diagramie.

Proces odzyskiwania ADR

  • Faza analizy

    Proces pozostaje taki sam, jak wcześniej, wraz z dodawaniem funkcji rekonstruowania dziennika sLog i kopiowania rekordów dziennika dla operacji bez wersji.

  • Faza ponownego wytłaniania

    Podzielone na dwie fazy (P)

    • Faza 1

      Ponownie wykonuj z sLog (najstarsze niezatwierdzone transakcji do ostatniego punktu kontrolnego). Ponownego tworzenia to szybka operacja, ponieważ musi przetworzyć tylko kilka rekordów z sLog.

    • Faza 2

      Ponownego uruchamiania dziennika transakcji rozpoczyna się od ostatniego punktu kontrolnego (zamiast najstarsze niezatwierdzone transakcji)

  • Faza cofania

    Faza cofania przy użyciu reguły ADR jest prawie natychmiast ukończona przy użyciu narzędzia sLog w celu cofnięcia operacji bez wersji i utrwalonego magazynu wersji (PVS) z logicznym przywracaniem do wykonania operacji cofania na poziomie wiersza na podstawie wersji.

Składniki odzyskiwania ADR

Cztery kluczowe składniki reguły ADR to:

  • Trwały magazyn wersji (PVS)

    Trwały magazyn wersji to nowy mechanizm aparatu SQL Server do utrwalania wersji wierszy wygenerowanych w samej bazie danych, a nie w tradycyjnym tempdb magazynie wersji. PvS umożliwia izolację zasobów, a także zwiększa dostępność odczytywalnych secondaries.

  • Przywracanie logiczne

    Przywracanie logiczne to proces asynchroniczny odpowiedzialny za wykonywanie operacji cofania opartych na wersji na poziomie wiersza — zapewnia natychmiastowe wycofywanie i cofanie transakcji dla wszystkich operacji wersjonarowanych. Przywracanie logiczne jest realizowane przez:

    • Śledzenie wszystkich przerwanych transakcji i oznaczanie ich jako niewidocznych dla innych transakcji.
    • Wykonywanie wycofywania przy użyciu usługi PVS dla wszystkich transakcji użytkownika, zamiast fizycznego skanowania dziennika transakcji i cofania zmian po jednym na raz.
    • Zwalnianie wszystkich blokad natychmiast po przerwie transakcji. Ponieważ przerwanie obejmuje po prostu oznaczanie zmian w pamięci, proces jest bardzo wydajny i w związku z tym blokady nie muszą być przechowywane przez długi czas.
  • Walić

    SLog to pomocniczy strumień dzienników w pamięci, który przechowuje rekordy dzienników dla operacji bez wersji (takich jak unieważnianie pamięci podręcznej metadanych, pozyskiwanie blokad itd.). SLog to:

    • Mała ilość i ilość w pamięci
    • Utrwalone na dysku przez serializę podczas procesu punktu kontrolnego
    • Okresowe obcinanie podczas zatwierdzania transakcji
    • Przyspiesza ponowne i cofanie przez przetwarzanie tylko operacji bez wersji
    • Umożliwia agresywne przycinanie dziennika transakcji przez zachowywanie tylko wymaganych rekordów dziennika
  • Cleaner

    Czyszczenia jest asynchroniczny proces, który jest okresowo wznawiany i czyści wersje stron, które nie są potrzebne.

przyspieszone odzyskiwanie bazy danych wzorców

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

  • Obciążenia z długotrwałych transakcji.
  • Obciążenia, w których były widoczne przypadki, w których aktywne transakcje powodują znaczne wzrosty dziennika transakcji.
  • Obciążenia, w przypadku których wystąpiły długie okresy niedostępności bazy danych z powodu długotrwałego odzyskiwania (na przykład nieoczekiwanego ponownego uruchomienia usługi lub ręcznego wycofywania transakcji).