Optimieren des Datenbankspeichers

Abgeschlossen

Um den Datenbankspeicher zu optimieren, sollten Sie eine proportionale Füllung und eine tempdb-Konfiguration in Erwägung ziehen.

Grundlegendes zur E/A-Leistung

Die E/A-Leistung kann für eine Datenbankanwendung von entscheidender Bedeutung sein. In Azure SQL werden Sie von der physischen Dateiplatzierung entbunden, aber es gibt Methoden, um sicherzustellen, dass Sie die benötigte E/A-Leistung erhalten.

Die Eingabe/Ausgabe pro Sekunde (Input/Output Per Second, IOPS) kann eine sehr wichtige Kennzahl für Ihre Anwendung sein. Vergewissern Sie sich, dass Sie die richtige Dienstebene und die richtige Anzahl von virtuellen Kernen für Ihre IOPS-Anforderungen ausgewählt haben. Erfahren Sie, wie Sie IOPS für Ihre lokalen Abfragen messen, wenn Sie zu Azure migrieren. Wenn Sie Einschränkungen für Ihre IOPS konfiguriert haben, kommt es möglicherweise zu langen E/A-Wartevorgängen. Im vCore-Einkaufsmodell können Sie vCores skalieren oder zu Business Critical oder Hyperscale wechseln, wenn Sie nicht über genügend IOPS verfügen. Bei Produktions-Workloads empfehlen wir bei Verwendung von DTU den Umstieg auf den Premium-Tarif.

Die E/A-Latenz ist eine weitere Schlüsselkomponente der E/A-Leistung. Wenn Sie die E/A-Latenz für Azure SQL-Datenbank verkürzen möchten, sollten Sie zur Dienstebene „Unternehmenskritisch“ oder „Hyperscale“ wechseln. Die E/A-Latenz in SQL Managed Instance kann ebenfalls durch einen Wechsel zu einer Dienstebene des Typs „Unternehmenskritisch“ oder durch das Heraufsetzen der Dateigröße oder der Dateianzahl für die Datenbank beschleunigt werden. Für die Verringerung der Latenz des Transaktionsprotokolls müssen Sie unter Umständen Transaktionen mit mehreren Anweisungen ausführen.

Dateien und Dateigruppen

SQL Server-Experten setzen häufig Dateien und Dateigruppen ein, um die E/A-Leistung durch aktive Dateiplatzierung zu verbessern. Azure SQL lässt nicht zu, dass Benutzer Dateien in bestimmten Festplattensystemen ablegen. Azure SQL hat jedoch Ressourcenverpflichtungen für die E/A-Leistung in Bezug auf Raten, IOPS und Latenzen. Indem man den Benutzer von der physischen Dateiplatzierung abstrahiert, kann dies von Vorteil sein.

Azure SQL-Datenbank verfügt nur über eine einzelne Datenbankdatei (Hyperscale in der Regel über mehrere), und die maximale Größe wird über Azure-Schnittstellen konfiguriert. Es gibt keine Funktionalität zum Erstellen weiterer Dateien.

Azure SQL Managed Instance unterstützt das Hinzufügen von Datenbankdateien sowie das Konfigurieren der Dateigrößen, jedoch nicht die aktive Dateiplatzierung. Sie können die Dateianzahl und die Dateigrößen für SQL Managed Instance zur Verbesserung der E/A-Leistung einsetzen. Außerdem werden benutzerdefinierte Dateigruppen in SQL Managed Instance zu Verwaltungszwecken unterstützt.

Proportionale Füllung beschreiben

Wenn Sie 1 GIGABYTE Daten in eine SQL Server-Datenbank mit zwei Datendateien einfügen, erwarten Sie möglicherweise, dass jede Datei um ca. 512 MB ansteigt. Dies ist jedoch nicht immer der Fall. SQL Server verteilt Daten basierend auf der Größe jeder Datei. Wenn beispielsweise beide Datendateien 2 Gb groß sind, würden die Daten gleichmäßig verteilt. Wenn eine Datei jedoch 10 Gigabyte beträgt und das andere 1 Gigabyte beträgt, würden etwa 900 MB in die größere Datei und 100 MB in die kleinere datei gehen. Dieses Verhalten ist in jeder Datenbank üblich, aber in der schreibintensiven tempdb kann ein ungleichmäßiges Schreibmuster einen Engpass in der größten Datei erzeugen, da mehr Schreibvorgänge verarbeitet werden.

Konfigurieren von Tempdb in SQL Server

SQL Server erkennt die Anzahl der verfügbaren CPUs während des Setups und konfiguriert die entsprechende Anzahl von Dateien, bis zu acht, mit gleichmäßiger Größenanpassung. Darüber hinaus sind die Funktionen der Trace-Flags 1117 und 1118 in das Datenbankmodul integriert, jedoch nur für tempdb. Bei tempdb-intensiven Workloads kann es vorteilhaft sein, die Anzahl der tempdb-Dateien auf mehr als acht zu erhöhen, sodass sie der Anzahl der CPUs auf Ihrem Computer entspricht.

Die Verwendung von tempdb erfolgt in Azure SQL und SQL Server auf die gleiche Weise. Beachten Sie jedoch, dass Ihre Möglichkeiten zur Konfiguration von tempdb unterschiedlich sind, einschließlich der Platzierung von Dateien, der Anzahl und Größe von Dateien und tempdb-Konfigurationsoptionen.

SQL Server verwendet tempdb für verschiedene Aufgaben, die nicht nur benutzerdefinierte temporäre Tabellen speichern. Es wird für Arbeitstabellen verwendet, die Zwischenabfrageergebnisse, Sortiervorgänge und den Versionsspeicher für zeilenweise Versionsverwaltung speichern. Aufgrund dieser umfangreichen Auslastung ist es wichtig, tempdb auf den niedrigsten verfügbaren Latenzspeicher zu setzen und die Datendateien ordnungsgemäß zu konfigurieren.

Die Datenbankdateien von tempdb werden immer automatisch auf lokalen SSD-Laufwerken gespeichert, sodass die E/A-Leistung kein Problem sein sollte.

SQL Server-Experten verwenden oft mehr als eine Datenbankdatei, um die Speicherbelegung von tempdb-Tabellen zu partitionieren. Bei Der Azure SQL-Datenbank wird die Anzahl der Dateien mit der Anzahl der vCores skaliert (z. B. zwei vCores gleich vier Dateien) mit maximal 16. Die Anzahl der Dateien in tempdb kann nicht über T-SQL konfiguriert werden, sondern nur durch Ändern der Bereitstellungs-Einstellung. Die maximale Größe von tempdb wird mit Anzahl von virtuellen Kernen skaliert. Unabhängig von der Anzahl der vCores erhalten Sie in SQL Managed Instance 12 Dateien.

Die Datenbankoption MIXED_PAGE_ALLOCATION ist auf AUS festgelegt und AUTOGROW_ALL_FILES auf EIN festgelegt. Sie können dies nicht konfigurieren, aber wie bei SQL Server sind dies die empfohlenen Standardeinstellungen.

Die in SQL Server 2019 eingeführte tempdb-Metadaten-Optimierungsfunktion, die große Latchkonflikte verringern kann, ist derzeit nicht in Azure SQL Database oder Azure SQL Managed Instance verfügbar.

Datenbankkonfiguration

Häufig konfigurieren Sie eine Datenbank mit den T-SQL ALTER DATABASE und ALTER DATABASE SCOPED CONFIGURATION Anweisungen. Viele der Optionen für die Konfiguration der Leistung sind für Azure SQL verfügbar. Informationen zu den Unterschieden zwischen SQL Server, Azure SQL-Datenbank und Azure SQL Managed Instance finden Sie in der T-SQL-Referenz zu ALTER DATABASE und ALTER DATABASE SCOPED CONFIGURATION.

In der Azure SQL-Datenbank ist das Standardwiederherstellungsmodell die vollständige Wiederherstellung, wodurch sichergestellt wird, dass Ihre Datenbank Vereinbarungen auf Dienstebene (Azure Service Level Agreements, SLAs) erfüllen kann. Dies bedeutet, dass die minimale Protokollierung für Massenvorgänge nicht unterstützt wird, mit Ausnahme von tempdb, wobei die Minimalprotokollierung zulässig ist.

MAXDOP-Konfiguration

Der maximale Parallelitätsgrad (Max Degree Of Parallelism, MAXDOP) kann die Leistung einzelner Abfragen beeinflussen SQL Server und Azure SQL behandeln MAXDOP auf die gleiche Weise. Wenn MAXDOP sie auf einen höheren Wert festgelegt ist, werden pro Abfrage mehr parallele Threads verwendet, was die Abfrageausführung potenziell beschleunigt. Diese erhöhte Parallelität erfordert jedoch zusätzliche Speicherressourcen, die zu Speicherdruck führen und die Speicherleistung beeinträchtigen können. Beim Komprimieren von Zeilengruppen in einen Columnstore erfordert paralleler Speicherplatz beispielsweise mehr Arbeitsspeicher, was zu Speicherdruck und Zeilengruppenkürzung führen kann.

Umgekehrt kann das Festlegen von MAXDOP auf einen niedrigeren Wert den Arbeitsspeicherdruck verringern, sodass das Speichersystem effizienter ausgeführt werden kann. Dies ist in Umgebungen mit begrenzten Speicherressourcen oder hohen Speicheranforderungen wichtig. Durch die sorgfältige Konfiguration von MAXDOP können Sie abfrageleistung und Speichereffizienz ausgleichen und so eine optimale Nutzung von CPU- und Speicherressourcen gewährleisten.

Die Konfiguration von MAXDOP erfolgt in Azure SQL auf ähnliche Weise wie in SQL Server mithilfe einer der folgenden Methoden:

• ALTER DATABASE SCOPED CONFIGURATION Das Konfigurieren von MAXDOP wird für Azure SQL unterstützt.
• Die gespeicherte Prozedur sp_configure für "max. Grad der Parallelität" wird für die verwaltete SQL-Instanz unterstützt.
• MAXDOP Abfragehinweise werden vollständig unterstützt.
• Die Konfiguration von MAXDOP mit Resource Governor wird für SQL Managed Instance unterstützt.