Pool di buffer ibrido

Si applica a: SQL Server 2019 (15.x) e versioni successive

Il pool di buffer ibrido consente agli oggetti del pool di fare riferimento alle pagine dati nei file di database presenti nei dispositivi con memoria persistente, anziché a copie delle pagine dati nel disco fisso e nella memoria DRAM volatile. Questa funzionalità è stata introdotta in SQL Server 2019 (15.x) ed è stata ulteriormente migliorata in SQL Server 2022 (16.x).

I dispositivi con memoria persistente (PMEM) sono indirizzabili a byte e, se viene usato un file system con supporto per la memoria persistente (DAX) con accesso diretto (come XFS, EXT4 o NTFS), consentono di accedere ai file nel file system usando le consuete API di file system nel sistema operativo. In alternativa, possono eseguire operazioni di caricamento e archiviazione in base alle mappe di memoria dei file nel dispositivo. In questo modo, le applicazioni in grado di riconoscere i dispositivi con memoria persistente, come SQL Server, possono accedere ai file nel dispositivo senza attraversare lo stack di archiviazione tradizionale.

Il pool di buffer ibrido usa questa funzionalità per eseguire operazioni di caricamento e archiviazione sui file mappati alla memoria, in modo da usare il dispositivo PMEM come cache per il pool di buffer e per l'archiviazione dei file di database. Si verifica così la situazione unica in cui una lettura logica e una lettura fisica diventano essenzialmente la stessa operazione. I dispositivi con memoria persistente sono accessibili tramite il bus di memoria esattamente come la normale DRAM volatile.

Nella cache del dispositivo per il pool di buffer ibrido PMEM vengono memorizzate solo le pagine di dati clean. Affinché una pagina venga modificata e contrassegnata come non pulita, deve essere copiata dal dispositivo PMEM in un pool di buffer DRAM, modificata e infine una copia della pagina modificata viene scritta dal DRAM al modulo PMEM, a quel punto può essere contrassegnata nuovamente come pulita. Questo processo si verifica usando normali operazioni in background, ad esempio checkpoint o writer lazy, come se il modulo PMEM fosse un dispositivo a blocchi standard.

La funzionalità di pool di buffer ibrido è disponibile sia per Windows che per Linux. Il dispositivo PMEM deve essere formattato con un file system che supporti DAX (DirectAccess). I file system XFS, EXT4 e NTFS supportano tutte le estensioni DAX che consentono l'accesso al file system direttamente dallo spazio utente. SQL Server rileva automaticamente se i file di dati si trovano in un dispositivo PMEM configurato in modo appropriato ed eseguono il mapping della memoria per i file di database all'avvio, quando un nuovo database viene collegato, ripristinato o creato.

Per altre informazioni, vedi:

• Configurare la memoria persistente (PMEM) per SQL Server in Windows (SQL Server 2022 (16.x) e versioni successive.
• Configurare la memoria persistente per SQL Server in Linux.

Abilitare il pool di buffer ibrido

In SQL Server 2019 (15.x) è stato introdotto il linguaggio dei dati dinamici (DDL) per controllare il pool di buffer ibrido.

Nell'esempio seguente viene abilitato il pool di buffer ibrido per un'istanza di SQL Server:

ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED HYBRID_BUFFER_POOL = ON;

Per impostazione predefinita, il pool di buffer ibrido è disabilitato nell'ambito dell'istanza. È necessario riavviare l'istanza di SQL Server per rendere effettiva la modifica dell'impostazione. È necessario un riavvio per facilitare l'allocazione di pagine hash sufficienti tenendo conto della capacità PMEM totale nel server.

Nell'esempio seguente viene abilitato il pool di buffer ibrido per un database specifico.

ALTER DATABASE <databaseName> SET MEMORY_OPTIMIZED = ON;

Per impostazione predefinita, il pool di buffer ibrido è abilitato nell'ambito del database.

Disabilitare il pool di buffer ibrido

L'esempio seguente disabilita il pool di buffer ibrido a livello di istanza:

ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED HYBRID_BUFFER_POOL = OFF;

Per impostazione predefinita, il pool di buffer ibrido è disabilitato a livello di istanza. Affinché la modifica abbia effetto, l'istanza deve essere riavviata. Il riavvio consente di assicurarsi che per il pool di buffer venga allocato un numero sufficiente di pagine hash, poiché in questo caso è necessario tenere in considerazione la capacità della memoria persistente sul server.

Nell'esempio seguente viene disabilitato il pool di buffer ibrido per un database specifico.

ALTER DATABASE <databaseName> SET MEMORY_OPTIMIZED = OFF;

Per impostazione predefinita, il pool di buffer ibrido è abilitato nell'ambito del database e disabilitato nel server.

Visualizzare la configurazione pool di buffer ibrido

Mostrare il valore di runtime

L'esempio seguente restituisce lo stato corrente della configurazione del pool di buffer ibrido per l'istanza.

SELECT * FROM
sys.server_memory_optimized_hybrid_buffer_pool_configuration;

Nell'esempio seguente vengono elencati i database e l'impostazione del livello di database per il pool di buffer ibrido (is_memory_optimized_enabled).

È anche possibile montare o formattare il modulo PMEM senza DAX abilitato e considerarlo come un normale dispositivo a blocchi, ossia eseguire operazioni di I/O tramite il kernel. Se configurata in questo modo, non è possibile usare moduli PMEM da SQL Server per eseguire operazioni indirizzabili tramite byte e tutte le chiamate useranno driver di spazio kernel.

SELECT name, is_memory_optimized_enabled FROM sys.databases;

Pool di buffer ibrido con scrittura diretta

Il pool di buffer ibrido con comportamento di scrittura diretta riduce il numero di memcpy comandi che devono essere eseguiti nei dati modificati o nelle pagine di indice che risiedono nei dispositivi PMEM. Per farlo, utilizza il buffer di log permanente come mezzo per modificare la pagina senza doverlo copiare in uno dei pool di buffer DRAM. Le pagine nei file di database che risiedono nei dispositivi PMEM vengono, invece, modificate direttamente senza la necessità di memorizzare nella cache in un pool di buffer DRAM e successivamente scaricare su disco in modo asincrono. Questo comportamento è ancora conforme alla semantica di registrazione in anticipo (WAL), perché i record (log) nel buffer del log delle transazioni persistente vengono scritti o sottoposti a protezione avanzata in supporti durevoli. Sono stati osservati notevoli miglioramenti delle prestazioni per i carichi di lavoro transazionali usando il pool di buffer ibrido e il buffer di log persistente in questo modo.

Per abilitare la modalità di scrittura diretta, occorre abilitare il pool di buffer ibrido e il buffer di log persistente per un database e abilitare il flag di traccia 809.

Procedure consigliate per il pool di buffer ibrido

• Quando si formatta un dispositivo PMEM in Windows, usare le dimensioni di unità di allocazione più grandi disponibili per NTFS (2 MB in Windows Server 2019) e assicurarsi che il dispositivo sia stato formattato per DAX (Direct Access).

• Abilitare l'opzione Blocco di pagine in memoria (Windows).

• Le dimensioni dei file devono essere un multiplo di 2 MB (modulo 2 MB deve essere uguale a zero).

• Se l'impostazione con ambito server per il pool di buffer ibrido è disabilitata, la funzionalità non verrà usata da alcun database utente.

• Se l'impostazione con ambito server per il pool di buffer ibrido è abilitata, sarà possibile usare l'impostazione con ambito database per disabilitare la funzionalità per i singoli database utente.

• A partire da SQL Server 2019 (15.x) CU 3 (vedere KB4538118), la memorizzazione nella cache di lettura è abilitata per impostazione predefinita, con un processo in cui le pagine più calde vengono rilevate nel pool di buffer ibrido, quindi alzate automaticamente di livello a un pool di buffer DRAM per migliorare le prestazioni.

• A partire da SQL Server 2022 (16.x) CU 1, il comportamento Direct Write è quello predefinito quando il pool di buffer ibrido viene combinato con il buffer di log persistente. Questo dovrebbe migliorare le prestazioni per quasi tutti i carichi di lavoro, ma esiste sempre una possibilità di regressione e il CU deve essere testato accuratamente prima di essere applicato. Se si verifica una regressione a causa di questa modifica del comportamento, è possibile ripristinare il comportamento precedente usando il flag di traccia 898.

• A partire da SQL Server 2022 (16.x) CU 1, il flag di traccia 809 verrà ignorato da SQL Server all'avvio. Sia il flag di traccia 809 che il flag di traccia 898 si applicano solo a Windows e non si applicano a SQL Server in Linux. I flag di traccia devono essere usati solo se indirizzati a tale scopo da un professionista di Microsoft Server certificato.