Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird erläutert, wie die Workload-Wichtigkeit die Ausführungsreihenfolge für dedizierte SQL-Poolanforderungen in Azure Synapse beeinflussen kann.
Wichtigkeit
Geschäftsanforderungen können erfordern, dass Data Warehouse-Workloads wichtiger sind als andere. Betrachten Sie ein Szenario, in dem unternehmenskritische Umsatzdaten vor Abschluss des Geschäftsjahres geladen werden. Datenladevorgänge für andere Quellen, z. B. Wetterdaten, weisen keine strengen SLAs auf. Das Festlegen einer hohen Priorität für eine Anforderung zum Laden von Verkaufsdaten und einer niedrigen Priorität für eine Anforderung zum Laden von Wetterdaten stellt sicher, dass das Laden der Verkaufsdaten zuerst auf Ressourcen zugreifen kann und schneller abgeschlossen wird.
Wichtigkeitsstufen
Es gibt fünf Prioritätsstufen: „low“, „below_normal“, „normal“, „above_normal“ und „high“. Anforderungen, für die keine Priorität festgelegt wird, weisen die Standardstufe „normal“ auf. Anforderungen mit der gleichen Prioritätsstufe weisen das herkömmliche Planungsverhalten auf.
Wichtigkeitsszenarien
Über das oben beschriebene grundlegende Wichtigkeitsszenario mit Umsatz- und Wetterdaten hinaus gibt es andere Szenarien, in denen die Arbeitsauslastung wichtig ist, die Datenverarbeitungs- und Abfrageanforderungen zu erfüllen.
Sperrung
Der Zugriff auf Sperren für Lese- und Schreibvorgänge ist ein Bereich inhärenter Konflikte. Aktivitäten wie Partitionswechsel oder RENAME OBJECT erfordern erhöhte Sperren. Ohne Workload-Wichtigkeit optimiert der dedizierte SQL-Pool in Azure Synapse den Durchsatz. Die Optimierung für den Durchsatz bedeutet, dass bei laufenden und in der Warteschlange befindlichen Anfragen mit denselben Sperranforderungen und verfügbaren Ressourcen die in der Warteschlange befindlichen Anfragen solche mit höheren Sperranforderungen umgehen können, die früher in der Anfragenschlange eingetroffen sind. Sobald die Workload-Wichtigkeit auf Anforderungen mit höheren Sperranforderungen angewendet wird. Die Anforderung mit höherer Wichtigkeit wird vor der Anforderung mit niedrigerer Wichtigkeit ausgeführt.
Betrachten Sie das folgenden Beispiel:
- Q1 läuft aktiv und wählt Daten aus SalesFact aus.
- Q2 steht in der Warteschlange und wartet darauf, dass Q1 abgeschlossen wird. Es wurde um 9:00 Uhr übermittelt und versucht, neue Daten in SalesFact zu partitionieren.
- Q3 wird um 9:01 Uhr übermittelt und möchte Daten aus SalesFact auswählen.
Wenn Q2 und Q3 die gleiche Bedeutung haben und Q1 noch ausgeführt wird, beginnt Q3 mit der Ausführung. Q2 wartet weiterhin auf eine exklusive Sperre für SalesFact. Wenn Q2 eine höhere Wichtigkeit als Q3 hat, wartet Q3, bis Q2 abgeschlossen ist, bevor er mit der Ausführung beginnen kann.
Nicht einheitliche Anforderungen
Ein weiteres Szenario, in dem die Wichtigkeit helfen kann, Abfrageanforderungen zu erfüllen, ist, wenn Anforderungen mit verschiedenen Ressourcenklassen übermittelt werden. Wie bereits erwähnt, optimiert der dedizierte SQL-Pool in Azure Synapse unter der gleichen Bedeutung für den Durchsatz. Wenn Anforderungen mit gemischter Größe (z. B. smallrc oder mediumrc) in die Warteschlange gestellt werden, wählt der dedizierte SQL-Pool die früheste eingehende Anforderung aus, die in die verfügbaren Ressourcen passt. Wenn die Workload-Priorität angewendet wird, wird die Anfrage mit der höchsten Priorität als nächstes geplant.
Betrachten Sie das folgende Beispiel auf DW500c:
- Q1, Q2, Q3 und Q4 führen smallrc-Abfragen aus.
- Q5 wird mit der Ressourcenklasse "mediumrc" um 9 Uhr eingereicht.
- Q6 wird mit der Smallrc-Ressourcenklasse um 9:01 Uhr übermittelt.
Da Q5 in der Mediumrc-Klasse liegt, erfordert es zwei Gleichzeitigkeitsslots. Q5 muss warten, bis zwei der ausgeführten Abfragen abgeschlossen sind. Wenn jedoch eine der ausgeführten Abfragen (Q1-Q4) abgeschlossen ist, wird Q6 sofort geplant, da die Ressourcen zum Ausführen der Abfrage vorhanden sind. Wenn Q5 eine höhere Wichtigkeit hat als Q6, wartet Q6, bis Q5 ausgeführt wird, bevor es mit der Ausführung beginnen kann.
Nächste Schritte
- Weitere Informationen zum Erstellen eines Klassifizierers finden Sie unter CREATE WORKLOAD CLASSIFIER (Transact-SQL).
- Weitere Informationen zur Workloadklassifizierung finden Sie unter Workload Classification.
- Informationen zum Erstellen eines Workloadklassifizierers finden Sie in der Schnellstartanleitung zum Erstellen eines Workloadklassifizierers.
- Lesen Sie die Artikel zum Konfigurieren der Workload-Wichtigkeit und zum Verwalten und Überwachen der Workloadverwaltung.
- Siehe sys.dm_pdw_exec_requests, um Abfragen und die zugewiesene Wichtigkeit einzusehen.