Ripristino accelerato del database

  • Articolo

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 (ADR) consente di migliorare la disponibilità del database, in particolare in presenza di transazioni a esecuzione prolungata, riprogettando il processo di ripristino del motore di database di SQL Server.

Azure Data Recovery è stato introdotto in SQL Server 2019 (15.x) e migliorato in SQL Server 2022 (16.x). Il ripristino accelerato del database è disponibile anche per i database nel database SQL di Azure, in Istanza gestita di SQL di Azure e Azure Synapse SQL. Per impostazione predefinita, ADR è abilitato nel database SQL e in Istanza gestita di SQL, dove non può essere disabilitato. Per altre informazioni su ADR in Azure SQL, consultare Ripristino accelerato del database in Azure SQL.

Questo articolo offre una panoramica della funzionalità ADR. 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

    Grazie al ripristino accelerato del database, le transazioni a esecuzione prolungata non influiscono sul tempo di ripristino complessivo e ciò consente 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.

Diagramma del processo di ripristino corrente.

  • 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, eseguendo il rollback delle operazioni eseguite dalla 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 in base a questa progettazione può richiedere molto tempo in quanto viene usata la stessa fase di ripristino del rollback descritta in precedenza.

Inoltre, il motore di database non può troncare il log delle transazioni quando sono presenti transazioni a esecuzione prolungata, poiché i record del log corrispondenti sono necessari 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

Il ripristino accelerato del database risolve i problemi precedenti riprogettando completamente il processo di ripristino del motore di database per:

  • 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, le transazioni a esecuzione prolungata non influiscono sul tempo di ripristino.
  • Ridurre al minimo lo spazio necessario per il log delle transazioni, in quanto non è più necessario elaborare il log per l’intera transazione. Di conseguenza, è possibile troncare con decisione il log delle transazioni 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.

Diagramma del processo di ripristino accelerato del database.

  • Fase di analisi

    Il processo è identico a quello corrente, con l'aggiunta della ricostruzione di SLOG (flusso di log di sistema) e della copia dei record di log per le operazioni senza controllo delle versioni.

  • Fase di rollforward

    Suddivisa in due fasi secondarie

    • Fase secondaria 1

      Rollforward da SLOG, dalla transazione meno recente di cui non è stato eseguito il commit fino all’ultimo checkpoint. La fase di rollforward è un’operazione rapida, in quanto basta elaborare solo pochi 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 rollback con il ripristino accelerato del database viene completata quasi istantaneamente usando SLOG per il rollback delle operazioni senza controllo delle versioni e l’archivio versioni permanente (PVS, Persisted Version Store) con ripristino logico per eseguire il rollback basato sulla versione a livello di riga.

È anche possibile guardare questo video di 8 minuti che spiega il recupero 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. In SQL Server 2019 (15.x) esiste un thread PVS per istanza. 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 senza controllo delle versioni, ad esempio l’invalidamento della cache dei metadati, le acquisizioni di blocchi e così via. SLOG vanta le caratteristiche seguenti:

    • Volume ridotto e modello 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
    • Accelerazione delle fasi di rollback e rollforward grazie all’elaborazione solo delle operazioni senza controllo delle versioni
    • Troncamento del log delle transazioni aggressivo mantenendo solo i record di log necessari

  • Pulizia

    La pulizia è un processo asincrono che viene riattivato periodicamente e pulisce le versioni di pagina non necessarie.

Miglioramenti del ripristino accelerato del database 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.

  • Pulizia delle transazioni utente

    Cancellare le pagine che non hanno potuto essere pulite dal processo regolare a causa di un errore di blocco.

    Questa funzionalità consente alle transazioni utente di eseguire la pulizia delle pagine che non possono essere gestite dal normale processo di pulizia a causa di conflitti di blocco a livello di tabella. Questo miglioramento contribuisce a garantire che il processo di pulizia dell'ADR non fallisca all'infinito perché i carichi di lavoro degli utenti non possono acquisire i lock a livello di tabella.

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

    Questo miglioramento tiene traccia delle pagine persistenti dell'archivio delle versioni (PVS) a livello di estensione, al fine di ridurre l'ingombro di memoria necessario per mantenere le pagine versionate.

  • Miglioramenti del programma di pulizia per il recupero accelerato dei dati (ADR)

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

  • Archivio delle versioni persistenti a livello di transazione (PVS)

    Questo miglioramento consente ad ADR di ripulire le versioni appartenenti a transazioni impegnate, indipendentemente dalla presenza di transazioni interrotte nel sistema. Con questo miglioramento le pagine dell'archivio di versioni persistenti (PVS) possono essere deallocate, anche se il cleanup non riesce a completare un'analisi corretta per tagliare la mappa della transazione interrotta.

    Il risultato di questo miglioramento è una crescita ridotta dell'archivio delle versioni persistenti (PVS) anche se la pulizia dell'ADR è lenta o fallisce.

  • 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 utilizza una pulizia della versione multi-thread. Ciò consente di pulire in parallelo più database nella stessa istanza di SQL Server. 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, si consiglia di utilizzare un numero di thread di pulizia ADR pari al numero di database. Ad esempio, se si configura ADR Cleaner Thread Count come 4 su un'istanza di SQL Server con due database, il pulitore ADR continuerà ad allocare solo un thread per database, lasciando inattivi i due thread rimanenti.

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

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

  • Nuovi eventi estesi

    È stato aggiunto un nuovo evento esteso, tx_mtvc2_sweep_stats, per la telemetria sul pulitore ADR PVS versione multi-thread.

Procedure consigliate e materiale sussidiario

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

Importante

Nel 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