Ripristinare e recuperare tabelle con ottimizzazione per la memoriaRestore and Recovery of Memory-Optimized Tables

In 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 con tabelle ottimizzate per la memoria è simile a quello per i database che hanno solo tabelle basate su disco.The basic mechanism to recover or restore a database with memory-optimized tables is similar to databases with only disk-based tables. A differenza delle tabelle basate su disco, le tabelle ottimizzate per la memoria devono essere caricate in memoria prima di rendere disponibile il database per l'accesso utente.But unlike disk-based tables, memory-optimized tables must be loaded into memory before database is available for user access. Si tratta di un nuovo passaggio nel processo di recupero del database.This adds a new step in the database recovery.

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 file contenitori e di core del processore.Degree of parallelism, determined by number of file containers and processor cores.

  • Quantità di record di log nella parte attiva del log che devono essere ripetuti.The amount of log records in the active portion of the log that need to be redone.

    Al riavvio di SQL ServerSQL Server , ogni database attraversa una fase di recupero suddivisa in tre parti:When the SQL ServerSQL Server restarts, each database goes through a recovery phase that consists of the following three phases:

  1. Fase di analisi.The analysis phase. Durante 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.During 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 will also process some file allocation log records.

  2. Fase di rollforward.The redo phase. 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 dalle coppie di file di dati e differenziali vengono caricati in memoria e aggiornati con il log delle transazioni attivo basato sull'ultimo checkpoint durevole.For memory-optimized tables, data from the data and delta file pairs are loaded into memory and then update the data with the active transaction log based on the last durable checkpoint.

    Quando vengono completate le operazioni riportate sopra per le tabelle basate su disco e le tabelle ottimizzate per la memoria, il database è disponibile per l'accesso.When the above operations on disk-based and memory-optimized tables are complete, the database is available for access.

  3. Fase di rollback.The undo phase. 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.

    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 con ottimizzazione per la memoria possono essere presenti più contenitori.(A memory optimized data filegroup can have one or more containers.)

  • Flusso dei file di dati.Streaming the data files. Alla creazione del filtro mappa differenziale, i file di dati vengono letti utilizzando un numero di thread equivalente al numero di CPU logiche.Once the delta-map filter is created, data files are read using as many threads as there are logical CPUs. Ogni thread che legge il file di dati legge le righe di dati, controlla la mappa differenziale associata e inserisce la riga nella tabella solo se tale riga non è stata contrassegnata come eliminata.Each thread reading the data file reads the data rows, checks the associated delta map and only inserts the row into table if this row has not been marked deleted. Questa parte del recupero può essere associata alla CPU in alcuni casi riportati di seguito.This part of recovery can be CPU bound in some cases as noted below.

    Tabelle con ottimizzazione per la memoria.Memory-optimized tables.

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

  • Un numero di bucket basso per l'indice hash può portare a conflitti eccessivi rallentando gli inserimenti delle righe di dati.Low bucket count for hash index can lead to excessive collision causing data row inserts to be slower. Ciò comporta in genere un utilizzo elevato della CPU per l'intero processo, in particolare verso la fine del recupero.This generally results in very high CPU utilization throughout, and especially towards 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 impact the recovery time.

  • L'utilizzo della CPU può risultare elevato per le tabelle ottimizzate per la memoria di grandi dimensioni con uno o più indici non cluster in quanto, a differenza di un indice hash in cui il numero di bucket è stabilito al momento della creazione, gli indici non cluster aumentano in modo dinamico.Large memory-optimized tables with one or more nonclustered indexes, unlike a hash index whose bucket count is sized at create time, the nonclustered indexes grow dynamically, resulting in high CPU utilization.

Vedere ancheSee Also

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