Ripristino accelerato del database

Si applica a:SQL Server 2019 (15.x) e versioni successive database SQL di Azure Istanza gestita di SQL di Azuredatabase SQL in Microsoft Fabric

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

Azure Data Recovery è stato introdotto in SQL Server 2019 (15.x) e migliorato in SQL Server 2022 (16.x). ADR è disponibile anche nel database SQL di Azure, nell'Istanza SQL Gestita di Azure, in Azure Synapse Analytics (solo pool SQL dedicato) e nel database SQL in Microsoft Fabric.

Questo articolo offre una panoramica di AdR. Per usare ADR, vedere Gestire il ripristino accelerato del database.

Per ulteriori informazioni sul log delle transazioni e sul ripristino del database, consulta la guida all'architettura e alla gestione del log delle transazioni di SQL Server e la panoramica sul ripristino e recupero (SQL Server).

Panoramica

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

• Ripristino rapido e coerente del database

  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

  Il rollback delle transazioni è istantaneo, indipendentemente dal momento in cui la transazione è stata attiva o dal numero di aggiornamenti eseguiti.

• Troncamento del log aggressivo

  Il log delle transazioni viene troncato in modo aggressivo, anche in presenza di transazioni attive di lunga durata, impedendone la crescita incontrollata.

Processo di ripristino del database tradizionale

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

• Fase di analisi

  Il motore di database esegue una scansione in avanti del log delle transazioni dall'inizio dell'ultimo checkpoint riuscito (o il numero di sequenza di log della pagina sporca più vecchio (LSN)) fino alla fine, per determinare lo stato di ogni transazione al momento dell'arresto del motore.

• Fase di rollforward

  Il motore di database esegue una scansione in avanti del log delle transazioni dalla transazione non commessa più vecchia fino alla fine. Questo processo riesegue tutte le operazioni di cui è stato eseguito il commit per riportare il database allo stato in cui si trovava nel momento in cui si è verificato l'arresto anomalo.

• Fase di rollback

  Per ogni transazione attiva al momento dell'arresto anomalo, il motore di database scorre il log all'indietro, annullando le operazioni eseguite da questa transazione.

• Con il tradizionale processo di ripristino del database, il recupero dopo un arresto anomalo può richiedere molto tempo se era attiva una transazione di lunga durata.

  Il tempo per il ripristino del motore di database 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.

• L'annullamento o il rollback di una transazione di grandi dimensioni può richiedere molto tempo, perché usa la stessa fase di ripristino di annullamento descritta in precedenza.

• Il motore di database non può troncare il log delle transazioni quando sono presenti transazioni di lunga durata, poiché i record di log corrispondenti sono necessari per i processi di ripristino e rollback. Di conseguenza, il log delle transazioni può aumentare notevolmente e consumare molto spazio di archiviazione.

Processo di ripristino accelerato del database

ADR affronta i problemi relativi al vecchio modello di recupero tradizionale attraverso una riprogettazione completa del processo di ripristino del motore di database:

• Rendere costante il tempo di ripristino perché non è più necessario analizzare il log delle transazioni dall'inizio della transazione attiva meno recente. Utilizzando ADR, il log delle transazioni viene elaborato solo dall'ultimo checkpoint riuscito (o dalla pagina sporca più antica LSN). Di conseguenza, il tempo di ripristino non è influenzato dalle transazioni a esecuzione prolungata ed è in genere istantaneo.

• Ridurre al minimo lo spazio necessario del log delle transazioni perché non è più necessario conservare 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, ADR ottiene un rapido ripristino del database gestendo le versioni di tutte le modifiche fisiche del database e annullando solo le operazioni non versionate, che sono limitate e possono essere annullate quasi istantaneamente. 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 di AdR ha le stesse tre fasi del processo di ripristino tradizionale. Il funzionamento di queste fasi con ADR è illustrato nel diagramma seguente:

• Fase di analisi

  Il processo rimane lo stesso del modello di recupero tradizionale, con l'aggiunta della ricostruzione del flusso di log secondario (SLOG) e la copia dei record di log per le operazioni non versionate.

• Fase di rollforward

  Suddivisa in due fasi secondarie

  • Fase secondaria 1

    Eseguire il recupero da SLOG (dalla transazione meno recente non confermata fino all'ultimo checkpoint). La riesecuzione è un'operazione veloce perché potrebbe essere necessario elaborare solo alcuni record dallo SLOG.

  • Sottofase 2

    Il rifare dal log delle transazioni inizia dall'ultimo checkpoint eseguito con successo (invece della transazione non registrata meno recente).

• Fase di rollback

  La fase di annullamento con ADR viene completata quasi istantaneamente usando SLOG per annullare le operazioni non-versionate e l'archivio delle versioni persistenti (PVS) utilizzando la reversione logica per eseguire l'annullamento a livello di riga basato sulla versione.

Per una spiegazione del ripristino accelerato del database, guardare questo video di otto minuti:

Componenti del ripristino accelerato del database

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

• archivio versioni permanenti (PVS)

  L'archivio versioni permanenti (PVS) è un meccanismo del motore di database per rendere persistenti le versioni di riga nel database stesso anziché nell'archivio versioni tradizionale nel database tempdb. L'archivio versioni permanente consente l'isolamento delle risorse e migliora la disponibilità di database secondari leggibili.

• 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
  • Persistente su disco durante il processo di checkpoint
  • Troncamento periodico quando viene eseguito il commit delle transazioni
  • Accelera la ripetizione e l'annullamento di operazioni elaborando solo operazioni non versionate.
  • 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.

Carichi di lavoro che traggono vantaggio da ADR

AdR è particolarmente utile per i carichi di lavoro con:

• Transazioni a esecuzione prolungata.
• Transazioni attive che causano un aumento significativo del log delle transazioni.
• Lunghi periodi di indisponibilità del database a causa del ripristino che richiede molto tempo, come nel caso di un riavvio imprevisto del servizio o del rollback delle transazioni effettuato manualmente.

Procedure consigliate per ADR

• Evitare transazioni lunghe non necessarie. Anche se ADR accelera il ripristino del database anche con transazioni a esecuzione prolungata, tali transazioni possono ritardare la pulizia della versione e aumentare le dimensioni del PVS.

• Evitare di effettuare transazioni di grandi dimensioni che includono operazioni DDL. AdR usa il meccanismo SLOG (Secondary Log Stream) per tenere traccia delle operazioni DDL usate nel ripristino. SLOG viene usato solo mentre la transazione è attiva. Evitare transazioni di grandi dimensioni che usano SLOG può migliorare le prestazioni complessive, poiché SLOG viene sottoposto a checkpoint. Questi scenari possono causare l'uso di più spazio da parte di SLOG:

  • Molti DDL vengono eseguiti in una transazione. Ad esempio, in una transazione, creare e eliminare rapidamente tabelle temporanee.
  • Una tabella ha un numero molto elevato di partizioni/indici modificati. Ad esempio, un'operazione di DROP TABLE su tale tabella richiederebbe una grande allocazione di memoria SLOG, che ritarderebbe il troncamento del log delle transazioni e le operazioni di annullamento/ricostruzione. Come soluzione alternativa, eliminare gli indici singolarmente e gradualmente, quindi eliminare la tabella.

  Per altre informazioni su SLOG, vedere componenti di ripristino di ADR.

• Impedire o ridurre le transazioni interrotte non necessarie. Una velocità di interruzione delle transazioni elevata comporta una pressione sul pulitore PVS e prestazioni ADR inferiori. Gli interruzioni potrebbero provenire da una frequenza elevata di deadlock, chiavi duplicate, violazioni dei vincoli o timeout delle query. La DMV sys.dm_tran_aborted_transactions mostra tutte le transazioni interrotte nell'istanza del motore di database. La colonna nested_abort indica che la transazione è stata confermata, ma ci sono parti interrotte (punti di salvataggio o transazioni annidate) che possono anche ritardare il processo di pulizia PVS.

• Assicurarsi che nel database sia disponibile spazio sufficiente per tenere conto dell'utilizzo di PVS. Se nel database non c'è spazio sufficiente per l'espansione di PVS, ADR potrebbe non riuscire a generare versioni, causando il fallimento delle istruzioni DML.

• Quando ADR è abilitato con carichi di lavoro a uso intensivo della scrittura, la velocità di generazione del log delle transazioni potrebbe aumentare notevolmente, poiché le versioni di riga scritte nel PVS vengono registrate. Ciò potrebbe aumentare le dimensioni dei backup del log delle transazioni.

• Quando si usa replica transazionale, replica snapshoto change data capture (CDC), il comportamento aggressivo di troncamento del log di AdR è disabilitato per consentire al lettore di log di raccogliere le modifiche dal log delle transazioni. Assicurarsi che il log delle transazioni sia sufficientemente grande.

  Nel database SQL di Azure potrebbe essere necessario aumentare il livello di servizio o le dimensioni di calcolo per assicurarsi che lo spazio del log delle transazioni sufficiente sia disponibile per le esigenze di tutti i carichi di lavoro. Analogamente, in Istanza gestita di SQL di Azure potrebbe essere necessario aumentare le dimensioni massime di archiviazione dell'istanza.

• Nel caso di SQL Server, isolare l'archivio delle versioni PVS su un filegroup su uno storage di livello superiore, come unità SSD di fascia alta o SSD avanzata o Memoria Persistente (PMEM), talvolta definita come Storage Class Memory (SCM). Per ulteriori informazioni, vedere Cambia la posizione del PVS in un filegroup diverso.

• Per SQL Server, monitorare il log degli errori relative alle voci PreallocatePVS. Se sono presenti voci PreallocatePVS, potrebbe essere necessario aumentare l'abilità di ADR per preallocare le pagine con un'attività in background. La preallocazione delle pagine PVS in background migliora le prestazioni di ADR riducendo le allocazioni PVS in primo piano più costose. È possibile usare la configurazione del server ADR Preallocation Factor per aumentare questa quantità. Per ulteriori informazioni, vedere Configurazione del Server : ADR Preallocation Factor.

• Per SQL Server 2022 (16.x) e versioni successive, valutare la possibilità di abilitare la pulizia PVS multithread se le prestazioni di pulizia a thread singolo non sono sufficienti. Per ulteriori informazioni, consultare la configurazione del server : ADR Cleaner Thread Count.

• Se si osservano problemi come l'utilizzo elevato dello spazio del database da parte di PVS o la pulizia lenta di PVS, vedere Risolvere i problemi relativi al ripristino accelerato del database.

Miglioramenti di ADR in SQL Server 2022

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.

Gli stessi miglioramenti sono disponibili anche nel database SQL di Azure, in Istanza gestita di SQL di Azure, in Azure Synapse Analytics (solo pool SQL dedicato) e nel database SQL in Microsoft Fabric.

• Pulizia delle transazioni utente

  Pulire le pagine che non possono essere pulite dal processo regolare a causa di un errore di acquisizione del 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.

• Ridurre il footprint di memoria per lo strumento di rilevamento delle pagine PVS

  Questo miglioramento tiene traccia delle pagine PVS all'estensione di livello, per ridurre l'occupazione di memoria necessaria a mantenere le pagine versionate.

• miglioramenti al pulitore PVS

  PvS cleaner ha migliorato l'efficienza di pulizia delle versioni per migliorare il modo in cui il motore di database tiene traccia delle versioni delle righe e registra le versioni delle righe per le transazioni interrotte. Ciò comporta miglioramenti nell'utilizzo della memoria e dell'archiviazione.

• archivio versioni persistenti a livello di transazione (PVS)

  Questo miglioramento consente ad ADR di pulire le versioni che appartengono alle transazioni confermate, indipendentemente dalla presenza di transazioni interrotte nel sistema. Con questo miglioramento, le pagine PVS possono essere deallocate, anche se la pulizia non riesce a completare un sweep di successo per ridurre la mappa delle transazioni interrotte.

  Il risultato di questo miglioramento è una riduzione della crescita PVS anche se la pulizia PVS è 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 del motore di database.

  A partire da SQL Server 2022 (16.x), è supportata la pulizia della versione multithread. Ciò consente di pulire più database nella stessa istanza del motore di database in parallelo o di pulire più rapidamente un singolo database. Per ulteriori informazioni, consultare la configurazione del server : ADR Cleaner Thread Count.

  È stato aggiunto un nuovo evento esteso, tx_mtvc2_sweep_stats, per il monitoraggio del pulitore della versione multi-threaded di ADR PVS.

Contenuto correlato

• Gestire il ripristino accelerato del database
• Risoluzione dei problemi relativi al ripristino accelerato del database