Accelererad databasåterställning

gäller för: SQL Server 2019 (15.x) och senare versioner Azure SQL DatabaseAzure SQL Managed InstanceSQL-databas i Microsoft Fabric

Accelererad databasåterställning (ADR) förbättrar databastillgängligheten, särskilt i närvaro av långvariga transaktioner, genom att göra om återställningsprocessen för databasmotorn.

ADR introducerades i SQL Server 2019 (15.x) och förbättrades i SQL Server 2022 (16.x). ADR är också tillgängligt i Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (endast dedikerad SQL-pool) och SQL-databas i Microsoft Fabric.

Not

ADR är alltid aktiverat i Azure SQL Database, Azure SQL Managed Instance och SQL Database i Fabric.

Den här artikeln innehåller en översikt över ADR. Om du vill arbeta med ADR läser du Hantera accelererad databasåterställning.

Mer information om transaktionslogg och databasåterställning finns i arkitektur och hanteringsguide för SQL Server-transaktionsloggar och Översikt över återställning och återställning (SQL Server).

Överblick

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

• snabb och konsekvent databasåterställning

  Långvariga transaktioner påverkar inte den totala återställningstiden, vilket möjliggör snabb och konsekvent databasåterställning oavsett antalet aktiva transaktioner i systemet eller deras storlek.

• Omedelbar återställning av transaktioner

  Transaktionsåterställningen sker omedelbart, oavsett när transaktionen har varit aktiv eller antalet uppdateringar som har gjorts.

• Aggressiv loggtrunkering

  Transaktionsloggen trunkeras aggressivt, även i närvaro av aktiva långvariga transaktioner, vilket förhindrar att den växer okontrollerat.

Den traditionella databasåterställningsprocessen

Utan ADR följer databasåterställningen ARIES- återställningsmodell och består av tre faser, som illustreras och förklaras mer detaljerat i följande diagram:

• Analysfasen

  Databasmotorn utför en framåtsökning av transaktionsloggen från början av den senaste lyckade kontrollpunkten (eller det äldsta smutsiga sidans loggsekvensnummer (LSN)) till slutet, för att fastställa läget för varje transaktion vid tidpunkten då motorn stoppades.

• Gör om fas

  Databasmotorn utför en vidaresökning av transaktionsloggen från den äldsta ogenomförda transaktionen till slutet. Den här processen gör om alla verkställda operationer för att återställa databasen till dess tillstånd vid tidpunkten för kraschen.

• Ångra fasen

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

• Med den traditionella databasåterställningsprocessen kan återställning efter en krasch ta lång tid om en tidskrävande transaktion var aktiv.

  Tiden för databasmotorn att återställas från en oväntad omstart är (ungefär) proportionell mot storleken på den längsta aktiva transaktionen i systemet vid tidpunkten för kraschen. Återställning kräver en återgång 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.

• Att avbryta eller återställa en stor transaktion kan ta lång tid eftersom den använder samma ångraåterställningsfas som beskrivits tidigare.

• Databasmotorn kan inte trunkera transaktionsloggen när det finns långvariga transaktioner eftersom motsvarande loggposter behövs för återställnings- och återgångsprocesserna. Därför kan transaktionsloggen växa mycket stort och förbruka mycket lagringsutrymme.

Den accelererade databasåterställningsprocessen

ADR åtgärdar tidigare problem med den traditionella återställningsmodellen genom att helt omdesigna återställningsprocessen för databasmotorn till:

• Gör återställningstiden konstant eftersom det inte längre finns något behov av att skanna transaktionsloggen från början av den äldsta aktiva transaktionen. Med ADR bearbetas transaktionsloggen från den senaste lyckade kontrollpunkten (eller den äldsta smutsiga sidan LSN) endast. Därför påverkas inte återställningstiden av långvariga transaktioner och är vanligtvis omedelbar.

• Minimera det nödvändiga transaktionsloggutrymmet eftersom det inte längre finns något behov av att behålla loggen för hela transaktionen. Därför kan transaktionsloggen förkortas aggressivt när kontrollpunkter och säkerhetskopior sker.

På ett övergripande plan uppnår ADR snabb återställning av databasen genom att skapa versioner av alla fysiska databasändringar och endast ångra icke-versionerade operationer, 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 traditionella återställningsprocessen. Hur dessa faser fungerar med ADR illustreras i följande diagram:

• Analysfas

  Processen förblir densamma som den traditionella återställningsmodellen med tillägget att rekonstruera den sekundära loggströmmen (SLOG) och kopiera loggposter för icke-versionerade operationer.

• Gör om fasen

  Uppdelad i två underfaser

  • Underfas 1

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

  • Underfas 2

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

• Ångra fas

  Ångra-fasen med ADR slutförs nästan omedelbart genom att använda SLOG för att ångra icke-versionerade åtgärder och persistent version store (PVS) med hjälp av logisk återställning för att utföra återställning baserad på versioner på radnivå.

En förklaring av accelererad databasåterställning finns i den här åtta minuter långa videon:

ADR-återställningskomponenter

De fyra viktigaste komponenterna i ADR är:

• beständigt versionsarkiv (PVS)

  Det beständiga versionsarkivet (PVS) är en databasmotormekanism för att bevara radversioner i själva databasen i stället för i det traditionella versionsarkivet i tempdb-databasen. 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 ångring på radnivå – vilket ger omedelbar återställning av transaktioner och ångra för alla versionerade operationer.

  • Håller reda på alla avbrutna transaktioner
  • Utför återställning med hjälp av PVS för alla användartransaktioner
  • Släpper alla lås omedelbart efter att transaktionen har avbrutits

• SLOG

  SLOG är en sekundär minnesintern loggström som lagrar loggposter för icke-versionerade operationer (till exempel ogiltigförklaring av metadatacache, låsförvärv och så vidare). SLOG:

  • Låg volym och internminne
  • Sparats på disk under kontrollpunktsprocessen
  • Trunkeras periodiskt när transaktioner bekräftas
  • Snabbar upp gör om och ångra genom att endast bearbeta icke-versionerade operationer
  • Aktiverar aggressiv förkortning av transaktionsloggar genom att endast bevara nödvändiga loggposter.

• Rengöring

  Städprocessen är den asynkrona process som med jämna mellanrum vaknar och rensar bort föråldrade radversioner från PVS.

Arbetsbelastningar som drar nytta av ADR

ADR är särskilt fördelaktigt för arbetsbelastningar som har:

• Långvariga transaktioner.
• Aktiva transaktioner som gör att transaktionsloggen växer avsevärt.
• Långa perioder av databas otillgänglighet på grund av tidskrävande återställning (till exempel från oväntad omstart av tjänsten eller manuell återställning av transaktioner).

Metodtips för ADR

• Undvik onödiga långvariga transaktioner. Även om ADR påskyndar databasåterställningen även med långvariga transaktioner kan sådana transaktioner fördröja versionsrensningen och öka storleken på PVS.

• Undvik stora transaktioner som innehåller DDL-åtgärder. ADR använder mekanismen för sekundär loggström (SLOG) för att spåra DDL-åtgärder som används vid återställning. SLOG används endast när transaktionen är aktiv. SLOG loggas med kontrollpunkter, så att undvika stora transaktioner som använder SLOG kan hjälpa den totala prestandan. Dessa scenarier kan leda till att SLOG tar upp mer utrymme:

  • Många DDL-kommandon 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. Till exempel skulle en DROP TABLE operation i en sådan tabell kräva en stor reservation av SLOG-minne, vilket skulle fördröja trunkeringen av transaktionsloggen och fördröja återställningsoperationer. Som en lösning släpper du indexen individuellt och gradvis och släpper sedan tabellen.

  Mer information om SLOG finns i ADR-återställningskomponenter.

• Förhindra eller minska onödiga avbrutna transaktioner. En hög transaktionsavbrottsrate sätter press på PVS-cleaner och resulterar i lägre ADR-prestanda. Avbrott kan bero på en hög frekvens av dödlägen, duplicerade nycklar, begränsningsöverträdelser eller tidsgränser för frågebegäran. sys.dm_tran_aborted_transactions DMV visar alla avbrutna transaktioner i databasmotorinstansen. Kolumnen nested_abort anger att transaktionen har genomförts, men att det finns delar som avbröts (sparpunkter eller kapslade transaktioner) som också kan fördröja PVS-rensningsprocessen.

• Se till att det finns tillräckligt med utrymme i databasen för att ta hänsyn till PVS-användning. Om databasen inte har tillräckligt med utrymme för att PVS ska växa kan ADR misslyckas med att generera versioner, vilket gör att DML-instruktioner misslyckas.

• När ADR är aktiverat med skrivintensiva arbetsbelastningar kan genereringshastigheten för transaktionsloggar öka avsevärt eftersom radversioner som skrivits till PVS loggas. Detta kan öka storleken på säkerhetskopieringar av transaktionsloggar.

• När du använder transaktionsreplikering, replikering av ögonblicksbildereller CDC (Change Data Capture, ändringsdatainsamling), inaktiveras det aggressiva loggtrunkeringsbeteendet i ADR för att loggläsaren ska kunna samla in ändringar från transaktionsloggen. Kontrollera att transaktionsloggen är tillräckligt stor.

  I Azure SQL Database kan du behöva öka tjänstnivån eller beräkningsstorleken för att säkerställa att det finns tillräckligt med transaktionsloggutrymme för alla dina arbetsbelastningar. På samma sätt kan du i Azure SQL Managed Instance behöva öka din instans maximal lagringsstorlek.

• För SQL Server isolerar du PVS-versionsarkivet i en filgrupp på lagringsenheter av högre klass, som exempelvis avancerad SSD eller beständigt minne (PMEM), som ibland kallas lagringsklassminne (SCM). Mer information finns i Ändra platsen för PVS till en annan filgrupp.

• Övervaka felloggen i SQL Server för inlägg markerade med PreallocatePVS. Om PreallocatePVS-poster finns kan du behöva förbättra ADR-förmågan att förallokera sidor med hjälp av en bakgrundsuppgift. Att förallokera PVS-sidor i bakgrunden förbättrar ADR-prestanda genom att minska de dyrare PVS-allokeringarna i förgrunden. Du kan använda ADR Preallocation Factor serverkonfigurationen för att öka den här mängden. Mer information finns i Server-konfiguration: ADR Preallocation Factor.

• För SQL Server 2022 (16.x) och senare bör du överväga att aktivera flertrådad PVS-rensning om prestanda för den entrådiga rengöraren inte är tillräcklig. Mer information finns i Serverkonfiguration: ADR Cleaner Thread Count.

• Om du märker problem som att PVS använder mycket databasutrymme eller att PVS-rensning går långsamt, se Felsöka accelererad databasåterställning.

ADR-förbättringar i SQL Server 2022

Det finns flera förbättringar för att hantera lagring av beständiga versioner (PVS) och förbättra den övergripande skalbarheten. Mer information om nya funktioner i SQL Server 2022 (16.x) finns i Nyheter i SQL Server 2022.

Samma förbättringar är också tillgängliga i Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (endast dedikerad SQL-pool) och SQL-databas i Microsoft Fabric.

• Rensning av användartransaktion

  Rensa sidor som inte kan rensas av den vanliga processen på grund av låsningsfel.

  Med den här funktionen kan användartransaktioner köra rensning på sidor som inte kunde åtgärdas av den regelbundna rensningsprocessen på grund av låskonflikter på tabellnivå. Den här förbättringen säkerställer att ADR-rensningsprocessen inte misslyckas på obestämd tid eftersom användararbetsbelastningar inte kan hämta lås på tabellnivå.

• Minska minnesavtrycket för PVS-sidspårare

  Den här förbättringen spårar PVS-sidor på omfattningsnivå för att minska det minnesavtryck som krävs för att underhålla versionssidor.

• Förbättringar av PVS-rengöringsmedel

  PVS Cleaner har förbättrat versionsrensningseffektiviteten för att förbättra hur databasmotorn spårar och registrerar radversioner för avbrutna transaktioner. Detta leder till förbättringar i minnes- och lagringsanvändningen.

• beständigt versionslager på transaktionsnivå (PVS)

  Den här förbättringen gör att ADR kan rensa versioner som tillhör committerade transaktioner oberoende av om det finns avbrutna transaktioner i systemet. Med den här förbättringen kan PVS-sidor frigöras, även om rensningen inte lyckas med ett fullständigt svep för att trimma kartan över avbrutna transaktioner.

  Resultatet av den här förbättringen är minskad PVS-tillväxt även om PVS-rensningen är långsam eller misslyckas.

• Städning av flertrådsversioner

  I SQL Server 2019 (15.x) är rensningsprocessen en enkeltrådad process inom en instans av databasmotorn.

  Från och med SQL Server 2022 (16.x) stöds rensning av flera trådar. Detta gör att flera databaser på samma databasmotorinstans kan rensas parallellt eller att en enskild databas rensas snabbare. Mer information finns i Server-konfiguration: ADR Cleaner Thread Count.

  En ny utökad händelse, tx_mtvc2_sweep_stats, har lagts till för övervakning av det flertrådiga versionsreningsverktyget i ADR PVS.

Relaterat innehåll

• Hantera accelererad databasåterställning
• Felsöka accelererad databasåterställning