Übersicht über das DTU-basierte Kaufmodell

Gilt für:Azure SQL-Datenbank

Dieser Artikel enthält Informationen zum DTU-basierten Kaufmodell für Azure SQL-Datenbank.

Weitere Informationen finden Sie unter Übersicht über das Kaufmodell für virtuelle Kerne: Azure SQL-Datenbank und Azure SQL Managed Instance sowie unter vCore- und DTU-basierte Kaufmodelle von Azure SQL-Datenbank im Vergleich.

Datenbanktransaktionseinheiten (DTUs)

Eine Datenbanktransaktionseinheit (Database Transaction Unit, DTU) entspricht einer Mischung aus den Werten von CPU, Arbeitsspeicher, Lesevorgängen und Schreibvorgängen. Beim DTU-basierten Kaufmodell unterscheiden sich Dienstebenen durch eine Reihe von Computegrößen mit einer festen Menge an integriertem Speicher, einem festen Aufbewahrungszeitraum für Sicherungen und einem festen Preis. Alle Dienstebenen im DTU-basierten Kaufmodell bieten die Flexibilität, Computegrößen bei minimaler Downtime zu ändern. Die Datenbankverbindung wird zwar umstellungsbedingt kurzzeitig unterbrochen, dies lässt sich jedoch durch eine Wiederholungslogik kompensieren. Einzeldatenbanken und Pools für elastische Datenbanken werden nach Dienstebene und Computegröße auf Stundenbasis abgerechnet.

Für eine Einzeldatenbank mit einer bestimmten Computegröße innerhalb einer Dienstebene wird von Azure SQL-Datenbank ein bestimmter Ressourcenumfang garantiert (unabhängig von anderen Datenbanken). Diese Garantie bietet eine vorhersagbare Leistungsebene. Der Umfang der Ressourcen, die einer Datenbank zugeordnet werden, wird als Anzahl von DTUs berechnet. Es handelt sich dabei um ein Paket aus Compute-, Speicher- und E/A-Ressourcen.

Das Verhältnis zwischen diesen Ressourcen wurde ursprünglich anhand einer OLTP-Benchmark-Workload ermittelt, die für realistische Onlinetransaktionsverarbeitungs-Workloads (Online Transaction Processing, OLTP) typisch ist. Wenn Ihre Workload den Umfang einer dieser Ressourcen überschreitet, wird der Durchsatz gedrosselt, wodurch eine niedrigere Leistung und Timeouts verursacht werden.

Bei Einzeldatenbanken wirken sich die von Ihrer Workload verwendeten Ressourcen nicht auf die Ressourcen aus, die für andere Datenbanken in der Azure-Cloud verfügbar sind. Umgekehrt wirken sich die von anderen Workloads verwendeten Ressourcen nicht auf die Ressourcen aus, die für Ihre Datenbank verfügbar sind.

DTUs sind besonders aufschlussreich, um die relativen Ressourcen zu verstehen, die für Datenbanken in unterschiedlichen Computegrößen und Dienstebenen zugeordnet werden. Beispiel:

• Eine Verdoppelung der DTUs durch Erhöhen der Computegröße einer Datenbank entspricht einer Verdoppelung des Satzes von Ressourcen, die dieser Datenbank zur Verfügung stehen.
• Eine P11-Datenbank in der Dienstebene „Premium“ mit 1750 DTUs bietet eine um 350 Mal höhere DTU-Computeleistung als eine Datenbank in der Dienstebene „Basic“mit 5 DTUs.

Um einen tieferen Einblick in den Ressourcenverbrauch (DTU) Ihrer Workload zu erhalten, verwenden Sie die Statistik zur Abfrageleistung für die folgenden Aufgaben:

• Ermitteln der häufigsten Abfragen nach den Werten von CPU-Nutzung/Dauer/Ausführungshäufigkeit, bei denen unter Umständen eine Leistungssteigerung erzielt werden kann. Beispielsweise könnte eine E/A-intensive Abfrage von In-Memory-Optimierungstechniken profitieren, um den verfügbaren Arbeitsspeicher in einer bestimmten Dienstebene und einer bestimmten Computegröße besser zu nutzen.
• Analysieren der Details einer Abfrage, um deren Text und deren Verlauf der Ressourcennutzung anzuzeigen.
• Anzeigen von Empfehlungen zur Leistungsoptimierung, die Aktionen von SQL Database Advisor erläutern.

Transaktionseinheiten in elastischer Datenbank (eDTUs)

Diese Datenbanken können in einem Pool für elastische Datenbanken platziert werden, anstatt eine dedizierte Menge von Ressourcen (DTUs) bereitzustellen, die ggf. nicht immer benötigt werden. Datenbanken in einem Pool für elastische Datenbanken verwenden eine einzelne Instanz der Datenbank-Engine und den gleichen Ressourcenpool.

Die gemeinsam genutzten Ressourcen in einem Pool für elastische Datenbanken werden als elastische Datenbanktransaktionseinheiten (elastic Database Transaction Units, eDTUs) gemessen. Pools für elastische Datenbanken stellen eine einfache und kostengünstige Lösung dar, um Leistungsziele für mehrere Datenbanken mit unterschiedlichsten und unvorhersehbaren Nutzungsmustern zu verwalten. Mit einem Pool für elastische Datenbanken wird sichergestellt, dass eine einzelne Datenbank im Pool nicht alle Ressourcen nur für sich nutzen kann, wodurch dafür gesorgt ist, dass jeder Datenbank im Pool immer eine Mindestmenge an erforderlichen Ressourcen zur Verfügung steht.

Ein Pool erhält eine festgelegte Anzahl von eDTUs zu einem festen Preis. Im Pool für elastische Datenbanken können einzelne Datenbanken die automatische Skalierung innerhalb der konfigurierten Grenzen ausführen. Eine Datenbank mit einer höheren Last verbraucht mehr eDTUs, um die Anforderungen zu erfüllen. Datenbanken mit geringerer Last nutzen weniger eDTUs. Datenbanken ohne Auslastung verbrauchen keine eDTUs. Weil Ressourcen für den gesamten Pool statt pro Datenbank bereitgestellt werden, vereinfacht ein Pool für elastische Datenbanken Ihre Verwaltungsaufgaben, und bietet dieser Pool ein vorhersagbares Budget für den Pool.

Sie können einem vorhandenen Pool mit minimaler Downtime der Datenbank weitere eDTUs hinzufügen. Umgekehrt können Sie jederzeit zusätzliche eDTUs, die Sie nicht mehr benötigen, aus einem vorhandenen Pool entfernen. Außerdem können Sie jederzeit Datenbanken zu einem Pool hinzufügen oder aus einem Pool entfernen. Um eDTUs für andere Datenbanken zu reservieren, können Sie die Anzahl von eDTUs begrenzen, die eine Datenbank unter hoher Last verwenden kann. Falls eine Datenbank über eine durchgängig hohe Ressourcenauslastung verfügt, die sich auf andere Datenbanken im Pool auswirkt, verschieben Sie sie aus dem Pool, und konfigurieren Sie sie als Einzeldatenbank mit einer planbaren Menge an erforderlichen Ressourcen.

Workloads, die von einem elastischen Ressourcenpool profitieren

Pools eignen sich sehr gut für Datenbanken mit einer geringen durchschnittlichen Ressourcennutzung und mit relativ seltenen Nutzungsspitzen. Weitere Informationen finden Sie unter Wann sollten Sie einen Pool für elastische SQL-Datenbank-Instanzen erwägen?

Ermitteln der für eine Workload erforderlichen Anzahl von DTUs

Wenn Sie die vorhandene Workload eines lokalen oder virtuellen SQL Server Computers zu SQL-Datenbank migrieren möchten, sehen Sie sich die SKU-Empfehlungen an, um die ungefähre Anzahl benötigter DTUs zu ermitteln. Für eine vorhandene SQL-Datenbank-Workload verwenden Sie die Statistik zur Abfrageleistung, um den Ressourcenverbrauch (DTUs) Ihrer Datenbank zu verstehen und einen tieferen Einblick zur Optimierung Ihrer Workload zu gewinnen. In der dynamischen Verwaltungssicht (Dynamic Management View, DMV) sys.dm_db_resource_stats können Sie den Ressourcenverbrauch der letzten Stunde anzeigen. In der Katalogansicht sys.resource_stats wird der Ressourcenverbrauch der letzten 14 Tage angezeigt. Da hierfür Durchschnittswerte für jeweils fünf Minuten genutzt werden, ist jedoch die Genauigkeit geringer.

Ermitteln der DTU-Nutzung

Verwenden Sie die folgende Formel, um den durchschnittlichen Prozentsatz der DTU-/eDTU-Nutzung in Relation zum DTU-/eDTU-Grenzwert einer Datenbank oder eines Pools für elastische Datenbanken zu bestimmen:

avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)

Die Eingabewerte für diese Formel können aus den DMVs sys.dm_db_resource_stats, sys.resource_stats und sys.elastic_pool_resource_stats abgerufen werden. Anders ausgedrückt: Um den Prozentsatz der DTU-/eDTU-Nutzung für den DTU-/eDTU-Grenzwert einer Datenbank oder eines Pools für elastische Datenbanken zu ermitteln, wählen Sie den größten Prozentwert aus avg_cpu_percent, avg_data_io_percent und avg_log_write_percent zu einem bestimmten Zeitpunkt aus.

Hinweis

Der DTU-Grenzwert einer Datenbank wird durch die für die Datenbank verfügbaren Werte von CPU, Lesevorgängen, Schreibvorgängen und Arbeitsspeicher bestimmt. Da die SQL-Datenbank-Engine jedoch in der Regel den gesamten verfügbaren Arbeitsspeicher für den Datencache verwendet, um die Leistung zu verbessern, liegt der avg_memory_usage_percent-Wert unabhängig von der aktuellen Datenbankauslastung normalerweise nahe bei 100 Prozent. Daher wird der Arbeitsspeicher nicht in der DTU-Nutzungsformel verwendet, obwohl er den DTU-Grenzwert indirekt beeinflusst.

Hardwarekonfiguration

Im DTU-basierten Kaufmodell können Kunden die für ihre Datenbanken verwendete Hardwarekonfiguration nicht auswählen. Während eine bestimmte Datenbank normalerweise für einen längeren Zeitraum (in der Regel mehrere Monate) auf einem bestimmten Hardwaretyp verbleibt, gibt es bestimmte Ereignisse, die dazu führen können, dass eine Datenbank auf andere Hardware verschoben wird.

Beispielsweise kann eine Datenbank auf andere Hardware verschoben werden, wenn sie auf ein anderes Dienstziel hoch- oder herunterskaliert wird, oder aber wenn die aktuelle Infrastruktur in einem Rechenzentrum ihre Kapazitätsgrenzen erreicht oder die aktuell verwendete Hardware aufgrund ihres Lebenszyklus außer Betrieb genommen wird.

Wenn eine Datenbank auf eine andere Hardware verschoben wird, kann sich die Workloadleistung ändern. Das DTU-Modell gewährleistet, dass der Durchsatz und die Reaktionszeit der DTU-Benchmarkworkload im Wesentlichen identisch bleiben, wenn die Datenbank auf einen anderen Hardwaretyp verschoben wird, solange das Dienstziel (die Anzahl der DTUs) unverändert bleibt.

Allerdings können die Auswirkungen der Verwendung unterschiedlicher Hardware für dasselbe Dienstziel über das gesamte Spektrum der in Azure SQL-Datenbank ausgeführten Kundenworkloads ausgeprägter sein. Unterschiedliche Workloads profitieren von unterschiedlichen Hardwarekonfigurationen und -features. Deshalb ist es für andere Workloads als der DTU-Benchmark möglich, Leistungsunterschiede zu erkennen, wenn die Datenbank von einem Hardwaretyp auf einen anderen verschoben wird.

Kunden können das vCore-Modell verwenden, um ihre bevorzugte Hardwarekonfiguration während der Datenbankerstellung und -skalierung auszuwählen. Im vCore-Modell werden detaillierte Ressourcengrenzen für jedes Dienstziel in jeder Hardwarekonfiguration für einzelne Datenbanken und Pools für elastische Datenbanken dokumentiert. Weitere Informationen zur Hardware im vCore-Modell finden Sie unter Hardwarekonfiguration für SQL-Datenbank oder Hardwarekonfiguration für SQL Managed Instance.

Vergleichen der Dienstebenen

Die Auswahl einer Dienstebene hängt in erster Linie von den Anforderungen an Geschäftskontinuität, Speicher und Leistung ab.

	Basic	Standard	Premium
Zielworkload	Entwicklung und Produktion	Entwicklung und Produktion	Entwicklung und Produktion
Betriebszeit-SLA	99,99 %	99,99 %	99,99 %
Backup	Wahl zwischen georedundantem, zonenredundantem oder lokal redundantem Sicherungsspeicher mit einer Aufbewahrungsdauer von 1 bis 7 Tagen (Standardeinstellung: 7 Tage) Langzeitaufbewahrung für bis zu 10 Jahre	Wahl zwischen georedundantem, zonenredundantem oder lokal redundantem Sicherungsspeicher mit einer Aufbewahrungsdauer von 1 bis 35 Tagen (Standardeinstellung: 7 Tage) Langzeitaufbewahrung für bis zu 10 Jahre	Auswahl zwischen lokal redundantem Speicher (LRS), zonenredundantem Speicher (ZRS) oder georedundantem Speicher (GRS) Aufbewahrungsdauer von 1 bis 35 Tagen (standardmäßig 7 Tage) mit bis zu 10 Jahren Langzeitaufbewahrung
CPU	Niedrig	Niedrig, Mittel, Hoch	Mittel, Hoch
IOPS (ungefähr)*	1–4 IOPS pro DTU	1–4 IOPS pro DTU	>25 IOPS pro DTU
E/A-Wartezeit (ungefähr)	5 ms (Lesen), 10 ms (Schreiben)	5 ms (Lesen), 10 ms (Schreiben)	2 ms (Lesen/Schreiben)
Columnstore-Indizierung	–	Standard S3 und höher	Unterstützt
In-Memory-OLTP	–	–	Unterstützt

* Alle Lese- und Schreib-IOPS mit Datendateien, einschließlich Hintergrund-E/A (Prüfpunkt und verzögertes Schreiben)

Wichtig

Die Dienstziele „Basic“, „S0“, „S1“ und „S2“ bieten weniger als einen virtuellen Kern (CPU). Für CPU-intensive Workloads wird ein Dienstziel von S3 oder höher empfohlen.

Bei den Dienstzielen „Basic“, „S0“ und „S1“ werden Datenbankdateien in Azure Storage Standard gespeichert. Dabei kommen Speichermedien mit Festplattenlaufwerken (HDD) zum Einsatz. Diese Dienstziele eignen sich hervorragend für Entwicklungs- und Testaufgaben sowie andere weniger häufig anfallende Workloads, bei denen Leistungsschwankungen keine große Rolle spielen.

Tipp

Für die tatsächlichen Grenzwerte für die Ressourcengovernance einer Datenbank oder eines Pools für elastische Datenbanken fragen Sie die Sicht sys.dm_user_db_resource_governance ab. Für eine einzelne Datenbank wird eine Zeile zurückgegeben. Für eine Datenbank in einem Pool für elastische Datenbanken wird eine Zeile für jede Datenbank im Pool zurückgegeben.

Hinweis

Mit einem kostenlosen Azure-Konto können Sie eine kostenlose Azure SQL-Datenbank mit der Dienstebene „Basic“ erhalten. Weitere Informationen finden Sie unter Mit dem kostenlosen Azure-Konto eine verwaltete Clouddatenbank erstellen.

Ressourceneinschränkungen

Für Einzeldatenbanken und Pooldatenbanken gelten unterschiedliche Ressourcenlimits.

Speichergrenzwerte für Einzeldatenbanken

In Azure SQL-Datenbank werden Computegrößen für Einzeldatenbanken als Datenbanktransaktionseinheiten (DTUs) und für Pools für elastische Datenbanken als elastische Datenbanktransaktionseinheiten (eDTUs) bezeichnet. Weitere Informationen finden Sie unter Ressourcengrenzwerte für Einzeldatenbanken, die das DTU-Kaufmodell verwenden: Azure SQL-Datenbank.

	Basic	Standard	Premium
Maximale Speichergröße	2 GB	1 TB	4 TB
Maximale DTU-Anzahl	5	3000	4000

Wichtig

Unter bestimmten Umständen müssen Sie ggf. eine Datenbank verkleinern, um ungenutzten Speicherplatz freizugeben. Weitere Informationen finden Sie unter Verwalten von Dateispeicherplatz in Azure SQL-Datenbank.

Grenzwerte für Pools für elastische Datenbanken

Weitere Informationen finden Sie unter Grenzwerte für Ressourcen für Pools für elastische Datenbanken, die das DTU-Kaufmodell verwenden.

	Grundlegend	Standard	Premium
Maximale Speichergröße pro Datenbank	2 GB	1 TB	1 TB
Maximale Speichergröße pro Pool	156 GB	4 TB	4 TB
Maximale Anzahl von eDTUs pro Datenbank	5	3000	4000
Maximale Anzahl von eDTUs pro Pool	1600	3000	4000
Maximale Anzahl von Datenbanken pro Pool	500	500	100

Wichtig

In allen Regionen außer den folgenden ist im Premium-Tarif derzeit mehr als 1 TB Speicher verfügbar: China, Osten; China, Norden; Deutschland, Mitte; Deutschland, Nordosten. In diesen Regionen ist der Speicher im Tarif „Premium“ auf 1 TB begrenzt. Weitere Informationen finden Sie unter Einschränkungen von P11 und P15.

Wichtig

Unter bestimmten Umständen müssen Sie ggf. eine Datenbank verkleinern, um ungenutzten Speicherplatz freizugeben. Weitere Informationen finden Sie unter Verwalten von Dateispeicherplatz in Azure SQL-Datenbank.

DTU-Vergleichstest

Physische Merkmale (CPU, Arbeitsspeicher, E/A), die jedem DTU-Measure zugeordnet sind, werden mithilfe eines Vergleichstests kalibriert, der eine realitätsnahe Datenbankworkload simuliert.

Erfahren Sie mehr über das Schema, die verwendeten Transaktionstypen, den Workloadmix, die Benutzer und das Tempo, die Skalierungsregeln und die Metriken im Zusammenhang mit dem DTU-Benchmark.

Vergleichen von DTU-basierten und vCore-Kaufmodellen

Während das DTU-basierte Kaufmodell auf einem gebündelten Maß an Compute-, Speicher- und E/A-Ressourcen basiert, erlaubt das vCore-Kaufmodell für Azure SQL-Datenbank im Vergleich dazu die unabhängige Auswahl und Skalierung von Compute- und Speicherressourcen.

Das vCore-basierte Kaufmodell ermöglicht Ihnen auch die Nutzung des Azure-Hybridvorteils für SQL Server, um Kosten zu sparen, und bietet serverlose und Hyperscale-Optionen für Azure SQL-Datenbank, die im DTU-basierten Kaufmodell nicht verfügbar sind.

Weitere Informationen finden Sie unter vCore- und DTU-basierte Kaufmodelle von Azure SQL-Datenbank im Vergleich.

Nächste Schritte

Weitere Informationen zu Kaufmodellen und verwandten Konzepten finden Sie in den folgenden Artikeln:

• Ausführliche Informationen zu bestimmten Computegrößen und Speichergrößen für Einzeldatenbanken finden Sie unter DTU-basierte Ressourceneinschränkungen in SQL-Datenbank für Einzeldatenbanken.
• Ausführliche Informationen zu Auswahlmöglichkeiten bestimmter Computegrößen und Speichergrößen für Pools für elastische Datenbanken finden Sie unter DTU-basierte Ressourceneinschränkungen in SQL-Datenbank.
• Informationen zu den Benchmarks, die dem DTU-basierten Kaufmodell zugeordnet sind, finden Sie unter DTU-Benchmark.
• vCore- und DTU-basierte Kaufmodelle von Azure SQL-Datenbank im Vergleich.