Versneld database herstel

van toepassing op: SQL Server 2019 (15.x) en latere versies Azure SQL DatabaseAzure SQL Managed InstanceSQL-database in Microsoft Fabric

Versneld databaseherstel (ADR) verbetert de beschikbaarheid van databases, met name in aanwezigheid van langdurige transacties, door het herstelproces van de database-engine opnieuw te ontwerpen.

ADR is geïntroduceerd in SQL Server 2019 (15.x) en verbeterd in SQL Server 2022 (16.x). ADR is ook beschikbaar in Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (alleen toegewezen SQL-pool) en SQL-database in Microsoft Fabric.

Notitie

ADR is altijd ingeschakeld in Azure SQL Database, Azure SQL Managed Instance en SQL Database in Fabric.

Dit artikel bevat een overzicht van ADR. Als u met ADR wilt werken, raadpleegt u Versneld databaseherstel beheren.

Zie voor meer informatie over transactielogboeken en databaseherstel architectuur en beheerhandleiding voor SQL Server-transactielogboeken en Overzicht van herstel en herstel (SQL Server).

Overzicht

De belangrijkste voordelen van ADR zijn:

• Snel en consistent gegevensbankherstel

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

• direct terugdraaien van transacties

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

• agressieve inkorting van logbestanden

  Het transactielogboek wordt agressief ingekort, zelfs in de aanwezigheid van actieve langlopende transacties, om te voorkomen dat het uit de hand loopt.

Het traditionele databaseherstelproces

Zonder ADR volgt databaseherstel de ARIES herstelmodel en bestaat uit drie fasen, die in het volgende diagram worden geïllustreerd en uitgelegd:

• Analysefase

  De database-engine voert een forward scan van het transactielogboek uit vanaf het begin van het laatste geslaagde controlepunt (of het oudste dirty page log sequence number (LSN)) tot het einde, om de status van elke transactie te bepalen op het moment dat de engine is gestopt.

• fase opnieuw uitvoeren

  De database-engine voert een forward scan uit van het transactielogboek van de oudste niet-doorgevoerde transactie tot het einde. Met dit proces worden alle vastgelegde bewerkingen opnieuw uitgevoerd om de database te herstellen naar de status op het moment van de crash.

• fase ongedaan maken

  Voor elke transactie die actief was op het moment van de crash, doorkruist de database-engine het logboek achterwaarts, waarbij de bewerkingen ongedaan worden gemaakt die door deze transactie zijn uitgevoerd.

• Met het traditionele databaseherstelproces kan herstel na een crash lang duren als een langlopende transactie actief was.

  De tijd voor het herstellen van een onverwachte herstart van de database-engine is (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.

• Het annuleren of terugdraaien van een grote transactie kan lang duren, omdat deze dezelfde herstelfase ongedaan maakt zoals eerder is beschreven.

• De database-engine kan het transactielogboek niet afkappen wanneer er langlopende transacties zijn, omdat de bijbehorende logboekrecords nodig zijn voor de herstel- en terugdraaiprocessen. Als gevolg hiervan kan het transactielogboek zeer groot worden en veel opslagruimte verbruiken.

Het versnelde databaseherstelproces

ADR lost eerdere problemen met het traditionele herstelmodel op door het herstelproces van de database-engine volledig opnieuw te ontwerpen voor:

• Maak de hersteltijd constant omdat het transactielogboek vanaf het begin van de oudste actieve transactie niet meer hoeft te worden gescand. Met ADR wordt het transactielogboek alleen verwerkt vanaf het laatste geslaagde controlepunt (of de oudste vuile pagina LSN). Hierdoor wordt de hersteltijd niet beïnvloed door langlopende transacties en wordt deze doorgaans onmiddellijk uitgevoerd.

• Minimaliseer de vereiste transactielogboekruimte, omdat het logboek niet langer voor de hele transactie hoeft te worden bewaard. Als gevolg hiervan kan het transactielogboek agressief worden ingekort als er controlepunten en back-ups plaatsvinden.

Op hoog niveau bereikt ADR snel databaseherstel door alle wijzigingen in de fysieke database te versieren en alleen niet-geversiede bewerkingen ongedaan te maken, die beperkt zijn en vrijwel onmiddellijk ongedaan kunnen worden gemaakt. Transacties die actief waren op het moment van een crash, worden 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 traditionele herstelproces. Hoe deze fasen werken met ADR, wordt geïllustreerd in het volgende diagram:

• Analysefase

  Het proces blijft hetzelfde als het traditionele herstelmodel met toevoeging van het reconstrueren van de secundaire logboekstroom (SLOG) en het kopiëren van logboekrecords voor niet-geversiede bewerkingen.

• fase opnieuw uitvoeren

  Onderverdeeld in twee subfasen

  • Subfase 1

    Opnieuw uitvoeren vanuit SLOG (oudste niet-doorgevoerde transactie tot het laatste controlepunt). Opnieuw uitvoeren is een snelle bewerking, omdat het mogelijk slechts enkele records uit de SLOG hoeft te verwerken.

  • Subfase 2

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

• Fase ongedaan maken

  De ongedaan-maakfase met ADR wordt bijna onmiddellijk voltooid door gebruik te maken van SLOG om niet-geversioneerde bewerkingen ongedaan te maken, en door gebruik te maken van de persistente versieopslag (PVS) met een logische terugzetoperatie om versiegebaseerde ongedaanmaking op rijniveau uit te voeren.

Bekijk deze acht minuten durende video voor een uitleg van versneld databaseherstel:

ADR-herstelonderdelen

De vier belangrijkste onderdelen van ADR zijn:

• PVS- (Persistent Version Store)

  Het permanente versiearchief (PVS) is een mechanisme voor database-engine voor het persistent maken van rijversies in de database zelf in plaats van in het traditionele versiearchief in de tempdb-database. PVS maakt resourceisolatie mogelijk en verbetert de beschikbaarheid van leesbare secundaire bestanden.

• logische terugdraaien

  Logisch terugdraaien is het asynchrone proces dat verantwoordelijk is voor het uitvoeren van versie-gebaseerd ongedaan maken op rijniveau, waarbij direct terugdraaien van transacties en ongedaan maken wordt geboden voor alle versie-gebaseerde bewerkingen.

  • Houdt alle afgebroken transacties bij
  • Hiermee wordt rollback uitgevoerd met PVS voor alle gebruikerstransacties.
  • Alle vergrendelingen worden onmiddellijk na het afbreken van een transactie vrijgegeven.

• SLOG

  De SLOG is een secundaire in-memory logboekstream waarin logboekrecords worden opgeslagen voor operaties zonder versiebeheer (zoals het ongeldig maken van de metagegevenscache, het vastleggen van vergrendelingen, enzovoort). De SLOG is:

  • Klein volume en in-memory
  • Behouden op schijf tijdens het controlepuntproces
  • Periodiek ingekort wanneer transacties worden uitgevoerd
  • Versnelt herstel en terugdraaien door alleen niet-versiegebonden bewerkingen te verwerken.
  • Maakt agressieve afkapping van transactielogboeken mogelijk door alleen de vereiste logboekrecords te behouden

• Cleaner

  De schoner is het asynchrone proces dat periodiek wakker wordt en verouderde versies van rijen uit PVS opruimt.

Workloads die baat hebben bij ADR

ADR is met name nuttig voor workloads met:

• Langlopende transacties.
• Actieve transacties die ervoor zorgen dat het transactielogboek aanzienlijk toeneemt.
• Lange perioden van niet-beschikbaarheid van de database vanwege langlopend herstel (zoals bij onverwacht opnieuw opstarten van de service of handmatig terugdraaien van transacties).

Aanbevolen procedures voor ADR

• Vermijd onnodige langlopende transacties. Hoewel ADR het herstel van databases versnelt, zelfs met langlopende transacties, kunnen dergelijke transacties het opschonen van versies vertragen en de grootte van de PVS vergroten.

• Vermijd grote transacties met DDL-bewerkingen. ADR maakt gebruik van het secundaire log stream (SLOG)-mechanisme om DDL-bewerkingen bij te houden die bij herstel worden gebruikt. SLOG wordt alleen gebruikt terwijl de transactie actief is. SLOG wordt gecontroleerd, 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 verwijderen.
  • Een tabel heeft een zeer groot aantal partities/indexen die worden gewijzigd. Een DROP TABLE bewerking op een dergelijke tabel vereist bijvoorbeeld een grote reservering van het SLOG-geheugen, waardoor het afkappen van het transactielogboek wordt vertraagd en het ongedaan maken/opnieuw uitvoeren van bewerkingen wordt vertraagd. Als tijdelijke oplossing kunt u de indexen afzonderlijk verwijderen en geleidelijk verwijderen en vervolgens de tabel verwijderen.

  Zie ADR-herstelonderdelenvoor meer informatie over SLOG.

• Voorkom of verminder onnodige afgebroken transacties. Een hoge afbreekpercentage van transacties zorgt voor druk op de PVS-opruimer en lagere prestaties van de ADR. De aborts kunnen afkomstig zijn van een hoge frequentie van impasses, dubbele sleutels, schendingen van beperkingen of query-time-outs. In de sys.dm_tran_aborted_transactions DMV worden alle afgebroken transacties van het database-engine-exemplaar weergegeven. De kolom nested_abort geeft aan dat de transactie is doorgevoerd, maar dat er delen zijn die zijn afgebroken (savepoints of geneste transacties) die ook het PVS-opschoonproces kunnen vertragen.

• Zorg ervoor dat er voldoende ruimte in de database is om rekening te houden met PVS-gebruik. Als de database onvoldoende ruimte heeft om PVS te laten groeien, kan ADR mogelijk geen versies genereren, waardoor DML-instructies mislukken.

• Wanneer ADR is ingeschakeld met schrijfintensieve taken, kan de aanmaaksnelheid van transactielogboeken aanzienlijk toenemen omdat de naar PVS geschreven rijversies worden geregistreerd. Dit kan de grootte van back-ups van transactielogboeken vergroten.

• Wanneer u transactionele replicatie gebruikt, momentopnamereplicatieof CDC-(Change Data Capture) wijzigt, wordt het agressieve afkappingsgedrag van ADR uitgeschakeld zodat de logboeklezer wijzigingen uit het transactielogboek kan verzamelen. Zorg ervoor dat het transactielogboek voldoende groot is.

  In Azure SQL Database moet u mogelijk de servicelaag of rekenkracht verhogen om ervoor te zorgen dat er voldoende transactielogboekruimte beschikbaar is voor de behoeften van al uw workloads. Op dezelfde manier moet u in Azure SQL Managed Instance mogelijk de maximale opslaggrootte van uw exemplaar verhogen.

• Voor SQL Server isoleert u het PVS-versiearchief op een bestandsgroep op een hogere opslaglaag, zoals high-end SSD of advanced SSD of PERSISTENT Memory (PMEM), ook wel Storage Class Memory (SCM) genoemd. Zie De locatie van de PVS wijzigen in een andere bestandsgroepvoor meer informatie.

• Controleer het foutenlogboek van SQL Server op vermeldingen van PreallocatePVS. Als PreallocatePVS vermeldingen aanwezig zijn, zou u mogelijk de ADR-capaciteit moeten vergroten om pagina's vooraf toe te wijzen met behulp van een achtergrondtaak. Het vooraf toewijzen van PVS-pagina's op de achtergrond verbetert de ADR-prestaties door duurdere PVS-toewijzingen op de voorgrond te verminderen. U kunt de ADR Preallocation Factor-serverconfiguratie gebruiken om dit bedrag te verhogen. Zie Serverconfiguratie: ADR Preallocation Factorvoor meer informatie.

• Voor SQL Server 2022 (16.x) en later kunt u overwegen om multithread PVS-opschoning in te schakelen als de prestaties van de eendraadse opschoner onvoldoende zijn. Zie Serverconfiguratie: ADR Cleaner Thread Countvoor meer informatie.

• Zie Problemen met versneld databaseherstel oplossenals u problemen ondervindt zoals hoog databaseruimtegebruik door PVS of trage PVS-opschoning.

ADR-verbeteringen in SQL Server 2022

Er zijn verschillende verbeteringen voor het aanpakken van de opslag van persistente versieopslag (PVS) en verbeteren de algehele schaalbaarheid. Zie Wat is er nieuw in SQL Server 2022voor meer informatie over nieuwe functies van SQL Server 2022 (16.x).

Dezelfde verbeteringen zijn ook beschikbaar in Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (alleen toegewezen SQL-pool) en SQL-database in Microsoft Fabric.

• opschonen van gebruikerstransacties

  Opschonen van pagina's die niet kunnen worden opgeschoond door het reguliere proces vanwege een fout bij het verkrijgen van vergrendelingen.

  Met deze functie kunnen gebruikerstransacties een opschoning uitvoeren op pagina's die niet konden worden aangepakt door het reguliere opschoningsproces vanwege tabelniveauvergrendeling conflicten. Deze verbetering helpt ervoor te zorgen dat het ADR-opschoonproces niet voor onbepaalde tijd mislukt, omdat gebruikersworkloads geen vergrendelingen op tabelniveau kunnen verkrijgen.

• Geheugenvoetafdruk voor PVS-paginatracker verminderen

  Met deze verbetering worden PVS-pagina's op het niveau van de omvang bijgehouden om de geheugenvoetafdruk te verminderen die nodig is om geversiede pagina's te onderhouden.

• PVS schonere verbeteringen

  PVS-cleaner heeft de efficiëntie van het opschonen van versies verbeterd, zodat de database-engine rijversies van afgebroken transacties beter kan bijhouden en registreren. Dit leidt tot verbeteringen in het geheugen- en opslaggebruik.

• permanente versieopslag op transactieniveau (PVS)

  Met deze verbetering kan ADR versies opschonen die deel uitmaken van vastgelegde transacties, onafhankelijk van of er afgebroken transacties in het systeem zijn. Dankzij deze verbetering kunnen PVS-pagina's worden vrijgegeven, zelfs als het opschonen niet kan worden voltooid om de afgebroken transactiemap bij te werken.

  Het resultaat van deze verbetering is een verminderde PVS-groei, zelfs als PVS-opschoning traag of mislukt.

• Opschonen van multi-threaded versie

  In SQL Server 2019 (15.x) is het opschoningsproces enkelvoudig gethreaded binnen een database-engine-instantie.

  Vanaf SQL Server 2022 (16.x) wordt het opschonen van versies met meerdere threads ondersteund. Hierdoor kunnen meerdere databases op hetzelfde database-engineexemplaren parallel worden opgeschoond of kan één database sneller worden opgeschoond. Zie Serverconfiguratie: ADR Cleaner Thread Countvoor meer informatie.

  Er is een nieuwe uitgebreide gebeurtenis, tx_mtvc2_sweep_stats, toegevoegd voor bewaking van de ADR PVS multithreaded versiereiniger.

Verwante inhoud

• Versnelde databaseherstel beheren
• Problemen met versneld databaseherstel oplossen