Recupero del database accelerato

Si applica a: SQL Server 2019 (15.x) e versioni successive database SQL di Azure Istanza gestita di SQL di Azure Azure Synapse Analytics

Il ripristino accelerato del database migliora la disponibilità del database, soprattutto in presenza di transazioni a esecuzione prolungata, riprogettando il processo di ripristino del motore di database SQL.

Azure Data Recovery è stato introdotto in SQL Server 2019 (15.x) e migliorato in SQL Server 2022 (16.x). Azure Synapse SQL è disponibile anche per i database in database SQL di Azure, Istanza gestita di SQL di Azure e Azure Synapse SQL. Active Directory è abilitata per impostazione predefinita in database SQL e Istanza gestita di SQL e non può essere disabilitata. Per altre informazioni su ADR in Azure SQL, vedere Ripristino accelerato del database in Azure SQL.

Questo articolo offre una panoramica della funzionalità DIR. Per usare ADR, vedere Gestire il ripristino accelerato del database.

Panoramica

I principali vantaggi del ripristino accelerato del database sono i seguenti:

• Ripristino rapido e coerente del database

  Con ADR, le transazioni a esecuzione prolungata non influiscono sul tempo di recupero complessivo, consentendo un ripristino rapido e coerente del database indipendentemente dal numero di transazioni attive nel sistema o dalle relative dimensioni.

• Rollback di transazione istantaneo

  Con il ripristino accelerato del database, il rollback di transazione è istantaneo, indipendentemente dal tempo in cui la transazione è stata attiva o dal numero di aggiornamenti eseguiti.

• Troncamento del log aggressivo

  Con il ripristino accelerato del database, il log delle transazioni viene troncato in modo aggressivo, anche in presenza di transazioni a esecuzione prolungata attive, per impedire la crescita fuori controllo.

Processo di ripristino del database corrente

Senza il ripristino accelerato del database, il processo di ripristino del database in SQL Server segue il modello ARIES ed è costituito da tre fasi, illustrate nel diagramma seguente e spiegate in modo più dettagliato dopo il diagramma.

• Fase di analisi

  SQL Server esegue un'analisi in avanti del log delle transazioni dall'inizio dell'ultimo checkpoint riuscito, o il numero di sequenza del file di log (LSN) della pagina dirty meno recente, fino alla fine, per determinare lo stato di ogni transazione al momento dell'arresto di SQL Server.

• Fase di rollforward

  SQL Server esegue un'analisi in avanti del log delle transazioni dalla transazione meno recente di cui non è stato eseguito il commit fino alla fine, per portare il database allo stato in cui si trovava al momento dell'arresto anomalo del sistema, eseguendo il rollforward di tutte le operazioni di cui è stato eseguito il commit.

• Fase di rollback

  Per ogni transazione attiva al momento dell'arresto anomalo, SQL Server attraversa il log all'indietro, annullando le operazioni eseguite da questa transazione.

In base a questa progettazione, il tempo impiegato dal motore di database per il ripristino da un riavvio imprevisto è (approssimativamente) proporzionale alle dimensioni della transazione attiva più lunga nel sistema al momento dell'arresto anomalo. Il ripristino richiede un rollback di tutte le transazioni incomplete. La quantità di tempo necessaria è proporzionale al lavoro eseguito dalla transazione e al tempo per cui è stata attiva. Il processo di ripristino di SQL Server può quindi richiedere molto tempo in presenza di transazioni a esecuzione prolungata, ad esempio operazioni di inserimento bulk di grandi dimensioni o operazioni di compilazione di indici su una tabella di grandi dimensioni.

Inoltre, l'annullamento o il rollback di una transazione di grandi dimensioni basata su questa progettazione può richiedere molto tempo, perché usa la stessa fase di ripristino di annullamento descritta in precedenza.

Inoltre, il motore di database non può troncare il log delle transazioni quando sono presenti transazioni a esecuzione prolungata perché sono necessari i record di log corrispondenti per i processi di ripristino e rollback. Di conseguenza, alcuni log delle transazioni diventano molto grandi e utilizzano ingenti quantità di spazio su disco.

Processo di ripristino accelerato del database

AdR risolve i problemi precedenti riprogettando completamente il processo di ripristino del motore di database in:

• Rendere il ripristino costante e istantaneo, in quanto non è necessario analizzare il log da o fino all'inizio della transazione attiva meno recente. Con il ripristino accelerato del database, il log delle transazioni viene elaborato solo dall'ultimo checkpoint completato o dal numero di sequenza del file di log (LSN) della pagina dirty meno recente. Di conseguenza, il tempo di ripristino non è influenzato dalle transazioni a esecuzione prolungata.
• Ridurre al minimo lo spazio necessario del log delle transazioni perché non è più necessario elaborare il log per l'intera transazione. Di conseguenza, è possibile troncare il log delle transazioni in modo aggressivo quando si verificano checkpoint e backup.

A livello generale, il ripristino accelerato del database consente il ripristino rapido del database tramite il controllo delle versioni di tutte le modifiche fisiche del database e il rollback solo delle operazioni logiche, che sono limitate e che consentono un rollback quasi istantaneo. Tutte le transazioni attive al momento dell'arresto anomalo vengono contrassegnate come interrotte e, di conseguenza, tutte le versioni generate da queste transazioni possono essere ignorate dalle query utente simultanee.

Il processo di ripristino accelerato del database prevede le stesse tre fasi del processo di ripristino corrente. Il funzionamento di queste fasi con il ripristino accelerato del database è illustrato nel diagramma seguente.

• Fase di analisi

  Il processo rimane invariato oggi con l'aggiunta della ricostruzione del flusso di log di sistema (SLOG) e la copia dei record di log per le operazioni nonversionate.

• Fase di rollforward

  Suddiviso in due sottofase

  • Sottofase 1

    Eseguire il rollforward da SLOG (transazione di cui non è stato eseguito il commit meno recente fino all'ultimo checkpoint). Il rollforward è un'operazione veloce perché deve elaborare solo alcuni record da SLOG.

  • Fase secondaria 2

    Il rollforward dal log delle transazioni inizia dall'ultimo checkpoint (anziché dalla transazione meno recente di cui non è stato eseguito il commit).

• Fase di rollback

  La fase di annullamento con ADR viene completata quasi istantaneamente usando SLOG per annullare le operazioni nonversioni e l'archivio versioni persistenti con ripristino logico per eseguire l'annullamento basato sulla versione a livello di riga.

È anche possibile guardare questo video di otto minuti che illustra il ripristino accelerato del database:

Componenti del ripristino accelerato del database

I quattro componenti chiave del ripristino accelerato del database sono i seguenti:

• Archivio versioni permanente

  L'archivio versioni permanente è un meccanismo del motore di database per salvare in modo permanente le versioni di riga generate nel database stesso al posto di usare l'archivio versioni tempdb tradizionale. L'archivio versioni permanente consente l'isolamento delle risorse e migliora la disponibilità di database secondari leggibili. Esiste un thread PVS per istanza in SQL Server 2019 (15.x). A partire da SQL Server 2022 (16.x), SQL Server ha un thread di pulizia PVS per ogni database.

• Ripristino logico

  Il ripristino logico è il processo asincrono responsabile dell'esecuzione del rollback basato sulla versione a livello di riga, che consente di eseguire in modo istantaneo il rollback di transazione e l'annullamento per tutte le operazioni con controllo delle versioni.

  • Tiene traccia di tutte le transazioni interrotte
  • Esegue il rollback usando l'archivio versioni permanente per tutte le transazioni utente
  • Rilascia tutti i blocchi immediatamente dopo l'interruzione della transazione

• SLOG

  SLOG è un flusso di log in memoria secondario che archivia i record di log per le operazioni nonversione, ad esempio l'invalidazione della cache dei metadati, le acquisizioni di blocchi e così via. SLOG è:

  • Volume ridotto e in memoria
  • Salvataggio in modo permanente sul disco mediante la serializzazione durante il processo di checkpoint
  • Troncamento periodico quando viene eseguito il commit delle transazioni
  • Accelera il rollforward e l'annullamento elaborando solo le operazioni nonversioned
  • Troncamento del log delle transazioni aggressivo mantenendo solo i record di log necessari

• Pulizia

  Il pulitore è il processo asincrono che si riattiva periodicamente e pulisce le versioni di riga obsolete da PVS.

Miglioramenti di ADR in SQL Server 2022 (16.x)

Sono stati apportati diversi miglioramenti per risolvere il problema dell'archiviazione dell'archivio versioni permanente e migliorare la scalabilità complessiva. Per altre informazioni sulle nuove funzionalità di SQL Server 2022 (16.x), vedere Novità di SQL Server 2022 (16.x).

• Pulizia delle transazioni utente

  Cancellare le pagine che non possono essere pulite dal normale processo a causa di un errore di blocco.

  Questa funzionalità consente alle transazioni utente di eseguire la pulizia nelle pagine che non possono essere risolte dal normale processo di pulizia a causa di conflitti di blocco a livello di tabella. Questo miglioramento consente di garantire che il processo di pulizia DIR non venga eseguito a tempo indeterminato perché i carichi di lavoro utente non possono acquisire blocchi a livello di tabella.

• Riduzione del footprint di memoria per lo strumento di rilevamento della pagina PVS

  Questo miglioramento tiene traccia delle pagine dell'archivio versioni persistenti (PVS) a livello di extent, per ridurre il footprint di memoria necessario per mantenere le pagine con controllo delle versioni.

• Miglioramenti del ripristino accelerato dei dati (ADR)

  Ripristino accelerato dei dati (ADR) ha migliorato l'efficienza di pulizia della versione per migliorare il modo in cui SQL Server tiene traccia e registra le versioni interrotte di una pagina, con miglioramenti della memoria e capacità.

• Archivio versioni persistenti a livello di transazione

  Questo miglioramento consente ad ADR di pulire le versioni appartenenti alle transazioni di cui è stato eseguito il commit indipendentemente dal fatto che nel sistema siano presenti transazioni interrotte. Con questo miglioramento le pagine dell'archivio versioni persistenti possono essere deallocate, anche se la pulizia non riesce a completare uno sweep riuscito per tagliare la mappa delle transazioni interrotta.

  Il risultato di questo miglioramento è una riduzione della crescita dell'archivio versioni persistenti (PVS) anche se la pulizia di AdR è lenta o non riesce.

• Pulizia della versione multithread

  In SQL Server 2019 (15.x), il processo di pulizia è a thread singolo all'interno di un'istanza di SQL Server.

  A partire da SQL Server 2022 (16.x), questo processo usa la pulizia della versione a thread multipla. In questo modo è possibile pulire più database nella stessa istanza di SQL Server in parallelo. Questo miglioramento è utile quando si dispone di più database di grandi dimensioni.

  Per regolare il numero di thread per la scalabilità della pulizia della versione, impostare ADR Cleaner Thread Count con sp_configure. Il numero di thread è limitato al numero di core per l'istanza.

  Come procedura consigliata, è consigliabile usare lo stesso numero di thread ADR più puliti del numero di database. Ad esempio, se si configura l'oggetto in 4 un'istanza ADR Cleaner Thread Count di SQL Server con due database, ADR cleaner allocherà ancora un solo thread per database, lasciando inattivi i due thread rimanenti.

  L'esempio seguente modifica il numero di thread in 4:

  EXEC sp_configure 'ADR Cleaner Thread Count', '4';
  RECONFIGURE WITH OVERRIDE; 
  

• Nuovo evento esteso

  È stato aggiunto un nuovo evento esteso, tx_mtvc2_sweep_stats, per i dati di telemetria in ADR PVS multithread version cleaner.

Procedure consigliate e linee guida

Per indicazioni sui carichi di lavoro che sono e non sono consigliati per ADR, vedere Gestire il ripristino accelerato del database.

Importante

In database SQL di Azure le transazioni inattive (transazioni che non sono state scritte nel log delle transazioni per sei ore) vengono terminate automaticamente per liberare risorse.

Contenuto correlato

• Gestire il ripristino accelerato del database
• Risolvere i problemi relativi al ripristino accelerato del database
• Ripristino accelerato del database in Azure SQL