Hybrider Pufferpool

Gilt für: SQL Server 2019 (15.x) und höhere Versionen

In einem Hybridpufferpool können Pufferpoolobjekte auf Datenseiten in Datenbankdateien verweisen, die sich auf Geräten mit persistentem Arbeitsspeicher (Persistent Memory, PMEM) befinden, anstatt Kopien der Datenseiten von einem Datenträger abzurufen und im flüchtigen DRAM zwischenzuspeichern. Dieses Feature wurde in SQL Server 2019 (15.x) eingeführt und in SQL Server 2022 (16.x) weiter verbessert.

Persistente Speichergeräte sind byteadressierbar. Wenn ein PMEM-fähiges Dateisystem mit Direktzugriff (Direct Access, DAX) (z. B. XFS, EXT4 oder NTFS) verwendet wird, kann mithilfe der üblichen Dateisystem-APIs des Betriebssystems auf die Dateien im Dateisystem zugegriffen werden. Alternativ kann SQL Server sogenannte Lade- und Speichervorgänge für die Speicherzuordnungen der Dateien auf dem PMEM-Gerät ausführen. Dies ermöglicht den PMEM-fähigen Anwendungen wie SQL Server, auf Dateien auf dem Gerät zuzugreifen, ohne den herkömmlichen Speicherstapel durchlaufen zu müssen.

Der Hybridpufferpool nutzt die Möglichkeit, Lade- und Speichervorgänge für im Arbeitsspeicher abgebildete Dateien auszuführen und das PMEM-Gerät sowohl als Cache für den Pufferpool als auch als Speicherort für die Datenbankdateien zu verwenden. Dadurch ergibt sich die außergewöhnliche Situation, dass logische und physische Lesevorgänge im Grunde genommen dasselbe sind. Persistente Speichergeräte können über den Speicherbus aufgerufen werden, genauso wie reguläres flüchtiges DRAM.

Standardmäßig werden nur bereinigte Datenseiten auf dem PMEM-Modul für den hybriden Pufferpool zwischengespeichert. Damit eine Seite geändert und als modifiziert gekennzeichnet wird, muss sie vom PMEM-Gerät in einen DRAM-Pufferpool kopiert und geändert werden. Zuletzt wird eine Kopie der geänderten Seite von DRAM zurück in das PMEM-Modul geschrieben. Zu diesem Zeitpunkt kann sie wieder als bereinigt gekennzeichnet werden. Dies geschieht unter Verwendung normaler Hintergrundvorgänge wie Prüfpunkt- oder Lazy Writer-Vorgänge, und zwar so, als wäre das PMEM-Modul ein Standardblockgerät.

Die Funktion für hybriden Pufferpool ist für Windows und Linux verfügbar. Das PMEM-Gerät muss ein Dateisystem verwenden, das DAX (DirectAccess) unterstützt. Die XFS-, EXT4- und NTFS-Dateisysteme bieten alle Unterstützung für DAX-Erweiterungen, die einen Direktzugriff auf das Dateisystem aus dem Benutzerbereich bieten. SQL Server erkennt, ob sich Datenbank-Datendateien auf einem entsprechend konfigurierten PMEM-Datenträgermedium befinden, und führt beim Starten der Datenbank oder bei jedem Anfügen, Wiederherstellen oder Erstellen einer Datenbank automatisch die erforderliche Speicherzuordnung für die Datenbankdateien durch.

Weitere Informationen finden Sie unter

• Konfigurieren von persistentem Arbeitsspeicher (PMEM) für SQL Server unter Windows (SQL Server 2022 (16.x) und höher).
• Konfigurieren von persistentem Speicher (PMEM) für SQL Server für Linux.

Aktivieren des hybriden Pufferpools

Mit SQL Server 2019 (15.x) wurde DDL (Dynamic Data Language) zum Steuern des Hybridpufferpools eingeführt.

Im folgenden Beispiel wird der hybride Pufferpool für eine Instanz von SQL Server aktiviert:

ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED HYBRID_BUFFER_POOL = ON;

Standardmäßig ist der hybride Pufferpool für die gesamte Instanz deaktiviert. Damit die Einstellungsänderung wirksam wird, muss die SQL Server-Instanz neu gestartet werden. Ein Neustart ist erforderlich, um eine Zuordnung ausreichender Hashseiten entsprechend der PMEM-Gesamtkapazität auf dem Server zu ermöglichen.

Im folgenden Beispiel wird der hybride Pufferpool für eine bestimmte Datenbank aktiviert.

ALTER DATABASE <databaseName> SET MEMORY_OPTIMIZED = ON;

Standardmäßig ist der hybride Pufferpool für die gesamte Datenbank aktiviert.

Deaktivieren des hybriden Pufferpools

Im folgenden Beispiel wird der hybride Pufferpool auf Instanzebene deaktiviert.

ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED HYBRID_BUFFER_POOL = OFF;

Standardmäßig wird der hybride Pufferpool auf Instanzebene deaktiviert. Damit diese Änderung wirksam wird, muss die Instanz neu gestartet werden. Durch den Neustart wird sichergestellt, dass dem Pufferpool genügend Hashseiten zugewiesen sind, da die PMEM-Kapazität auf dem Server jetzt berücksichtigt werden muss.

Im folgenden Beispiel wird der hybride Pufferpool für eine bestimmte Datenbank deaktiviert.

ALTER DATABASE <databaseName> SET MEMORY_OPTIMIZED = OFF;

Standardmäßig ist der Hybridpufferpool im Datenbankbereich aktiviert und im Serverbereich deaktiviert.

Anzeigen der Konfiguration des hybriden Pufferpools

Laufzeitwert anzeigen

Im folgenden Beispiel wird der aktuelle Konfigurationsstatus des hybriden Pufferpools der Instanz zurückgegeben.

SELECT * FROM
sys.server_memory_optimized_hybrid_buffer_pool_configuration;

Im folgenden Beispiel sind die Datenbanken und die Einstellung auf Datenbankebene für den Hybridpufferpool (is_memory_optimized_enabled) aufgeführt.

Sie können das PMEM-Modul auch ohne DAX-Aktivierung einbinden oder formatieren und es als reguläres Blockgerät behandeln (d. h. E/A über den Kernel ausführen). Bei dieser Art von Konfiguration können keine PMEM-Module von SQL Server verwendet werden, um byteadressierbare Vorgänge durchzuführen (d. h., alle Aufrufe verwenden Kernelspeichertreiber).

SELECT name, is_memory_optimized_enabled FROM sys.databases;

Hybridpufferpool mit direktem Schreibvorgang

Ein Hybridpufferpool mit dem Direct Write-Verhalten reduziert die Anzahl von memcpy-Befehlen, die für geänderte Daten oder Indexseiten auf PMEM-Geräten ausgeführt werden müssen. Dazu wird der dauerhaft persistierte Protokollpuffer zum Ändern der Seite verwendet, ohne dass sie in einen der DRAM-Pufferpools kopiert werden muss. Stattdessen werden Seiten in Datenbankdateien, die sich auf PMEM-Geräten befinden, direkt geändert, ohne dass sie in einem DRAM-Pufferpool zwischengespeichert werden müssen, und später asynchron auf den Datenträger geleert. Dieses Verhalten entspricht immer noch der WAL-Semantik (Write-Ahead-Protokollierung), da die Datensätze (des Protokolls) im persistierten Transaktionsprotokollpuffer auf dauerhafte Datenträger geschrieben bzw. festgeschrieben wurden. Bei Transaktionsworkloads, bei denen der Hybridpufferpool und der persistierte Protokollpuffer auf diese Weise zusammen verwendet werden, ließen sich beträchtliche Leistungssteigerungen beobachten.

Um den direkten Schreibmodus zu aktivieren, aktivieren Sie den Hybridpufferpool und den persistierten Protokollpuffer für eine Datenbank, und aktivieren Sie das Startup-Ablaufverfolgungsflag 809.

Best Practices für den Hybridpufferpool

• Verwenden Sie beim Formatieren Ihres PMEM-Geräts unter Windows die größte verfügbare Zuordnungseinheit für NTFS (2 MB in Windows Server 2019 und später), und stellen Sie sicher, dass das Gerät für DAX (DirectAccess) formatiert wurde.

• Aktivieren Sie die Richtlinie Seiten im Arbeitsspeicher sperren unter Windows.

• Dateigrößen müssen ein Vielfaches von 2 MB sein (Modulo 2 MB muss 0 (Null) sein).

• Wenn die für den Server gültige Einstellung für den Hybridpufferpool deaktiviert ist, wird das Feature von keiner Benutzerdatenbank verwendet.

• Wenn die für den Server gültige Einstellung für den Hybridpufferpool aktiviert ist, können Sie mit der für die Datenbank gültigen Einstellung das Feature für einzelne Benutzerdatenbanken deaktivieren.

• Ab SQL Server 2019 (15.x) CU 3 (siehe KB4538118) ist die Lesezwischenspeicherung standardmäßig aktiviert, ein Prozess, bei dem die am meisten nachgefragten Seiten im Hybridpufferpool nachverfolgt und dann automatisch zu einem DRAM-Pufferpool heraufgestuft werden, um die Leistung zu verbessern.

• Ab SQL Server 2022 (16.x) CU 1 ist Direct Write das Standardverhalten, wenn der Hybridpufferpool mit einem persistenten Protokollpuffer kombiniert wird. Dies sollte die Leistung für fast alle Workloads verbessern, aber es besteht immer die Möglichkeit einer Regression, und die CU sollte vor der Anwendung gründlich getestet werden. Wenn aufgrund dieser Verhaltensänderung eine Regression auftritt, können Sie das vorherige Verhalten mithilfe des Start-Ablaufverfolgungsflags 898 wiederherstellen.

• Ab SQL Server 2022 (16.x) CU 1 wird das Ablaufverfolgungsflag 809 vom SQL Server beim Start ignoriert. Sowohl Ablaufverfolgungsflag 809 als auch Ablaufverfolgungsflag 898 gelten nur für Windows und nicht für SQL Server für Linux. Die Ablaufverfolgungsflags sollten nur verwendet werden, wenn ein zertifizierter Microsoft Server-Experte dies anweist.