Accelererad databasåterställning i Azure SQL

  • Artikel

Gäller för:Azure SQL DatabaseAzure SQL Managed Instance

Accelerated Database Recovery (ADR) är en SQL Server-databasmotorfunktion som avsevärt förbättrar databastillgängligheten, särskilt i närvaro av långvariga transaktioner, genom att göra om återställningsprocessen för SQL Server-databasmotorn.

ADR är för närvarande tillgängligt för Azure SQL Database, Azure SQL Managed Instance, databaser i Azure Synapse Analytics och SQL Server på virtuella Azure-datorer från och med SQL Server 2019. Information om ADR i SQL Server finns i Hantera accelererad databasåterställning.

Kommentar

ADR är aktiverat som standard i Azure SQL Database och Azure SQL Managed Instance. Det går inte att inaktivera ADR i Azure SQL Database och Azure SQL Managed Instance.

Översikt

De främsta fördelarna med ADR är:

  • Snabb och konsekvent databasåterställning

    Med ADR påverkar tidskrävande transaktioner inte den totala återställningstiden, vilket möjliggör snabb och konsekvent databasåterställning oavsett antalet aktiva transaktioner i systemet eller deras storlekar.

  • Omedelbar transaktionsåterställning

    Med ADR är transaktionsåterställningen omedelbar, oavsett när transaktionen har varit aktiv eller antalet uppdateringar som har utförts.

  • Aggressiv loggtrunkering

    Med ADR trunkeras transaktionsloggen aggressivt, även i närvaro av aktiva långvariga transaktioner, vilket hindrar den från att växa utom kontroll.

Standardåterställningsprocess för databaser

Databasåterställning följer ARIES-återställningsmodellen och består av tre faser, som illustreras i följande diagram och förklaras mer detaljerat efter diagrammet.

current recovery process

  • Analysfas

    Vidarebefordra genomsökning av transaktionsloggen från början av den senaste lyckade kontrollpunkten (eller den äldsta felaktiga sidan LSN) till slutet för att fastställa tillståndet för varje transaktion när databasen stoppades.

  • Gör om fas

    Vidarebefordra genomsökning av transaktionsloggen från den äldsta icke-bekräftade transaktionen till slutet för att föra databasen till det tillstånd som den var vid tidpunkten för kraschen genom att göra om alla incheckade åtgärder.

  • Ångra fas

    För varje transaktion som var aktiv vid tidpunkten för kraschen går du bakåt i loggen och ångrar de åtgärder som transaktionen utförde.

Baserat på den här designen är den tid det tar för SQL Server-databasmotorn att återställa från en oväntad omstart (ungefär) proportionell mot storleken på den längsta aktiva transaktionen i systemet vid tidpunkten för kraschen. Återställning kräver en återställning av alla ofullständiga transaktioner. Den tid som krävs är proportionell mot det arbete som transaktionen har utfört och den tid den har varit aktiv. Återställningsprocessen kan därför ta lång tid i närvaro av långvariga transaktioner (till exempel stora massinfogningsåtgärder eller indexskapande åtgärder mot en stor tabell).

Det kan också ta lång tid att avbryta/återställa en stor transaktion baserat på den här designen eftersom den använder samma Ångra-återställningsfas som beskrivs ovan.

Dessutom kan SQL Server-databasmotorn inte trunkera transaktionsloggen när det finns långvariga transaktioner eftersom motsvarande loggposter behövs för återställnings- och återställningsprocesserna. Som ett resultat av den här designen av SQL Server-databasmotorn brukade vissa kunder stöta på problemet att storleken på transaktionsloggen växer mycket stor och förbrukar enorma mängder diskutrymme.

Processen för accelererad databasåterställning

ADR åtgärdar ovanstående problem genom att helt omdesigna återställningsprocessen för SQL Server-databasmotorn till:

  • Gör det konstant tid/ögonblick genom att undvika att behöva skanna loggen från/till början av den äldsta aktiva transaktionen. Med ADR bearbetas transaktionsloggen endast från den senaste lyckade kontrollpunkten (eller den äldsta felaktiga sidans loggsekvensnummer (LSN)). Därför påverkas inte återställningstiden av långvariga transaktioner.
  • Minimera det nödvändiga transaktionsloggutrymmet eftersom det inte längre finns något behov av att bearbeta loggen för hela transaktionen. Därför kan transaktionsloggen trunkeras aggressivt när kontrollpunkter och säkerhetskopior sker.

På hög nivå uppnår ADR snabb databasåterställning genom att versionshantera alla ändringar av fysiska databaser och endast ångra logiska åtgärder, som är begränsade och kan ångras nästan omedelbart. Alla transaktioner som var aktiva vid tidpunkten för en krasch markeras som avbrutna och därför kan alla versioner som genereras av dessa transaktioner ignoreras av samtidiga användarfrågor.

ADR-återställningsprocessen har samma tre faser som den aktuella återställningsprocessen. Hur dessa faser fungerar med ADR illustreras i följande diagram och förklaras mer detaljerat efter diagrammet.

ADR recovery process

  • Analysfas

    Processen förblir densamma som tidigare med tillägg av rekonstruera SLOG och kopiera loggposter för icke-versionsbaserade åtgärder.

  • Gör om fas

    Uppdelad i två faser (P)

    • Fas 1

      Gör om från SLOG (den äldsta ogenomförda transaktionen upp till den sista kontrollpunkten). Gör om är en snabb åtgärd eftersom den bara behöver bearbeta några poster från SLOG.

    • Fas 2

      Gör om från transaktionsloggen börjar från den senaste kontrollpunkten (i stället för den äldsta icke-samtidiga transaktionen)

  • Ångra fas

    Ångra-fasen med ADR slutförs nästan omedelbart med hjälp av SLOG för att ångra icke-versionsåtgärder och beständiga versionsarkiv (PVS) med logisk återställning för att utföra versionsbaserad ångra på radnivå.

ADR-återställningskomponenter

De fyra viktigaste komponenterna i ADR är:

  • Beständigt versionsarkiv (PVS)

    Det bevarade versionsarkivet är en ny SQL Server-databasmotormekanism för att bevara radversionerna som genereras i själva databasen i stället för det traditionella tempdb versionsarkivet. PVS möjliggör resursisolering och förbättrar tillgängligheten för läsbara sekundärfiler.

  • Logisk återställning

    Logisk återställning är den asynkrona process som ansvarar för att utföra versionsbaserad ångra på radnivå – vilket ger omedelbar transaktionsåterställning och ångra för alla versionsbaserade åtgärder. Logisk återställning utförs av:

    • Hålla reda på alla avbrutna transaktioner och markera dem som osynliga för andra transaktioner.
    • Utföra återställning med hjälp av PVS för alla användartransaktioner i stället för att fysiskt genomsöka transaktionsloggen och ångra ändringar en i taget.
    • Frigör alla lås omedelbart efter att transaktionen avbrutits. Eftersom abort innebär att helt enkelt markera ändringar i minnet, är processen mycket effektiv och därför behöver lås inte hållas under lång tid.

  • SLIT

    SLOG är en sekundär minnesintern loggström som lagrar loggposter för icke-versionsbaserade åtgärder (till exempel ogiltig metadatacache, låsförvärv och så vidare). SLÅ är:

    • Låg volym och minnesintern
    • Bevaras på disken genom att serialiseras under kontrollpunktsprocessen
    • Periodiskt trunkerad som transaktionsöverföring
    • Gör om och ångra snabbare genom att endast bearbeta icke-versionsåtgärder
    • Aktiverar aggressiv trunkering av transaktionsloggar genom att endast bevara nödvändiga loggposter

  • Renare

    Renare är den asynkrona process som vaknar regelbundet och rensar sidversioner som inte behövs.

Accelererade databasåterställningsmönster (ADR)

Följande typer av arbetsbelastningar drar mest nytta av ADR:

  • ADR rekommenderas för arbetsbelastningar med långvariga transaktioner.
  • ADR rekommenderas för arbetsbelastningar som har sett fall där aktiva transaktioner gör att transaktionsloggen växer avsevärt.
  • ADR rekommenderas för arbetsbelastningar som har upplevt långa perioder av databas otillgänglighet på grund av långvarig återställning (till exempel oväntad omstart av tjänsten eller manuell återställning av transaktioner).

Metodtips för accelererad databasåterställning

  • Undvik långvariga transaktioner i databasen. Även om ett mål med ADR är att påskynda databasåterställningen på grund av att du gör om långa aktiva transaktioner, kan långvariga transaktioner fördröja versionsrensningen och öka storleken på PVS.

  • Undvik stora transaktioner med datadefinitionsändringar eller DDL-åtgärder. ADR använder en SLOG-mekanism (systemloggström) för att spåra DDL-åtgärder som används vid återställning. SLÅ används endast när transaktionen är aktiv. SLOG är kontrollpunkt, så att undvika stora transaktioner som använder SLOG kan hjälpa övergripande prestanda. Dessa scenarier kan leda till att SLOG tar upp mer utrymme:

    • Många DDL:er körs i en transaktion. I en transaktion kan du till exempel snabbt skapa och släppa temporära tabeller.

    • En tabell har ett mycket stort antal partitioner/index som har ändrats. En DROP TABLE-åtgärd i en sådan tabell skulle till exempel kräva en stor reservation av SLOG-minnet, vilket skulle fördröja trunkeringen av transaktionsloggen och fördröja ångra/göra om åtgärder. Lösningen kan vara att släppa indexen individuellt och gradvis och sedan släppa tabellen. Mer information om SLOG finns i ADR-återställningskomponenter.

  • Förhindra eller minska onödiga avbrutna situationer. En hög avbruten frekvens kommer att sätta press på PVS-renare och lägre ADR-prestanda. Avbrutna kan komma från en hög hastighet av dödlägen, dubbletter av nycklar eller andra begränsningar.

    • sys.dm_tran_aborted_transactions DMV visar alla avbrutna transaktioner på SQL Server-instansen. Kolumnen nested_abort anger att transaktionen har checkats in men att det finns delar som avbröts (sparpunkter eller kapslade transaktioner) som kan blockera PVS-rensningsprocessen. Mer information finns i sys.dm_tran_aborted_transactions (Transact-SQL).

    • Om du vill aktivera PVS-rensningsprocessen manuellt mellan arbetsbelastningar eller under underhållsperioder använder du sys.sp_persistent_version_cleanup. Mer information finns i sys.sp_persistent_version_cleanup.

  • Om du ser problem med lagringsanvändning, hög avbrutna transaktioner och andra faktorer kan du läsa Felsöka accelererad databasåterställning (ADR) på SQL Server.

Nästa steg