Ripristino accelerato del database in Azure SQL

Si applica a: database SQL di Azure Istanza gestita di SQL di Azure database SQL in Fabric

Il ripristino accelerato del database è una funzionalità del motore di database SQL Server che migliora notevolmente la disponibilità dei database, specialmente in presenza di transazioni a esecuzione prolungata, grazie alla riprogettazione del processo di ripristino del motore di database SQL Server.

AdR è attualmente disponibile per database SQL di Azure, Istanza gestita di SQL di Azure, database in Azure Synapse Analytics, database SQL dell'infrastruttura e SQL Server in macchine virtuali di Azure a partire da SQL Server 2019. Per informazioni sul ripristino accelerato del database in SQL Server, consultare Gestire il ripristino accelerato del database.

Nota

In database SQL di Azure, i database SQL dell'infrastruttura e Istanza gestita di SQL di Azure, il ripristino accelerato del database (ADR) è abilitato per impostazione predefinita e la disabilitazione di ADR non è supportata.

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 standard

Il ripristino del database segue il modello di ripristino ARIES e prevede tre fasi, illustrate e descritte in modo più dettagliato nel diagramma seguente.

• Fase di analisi

  Analisi del log delle transazioni dall’inizio dell’ultimo checkpoint valido (o LSN della pagina dirty meno recente) fino alla fine, per stabilire lo stato di ogni transazione al momento dell’arresto del database.

• Fase di rollforward

  Analisi del log delle transazioni dalla transazione meno recente non sottoposta a commit fino alla fine, per ripristinare lo stato del database al momento dell’arresto anomalo rieseguendo tutte le operazioni sottoposte a commit.

• Fase di rollback

  Per ogni transazione attiva al momento dell’arresto anomalo, ripercorre il log all’indietro, annullando le operazioni eseguite dalla transazione.

In base a questa progettazione, il tempo necessario per il ripristino del motore di database SQL Server da un riavvio imprevisto è pressoché proporzionale alla dimensione della transazioni attiva più lunga presente 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 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.

In base a questa progettazione, anche l’annullamento o il rollback di una transazione di grandi dimensioni può richiedere molto tempo, poiché viene usata la stessa fase di rollback descritta sopra.

Inoltre, il motore di database SQL Server 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. A causa di questa progettazione del motore di database SQL Server, alcuni clienti si trovano con log delle transazioni di grandi dimensioni che occupano una grande quantità di spazio su disco.

Processo di ripristino accelerato del database

Il ripristino accelerato del database risolve i problemi descritti sopra riprogettando completamente il processo di ripristino del motore di database SQL Server con gli scopi seguenti:

• 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; pertanto, 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 delle tre fasi del ripristino accelerato del database è illustrato nella figura seguente e descritto nel dettaglio di seguito.

• Fase di analisi

  Il processo è identico a quello precedente, con l’aggiunta della ricostruzione di SLOG e della copia dei record di log per le operazioni senza controllo delle versioni.

• Fase di rollforward

  Suddivisa in due fasi (P)

  • Fase 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 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.

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 (PVS) è un nuovo meccanismo del motore di database SQL per il mantenimento delle versioni di riga generate nel database anziché nell’archivio versioni tempdb tradizionale. Il PVS abilita l’isolamento delle risorse e migliora la disponibilità delle repliche secondarie 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. Il ripristino logico viene eseguito nei modi seguenti:

  • Tenendo traccia di tutte le transazioni interrotte e contrassegnandole come invisibili ad altre transazioni.
  • Eseguendo il rollback con il PVS per tutte le transazioni utente, anziché analizzando fisicamente il log delle transazioni e annullando le modifiche una alla volta.
  • Rilasciando tutti i blocchi immediatamente dopo l’interruzione della transazione. Poiché l’interruzione implica semplicemente il contrassegno delle modifiche nella memoria, il processo è molto efficiente e quindi i blocchi non devono essere mantenuti a lungo.

• 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.

Modelli di ripristino accelerato del database

I tipi di carichi di lavoro seguenti traggono più vantaggio dal ripristino accelerato del database:

• Carichi di lavoro con transazioni a esecuzione prolungata.
• Carichi di lavoro in cui sono stati riscontrati casi in cui le transazioni attive causano un aumento significativo delle dimensioni del log delle transazioni.
• Carichi di lavoro in cui sono stati registrati lunghi periodi di indisponibilità del database a causa di un ripristino a esecuzione prolungata di SQL Server, ad esempio in caso di riavvio imprevisto di SQL Server o rollback di transazione manuale.

Procedure consigliate per il ripristino accelerato del database

• Evitare transazioni a esecuzione prolungata nel database. Anche se un obiettivo del ripristino accelerato del database è velocizzare il ripristino del database rallentato da transazioni attive troppo lunghe, le transazioni a esecuzione prolungata possono ritardare la pulizia della versione e aumentare le dimensioni del PVS.

• Evitare transazioni di grandi dimensioni con modifiche alla definizione dei dati o operazioni DDL. Il ripristino accelerato del database usa un meccanismo SLOG (flusso di log di sistema) per tenere traccia delle operazioni DDL usate nel ripristino. Il flusso SLOG viene utilizzato solo quando la transazione è attiva. Poiché viene sottoposto a checkpoint, è possibile evitare transazioni di grandi dimensioni che usano SLOG per migliorare le prestazioni complessive. Gli scenari seguenti possono causare l’uso di più spazio da parte di SLOG:

  • In un’unica transazione vengono eseguiti molti DDLS. Ad esempio, la creazione rapida e l’eliminazione di tabelle temporanee in un’unica transazione.

  • Una tabella ha un numero molto elevato di partizioni o indici modificati. Ad esempio, un’operazione DROP TABLE in tale tabella richiederebbe una grande prenotazione di memoria SLOG, che ritarderebbe il troncamento del log delle transazioni e le operazioni di annullamento/rollforward. Come soluzione alternativa, eliminare gli indici singolarmente e gradualmente, quindi eliminare la tabella. Per altre informazioni su SLOG, consultare Componenti del ripristino accelerato del database.

• Evitare o ridurre interruzioni non necessarie. Una velocità di interruzione elevata metterà pressione sul pulitore del PVS e ridurrà le prestazioni del ripristino accelerato del database. Le interruzioni possono provenire da una frequenza elevata di deadlock, chiavi duplicate o altre violazioni dei vincoli.

  • La DMV sys.dm_tran_aborted_transactions mostra tutte le transazioni interrotte nell’istanza di SQL Server. La colonna nested_abort indica che la transazione è stata sottoposta a commit, ma sono presenti parti interrotte (punti di salvataggio o transazioni nidificate) che possono bloccare il processo di pulizia del PVS. Per altre informazioni, consultare sys.dm_tran_aborted_transactions (Transact-SQL).

  • Per attivare manualmente il processo di pulizia del PVS tra carichi di lavoro o durante le finestre di manutenzione, usare sys.sp_persistent_version_cleanup. Per altre informazioni, consultare sys.sp_persistent_version_cleanup.

• Se si osservano problemi con l’utilizzo dell’archiviazione, la transazione di interruzione elevata e altri fattori, vedere Risoluzione dei problemi relativi al ripristino accelerato del database in SQL Server.

Passaggi successivi

• Ripristino accelerato del database
• Risoluzione dei problemi relativi al ripristino accelerato del database in SQL Server.