Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a:
SQL Server
OLTP in memoria fornisce durabilità completa per le tabelle ottimizzate per la memoria. Quando una transazione che ha modificato una tabella ottimizzata per la memoria viene completata, SQL Server, come fa per le tabelle su disco, garantisce che le modifiche siano permanenti (sopravvivono a un riavvio del database), purché il supporto di memorizzazione sottostante sia disponibile. I componenti chiave della durabilità sono due: registrazione delle transazioni e salvataggio in modo permanente delle modifiche ai dati nell'archiviazione su disco.
Per informazioni dettagliate sulle limitazioni delle dimensioni per le tabelle durevoli, vedere Stimare i requisiti di memoria per le tabelle Memory-Optimized.
Log delle transazioni
Tutte le modifiche apportate alle tabelle basate su disco o alle tabelle ottimizzate per la memoria durevoli vengono acquisite in uno o più record di log delle transazioni. In corrispondenza del commit di una transazione, tramite SQL Server vengono scritti sul disco i record di log associati alla transazione prima di comunicare all'applicazione o alla sessione utente che è stato eseguito il commit della transazione. In questo modo viene garantita la durabilità delle modifiche apportate dalla transazione. Il log delle transazioni per le tabelle ottimizzate per la memoria è completamente integrato con lo stesso flusso del log utilizzato dalle tabelle basate su disco. Questa integrazione consente il backup, il ripristino e il ripristino del log delle transazioni esistenti per continuare a funzionare senza richiedere passaggi aggiuntivi. Tuttavia, poiché In-Memory OLTP può aumentare significativamente la velocità effettiva delle transazioni del carico di lavoro, l'I/O del log potrebbe diventare un collo di bottiglia delle prestazioni. Per sostenere questa maggiore velocità effettiva, verificare che il sottosistema delle operazioni di I/O sui log sia in grado di gestire l'aumento del carico.
File di dati e file delta
I dati nelle tabelle ottimizzate per la memoria vengono archiviati come righe di dati in formato libero in una struttura di dati di heap in memoria e collegati tramite uno o più indici in memoria. Non esistono strutture per le righe di dati, quali quelle utilizzate per le tabelle basate su disco. Per la persistenza a lungo termine e per consentire il troncamento del log delle transazioni, le operazioni sulle tabelle ottimizzate per la memoria sono persistenti in un set di file di dati e differenziali. Questi file vengono generati in base al log delle transazioni, tramite un processo in background asincrono. I file di dati e differenziali si trovano in uno o più contenitori, che utilizzano lo stesso meccanismo utilizzato per i dati FILESTREAM. Questi contenitori fanno parte di un filegroup ottimizzato per la memoria.
I dati vengono scritti in tali file in un modo strettamente sequenziale riducendo la latenza del disco per la rotazione dei supporti. È possibile utilizzare più contenitori in dischi diversi per distribuire l'attività di I/O. I file di dati e differenziali in più contenitori su dischi diversi aumentano le prestazioni di ripristino/recupero del database quando i dati vengono letti in memoria dai file di dati e differenziali su disco.
Le transazioni degli utenti non accedono direttamente ai file di dati e differenziali. Tutte le letture e scritture di dati usano strutture di dati in memoria.
File di dati
Un file di dati contiene righe di una o più tabelle ottimizzate per la memoria inserite da più transazioni come parte di operazioni INSERT o UPDATE. Ad esempio, una riga può provenire dalla tabella ottimizzata per la memoria T1 e la riga successiva può provenire dalla tabella ottimizzata per la memoria T2. Le righe vengono accodate al file di dati nell'ordine delle transazioni nel log delle transazioni, in modo da rendere sequenziale l'accesso ai dati. Ciò consente una velocità effettiva delle operazioni di I/O decisamente maggiore rispetto alle operazioni di I/O casuali.
Quando il file di dati è pieno, le righe inserite dalle nuove transazioni vengono archiviate in un altro file di dati. Nel corso del tempo, le righe delle tabelle durevoli ottimizzate per la memoria vengono archiviate in uno o più file di dati e ogni file di dati contiene righe che formano intervalli di transazioni disgiunti ma contigui. Ad esempio un file di dati con un timestamp di commit della transazione nell'intervallo (100, 200) include tutte le righe inserite dalle transazioni con un timestamp di commit maggiore di 100 e minore di o uguale a 200. Il timestamp di commit è un numero che aumenta in modo monotonico assegnato a una transazione quando è pronto per il commit. Ogni transazione ha un timestamp di commit univoco.
Quando una riga viene eliminata o aggiornata, la riga non viene rimossa o modificata sul posto nel file di dati, ma le righe eliminate vengono rilevate in un altro tipo di file: il file differenziale. Le operazioni di aggiornamento sono elaborate come una tupla di operazioni di eliminazione e inserimento per ogni riga. Ciò consente di eliminare le operazioni di I/O casuali nel file di dati.
Dimensioni: ogni file di dati viene ridimensionato approssimativamente a 128 MB per i computer con memoria superiore a 16 GB e a 16 MB per i computer con memoria minore o uguale a 16 GB. In SQL Server 2016 (13.x), SQL Server può usare la modalità di checkpoint di grandi dimensioni se ritiene che il sottosistema di archiviazione sia sufficientemente veloce. In modalità di checkpoint di grandi dimensioni, i file di dati vengono ridimensionati a 1GB. In questo modo è possibile migliorare l'efficienza del sottosistema di archiviazione per i carichi di lavoro con velocità effettiva elevata.
File differenziale
Ogni file di dati è associato a un file differenziale con lo stesso intervallo di transazione che tiene traccia delle righe eliminate inserite dalle transazioni nell'intervallo di transazione. Questo file di dati e differenziali viene definito coppia di file di checkpoint (CFP) ed è l'unità di allocazione e deallocazione, nonché l'unità per le operazioni di merge. Ad esempio, un file delta corrispondente all'intervallo di transazioni (100, 200) archivia le righe eliminate inserite dalle transazioni nell'intervallo (100, 200). Come per i file di dati, l'accesso al file differenziale avviene in ordine sequenziale.
Quando una riga viene eliminata, la riga non viene rimossa dal file di dati, ma viene aggiunto un riferimento alla riga al file differenziale associato all'intervallo di transazioni in cui è stata inserita la riga di dati. Poiché la riga da eliminare esiste già nel file di dati, nel file differenziale sono archiviate solo le informazioni di riferimento {inserting_tx_id, row_id, deleting_tx_id} seguendo l'ordine del log delle transazioni delle operazioni originali di eliminazione o aggiornamento.
Dimensioni: ogni file differenziale viene ridimensionato approssimativamente a 16 MB per i computer con memoria superiore a 16 GB e a 1 MB per i computer con memoria minore o uguale a 16 GB. All'avvio di SQL Server 2016 (13.x), SQL Server può usare la modalità di checkpoint di grandi dimensioni se ritiene che il sottosistema di archiviazione sia sufficientemente veloce. In modalità di checkpoint di grandi dimensioni, i file differenziali vengono ridimensionati a 128MB.
Popolare i file di dati e di delta
I file di dati e differenziali vengono popolati in base ai record del log delle transazioni generati dalle transazioni di cui è stato eseguito il commit nelle tabelle ottimizzate per la memoria e aggiungono le informazioni relative alle righe inserite o eliminate nei file di dati e differenziali appropriati. A differenza delle tabelle basate su disco in cui le pagine di dati e indice vengono scaricate con I/O casuale al completamento del checkpoint, la persistenza della tabella ottimizzata per la memoria è un'operazione in background continua. Si accede a più file differenziali poiché una transazione può eliminare o aggiornare qualsiasi riga inserita da una transazione precedente. Le informazioni di eliminazione vengono sempre aggiunte alla fine del file differenziale. Ad esempio, una transazione con un timestamp di commit pari a 600 inserisce una nuova riga ed elimina le righe inserite dalle transazioni con un timestamp di commit pari a 150, 250 e 450, come illustrato nell'immagine seguente. Tutte e quattro le operazioni di I/O dei file (tre per le righe eliminate e una per le righe appena inserite), sono operazioni in sola aggiunta ai file delta e dati corrispondenti.
Accedere ai file di dati e ai file delta
Quando si verificano i seguenti eventi, si accede a coppie di file dati e delta.
Lavoratori del checkpoint offline
Il thread accoda inserimenti ed eliminazioni effettuati nelle righe di dati ottimizzati per la memoria alle coppie di file di dati e differenziali corrispondenti. SQL Server 2014 (12.x) dispone di un lavoratore del checkpoint offline. SQL Server 2016 (13.x) e versioni successive hanno più ruoli di lavoro del checkpoint.
Operazione Merge
L'operazione unisce una o più coppie di file di dati e differenziali e crea una nuova coppia.
Durante il recupero a seguito dell'arresto anomalo del sistema
Quando SQL Server viene riavviato o il database viene riportato online, i dati ottimizzati per la memoria vengono popolati utilizzando le coppie di file di dati e differenziali. Il file differenziale svolge la funzione di filtro per le righe eliminate durante la lettura delle righe dal file di dati corrispondente. Poiché ogni coppia di file di dati e differenziale è indipendente, questi file vengono caricati in parallelo per ridurre il tempo necessario per popolare i dati in memoria. Dopo aver caricato i dati in memoria, il motore OLTP In-Memory applica i record del log delle transazioni attivi non ancora coperti dai file di checkpoint in modo che i dati ottimizzati per la memoria siano completati.
Durante l'operazione di ripristino
I file di checkpoint di OLTP in memoria vengono creati dal backup del database, quindi vengono applicati uno o più backup del log delle transazioni. Come per il ripristino da arresto anomalo, il motore OLTP In-Memory carica i dati in memoria in parallelo per minimizzare l'impatto sul tempo di recupero.
Unire file di dati e file differenziali
I dati per le tabelle con ottimizzazione per la memoria vengono archiviati in uno o più coppie di file di dati e differenziali, anche dette coppie di file di checkpoint o CFP. I file di dati archiviano le righe inserite e i file differenziali fanno riferimento alle righe eliminate. Durante l'esecuzione di un carico di lavoro OLTP, mentre le righe vengono aggiornate, inserite ed eliminate dalle operazioni DML, vengono create nuove coppie di file di checkpoint per rendere persistenti le nuove righe e il riferimento alle righe eliminate viene aggiunto ai file differenziali.
Nel corso del tempo, con le operazioni DML, il numero di file di dati e differenziali aumenta, causando un aumento dell'utilizzo dello spazio su disco e un aumento del tempo di recupero.
Per evitare queste inefficienze, i file di dati chiusi e differenziali meno recenti vengono uniti, in base a un criterio di unione descritto più avanti in questo articolo, quindi la matrice di archiviazione viene compattata per rappresentare lo stesso set di dati, con un numero ridotto di file.
L'operazione di unione accetta come input una o più coppie di file di checkpoint chiusi adiacenti, che sono coppie di file di dati e differenziali (denominata fonte di unione) in base a un criterio di unione definito internamente e produce una CFP risultante, denominata obiettivo di unione. Le voci in ciascun file delta dei CFP di origine vengono utilizzate per filtrare le righe dal file di dati corrispondente al fine di rimuovere le righe di dati che non sono necessarie. Le righe rimanenti nelle coppie di file di checkpoint di origine vengono consolidate in una coppia di file di checkpoint di destinazione. Dopo che la fusione è stata completata, il CFP risultante della fusione sostituisce i CFP di origine (fonti della fusione). I CFP di origine dell'unione attraversano una fase di transizione prima di essere rimossi dall'archiviazione.
Nell'esempio seguente il gruppo di file di tabella ottimizzato per la memoria ha quattro coppie di file di dati e differenziali al timestamp 500 contenente i dati delle transazioni precedenti. Ad esempio, le righe del primo file di dati corrispondono alle transazioni con timestamp maggiore di 100 e minore di o uguale a 200; in alternativa sono rappresentate come (100, 200]. La percentuale di completamento del secondo e terzo file di dati è inferiore al 50% dopo aver considerato le righe contrassegnate come eliminate. L'operazione di unione combina le due coppie di file di checkpoint e crea una nuova coppia di file di checkpoint contenente le transazioni con timestamp maggiore di 200 e minore o uguale a 400, ovvero l'intervallo combinato di queste due coppie di file di checkpoint. È presente un'altra coppia di file di checkpoint con intervallo (500, 600] e il file differenziale non vuoto per l'intervallo della transazione (200, 400] indica che l'operazione di unione può essere eseguita contemporaneamente all'attività transazionale, inclusa l'eliminazione di più righe dalle coppie di file di checkpoint di origine.
Un thread in background valuta tutte le coppie di file di checkpoint chiuse utilizzando un criterio di unione, quindi avvia una o più richieste di unione per le coppie di file di checkpoint qualificate. Queste richieste di unione vengono elaborate dal thread del checkpoint offline. La valutazione dei criteri di unione viene eseguita periodicamente, anche quando un checkpoint viene chiuso.
Criteri di unione di SQL Server
SQL Server implementa i criteri di unione seguenti:
Viene pianificata un'unione se è possibile consolidare due o più cfp consecutivi, tenendo conto delle righe eliminate, in modo che le righe risultanti possano rientrare in una CFP di dimensioni di destinazione. Le dimensioni di destinazione dei file di dati e file delta corrispondono al dimensionamento originale, come descritto in precedenza.
Un singola coppia di file di checkpoint può essere unita automaticamente se il file di dati è due volte più grande delle dimensioni di destinazione ed è maggiore della metà delle righe eliminate. Un file di dati può aumentare di dimensioni superiori a quelle di destinazione se, ad esempio, una singola transazione o più transazioni simultanee inseriscono o aggiornano una grande quantità di dati. Questo costringe il file di dati a crescere oltre le dimensioni di destinazione, perché una transazione non può estendersi su più CFP.
Di seguito sono riportati alcuni esempi che mostrano i CFPs da unire secondo la politica di unione.
| File di origine CFP adiacenti (% pieno) | Unisci selezione |
|---|---|
| CFP0 (30%), CFP1 (50%), CFP2 (50%), CFP3 (90%) | (CFP0, CFP1) CFP2 non viene scelto perché rende il file di dati risultante maggiore di 100% delle dimensioni ideali. |
| CFP0 (30%), CFP1 (20%), CFP2 (50%), CFP3 (10%) | (CFP0, CFP1, CFP2). I file vengono scelti a partire da sinistra. CFP3 non viene scelto perché rende il file di dati risultante maggiore di 100% delle dimensioni ideali. |
| CFP0 (80%), CFP1 (30%), CFP2 (10%), CFP3 (40%) | (CFP1, CFP2, CFP3). I file vengono scelti a partire da sinistra. CFP0 viene ignorato perché, se combinato con CFP1, il file di dati risultante è maggiore di 100% delle dimensioni ideali. |
Non tutte le coppie di file di checkpoint con spazio disponibile sono qualificate per l'unione. Ad esempio, se due CFP adiacenti sono al 60% completi, non si qualificano per la fusione e ciascuno di questi CFP ha il 40% dello spazio di archiviazione non utilizzato. Nel peggiore dei casi, tutti i CFP sono pieni al 50%, con un utilizzo dello spazio di archiviazione del solo 50%. Anche se le righe eliminate potrebbero esistere nello storage perché i CFP non sono idonei per l'unione, le righe eliminate potrebbero essere già state rimosse dalla memoria dal processo di garbage collection in memoria. La gestione dello spazio di archiviazione e della memoria è indipendente da Garbage Collection. L'archiviazione utilizzata dai CFP attivi (non tutti i CFP vengono aggiornati) può essere fino a due volte superiore rispetto alle dimensioni delle tabelle durevoli in memoria.
Ciclo di vita di una CFP
Le coppie di file di checkpoint attraversano diversi stati prima di poter essere deallocate. I checkpoint del database e i backup del log devono essere eseguiti per la transizione dei file attraverso le fasi e infine per pulire i file che non sono più necessari. Per una descrizione di queste fasi, vedere sys.dm_db_xtp_checkpoint_files.
È possibile forzare manualmente il checkpoint seguito dal backup del log per velocizzare l'operazione di garbage collection. Negli scenari di produzione, i checkpoint automatici e i backup del log eseguiti nell'ambito della strategia di backup facilitano il passaggio dei CFP attraverso queste fasi senza richiedere alcun intervento manuale. L'effetto del processo di Garbage Collection è che i database con tabelle ottimizzate per la memoria potrebbero avere dimensioni di archiviazione maggiori rispetto alla loro dimensione in memoria. Se i backup dei checkpoint e del log non vengono eseguiti, lo spazio occupato su disco dai file di checkpoint continua a crescere.