Versneld database herstel in Azure SQLAccelerated Database Recovery in Azure SQL

van toepassing op:  Ja Azure SQL database  Ja Azure SQL Managed instanceAPPLIES TO: yesAzure SQL Database yesAzure SQL Managed Instance

Versneld database herstel (ADR) is een functie van SQL server data base-engine waarmee de beschik baarheid van de data base aanzienlijk wordt verbeterd, met name als er langlopende trans acties worden uitgevoerd, door het herstel proces van de SQL server data base-engine opnieuw te ontwerpen.Accelerated Database Recovery (ADR) is a SQL Server database engine feature that greatly improves database availability, especially in the presence of long running transactions, by redesigning the SQL Server database engine recovery process. ADR is momenteel beschikbaar voor Azure SQL Database, Azure SQL Managed instance, SQL Server op Azure VM en data bases in azure Synapse Analytics (momenteel als preview-versie).ADR is currently available for Azure SQL Database, Azure SQL Managed Instance, SQL Server on Azure VM, and databases in Azure Synapse Analytics (currently in preview). De belangrijkste voor delen van ADR zijn:The primary benefits of ADR are:

  • Snel en consistent herstel van de data baseFast and consistent database recovery

    Met ADR hebben langlopende trans acties geen invloed op de algehele herstel tijd, waardoor snel en consistent herstel van de data base mogelijk is, ongeacht het aantal actieve trans acties in het systeem of de grootte ervan.With ADR, long running transactions do not impact the overall recovery time, enabling fast and consistent database recovery irrespective of the number of active transactions in the system or their sizes.

  • Momentane trans actie terugdraaienInstantaneous transaction rollback

    Met ADR is het terugdraaien van trans acties onmiddellijk, ongeacht het tijdstip waarop de trans actie actief is of het aantal updates dat is uitgevoerd.With ADR, transaction rollback is instantaneous, irrespective of the time that the transaction has been active or the number of updates that has performed.

  • Afkap ping van agressief logboekAggressive log truncation

    Met ADR wordt het transactie logboek agressief afgekapt, zelfs in de aanwezigheid van actieve langlopende trans acties, waardoor het niet mogelijk is om de controle te vervolledigen.With ADR, the transaction log is aggressively truncated, even in the presence of active long-running transactions, which prevents it from growing out of control.

Standaard database herstel procesStandard database recovery process

Database herstel volgt het Aries -herstel model en bestaat uit drie fasen, die in het volgende diagram worden geïllustreerd en uitvoeriger worden beschreven in het diagram.Database recovery follows the ARIES recovery model and consists of three phases, which are illustrated in the following diagram and explained in more detail following the diagram.

huidig herstel proces

  • Analyse faseAnalysis phase

    Voorwaartse scan van het transactie logboek vanaf het begin van het laatste geslaagde controle punt (of het oudste wegge schreven pagina-LSN) tot aan het eind, om de status van elke trans actie te bepalen op het moment dat de data base is gestopt.Forward scan of the transaction log from the beginning of the last successful checkpoint (or the oldest dirty page LSN) until the end, to determine the state of each transaction at the time the database stopped.

  • Fase opnieuw uitvoerenRedo phase

    Voorwaartse scan van het transactie logboek van de oudste niet-doorgevoerde trans actie tot het eind, om de data base te verplaatsen naar de status die het was op het moment van de crash door alle doorgevoerde bewerkingen opnieuw uit te voeren.Forward scan of the transaction log from the oldest uncommitted transaction until the end, to bring the database to the state it was at the time of the crash by redoing all committed operations.

  • Fase ongedaan makenUndo phase

    Voor elke trans actie die actief was op het moment van de crash, doorloopt het logboek achterwaarts, waardoor de bewerkingen die deze trans actie hebben uitgevoerd, worden ongedaan gemaakt.For each transaction that was active as of the time of the crash, traverses the log backwards, undoing the operations that this transaction performed.

Op basis van dit ontwerp is de tijd die het kost om de SQL Server data base-engine te herstellen na een onverwachte herstart (ruwweg) evenredig met de grootte van de langste actieve trans actie in het systeem op het moment van de crash.Based on this design, the time it takes the SQL Server database engine to recover from an unexpected restart is (roughly) proportional to the size of the longest active transaction in the system at the time of the crash. Voor het herstel moeten alle onvolledige trans acties worden teruggedraaid.Recovery requires a rollback of all incomplete transactions. De vereiste hoeveelheid tijd is evenredig met het werk dat de trans actie heeft uitgevoerd en de tijd die het is actief.The length of time required is proportional to the work that the transaction has performed and the time it has been active. Daarom kan het herstel proces enige tijd in beslag nemen in de aanwezigheid van langlopende trans acties (zoals grote bulksgewijze bewerkingen of het bouwen van index bewerkingen voor een grote tabel).Therefore, the recovery process can take a long time in the presence of long-running transactions (such as large bulk insert operations or index build operations against a large table).

Het annuleren/terugdraaien van een grote trans actie op basis van dit ontwerp kan ook lang duren omdat deze dezelfde fase voor het ongedaan maken van de herstel bewerking gebruikt, zoals hierboven wordt beschreven.Also, cancelling/rolling back a large transaction based on this design can also take a long time as it is using the same Undo recovery phase as described above.

Daarnaast kan de SQL Server data base-engine het transactie logboek niet afkappen wanneer er langlopende trans acties zijn, omdat de bijbehorende logboek records nodig zijn voor de herstel-en terugdraai processen.In addition, the SQL Server database engine cannot truncate the transaction log when there are long-running transactions because their corresponding log records are needed for the recovery and rollback processes. Als gevolg van dit ontwerp van de SQL Server data base-engine, hebben sommige klanten gebruikt om het probleem te verhelpen dat de omvang van het transactie logboek erg groot wordt en grote hoeveel heden schijf ruimte verbruikt.As a result of this design of the SQL Server database engine, some customers used to face the problem that the size of the transaction log grows very large and consumes huge amounts of drive space.

Het herstel proces voor versneld data baseThe Accelerated Database Recovery process

ADR behandelt de bovenstaande problemen door het herstel proces van de SQL Server data base-engine volledig opnieuw te ontwerpen:ADR addresses the above issues by completely redesigning the SQL Server database engine recovery process to:

  • Maak deze constant tijd/direct door te voor komen dat u het logboek van/naar het begin van de oudste actieve trans actie moet scannen.Make it constant time/instant by avoiding having to scan the log from/to the beginning of the oldest active transaction. Met ADR wordt het transactie logboek alleen verwerkt vanaf het laatste geslaagde controle punt (of het oudste LSN (Dirty page log Sequence Number)).With ADR, the transaction log is only processed from the last successful checkpoint (or oldest dirty page Log Sequence Number (LSN)). Als gevolg hiervan worden de herstel tijd niet beïnvloed door langlopende trans acties.As a result, recovery time is not impacted by long running transactions.
  • Minimaliseer de vereiste transactie logboek ruimte, omdat het logboek voor de hele trans actie niet meer hoeft te worden verwerkt.Minimize the required transaction log space since there is no longer a need to process the log for the whole transaction. Als gevolg hiervan kan het transactie logboek agressief worden afgekapt als controle punten en back-ups worden uitgevoerd.As a result, the transaction log can be truncated aggressively as checkpoints and backups occur.

Op hoog niveau verkrijgt ADR snelle herstel van de data base door versie beheer van alle fysieke database wijzigingen en alleen ongedaan maken van logische bewerkingen, die beperkt zijn en bijna onmiddellijk ongedaan kunnen worden gemaakt.At a high level, ADR achieves fast database recovery by versioning all physical database modifications and only undoing logical operations, which are limited and can be undone almost instantly. Alle trans acties die actief waren op het moment van een crash, worden gemarkeerd als afgebroken en daarom kunnen alle door deze trans acties gegenereerde versies worden genegeerd door gelijktijdige gebruikers query's.Any transaction that was active as of the time of a crash are marked as aborted and, therefore, any versions generated by these transactions can be ignored by concurrent user queries.

Het proces voor het herstellen van ADR heeft dezelfde drie fasen als het huidige herstel proces.The ADR recovery process has the same three phases as the current recovery process. Hoe deze fasen met ADR worden gebruikt, worden in het volgende diagram geïllustreerd en uitvoerig beschreven in het diagram.How these phases operate with ADR is illustrated in the following diagram and explained in more detail following the diagram.

ADR-herstel proces

  • Analyse faseAnalysis phase

    Het proces blijft hetzelfde als vóór het toevoegen van het opnieuw samen stellen van sLog en het kopiëren van logboek records voor niet-versie bewerkingen.The process remains the same as before with the addition of reconstructing sLog and copying log records for non-versioned operations.

  • Fase opnieuw uitvoerenRedo phase

    Onderverdeeld in twee fasen (P)Broken into two phases (P)

    • Fase 1Phase 1

      Voer de bewerking opnieuw uit vanaf sLog (oudste niet-doorgevoerde trans actie tot het laatste controle punt).Redo from sLog (oldest uncommitted transaction up to last checkpoint). Opnieuw is een snelle bewerking, omdat alleen enkele records uit de sLog moeten worden verwerkt.Redo is a fast operation as it only needs to process a few records from the sLog.

    • Fase 2Phase 2

      Opnieuw uitvoeren vanuit het transactie logboek vanaf het laatste controle punt (in plaats van de oudste niet-doorgevoerde trans actie)Redo from Transaction Log starts from last checkpoint (instead of oldest uncommitted transaction)

  • Fase ongedaan makenUndo phase

    De fase voor het ongedaan maken met ADR wordt bijna onmiddellijk voltooid met behulp van sLog om bewerkingen zonder versie ongedaan te maken en de persistente versie van PVSThe Undo phase with ADR completes almost instantaneously by using sLog to undo non-versioned operations and Persisted Version Store (PVS) with Logical Revert to perform row level version-based Undo.

ADR-herstel onderdelenADR recovery components

De vier belangrijkste onderdelen van ADR zijn:The four key components of ADR are:

  • Permanente versie opslag (PVS)Persisted version store (PVS)

    De permanente versie opslag is een nieuw SQL Server data base engine-mechanisme voor het persistent maken van de rijdefinities die in de data base zelf zijn gegenereerd, in plaats van naar de traditionele tempdb versie opslag.The persisted version store is a new SQL Server database engine mechanism for persisting the row versions generated in the database itself instead of the traditional tempdb version store. PVS maakt het isoleren van bronnen mogelijk en verbetert de beschik baarheid van Lees bare secundaire zones.PVS enables resource isolation as well as improves availability of readable secondaries.

  • Logische terugzet actieLogical revert

    Logische herverteren is het asynchrone proces dat verantwoordelijk is voor het uitvoeren van ongedaan maken op basis van een op rijniveau gebaseerde, direct terugdraaiende trans actie en ongedaan maken voor alle bewerkingen met een versie.Logical revert is the asynchronous process responsible for performing row-level version-based Undo - providing instant transaction rollback and undo for all versioned operations. Logische terugzet actie wordt uitgevoerd door:Logical revert is accomplished by:

    • Alle afgebroken trans acties bijhouden en deze onzichtbaar maken voor andere trans acties.Keeping track of all aborted transactions and marking them invisible to other transactions.
    • Terugdraai actie uitvoeren met behulp van PVS voor alle gebruikers transacties in plaats van het transactie logboek fysiek te scannen en wijzigingen een voor een ongedaan te maken.Performing rollback by using PVS for all user transactions, rather than physically scanning the transaction log and undoing changes one at a time.
    • Alle vergren delingen direct na het afbreken van de trans actie worden vrijgegeven.Releasing all locks immediately after transaction abort. Omdat het afbreken vereist dat wijzigingen in het geheugen worden gemarkeerd, is het proces zeer efficiënt en kunnen vergren delingen gedurende een lange periode niet worden bewaard.Since abort involves simply marking changes in memory, the process is very efficient and therefore locks do not have to be held for a long time.
  • sLogsLog

    sLog is een secundaire logboek stroom in het geheugen waarin logboek records worden opgeslagen voor niet-verwerkte bewerkingen (zoals meta gegevens cache, vergren delen, enzovoort).sLog is a secondary in-memory log stream that stores log records for non-versioned operations (such as metadata cache invalidation, lock acquisitions, and so on). De sLog is:The sLog is:

    • Laag volume en in-MemoryLow volume and in-memory
    • Bewaard op schijf door geserialiseerd tijdens het controlepunt procesPersisted on disk by being serialized during the checkpoint process
    • Periodiek afgekapt tijdens het door voeren van trans actiesPeriodically truncated as transactions commit
    • Versnelt opnieuw en ongedaan maken door alleen de niet-geversiete bewerkingen te verwerkenAccelerates redo and undo by processing only the non-versioned operations
    • Maakt agressieve afkap ping van transactie logboeken mogelijk door alleen de vereiste logboek records te behoudenEnables aggressive transaction log truncation by preserving only the required log records
  • SchoneCleaner

    De Removal is het asynchrone proces dat periodiek wordt geactiveerd en dat er geen pagina versies worden opgeschoond die niet nodig zijn.The cleaner is the asynchronous process that wakes up periodically and cleans page versions that are not needed.

Versnelde database herstel patronenAccelerated Database Recovery Patterns

De volgende typen werk belastingen komen het meest voor in ADR:The following types of workloads benefit most from ADR:

  • Werk belastingen met langlopende trans acties.Workloads with long-running transactions.
  • Werk belastingen die gevallen hebben met de melding dat het transactie logboek aanzienlijk groeit door actieve trans acties.Workloads that have seen cases where active transactions are causing the transaction log to grow significantly.
  • Werk belastingen die lange Peri Oden niet beschik baarheid hebben vanwege langdurige herstel bewerking (zoals het onverwacht opnieuw opstarten van de service of het terugdraaien van hand matige trans acties).Workloads that have experienced long periods of database unavailability due to long running recovery (such as unexpected service restart or manual transaction rollback).