Versneld databaseherstel in Azure SQL

  • Artikel

Van toepassing op: Azure SQL DatabaseAzure SQL Managed Instance

Versneld databaseherstel (ADR) is een sql Server-database-enginefunctie die de beschikbaarheid van databases aanzienlijk verbetert, met name in aanwezigheid van langdurige transacties, door het herstelproces van de SQL Server-database-engine opnieuw te ontwerpen.

ADR is momenteel beschikbaar voor Azure SQL Database, Azure SQL Managed Instance, databases in Azure Synapse Analytics en SQL Server op Azure-VM's vanaf SQL Server 2019. Zie Versneld databaseherstel beheren voor meer informatie over ADR in SQL Server.

Notitie

ADR is standaard ingeschakeld in Azure SQL Database en Azure SQL Managed Instance. Het uitschakelen van ADR in Azure SQL Database en Azure SQL Managed Instance wordt niet ondersteund.

Overzicht

De belangrijkste voordelen van ADR zijn:

  • Snel en consistent databaseherstel

    Met ADR hebben langlopende transacties geen invloed op de totale hersteltijd, waardoor snel en consistent databaseherstel mogelijk is, ongeacht het aantal actieve transacties in het systeem of hun grootte.

  • Direct terugdraaien van transacties

    Met ADR is het terugdraaien van transacties onmiddellijk, ongeacht de tijd dat de transactie actief is geweest of het aantal updates dat is uitgevoerd.

  • Agressieve afkapping van logboeken

    Met ADR wordt het transactielogboek agressief afgekapt, zelfs in aanwezigheid van actieve langlopende transacties, waardoor het niet meer onder controle komt.

Standaarddatabaseherstelproces

Databaseherstel volgt het ARIES-herstelmodel en bestaat uit drie fasen, die worden geïllustreerd in het volgende diagram en in meer detail worden uitgelegd na het diagram.

current recovery process

  • Analysefase

    Scan doorsturen van het transactielogboek vanaf het begin van het laatste geslaagde controlepunt (of de oudste vuile pagina LSN) tot het einde, om de status van elke transactie te bepalen op het moment dat de database is gestopt.

  • Fase Opnieuw uitvoeren

    Scan doorsturen van het transactielogboek van de oudste niet-doorgevoerde transactie tot het einde, om de database naar de status te brengen die het was op het moment van de crash door alle vastgelegde bewerkingen opnieuw uit te voeren.

  • Fase Ongedaan maken

    Voor elke transactie die actief was vanaf het moment van de crash, gaat u terug naar het logboek en maakt u de bewerkingen ongedaan die door deze transactie zijn uitgevoerd.

Op basis van dit ontwerp is de tijd die nodig is om de SQL Server-database-engine te herstellen na een onverwachte herstart, evenredig met de grootte van de langste actieve transactie in het systeem op het moment van de crash. Herstel vereist een terugdraaiactie van alle onvolledige transacties. De benodigde tijdsduur is evenredig met het werk dat de transactie heeft uitgevoerd en de tijd waarop de transactie actief is geweest. Daarom kan het herstelproces lang duren in aanwezigheid van langlopende transacties (zoals grote bulksgewijze invoegbewerkingen of indexbuildbewerkingen op basis van een grote tabel).

Het annuleren/terugdraaien van een grote transactie op basis van dit ontwerp kan ook lang duren omdat deze dezelfde herstelfase ongedaan maken gebruikt, zoals hierboven beschreven.

Bovendien kan de SQL Server-database-engine het transactielogboek niet afkappen wanneer er langlopende transacties zijn, omdat de bijbehorende logboekrecords nodig zijn voor de herstel- en terugdraaiprocessen. Als gevolg van dit ontwerp van de SQL Server-database-engine hebben sommige klanten het probleem dat de grootte van het transactielogboek zeer groot wordt en enorme hoeveelheden schijfruimte verbruikt.

Het versnelde databaseherstelproces

ADR lost de bovenstaande problemen op door het herstelproces van de SQL Server-database-engine volledig opnieuw te ontwerpen voor:

  • Maak het constant tijd/instant door te voorkomen dat u het logboek moet scannen van/naar het begin van de oudste actieve transactie. Met ADR wordt het transactielogboek alleen verwerkt vanaf het laatste geslaagde controlepunt (of het oudste vuile paginalogboekreeksnummer (LSN)). Hierdoor wordt de hersteltijd niet beïnvloed door langdurige transacties.
  • Minimaliseer de vereiste transactielogboekruimte, omdat het logboek niet langer hoeft te worden verwerkt voor de hele transactie. Als gevolg hiervan kan het transactielogboek agressief worden afgekapt naarmate controlepunten en back-ups plaatsvinden.

Op hoog niveau bereikt ADR snel databaseherstel door alle wijzigingen in de fysieke database te versieren en alleen logische bewerkingen ongedaan te maken, die beperkt zijn en vrijwel onmiddellijk ongedaan kunnen worden gemaakt. Elke transactie die actief was vanaf het moment van een crash, wordt gemarkeerd als afgebroken en daarom kunnen alle versies die door deze transacties worden gegenereerd, worden genegeerd door gelijktijdige gebruikersquery's.

Het ADR-herstelproces heeft dezelfde drie fasen als het huidige herstelproces. Hoe deze fasen werken met ADR, wordt geïllustreerd in het volgende diagram en wordt in meer detail uitgelegd na het diagram.

ADR recovery process

  • Analysefase

    Het proces blijft hetzelfde als voorheen, met toevoeging van het reconstrueren van SLOG en het kopiëren van logboekrecords voor niet-versiebewerkingen.

  • Fase Opnieuw uitvoeren

    Opgesplitst in twee fasen (P)

    • Fase 1

      Opnieuw uitvoeren vanuit SLOG (oudste niet-doorgevoerde transactie tot laatste controlepunt). Opnieuw uitvoeren is een snelle bewerking omdat er slechts enkele records uit de SLOG moeten worden verwerkt.

    • Fase 2

      Opnieuw uitvoeren vanuit transactielogboek begint vanaf het laatste controlepunt (in plaats van de oudste niet-doorgevoerde transactie)

  • Fase Ongedaan maken

    De fase Ongedaan maken met ADR wordt bijna onmiddellijk voltooid met behulp van SLOG om niet-versiebeheerbewerkingen ongedaan te maken en PVS (Persistented Version Store) met Logical Revert om op versieniveau op rijniveau Ongedaan maken uit te voeren.

ADR-herstelonderdelen

De vier belangrijkste onderdelen van ADR zijn:

  • Persistent versiearchief (PVS)

    Het persistente versiearchief is een nieuw mechanisme voor sql Server-database-engine voor het behouden van de rijversies die zijn gegenereerd in de database zelf in plaats van het traditionele tempdb versiearchief. PVS maakt resource-isolatie mogelijk en verbetert de beschikbaarheid van leesbare secundaire bestanden.

  • Logische terugdraaiing

    Logisch terugdraaien is het asynchrone proces dat verantwoordelijk is voor het uitvoeren van op rijniveau gebaseerd ongedaan maken, waarbij direct terugdraaien van transacties wordt geboden en ongedaan wordt uitgevoerd voor alle versiebeheerbewerkingen. Logische terugdraaiing wordt bereikt door:

    • Houd alle afgebroken transacties bij en markeer ze onzichtbaar voor andere transacties.
    • Het terugdraaien uitvoeren met PVS voor alle gebruikerstransacties in plaats van het transactielogboek fysiek te scannen en wijzigingen één voor één ongedaan te maken.
    • Alle vergrendelingen onmiddellijk vrijgeven nadat de transactie is afgebroken. Aangezien het afbreken simpelweg het markeren van wijzigingen in het geheugen omvat, is het proces zeer efficiënt en hoeven vergrendelingen dus niet lang te worden vastgehouden.

  • SLOG

    SLOG is een secundaire logboekstream in het geheugen waarin logboekrecords worden opgeslagen voor niet-geversieerde bewerkingen (zoals ongeldige metagegevenscache, overnames vergrendelen, enzovoort). De SLOG is:

    • Laag volume en in-memory
    • Behouden op schijf door geserialiseerd te worden tijdens het controlepuntproces
    • Periodiek afgekapt als transacties doorvoeren
    • Versnelt opnieuw en ongedaan maken door alleen de niet-versiebewerkingen te verwerken
    • Maakt agressieve afkapping van transactielogboeken mogelijk door alleen de vereiste logboekrecords te behouden

  • Schoner

    De schoonmaker is het asynchrone proces dat periodiek wakker wordt en paginaversies opschoont die niet nodig zijn.

Patronen voor versneld databaseherstel (ADR)

De volgende typen workloads profiteren het meeste van ADR:

  • ADR wordt aanbevolen voor workloads met langdurige transacties.
  • ADR wordt aanbevolen voor workloads die gevallen hebben gezien waarin actieve transacties ertoe leiden dat het transactielogboek aanzienlijk toeneemt.
  • ADR wordt aanbevolen voor werkbelastingen die lange perioden van database niet beschikbaar zijn vanwege langlopend herstel (zoals onverwacht opnieuw opstarten van de service of handmatig terugdraaien van transacties).

Aanbevolen procedures voor versneld databaseherstel

  • Vermijd langdurige transacties in de database. Hoewel een van de ADR-doelstellingen is om het herstel van databases te versnellen vanwege opnieuw actieve transacties, kunnen langlopende transacties het opschonen van versies vertragen en de grootte van de PVS vergroten.

  • Vermijd grote transacties met wijzigingen in gegevensdefinities of DDL-bewerkingen. ADR maakt gebruik van een SLOG-mechanisme (systeemlogboekstroom) voor het bijhouden van DDL-bewerkingen die worden gebruikt in herstel. De SLOG wordt alleen gebruikt terwijl de transactie actief is. SLOG wordt gecontroleerd, dus het vermijden van grote transacties die gebruikmaken van SLOG kan de algehele prestaties helpen. Deze scenario's kunnen ertoe leiden dat de SLOG meer ruimte in beslag neemt:

    • Veel DDLs worden uitgevoerd in één transactie. In één transactie kunt u bijvoorbeeld snel tijdelijke tabellen maken en neerzetten.

    • Een tabel heeft een zeer groot aantal partities/indexen die worden gewijzigd. Een DROP TABLE-bewerking voor een dergelijke tabel vereist bijvoorbeeld een grote reservering van het SLOG-geheugen, waardoor het afkappen van het transactielogboek wordt vertraagd en ongedaan maken/opnieuw uitvoeren van bewerkingen wordt vertraagd. De tijdelijke oplossing kan de indexen afzonderlijk verwijderen en geleidelijk worden verwijderd en vervolgens de tabel verwijderen. Zie ADR-herstelonderdelen voor meer informatie over de SLOG.

  • Voorkom of verminder onnodige afgebroken situaties. Een hoge abortsnelheid zal de PVS-schonere en lagere ADR-prestaties onder druk zetten. De aborts kunnen afkomstig zijn van een hoge snelheid van impasses, dubbele sleutels of andere schendingen van beperkingen.

    • In sys.dm_tran_aborted_transactions de DMV worden alle afgebroken transacties op het SQL Server-exemplaar weergegeven. De nested_abort kolom geeft aan dat de transactie is doorgevoerd, maar dat er delen zijn die zijn afgebroken (savepoints of geneste transacties) die het PVS-opschoonproces kunnen blokkeren. Zie sys.dm_tran_aborted_transactions (Transact-SQL) voor meer informatie.

    • Als u het PVS-opschoonproces handmatig wilt activeren tussen werkbelastingen of tijdens onderhoudsvensters, gebruikt u sys.sp_persistent_version_cleanup. Zie sys.sp_persistent_version_cleanup voor meer informatie.

  • Als u problemen ondervindt met opslaggebruik, hoge afgebroken transactie en andere factoren, raadpleegt u Troubleshooting Accelerated Database Recovery (ADR) in SQL Server.

Volgende stappen