Ripristino e recupero di tabelle ottimizzate per la memoriaRestore and recovery of memory-optimized tables

QUESTO ARGOMENTO SI APPLICA A: SìSQL ServernonDatabase SQL di AzurenonAzure SQL Data Warehouse non Parallel Data WarehouseTHIS TOPIC APPLIES TO: yesSQL ServernoAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

Il meccanismo di base per recuperare o ripristinare un database che usa tabelle ottimizzate per la memoria è simile a quello per un database che usa solo tabelle basate su disco.The basic mechanism to recover or restore a database that uses memory-optimized tables is similar to the mechanism for a database that uses only disk-based tables. Ma a differenza delle tabelle basate su disco, per rendere disponibile il database per l'accesso dell'utente, le tabelle ottimizzate per la memoria devono essere prima caricate in memoria.But unlike disk-based tables, memory-optimized tables must be loaded into memory before the database is available for user access. Questo requisito aggiunge un nuovo passaggio nel processo di recupero del database.This requirement adds a new step in the database recovery.

Se la memoria disponibile nel server non è sufficiente, il recupero del database ha esito negativo e il database viene contrassegnato come sospetto.If the server does not have enough available memory, database recovery fails and the database is marked as suspect. Per risolvere questo problema, vedere Risolvere i problemi di memoria insufficiente.To resolve this problem, see Resolve out-of-memory issues.

Fattori che influiscono sul tempo di caricamentoFactors that affect load time

Durante le operazioni di recupero o ripristino, il motore di OLTP in memoria legge i file di dati e differenziali per il caricamento nella memoria fisica.During recovery or restore operations, the In-Memory OLTP engine reads data and delta files for loading into physical memory. Il tempo di caricamento viene determinato dai seguenti fattori:The load time is determined by:

  • Quantità di dati da caricare.The amount of data to load.

  • Larghezza di banda per operazioni di I/O sequenziali.Sequential I/O bandwidth.

  • Grado di parallelismo, determinato dal numero di contenitori di file e core del processore.The degree of parallelism, determined by the number of file containers and processor cores.

  • Numero di record di log nella parte attiva del log di cui è necessario eseguire il rollforward.The number of log records in the active portion of the log that need to be redone.

Fasi di recuperoPhases of recovery

Al riavvio di SQL ServerSQL Server, ogni database viene sottoposto a un processo di recupero costituito da tre fasi:When SQL ServerSQL Server restarts, each database goes through a recovery process that consists of three phases:

  1. Analisi.Analysis. In questa fase viene eseguito un passaggio nei log delle transazioni attivi per rilevare le transazioni di cui è stato eseguito il commit e di cui non è stato eseguito il commit.In this phase, a pass is made on the active transaction logs to detect committed and uncommitted transactions. Il motore OLTP in memoria identifica il checkpoint per caricare e precaricare le voci di log della tabella di sistema.The In-Memory OLTP engine identifies the checkpoint to load and preloads its system table log entries. Elabora inoltre alcuni record di log delle allocazioni di file.It also processes some file allocation log records.

  2. Rollforward.Redo. Questa fase viene eseguita contemporaneamente sia nelle tabelle basate su disco sia in quelle ottimizzate per la memoria.This phase is run concurrently on both disk-based and memory-optimized tables.

    • Per le tabelle basate su disco, il database viene spostato al momento corrente e acquisisce i blocchi utilizzati dalle transazioni di cui non è stato eseguito il commit.For disk-based tables, the database is moved to the current point in time and acquires locks taken by uncommitted transactions.

    • Per le tabelle ottimizzate per la memoria, i dati delle coppie di file di dati e differenziali vengono caricati in memoria.For memory-optimized tables, data from the data and delta file pairs are loaded into memory. I dati vengono quindi aggiornati con il log delle transazioni attivo in base all'ultimo checkpoint durevole.Data is then updated with the active transaction log based on the last durable checkpoint.

    Al termine delle operazioni appena descritte sulle tabelle basate su disco e su quelle ottimizzate per la memoria, il database è disponibile per l'accesso.When the preceding operations on disk-based and memory-optimized tables are complete, the database is available for access.

  3. Rollback.Undo. In questa fase, viene effettuato il rollback delle transazioni di cui non è stato eseguito il commit.In this phase, the uncommitted transactions are rolled back.

Processo per migliorare il tempo di caricamentoProcess for improving load time

Il caricamento delle tabelle ottimizzate per la memoria può influire sul tempo necessario per il pieno recupero dell'operatività (RTO, Recovery Time Objective).Loading memory-optimized tables into memory can affect performance of the recovery time objective (RTO). Per migliorare il tempo di caricamento dei dati ottimizzati per la memoria dai file di dati e differenziali, il motore OLTP in memoria carica i file di dati e differenziali in parallelo nel modo seguente:To improve the load time of memory-optimized data from data and delta files, the In-Memory OLTP engine loads the data/delta files in parallel as follows:

  • Creazione di un filtro mappa differenziale.Creating a delta map filter. I file differenziali archiviano i riferimenti alle righe eliminate.Delta files store references to the deleted rows. Un thread per contenitore legge i file differenziali e crea un filtro mappa differenziale.One thread per container reads the delta files and creates a delta map filter. In un filegroup di dati ottimizzato per la memoria possono essere presenti più contenitori.(A memory-optimized data file group can have one or more containers.)

  • Flusso dei file di dati.Streaming the data files. Dopo la creazione del filtro mappa differenziale, i file di dati vengono letti da un numero di thread equivalente al numero di CPU logiche.After the delta map filter is created, data files are read by as many threads as there are logical CPUs. Ogni thread legge le righe di dati, controlla la mappa differenziale associata e inserisce una riga nella tabella solo se la riga non è stata contrassegnata come eliminata.Each thread reads the data rows, checks the associated delta map, and inserts a row into the table only if the row has not been marked deleted. In alcuni casi questa parte del recupero può essere basata sulla CPU, come illustrato in questo diagramma:This part of recovery can be CPU bound in some cases, as noted in this diagram:

    Flusso dei dati alle tabelle ottimizzate per la memoriaData streaming to memory-optimized tables

Casi specifici di tempi di caricamento lentiSpecific cases of slow load times

Le tabelle ottimizzate per la memoria possono in genere essere caricate in memoria alla velocità di I/O, ma il caricamento delle righe di dati in memoria è talvolta più lento.Memory-optimized tables can generally be loaded into memory at the speed of I/O, but loading data rows into memory is sometimes slower. Alcuni casi specifici sono i seguenti:Specific cases are:

  • Un numero di bucket ridotto per un indice hash può determinare una collisione eccessiva rallentando gli inserimenti delle righe di dati.Low bucket count for a hash index can lead to excessive collision, which causes data row inserts to be slower. Ciò comporta in genere un uso elevato della CPU per l'intero processo, in particolare verso la fine del recupero.This generally results in high CPU utilization throughout, and especially toward the end of recovery. Se l'indice hash è stato configurato correttamente, non dovrebbe influire sul tempo di recupero.If you configured the hash index correctly, it should not affect the recovery time.

  • Tabelle ottimizzate per la memoria di grandi dimensioni con uno o più indici non cluster possono determinare un uso elevato della CPU.Large memory-optimized tables with one or more nonclustered indexes can cause high CPU utilization. A differenza di un indice hash, il cui numero di bucket viene stabilito al momento della creazione, le dimensioni degli indici non cluster aumentano in modo dinamico.Unlike a hash index whose bucket count is sized at create time, nonclustered indexes grow dynamically.

Vedere ancheSee also

Eseguire il backup, ripristinare e recuperare tabelle con ottimizzazione per la memoriaBackup, Restore, and Recovery of Memory-Optimized Tables