Empfehlen von Datenbankkonfigurationen

Abgeschlossen

Bevor Sie Abfragen optimieren oder die Parallelität beheben können, benötigen Sie die richtige Infrastruktur darunter. Azure SQL-Datenbank bietet Ihnen zwei Ressourcenmodelle und mehrere Dienstebenen. Die Kombination, die Sie auswählen, legt die Obergrenze für Compute, Arbeitsspeicher, E/A und Speicher für Ihre Arbeitslast fest. Wählen Sie zu wenig aus, und die Leistung leidet. Wählen Sie zu viel aus, und verschwenden Sie das Budget.

Vergleichen von Ressourcenmodellen

Azure SQL-Datenbank unterstützt zwei Ressourcenmodelle: vCore und DTU. Sie messen und rechnen Ressourcen unterschiedlich ab, sodass das Verständnis dieser Unterscheidung Ihnen hilft, die richtige Wahl gleich von Beginn an zu treffen.

Das vCore-Modell bietet Ihnen direkte Kontrolle über virtuelle Kerne, Arbeitsspeicher und Speicher. Sie wählen die Hardwaregenerierung, die Dienstebene und die Computeebene unabhängig voneinander aus. Wenn Sie von lokalem SQL Server migrieren, wird dieses Modell sauber der physischen CPU und dem Arbeitsspeicher zugeordnet, wodurch die Kapazitätsplanung einfacher wird. Sie unterstützt auch reservierte Instanzenpreise und den Azure-Hybridvorteil für Kosteneinsparungen.

Das DTU-Modell bündelt CPU, Arbeitsspeicher und E/A in einer einzigen Einheit, die als Datenbanktransaktionseinheit (Database Transaction Unit , DTU) bezeichnet wird. DTU-basierte Ebenen (Basic, Standard und Premium) bieten vorkonfigurierte Ressourcenpakete. Dieses Modell funktioniert, wenn Sie keine differenzierte Kontrolle über einzelne Ressourcenabmessungen benötigen.

Für die meisten neuen Bereitstellungen empfiehlt Microsoft das vCore-Modell. Sie bietet höhere Ressourcenlimits, eine höhere Skalierungs granularität und mehr Preisflexibilität.

Grundlegendes zu Dienstebenen im vCore-Modell

Das vCore-Modell verfügt über drei Dienstebenen: "General Purpose", "Business Critical" und "Hyperscale". Jede Ebene verwendet eine andere Architektur, die sich auf speichertyp, E/A-Leistung und Verfügbarkeit auswirkt.

Der allgemeine Zweck trennt Compute und Speicher. Das Datenbankmodul wird auf einem Computeknoten ausgeführt, während sich Datendateien in Azure Blob Storage befinden. Die Speicherlatenz liegt in der Regel zwischen 5 Millisekunden und 10 Millisekunden. Diese Architektur bietet budgetfreundliche Preise und eignet sich gut für die meisten Geschäftsworkloads. Wenn der Computer-Knoten ausfällt, verschiebt Azure Service Fabric den Prozess auf einen Ersatzknoten und bindet die Remotespeicherdateien erneut ein.

Betrachten Sie die E-Commerce-Anwendung aus der Einführung. Während der normalen Geschäftszeiten verarbeitet General Purpose das Auftragsvolumen ohne Problem. Während eines Blitzverkaufs an einem Feiertag reicht eine E/A-Latenz von 5 bis 10 Millisekunden für die Kaufabwicklung möglicherweise nicht aus.

Unternehmenskritisch integriert Compute und Speicher auf jedem Knoten. Das Datenbankmodul und die Datendateien verwenden beide lokal angefügte SSDs in einer AlwaysOn-Verfügbarkeitsgruppe mit drei sekundären Replikaten. Mit diesem Design erhalten Sie die niedrigste E/A-Latenz (1 Millisekunden bis 2 Millisekunden im Durchschnitt), die höchsten IOPS (Eingabe-/Ausgabevorgänge pro Sekunde) und ein kostenloses schreibgeschütztes Replikat, das Sie für Berichtsabfragen verwenden können. Der Kompromiss sind die Kosten, die ungefähr 2,7 Mal höher als bei „Universell“ für dieselbe vCore-Zahl sind. Für das E-Commerce-Team ist Business Critical sinnvoll, wenn ihre Checkout-Transaktionen eine konsistente Unter-2-Millisekundenlatenz benötigen.

Hyperscale verwendet eine entkoppelte Speicherarchitektur mit unabhängigen Seitenservern und einem mehrstufigen Cache. Es unterstützt Datenbanken bis zu 128 TB, ermöglicht 0 bis vier hochverfügebaren Replikaten und skaliert die Berechnung nach oben oder unten, ohne Daten zu kopieren. Sie werden nur für zugewiesenen Speicher und nicht für maximal zulässigen Speicherplatz in Rechnung gestellt. Hyperscale entfernt die praktischen Speicher- und Skalierungsgrenzen der anderen Ebenen und eignet sich für die größte Vielfalt von Workloads.

In der folgenden Tabelle sind die wichtigsten Unterschiede zusammengefasst:

Merkmal	Allgemeiner Zweck	Geschäftskritisch	Hyperskalierung
Speichertypus	Remote (Azure Blob Storage)	Lokale SSD	Entkoppelt mit lokalem SSD-Cache
Maximaler Speicher	4 TB	4 TB	128 TB
Max IOPS pro vCore	320	4\.000	5.500 (lokale SSD)
Verfügbarkeitsreplikate	1 (keine Lesereplikate)	3 + 1 Lesereplikat	0 bis 4 (konfigurierbar)
Am besten geeignet für	Budgetorientierte Arbeitslasten	Niedrige Latenz, hohe Eingabe/Ausgabe	Große Datenbanken, flexible Skalierung

Wählen Sie eine Computestufe aus.

Im vCore-Modell wählen Sie auch zwischen zwei Computeebenen: bereitgestellt und serverlos.

Bereitgestellte Rechenleistung weist eine feste Anzahl von vCores zu, die unabhängig von der Workloadaktivität verfügbar bleiben. Sie zahlen einen festen Stundensatz. Diese Stufe passt zu Workloads mit einem konsistenten oder vorhersagbaren Ressourcenverbrauch, z. B. der E-Commerce-Anwendung, die Bestellungen im Laufe des Tages verarbeitet.

Serverless Compute skaliert die Anzahl der vCores automatisch je nach Bedarf und berechnet die Kosten pro Sekunde für die genutzte Verarbeitungsleistung. Wenn sich die Datenbank im Leerlauf befindet, kann sie selbstständig pausieren und die Rechenkosten vollständig beseitigen, obwohl Autopause derzeit nur in General Purpose unterstützt wird. Serverless Compute selbst ist sowohl für die Ebenen "Allgemein" als auch für "Hyperscale" verfügbar. Es eignet sich gut für Entwicklungsumgebungen, interne Tools oder Anwendungen mit zeitweisem Datenverkehr.

Anpassen der Konfiguration an Ihre Workload

Nachdem Sie nun die Optionen verstanden haben, wie entscheiden Sie sich? Bewerten Sie Ihre Arbeitsauslastung anhand dieser Faktoren:

• Latenzanforderungen: Wenn Ihre Anwendung die E/A-Latenz unter 2 Millisekunden konsistent benötigt, wählen Sie "Geschäftskritisch" aus. Für eine moderate Latenztoleranz reicht General Purpose aus.
• Speichergröße: Wenn Ihre Datenbank 4 TB überschreitet oder Sie ein schnelles Wachstum erwarten, ist Hyperscale die einzige Option, die bis zu 128 TB aufnehmen kann.
• Leseintensive Workloads: „Unternehmenskritisch“ enthält ein kostenloses schreibgeschütztes Replikat. Hyperscale unterstützt benannte Replikate für eine horizontale Leseskalierung.
• Kostenempfindlichkeit: Allgemeiner Zweck mit bereitgestellter Rechenkapazität bietet vorhersehbare Preise. Die serverlose Berechnung in General Purpose oder Hyperscale reduziert die Kosten für zeitweilige Workloads.
• Verfügbarkeitsanforderungen: Business Critical bietet höchste Ausfallsicherheit mit drei synchronen Replikaten und dem schnellsten Failover. Mit Hyperscale können Sie die Anzahl der Replikate konfigurieren, um die Ausfallsicherheit mit Kosten auszugleichen.

Tipp

Verwenden Sie beim Migrieren von lokalem SQL Server das vCore-Modell, da es direkt physischer CPU und Arbeitsspeicher zugeordnet ist. Das DTU-Modell macht keine einzelnen Ressourcendimensionen verfügbar, wodurch die Kapazitätsplanung für Migrationen erschwert wird.

Konfigurieren von Einstellungen auf Datenbankebene

Sie haben Ihre Stufe und Ihr Computer-Modell ausgewählt. Schauen Sie sich nun die Datenbank selbst an. Mehrere Einstellungen wirken sich darauf aus, wie Azure SQL-Datenbank Parallelität, Abfrageoptimierung und Wiederherstellung verarbeitet. Sie passen diese Einstellungen an, ohne die Dienstebene zu ändern.

Steuern der Parallelität mit MAXDOP

Max. Grad der Parallelität (MAXDOP) steuert, wie viele Prozessorthreads die Engine einer einzelnen Abfrage zuweist. Die Azure SQL-Datenbank ist standardmäßig auf 8 festgelegt, was für die größte Vielfalt von Workloads geeignet ist. Vor September 2020 wurden neue Datenbanken standardmäßig auf 0, unbegrenzte Parallelität festgelegt und verursachten Probleme. Eine einzelne Analyseabfrage könnte jeden verfügbaren Thread verbrauchen und den Checkoutprozess der CPU beeinträchtigen.

Sie legen MAXDOP auf Datenbankebene mit ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP. Sie können auch einen anderen Wert für sekundäre Replikate festlegen, wenn Ihre Lese-Schreib- und schreibgeschützten Workloads unterschiedliche Parallelitätsanforderungen aufweisen. Verwenden Sie für eine bestimmte Abfrage den OPTION (MAXDOP) Hinweis. Die eine Regel: Vermeiden Sie MAXDOP 0 in der Produktion. Unbegrenzte Parallelität führt zu Ressourcenauslastung, Abfragetimeouts und Anwendungsausfällen.

Automatisches Tuning zum Erfassen von Regressionen verwenden

Der Abfrageoptimierer wählt nicht immer den besten Plan aus. Statistiken gehen veraltet, Datenverteilungen verschieben sich und ein Plan, der gestern schnell war, wird heute langsam. Die automatische Optimierung überwacht die Abfrageleistung und wendet Korrekturen an, bevor Sie diese bemerken.

Azure SQL-Datenbank unterstützt drei Optionen:

• FORCE_LAST_GOOD_PLAN erkennt Planregressionen und erzwingt den vorherigen schnellen Plan. Standardmäßig aktiviert.
• CREATE_INDEX identifiziert fehlende Indizes, erstellt sie und überprüft die Verbesserung. Standardmäßig deaktiviert.
• DROP_INDEX entfernt nicht verwendete und doppelte Indizes. Standardmäßig deaktiviert. Eindeutige Indizes, einschließlich solcher, die Primärschlüssel und einzigartige Einschränkungen unterstützen, werden niemals gelöscht.

Jede Änderung durchläuft je nach Abfragehäufigkeit ein Überprüfungsfenster, 30 Minuten bis 72 Stunden. Wenn die Leistung schlechter wird, wird die Änderung automatisch zurückgesetzt.

ALTER DATABASE CURRENT
SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN = ON,
                      CREATE_INDEX = ON,
                      DROP_INDEX = OFF);

Denken Sie an die E-Commerce-Anwendung während eines Feiertagsangebots. Abfragemuster verändern sich, während unterschiedliche Produktseiten an Beliebtheit gewinnen. FORCE_LAST_GOOD_PLAN fängt diese Regressionen automatisch ab, sodass eine schlechte Planänderung um 2:00 Uhr den Checkout nicht verlangsamt, bis jemand es am Montagmorgen bemerkt. Es ist ratsam, dass Sie CREATE_INDEX und DROP_INDEX deaktiviert lassen, bis die Vorschläge überprüft wurden.

Freischalten von Optimiererfeatures mit Kompatibilitätsstufe

Jede Datenbank verfügt über eine Kompatibilitätsstufe , die bestimmt, welche Abfrageoptimiererverhalten verfügbar sind. Neue Datenbanken in der Azure SQL-Datenbank werden standardmäßig auf Ebene 170 oder die höchste verfügbare Ebene festgelegt. Jede Ebene entsperrt eine Reihe intelligenter Abfrageverarbeitungsfunktionen (IQP):

• Ebene 150: Batchmodus im Zeilenspeicher, verzögerte Kompilierung von Tabellenvariablen, skalare benutzerdefinierte Funktion (UDF) Einbettung.
• Stufe 160: Optimierung sensibler Parameter in Plänen (PSP), Kardinalitätsbewertungsfeedback.
• Stufe 170: Optionale Parameterplanoptimierung.

Vorhandene Datenbanken können auf einer niedrigeren Kompatibilitätsebene ausgeführt werden, da Microsoft diese Einstellung nie automatisch aktualisiert. Eine Datenbank, die erstellt wurde, wenn ein niedrigerer Standardwert wirksam war, behält seine ursprüngliche Ebene bei. Wenn Sie beispielsweise 2024 eine Azure SQL-Datenbank erstellt haben, befindet sich die Datenbank immer noch auf Ebene 160, wenn die Ebene nicht manuell aktualisiert wird. Ebenso basiert die Kompatibilitätsebene der importierten Datenbank, wenn Sie eine Datenbank über eine BACPAC-Datei importiert haben, auf der Kompatibilitätsstufe der Quelldatenbank. So bewegen Sie sich nach oben:

ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 170;

Ändern Sie diese Einstellung nicht blind in der Produktion. Verwenden Sie den Abfragespeicher, um eine Leistungsbasislinie auf der aktuellen Ebene zu erfassen, ein Upgrade in einer Testumgebung durchzuführen und zu vergleichen. Wenn sich die Leistung einer Abfrage verschlechtert, können Sie den alten Plan durchsetzen, während Sie dies untersuchen.

Reduzieren von Überfrachtungen des Planzwischenspeichers mit OPTIMIZE_FOR_AD_HOC_WORKLOADS

Die E-Commerce-Anwendung generiert Produktsuchabfragen mit Dutzenden von Filterkombinationen. Jeder eindeutige Abfragetext erhält einen eigenen kompilierten Plan im Cache, auch wenn diese Abfrage nie wieder ausgeführt wird. Über die Zeit wird der Planzwischenspeicher mit Tausenden von Plänen zur einmaligen Verwendung gefüllt, was die häufig ausgeführten Pläne verdrängt, die tatsächlich wichtig sind.

OPTIMIZE_FOR_AD_HOC_WORKLOADS löst dieses Problem. Wenn diese Option aktiviert ist, speichert das Modul einen winzigen kompilierten Plan-Stub bei der ersten Ausführung anstelle des vollständigen Plans. Nur wenn dieselbe Abfrage ein zweites Mal ausgeführt wird, kompiliert und zwischenspeichert das Modul den vollständigen Plan.

ALTER DATABASE SCOPED CONFIGURATION
SET OPTIMIZE_FOR_AD_HOC_WORKLOADS = ON;

Diese Einstellung hält den Zwischenspeicher schlank und stellt sicher, dass die Pläne für Ihre wichtigsten Abfragen nicht aus dem Arbeitsspeicher verdrängt werden.

Grundlegendes zur beschleunigten Datenbankwiederherstellung

Die beschleunigte Datenbankwiederherstellung ist immer in der Azure SQL-Datenbank aktiviert. Sie können sie nicht deaktivieren und müssen nicht. Die beschleunigte Datenbankwiederherstellung (ADR) überarbeitet den Wiederherstellungsvorgang so, dass die Wiederherstellungszeit konstant bleibt, unabhängig davon, wie viele aktive Transaktionen ausgeführt wurden, wenn ein Fehler aufgetreten ist. Sie ermöglicht außerdem einen sofortigen Transaktionsrollback und eine aggressive Protokollkürzung.

ADR speichert Zeilenversionen in einem persistenten Versionsspeicher (PVS) in der Datenbank und nicht in tempdb. Abhängig von der Größe der Zeile, die modifiziert wird, werden Versionen entweder zeilenintern auf Datenseiten oder zeilenextern in einer separaten internen Tabelle gespeichert. Schreibintensive Workloads können erhöhte Seitenaufteilungen und eine höhere Protokollgenerierung erfahren, da jede Zeilenversion protokolliert wird. Um diesen Aufwand zu minimieren, halten Sie Transaktionen kurz und reduzieren Sie unnötige abgebrochene Transaktionen.

Die PVS teilt sich den Ihrer Datenbank zugewiesenen Speicherplatz, so dass ein wachsender PVS den für Ihre Daten verfügbaren Speicherplatz verringert. Um den PVS-Aufwand außerhalb der Zeile zu überwachen, führen Sie eine Abfrage für sys.dm_tran_persistent_version_store_stats aus, und überprüfen Sie die Spalte persistent_version_store_size_kb, die nur die Größe von zeilenexternen Versionen meldet und keine zeileninternen Versionen enthält, die auf Datenseiten gespeichert sind. Wenn Sie einen Basisplan während typischer Workloads einrichten möchten, vergleichen Sie diesen Wert mit Ihrer Gesamtdatenbankgröße. Wenn PVS deutlich über diese Basislinie hinaus wächst, suchen Sie nach lang andauernden Transaktionen oder hohen Abbruchraten, die die Versionsbereinigung verzögern.

Wichtige Erkenntnisse

Die Azure SQL-Datenbank bietet Ihnen zwei Ressourcenmodelle, drei Dienstebenen und zwei Computeebenen. Das vCore-Modell mit allgemeinem Zweck deckt die meisten Workloads ab. Business Critical fügt die Latenz von unter 2 Millisekunden hinzu. Hyperscale entfernt Speicher- und Skalierungsgrenzwerte. Innerhalb der Datenbank ist MAXDOP 8 die sichere Standardeinstellung, automatische Optimierung fängt Planregressionen ab und das Upgrade Ihrer Kompatibilitätsstufe entsperrt die neuesten intelligenten Abfrageverarbeitungsfeatures (IQP). Aktivieren Sie OPTIMIZE_FOR_AD_HOC_WORKLOADS, um den Planzwischenspeicher schlank zu halten, und überwachen Sie die PVS-Speichernutzung über ADR mittels sys.dm_tran_persistent_version_store_stats, insbesondere in schreibintensiven Szenarien. Als Nächstes untersuchen Sie, wie sich Isolationsstufen und Parallelitätssteuerung auf die Abfragen auswirken, die in dieser Infrastruktur ausgeführt werden.