Accelerated Database Recovery in Azure SQL

VAN TOEPASSING OP: Azure SQL Database Azure SQL Managed Instance

Accelerated Database Recovery (ADR) is een SQL Server-database-enginefunctie die de beschikbaarheid van databases sterk verbetert, met name in de aanwezigheid van langlopende 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.

Notitie

ADR is standaard ingeschakeld in Azure SQL Database en Azure SQL Managed Instance en het uitschakelen van ADR voor beide producten 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 wordt het terugdraaien van transacties onmiddellijk uitgevoerd, ongeacht het moment dat de transactie actief is of het aantal updates dat is uitgevoerd.

  • Agressieve afdronking van logboeken

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

Standaarddatabaseherstelproces

Databaseherstel volgt het ARIES-herstelmodel en bestaat uit drie fasen, die worden geïllustreerd in het volgende diagram en uitgebreider worden uitgelegd aan de hand van het diagram.

huidig herstelproces

  • Analysefase

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

  • Fase opnieuw

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

  • Fase ongedaan maken

    Voor elke transactie die op het moment van de crash actief was, gaat het logboek achterwaarts door, zodat de bewerkingen die door deze transactie zijn uitgevoerd ongedaan worden gemaakt.

Op basis van dit ontwerp is de tijd die de SQL Server-database-engine nodig heeft om te herstellen na een onverwachte herstart (ongeveer) evenredig met de grootte van de langste actieve transactie in het systeem op het moment van de crash. Herstel vereist een terugdraaien van alle onvolledige transacties. De benodigde tijdsduur is evenredig met het werk dat de transactie heeft uitgevoerd en de tijd dat deze actief is. Daarom kan het herstelproces lang duren in de aanwezigheid van langlopende transacties (zoals grote bulkinvoegbewerkingen of indexbouwbewerkingen voor 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 wordt beschreven.

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

Het Accelerated Database Recovery proces

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

  • Zorg ervoor dat de tijd constant is/direct door te voorkomen dat het logboek van/tot het begin van de oudste actieve transactie moet worden gescand. Met ADR wordt het transactielogboek alleen verwerkt vanaf het laatste geslaagde controlepunt (of het oudste, vervuilde paginalogboekreeksnummer (LSN).) Als gevolg hiervan wordt de hersteltijd niet beïnvloed door langlopende transacties.
  • Minimaliseer de vereiste transactielogboekruimte omdat het logboek voor de hele transactie niet meer hoeft te worden verwerkt. Als gevolg hiervan kan het transactielogboek agressief worden afgekapt wanneer controlepunten en back-ups plaatsvinden.

Op hoog niveau realiseert ADR snel databaseherstel door alle fysieke databasewijzigingen te wijzigen en alleen logische bewerkingen ongedaan te maken, die beperkt zijn en vrijwel onmiddellijk ongedaan kunnen worden gemaakt. Elke transactie die actief was op 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 uitgebreider uitgelegd na het diagram.

ADR-herstelproces

  • Analysefase

    Het proces blijft hetzelfde als voorheen met de toevoeging van het reconstrueren van sLog en het kopiëren van logboekrecords voor bewerkingen zonder versie.

  • Fase opnieuw

    Opgesplitst in twee fasen (P)

    • Fase 1

      Opnieuw doen vanuit sLog (oudste niet-doorgestuurde transactie tot laatste controlepunt). Redo is een snelle bewerking omdat er slechts enkele records uit de sLog moeten worden verwerkt.

    • Fase 2

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

  • Fase ongedaan maken

    De fase Ongedaan maken met ADR wordt bijna onmiddellijk voltooid door sLog te gebruiken om bewerkingen zonder versie ongedaan te maken en Persisted Version Store (PVS) met Logical Revert om op rijniveau ongedaan maken op basis van versie ongedaan te maken.

ADR-herstelonderdelen

De vier belangrijkste onderdelen van ADR zijn:

  • Persistent versie store (PVS)

    Het persistente versie-opslag is een nieuw SQL Server-database-enginemechanisme voor het persistent maken van de rijversies die zijn gegenereerd in de database zelf in plaats van het traditionele tempdb versie-store. PVS maakt resource-isolatie mogelijk en verbetert de beschikbaarheid van leesbare secondaries.

  • Logisch terugdraaien

    Logisch terugdraaien is het asynchrone proces dat verantwoordelijk is voor het uitvoeren van ongedaan maken op basis van een versie op rijniveau. Dit biedt direct terugdraaien van transacties en ongedaan maken voor alle versies van bewerkingen. Logisch terugdraaien wordt bereikt door:

    • Houd alle afgebroken transacties bij en markeer ze onzichtbaar voor andere transacties.
    • Terugdraaien door PVS te gebruiken voor alle gebruikerstransacties, in plaats van het transactielogboek fysiek te scannen en wijzigingen één voor één ongedaan te maken.
    • Alle vergrendelingen worden onmiddellijk na het afbreken van de transactie vrijgeven. Omdat afbreken alleen wijzigingen in het geheugen markeert, is het proces zeer efficiënt en moeten vergrendelingen daarom niet lang worden vastgehouden.
  • sLog

    sLog is een secundaire logboekstroom in het geheugen waarin logboekrecords worden opgeslagen voor bewerkingen zonder versie (zoals ongeldige metagegevenscache, vergrendelingsverwervingen, etc.). De sLog is:

    • Laag volume en in-memory
    • Persistent op schijf door te worden geseraliseerd tijdens het controlepuntproces
    • Periodiek afgekapt tijdens het doorwerken van transacties
    • Versnelt opnieuw uitvoeren en ongedaan maken door alleen de bewerkingen zonder versie te verwerken
    • Maakt agressieve afdroning van transactielogboek mogelijk door alleen de vereiste logboekrecords te behouden
  • Schoner

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

Accelerated Database Recovery patronen

De volgende typen workloads profiteren het meeste van ADR:

  • Workloads met langlopende transacties.
  • Werkbelastingen die gevallen hebben gezien waarbij actieve transacties ervoor zorgen dat het transactielogboek aanzienlijk groeit.
  • Workloads die lange perioden hebben gehad waarin de database niet beschikbaar was vanwege langlopende herstel (zoals onverwacht opnieuw opstarten van de service of handmatig terugdraaien van transacties).