Versneld databaseherstel in Azure SQL

Van toepassing op: Azure SQL Database-Azure SQL Managed Instance

Versneld databaseherstel (ADR) is een SQL Server functie voor database-engine die de beschikbaarheid van databases aanzienlijk verbetert, met name in de aanwezigheid van langlopende transacties, door het SQL Server herstelproces van de 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 Virtuele Azure-machines vanaf SQL Server 2019. Zie Versneld databaseherstel beheren voor 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 algehele hersteltijd, waardoor snel en consistent databaseherstel mogelijk is, ongeacht het aantal actieve transacties in het systeem of de grootte ervan.

  • Direct terugdraaien van transacties

    Bij ADR is het terugdraaien van transacties onmiddellijk, ongeacht de tijd waarop 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 in de hand loopt.

Standaarddatabaseherstelproces

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

huidig herstelproces

  • 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 van het transactielogboek van de oudste niet-doorgevoerde transactie doorsturen 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 actief was vanaf het moment van de crash, gaat u terug naar het logboek en verwijdert u de bewerkingen die door deze transactie zijn uitgevoerd.

Op basis van dit ontwerp is de tijd die nodig is voor de SQL Server database-engine 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 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 de 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 geconfronteerd dat de grootte van het transactielogboek erg 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/direct 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 oudste vuile paginalogboekreeksnummer (LSN)). Hierdoor wordt de hersteltijd niet beïnvloed door langdurige transacties.
  • Minimaliseer de vereiste transactielogboekruimte omdat het logboek niet meer hoeft te worden verwerkt voor de hele transactie. Als gevolg hiervan kan het transactielogboek agressief worden afgekapt wanneer er 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-herstelproces

  • Analysefase

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

  • Fase Opnieuw uitvoeren

    Onderverdeeld in twee fasen (P)

    • Fase 1

      Opnieuw uitvoeren vanuit SLOG (oudste niet-doorgevoerde transactie tot het 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-gegenereerde 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 rijniveau versiegebaseerd ongedaan te maken.

ADR-herstelonderdelen

De vier belangrijkste onderdelen van ADR zijn:

  • Persistent versiearchief (PVS)

    Het permanente versiearchief is een nieuw mechanisme voor SQL Server database-engine voor het persistent maken van de rijversies die in de database zelf zijn gegenereerd in plaats van het traditionele tempdb versiearchief. 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 op rijniveau versie gebaseerd ongedaan maken: het bieden van directe terugdraaibewerking van transacties en ongedaan maken voor alle versiebewerkingen. Logisch terugdraaien wordt bereikt door:

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

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

    • Laag volume en in-memory
    • Behouden op schijf door tijdens het controlepuntproces geserialiseerd te worden
    • Periodiek afgekapt als transacties doorvoeren
    • Versnelt het 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 schonere is het asynchrone proces dat periodiek wakker wordt en paginaversies schoont die niet nodig zijn.

Patronen voor versneld databaseherstel (ADR)

De volgende typen workloads profiteren het meeste van ADR:

  • ADR wordt aanbevolen voor workloads met langlopende 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 langdurig 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-doelen 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) om DDL-bewerkingen bij te houden die worden gebruikt in herstel. De SLOG wordt alleen gebruikt terwijl de transactie actief is. SLOG is controlepunt, dus het vermijden van grote transacties die gebruikmaken van SLOG kan helpen bij de algehele prestaties. 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. Voor een DROP TABLE-bewerking in een dergelijke tabel is bijvoorbeeld een grote reservering van het SLOG-geheugen vereist, waardoor het afkappen van het transactielogboek wordt vertraagd en bewerkingen voor ongedaan maken/opnieuw uitvoeren worden vertraagd. De tijdelijke oplossing kan de indexen afzonderlijk en geleidelijk worden verwijderd en vervolgens de tabel verwijderen. Zie ADR-herstelonderdelen voor meer informatie over de SLOG.

  • Voorkom of verminder onnodig afgebroken situaties. Een hoge afbreeksnelheid zal de PVS-schonere en lagere ADR-prestaties onder druk zetten. De afbreken kunnen afkomstig zijn van een hoog aantal impasses, dubbele sleutels of andere schendingen van beperkingen.

    • De sys.dm_tran_aborted_transactions DMV toont alle afgebroken transacties op het SQL Server exemplaar. 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 tussen werkbelastingen of tijdens onderhoudsvensters wilt activeren, gebruikt u sys.sp_persistent_version_cleanup. Zie sys.sp_persistent_version_cleanup voor meer informatie.

  • Zie Troubleshooting Accelerated Database Recovery (ADR) op SQL Server als u problemen ondervindt met opslaggebruik, een hoge afgebroken transactie en andere factoren.

Volgende stappen