vCore-Einkaufsmodell – Azure SQL-Datenbank

2025-04-10

In diesem Artikel wird das vCore-Einkaufsmodell für Die Azure SQL-Datenbank überprüft.

Überblick

Ein virtueller Kern (V-Kern) repräsentiert eine logische CPU und bietet Ihnen die Möglichkeit, die physischen Hardwaremerkmale (z. B. Anzahl der Kerne, Arbeitsspeicher und Speichergröße) auszuwählen. Beim vCore-basierten Kaufmodell erhalten Sie Flexibilität, Kontrolle und Transparenz in Bezug auf den individuellen Ressourcenverbrauch. Außerdem können Sie die lokalen Workloadanforderungen leicht auf die Cloud übertragen. Mit diesem Modell wird der Preis optimiert, und Sie können Compute-, Arbeitsspeicher- und Speicherressourcen entsprechend Ihren jeweiligen Workloadanforderungen auswählen.

Im vCore-basierten Kaufmodell hängen Ihre Kosten von der Auswahl und Verwendung der folgenden Elemente ab:

Dienstebene
Hardwarekonfiguration
Computeressourcen (Anzahl von virtuellen Kernen und Arbeitsspeichermenge)
Reservierter Datenbankspeicher
Tatsächlicher Sicherungsspeicher

Wichtig

Rechenressourcen, E/A sowie Daten- und Protokollspeicher werden pro Datenbank oder elastischem Pool berechnet. Der Sicherungsspeicher wird pro Datenbank belastet. Ausführliche Informationen zu Preisen finden Sie auf der Preisseite für Azure SQL-Datenbank.

Vergleich der vCore- und DTU-Einkaufsmodelle

Das von Azure SQL Database verwendete vCore-Einkaufsmodell bietet mehrere Vorteile gegenüber dem DTU-basierten Einkaufsmodell:

Höhere Rechen-, Speicher-, E/A- und Speichergrenzwerte.
Wählen Sie die Hardwarekonfiguration aus, um die Rechen- und Arbeitsspeicheranforderungen der Workload besser abzugleichen.
Preisrabatte mit dem Azure-Hybridvorteil (AHB)
Größere Transparenz in den Hardwaredetails, die die Berechnung ermöglichen, was die Planung von Migrationen aus lokalen Bereitstellungen erleichtert.
Reservierte Instanzenpreise sind nur für das vCore-Einkaufsmodell verfügbar.
Höhere Skalierungsgranularität mit mehreren verfügbaren Rechengrößen.

Hilfe bei der Auswahl zwischen vCore- und DTU-Einkaufsmodellen finden Sie unter den Unterschieden zwischen den vCore- und DTU-basierten Einkaufsmodellen.

Berechnen

Das vCore-basierte Einkaufsmodell verfügt über eine bereitgestellte Computeebene und eine serverlose Computeebene. In der bereitgestellten Computeebene spiegeln die Rechenkosten die gesamte Computekapazität wider, die kontinuierlich für die Anwendung bereitgestellt wird, unabhängig von der Workloadaktivität. Wählen Sie die Ressourcenzuordnung aus, die ihren Geschäftlichen Anforderungen am besten entspricht, basierend auf vCore- und Speicheranforderungen, und skalieren Sie dann Ressourcen nach Bedarf nach Ihren Arbeitsauslastungen nach oben und unten. In der serverlosen Computeebene für die Azure SQL-Datenbank werden Rechenressourcen basierend auf der Arbeitslast automatisch skaliert und pro Sekunde abgerechnet.

Zusammenfassung:

Während die bereitgestellte Computeebene eine bestimmte Menge an Rechenressourcen kontinuierlich bereitstellt, die unabhängig von der Workloadaktivität sind, skaliert die serverlose Computeebene automatisch die Rechenressourcen basierend auf der Workloadaktivität.
Während die bereitgestellte Compute-Ebene für die bereitgestellte Kapazität zu einem festen Preis pro Stunde abgerechnet wird, berechnet die serverlose Compute-Ebene die Kosten nach der Menge der genutzten Rechenleistung pro Sekunde.

Unabhängig von der Computeebene werden automatisch drei zusätzliche sekundäre Replikate für hohe Verfügbarkeit in der Business Critical-Dienstebene zugewiesen, um hohe Resilienz gegen Fehler zu bieten und schnelle Failovers zu ermöglichen. Aufgrund dieser zusätzlichen Replikate sind die Kosten ca. 2,7-mal höher als auf der universellen Dienstebene. Ebenso spiegelt die höheren Speicherkosten pro GB auf der Business Critical-Dienstebene die höheren E/A-Grenzwerte und die geringere Latenz des lokalen SSD-Speichers wider.

In Hyperscale steuern Kunden die Anzahl zusätzlicher Replikate mit hoher Verfügbarkeit von 0 bis 4, um die von ihren Anwendungen erforderliche Resilienzniveau zu erhalten und gleichzeitig Kosten zu steuern.

Weitere Informationen zur Berechnung in der Azure SQL-Datenbank finden Sie unter Computeressourcen (CPU und Arbeitsspeicher).For more information on compute in Azure SQL Database, see Compute resources (CPU and memory).

Ressourcenbeschränkungen

Überprüfen Sie für vCore-Ressourcenbeschränkungen die verfügbaren Hardwarekonfigurationen, und überprüfen Sie dann die Ressourcengrenzwerte für:

Daten- und Protokollspeicher

Die folgenden Faktoren wirken sich darauf aus, wie viel Speicherplatz für Daten- und Protokolldateien verwendet wird. Dies gilt für die Dienstebenen „Universell“ und „Unternehmenskritisch“.

Jede Computegröße unterstützt eine konfigurierbare maximale Datengröße mit einem Standardwert von 32 GB.
Wenn Sie die maximale Datengröße konfigurieren, kommen automatisch 30 Prozent zusätzlicher kostenpflichtiger Speicher für die Protokolldatei hinzu.
In der Service-Ebene „Generell“ wird für tempdb lokaler SSD-Speicher verwendet, und diese Speicherkosten sind im vCore-Preis enthalten.
In der Dienststufe „Unternehmenskritisch“ wird der lokale SSD-Speicher gemeinsam von Daten- und Protokolldateien genutzt, und die Speicherkosten für tempdb sind im vCore-Preis enthalten.
In den Ebenen "Allgemeiner Zweck" und "Geschäftskritisch" werden Sie für die maximale Speichergröße belastet, die für eine Datenbank oder einen elastischen Pool konfiguriert ist.
Für die SQL-Datenbank können Sie eine beliebige maximale Datengröße zwischen 1 GB und der unterstützten Speichergröße in 1-GB-Schritten auswählen.

Die folgenden Speicherüberlegungen gelten für Hyperscale:

Die maximale Datenspeichergröße ist auf 128 TB festgelegt und kann nicht konfiguriert werden.
Sie werden nur für den zugewiesenen Datenspeicher belastet, nicht für maximale Datenspeicherung.
Sie werden nicht für den Protokollspeicher belastet.
tempdb verwendet lokalen SSD-Speicher, und seine Kosten sind im vCore-Preis enthalten. Verwenden Sie zum Überwachen der aktuellen zugewiesenen und verwendeten Datenspeichergröße in der SQL-Datenbank die Azure Monitor-Metriken allocated_data_storage und storage jeweils.

Um die aktuelle zugewiesene und verwendete Speichergröße einzelner Daten und Protokolldateien in einer Datenbank mithilfe von T-SQL zu überwachen, verwenden Sie die sys.database_files Ansicht und die FILEPROPERTY(... , 'SpaceUsed')- Funktion.

Tipp

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.

Sicherungsspeicher

Speicher für Datenbanksicherungen wird zugewiesen, um die Funktionen für die Point-in-Time-Wiederherstellung (PITR) und die langfristige Aufbewahrung (LONG-Term Retention, LTR) der SQL-Datenbank zu unterstützen. Dieser Speicher ist vom Daten- und Protokolldateispeicher getrennt und wird separat abgerechnet.

PITR: In den Ebenen "Allgemeiner Zweck" und "Geschäftskritisch" werden einzelne Datenbanksicherungen automatisch in Azure Storage kopiert. Die Speichergröße wird dynamisch erhöht, wenn neue Sicherungen erstellt werden. Der Speicher wird für vollständige, differenzielle und Transaktionsprotokollsicherungen verwendet. Der Speicherverbrauch richtet sich nach der Änderungsrate der Datenbank und nach dem für Sicherungen konfigurierten Aufbewahrungszeitraum. Sie können einen separaten Aufbewahrungszeitraum für jede Datenbank zwischen 1 und 35 Tagen für die SQL-Datenbank konfigurieren. Eine Sicherungsspeichermenge, die der konfigurierten maximalen Datengröße entspricht, wird ohne Zusatzkosten bereitgestellt.
LTR: Sie können auch eine langfristige Aufbewahrung vollständiger Sicherungen für bis zu 10 Jahre konfigurieren. Wenn Sie eine LTR-Richtlinie einrichten, werden diese Sicherungen automatisch in Azure Blob Storage gespeichert, aber Sie können steuern, wie oft die Sicherungen kopiert werden. Zur Einhaltung unterschiedlicher Konformitätsanforderungen können Sie verschiedene Aufbewahrungszeiträume für wöchentliche, monatliche und/oder jährliche Sicherungen auswählen. Die Menge an Speicher, die für LTR-Sicherungen verwendet wird, richtet sich nach der ausgewählten Konfiguration. Weitere Informationen finden Sie unter Langfristiges Aufbewahren von Sicherungen.

Informationen zum Sicherungsspeicher in Hyperscale finden Sie unter Automatisierte Sicherungen für Hyperscale-Datenbanken.

Dienstebenen

Zu den Dienstebenenoptionen im vCore-Einkaufsmodell gehören "General Purpose", "Business Critical" und "Hyperscale". Die Dienstebene bestimmt in der Regel Speichertyp und Leistung, Optionen für hohe Verfügbarkeit und Notfallwiederherstellung sowie die Verfügbarkeit bestimmter Features wie In-Memory OLTP.

Anwendungsfall	Allgemeiner Zweck	Unternehmenskritisch	Hyperscale-
Am besten geeignet für	Die meisten geschäftlichen Workloads. Bietet budgetorientierte, ausgewogene und skalierbare Compute- und Speicheroptionen.	Bietet Geschäftsanwendungen die höchste Ausfallsicherheit bei Ausfällen durch den Einsatz mehrerer hochverfügbarer sekundärer Replikate und bietet die höchste E/A-Leistung.	Die größte Vielfalt von Workloads, einschließlich dieser Workloads mit hoch skalierbaren Speicher- und Leseanforderungen. Bietet eine höhere Resilienz gegenüber Fehlern, indem die Konfiguration von mehr als einem sekundären Replikat mit hoher Verfügbarkeit ermöglicht wird.
Berechnungsgröße	2 bis 128 virtuelle Kerne	2 bis 128 virtuelle Kerne	2 bis 128 virtuelle Kerne
Speichertyp	Premium-Fernspeicher (pro Instanz)	Äußerst schneller lokaler SSD-Speicher (pro Instanz)	Entkoppelter Speicher mit lokalem SSD-Cache (pro Computereplikat)
Speichergröße	1 GB – 4 TB	1 GB – 4 TB	10 GB – 128 TB
IOPS	320 IOPS pro virtuellem Kern mit maximal 16.000 IOPS	4.000 IOPS pro virtuellem Kern mit maximal 327.680 IOPS	327.680 IOPS mit max. lokaler SSD Hyperscale ist eine mehrstufige Architektur mit Caching auf mehreren Ebenen. Effektive IOPS sind von der Arbeitsauslastung abhängig.
Arbeitsspeicher/vCPU	5,1 GB	5,1 GB	5,1 GB oder 10,2 GB
Sicherungen	Eine Wahl zwischen georedundanten, zonenredundanten oder lokal redundanten Sicherungsspeichern, aufbewahrung von 1 bis 35 Tagen (Standard 7 Tage) Langzeitaufbewahrung für bis zu 10 Jahre	Eine Wahl zwischen georedundanten, zonenredundanten oder lokal redundanten Sicherungsspeichern, aufbewahrung von 1 bis 35 Tagen (Standard 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
Verfügbarkeit	Ein Replikat, keine Replikate mit Leseskalierung, zonenredundante Hochverfügbarkeit (High Availability, HA)	Drei Replikate, ein lesbares Replikat, zonenredundante Hochverfügbarkeit (High Availability, HA)	zonenredundante Hochverfügbarkeit (High Availability, HA)
Preise/Abrechnung	Virtueller Kern, reservierter Speicher und Sicherungsspeicher werden in Rechnung gestellt. IOPS werden nicht in Rechnung gestellt.	Virtueller Kern, reservierter Speicher und Sicherungsspeicher werden in Rechnung gestellt. IOPS werden nicht in Rechnung gestellt.	vCore für jedes Replikat und den verwendeten Speicher wird in Rechnung gestellt. IOPS werden nicht in Rechnung gestellt.
Rabattmodelle	Azure Reservations Azure-Hybridvorteil (nicht verfügbar für Dev/Test-Subscriptions) Enterprise- und Dev/Test Pay-As-You-Go-Abonnements	Azure Reservations Azure-Hybridvorteil (nicht verfügbar für Dev/Test-Subscriptions) Enterprise- und Dev/Test Pay-As-You-Go-Abonnements	Azure-Hybridvorteil (nicht verfügbar für Dev/Test-Abonnements) ¹ Enterprise- und Dev/Test Pay-As-You-Go-Abonnements
In-Memory-OLTP-Tabellen	Nein	Ja	Nein

¹ Vereinfachte Preise für SQL-Datenbank Hyperscale in Kürze verfügbar. Ausführlichere Informationen dazu finden Sie im Hyperscale-Preisblog.

Weitere Informationen erhalten Sie, wenn Sie Ressourcenbeschränkungen für logische Server, einzelne Datenbanken und poolierte Datenbanken überprüfen.

Hinweis

Weitere Informationen zum Service Level Agreement (SLA) finden Sie unter SLA für Azure SQL-Datenbank

Allgemeiner Zweck

Das Architekturmodell für die Dienstebene „Universell“ basiert auf der Trennung von Compute- und Speicherebene. Dieses Architekturmodell beruht auf der Hochverfügbarkeit und Zuverlässigkeit von Azure Blob Storage mit transparenter Replikation von Datenbankdateien und garantiert, dass bei einem Ausfall der zugrunde liegenden Infrastruktur keine Datenverluste auftreten.

In der folgenden Abbildung sind vier Knoten im Architekturmodell des Typs „Standard“ mit getrennter Compute- und Speicherebene dargestellt.

Diagramm zur Veranschaulichung der Trennung von Compute und Speicher.

Das Architekturmodell für die Dienstebene „Universell“ umfasst zwei Ebenen:

Eine zustandslose Computeebene, auf der der Prozess sqlservr.exe ausgeführt wird und die nur temporäre und zwischengespeicherte Daten (z. B. Plancache, Pufferpool, Spaltenspeicherpool) enthält. Dieser zustandslose Knoten wird von der Azure Service Fabric-Plattform gesteuert, die Prozesse initialisiert, die Integrität des Knotens überprüft und bei Bedarf ein Failover an einen anderen Ort durchführt.
Eine zustandsbehaftete Datenebene mit Datenbankdateien (MDF- und LDF-Dateien), die in Azure Blob Storage gespeichert sind. Azure Blob Storage garantiert, dass keine Datensätze verloren gehen, die in einer Datenbankdatei abgelegt werden. Azure Storage verfügt über integrierte Datenverfügbarkeit/Redundanz, die sicherstellt, dass jeder Datensatz in der Protokolldatei oder Seite in der Datendatei beibehalten wird, auch wenn der Prozess abstürzt.

Wenn das Datenbankmodul oder Betriebssystem aktualisiert wird, ein Teil der zugrunde liegenden Infrastruktur fehlschlägt oder ein kritisches Problem im sqlservr.exe Prozess erkannt wird, verschiebt Azure Service Fabric den zustandslosen Prozess in einen anderen zustandslosen Computeknoten. Es gibt eine Reihe von Ersatzknoten, die auf die Ausführung eines neuen Computediensts warten, wenn ein Failover des primären Knotens erfolgt, um die Failoverzeit zu minimieren. Daten in Azure-Speicherebene sind nicht betroffen, und Daten-/Protokolldateien werden an einen neu initialisierten Prozess angefügt. Dieser Prozess garantiert standardmäßig 99,99% Verfügbarkeit und 99,995% Verfügbarkeit, wenn Zonenredundanz aktiviert ist. Aufgrund der Übergangszeit und der Tatsache, dass der neue Knoten mit einem kalten Cache startet, kann es zu Leistungseinbußen bei großen Workloads kommen, die aktuell ausgeführt werden.

Wann man die Dienstebene für allgemeine Zwecke wählen sollte

Die Dienstebene für allgemeine Zwecke ist die Standarddienstebene in der Azure SQL-Datenbank, die für die meisten generischen Workloads entwickelt wurde. Wenn Sie ein vollständig verwaltetes Datenbankmodul mit einer standardmäßigen SLA- und Speicherlatenz zwischen 5 ms und 10 ms benötigen, ist die Stufe "Allgemein" die Option für Sie.

Geschäftskritisch

Das Dienstebenenmodell des Typs „Unternehmenskritisch“ basiert auf einem Cluster von Datenbank-Engine-Prozessen. Dieses Architekturmodell basiert auf einem Quorum von Datenbankmodulknoten, um die Leistungsauswirkungen auf Ihre Arbeitsauslastung zu minimieren, auch während Wartungsaktivitäten. Upgrades und Patches des zugrunde liegenden Betriebssystems, der Treiber und des Datenbankmoduls erfolgen transparent, mit minimaler Down-Time für Endbenutzer.

Im unternehmenskritischen Modell sind die Berechnung und der Speicher für jeden Knoten integriert. Hochverfügbarkeit wird durch Replikation von Daten zwischen Datenbankmodulprozessen auf jedem Knoten eines Vier-Knoten-Clusters erreicht, wobei jeder Knoten lokal angefügte SSD-Datenträger als Datenspeicher verwendet. Das folgende Diagramm zeigt, wie die Business Critical-Dienstebene einen Cluster von Datenbankmodulknoten in Verfügbarkeitsgruppenreplikaten organisiert.

Sowohl der Datenbankmodulprozess als auch die zugrunde liegenden .mdf/.ldf-Dateien werden auf demselben Knoten mit lokal angefügtem SSD-Speicher platziert und bieten eine geringe Latenz für Ihre Workload. Hochverfügbarkeit wird anhand einer ähnlichen Technologie wie AlwaysOn-Verfügbarkeitsgruppen in SQL Server implementiert. Jede Datenbank ist ein Cluster von Datenbankknoten mit einem primären Replikat, auf das für Kundenarbeitslasten zugegriffen werden kann, und drei sekundäre Replikate, die Kopien von Daten enthalten. Das primäre Replikat überträgt ständig Änderungen an die sekundären Replikate, um sicherzustellen, dass die Daten dort verfügbar sind, falls das primäre Replikat aus irgendeinem Grund ausfällt. Failover wird von Service Fabric und dem Datenbankmodul behandelt – ein sekundäres Replikat wird zum primären Replikat, und es wird ein neues sekundäres Replikat erstellt, um sicherzustellen, dass genügend Knoten im Cluster vorhanden sind. Die Workload wird automatisch an das neue primäre Replikat umgeleitet.

Darüber hinaus umfasst der Cluster des Typs „Unternehmenskritisch“ eine integrierte Funktion Horizontale Leseskalierung, die ein gebührenfreies, integriertes und schreibgeschütztes Replikat bereitstellt, das zum Ausführen von schreibgeschützten Abfragen (z. B. Berichten) verwendet werden kann, die die Leistung des primären Replikats nicht beeinträchtigen.

Wann sollte die Dienstebene "Geschäftskritischer Dienst" ausgewählt werden

Die Business Critical-Dienstebene wurde für Anwendungen entwickelt, die eine geringe Latenz bei den Antwortzeiten vom zugrunde liegenden SSD-Speicher (durchschnittlich 1-2 ms) erfordern, schneller wiederhergestellt werden müssen, wenn die zugrunde liegende Infrastruktur ausfällt, oder Berichte, Analysen und schreibgeschützte Abfragen an das kostenlos lesbare sekundäre Replikat der primären Datenbank auslagern möchten.

Die wichtigsten Gründe dafür, dass Sie die Dienstebene „Unternehmenskritisch“ anstelle der Ebene „Universell“ wählen sollten, sind folgende:

Niedrige E/A-Latenzanforderungen – Workloads, die eine konsistente schnelle Antwort von der Speicherschicht (1-2 Millisekunden im Durchschnitt) benötigen, sollten die Business Critical-Ebene verwenden.
Workloads mit Berichterstellungs- und Analyseabfragen eignen sich, wenn ein kostenloses sekundäres schreibgeschütztes Replikat ausreicht.
Höhere Resilienz und schnellere Wiederherstellung nach Fehlern. Falls ein Systemfehler auftritt, wird die Datenbank auf der primären Instanz deaktiviert, und eines der sekundären Replikate wird sofort zur neuen primären Lese-/Schreibdatenbank, die für die Verarbeitung von Abfragen bereit ist.
Erweiterter Schutz vor Datenbeschädigung. Da die Dienstebene „Unternehmenskritisch“ im Hintergrund Datenbankreplikate verwendet, nutzt der Dienst die automatische Seitenreparatur, die mit Spiegelung und Verfügbarkeitsgruppen verfügbar ist, um Datenbeschädigungen zu minimieren. Falls ein Replikat eine Seite aufgrund eines Datenintegritätsproblems nicht lesen kann, wird eine neue Kopie der Seite von einem anderen Replikat abgerufen, die die nicht lesbare Seite ohne Datenverluste oder Ausfallzeiten für die Kundschaft ersetzt. Diese Funktionalität ist auf der Ebene "Allgemeiner Zweck" verfügbar, wenn die Datenbank über ein geo-sekundäres Replikat verfügt.
Höhere Verfügbarkeit: Die Dienstebene „Unternehmenskritisch“ bietet in der Konfiguration mit mehreren Verfügbarkeitszonen Resilienz gegenüber Zonenausfällen und eine SLA mit höherer Verfügbarkeit.
Schnelle Geowiederherstellung – Wenn die aktive Georeplikation konfiguriert ist, verfügt die Business Critical-Stufe über ein garantiertes Wiederherstellungspunktziel (RPO) von 5 Sekunden und RTO (Recovery Time Objective) von 30 Sekunden für 100% der bereitgestellten Stunden.

Hyperskalierung

Die Dienstebene „Hyperscale“ ist für alle Workloadtypen geeignet. Die cloud-native Architektur bietet unabhängig skalierbare Rechen- und Speicherressourcen, um die unterschiedlichsten traditionellen und modernen Anwendungen zu unterstützen. Auf der Dienstebene „Hyperscale“ sind mehr Compute- und Speicherressourcen als auf den Dienstebenen „Universell“ oder „Unternehmenskritisch“ verfügbar.

Weitere Informationen finden Sie auf der Hyperscale-Dienstebene für Azure SQL-Datenbank.

Wann die Hyperscale-Dienstebene ausgewählt werden soll

Die Dienstebene „Hyperscale“ beseitigt viele praktische Einschränkungen, die normalerweise für Clouddatenbanken gelten. Während die meisten anderen Datenbanken durch die auf einem einzelnen Knoten verfügbaren Ressourcen eingeschränkt werden, gelten in der Dienstebene „Hyperscale“ keine solchen Limits. Mit seiner flexiblen Speicherarchitektur wächst eine Hyperscale-Datenbank nach Bedarf – und Sie werden nur für die verwendete Speicherkapazität in Rechnung gestellt.

Neben den erweiterten Skalierungsfunktionen ist Hyperscale eine großartige Option für jede Arbeitsauslastung, nicht nur für große Datenbanken. Mit Hyperscale können Sie:

Erzielen Sie hohe Resilienz und schnelle Fehlerwiederherstellung bei der Kostenkontrolle, indem Sie die Anzahl der Replikate mit hoher Verfügbarkeit von 0 bis 4 auswählen.
Verbessern Sie die hohe Verfügbarkeit , indem Sie Zonenredundanz für Compute und Speicher aktivieren.
Erzielen Sie eine niedrige E/A-Latenz (1-2 Millisekunden im Durchschnitt) für den häufig aufgerufenen Teil Ihrer Datenbank. Bei kleineren Datenbanken kann dies für die gesamte Datenbank gelten.
Implementieren Sie mit benannten Replikaten eine Vielzahl von Szenarien für die horizontale Leseskalierung.
Nutzen Sie die schnelle Skalierung, ohne darauf zu warten, dass Daten auf den lokalen Speicher auf neuen Knoten kopiert werden.
Genießen Sie eine kontinuierliche Datenbanksicherung ohne Beeinträchtigung und schnelle Wiederherstellung.
Unterstützen Sie Geschäftskontinuitätsanforderungen mithilfe von Failovergruppen und Georeplikation.

Hardwarekonfiguration

Zu den gängigen Hardwarekonfigurationen im vCore-Modell gehören Standardserien (Gen5), Premium-Serie, optimierter Speicher der Premium-Serie und DC-Serie. Hyperscale bietet auch eine Option für (arbeitsspeicheroptimierte) Hardware der Premium-Serie. Die Hardwarekonfiguration definiert Compute- und Speicherbeschränkungen und andere Merkmale, die sich auf die Workloadleistung auswirken.

Bestimmte Hardwarekonfigurationen wie Standardreihen (Gen5) können mehr als einen Prozessortyp (CPU) verwenden, wie in Computeressourcen (CPU und Arbeitsspeicher) beschrieben. Während eine bestimmte Datenbank oder ein bestimmter elastischer Pool für längere Zeit auf der Hardware mit demselben CPU-Typ (häufig für mehrere Monate) verbleibt, gibt es bestimmte Ereignisse, die dazu führen können, dass eine Datenbank oder ein Pool auf die Hardware verschoben wird, die einen anderen CPU-Typ verwendet.

Eine Datenbank oder ein Pool kann für eine Vielzahl von Szenarien verschoben werden, einschließlich, aber nicht beschränkt auf folgendes:

Das Dienstziel wird geändert.
Die aktuelle Infrastruktur in einem Rechenzentrum nähert sich kapazitätsgrenzen
Die aktuell verwendete Hardware wird aufgrund des Endes der Lebensdauer außer Betrieb genommen.
Die zonenredundante Konfiguration ist aktiviert und wechselt aufgrund der verfügbaren Kapazität zu einer anderen Hardware.

Bei einigen Workloads kann ein Wechsel zu einem anderen CPU-Typ die Leistung ändern. DIE SQL-Datenbank konfiguriert Hardware mit dem Ziel, eine vorhersehbare Workloadleistung bereitzustellen, auch wenn sich der CPU-Typ ändert, um Leistungsänderungen innerhalb eines schmalen Bandes beizubehalten. Im breiten Spektrum der Kundenarbeitsauslastungen in der SQL-Datenbank und wenn neue CPUs-Typen verfügbar sind, ist es gelegentlich möglich, spürbarere Leistungsänderungen zu sehen, wenn eine Datenbank oder ein Pool zu einem anderen CPU-Typ wechselt.

Unabhängig vom verwendeten CPU-Typ bleiben Ressourcenlimits für eine Datenbank oder einen elastischen Pool (z. B. die Anzahl der Kerne, Arbeitsspeicher, max. Daten-IOPS, max. Protokollrate und max. gleichzeitige Mitarbeiter) gleich, solange die Datenbank auf demselben Dienstziel bleibt.

Rechenressourcen (CPU und Arbeitsspeicher)

In der folgenden Tabelle werden Computeressourcen in verschiedenen Hardwarekonfigurationen und Computeebenen verglichen:

Hardwarekonfiguration	Zentrale Verarbeitungseinheit (CPU)	Gedächtnis
Standard-Serie (Gen5)	Provisioniertes Rechnen - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), Intel® 8272CL (Cascade Lake) 2,5 GHz, Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan) Prozessoren – Bereitstellung von bis zu 128 virtuellen Kernen (mit Hyperthreading) Serverloses Computing* - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), Intel® 8272CL (Cascade Lake) 2,5 GHz, Intel® Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC 7763v (Milan) Prozessoren – Autoskalierung auf bis zu 80 virtuelle Kerne (mit Hyperthreading) – Das Verhältnis von Arbeitsspeicher zu virtuellen Kernen passt sich je nach Workloadbedarf dynamisch an die Arbeitsspeicher- und CPU-Auslastung an und kann bis zu 24 GB pro virtuellem Kern betragen. Beispielsweise kann eine Workload zu einem bestimmten Zeitpunkt 240 GB Arbeitsspeicher und nur 10 vCores verwenden und dafür in Rechnung gestellt werden.	Provisioniertes Rechnen - 5,1 GB pro virtuellem Kern – Bereitstellung von bis zu 625 GB Serverloses Computing - Autoskalierung auf bis zu 24 GB pro virtuellem Kern - Autoskalierung auf bis zu 240 GB
Fsv2-Serie**	- Intel® 8168 (Skylake) Prozessoren - Mit einer anhaltenden Kern-Turbo-Taktgeschwindigkeit von 3,4 GHz und einer maximalen Einzelkern-Turbotaktgeschwindigkeit von 3,7 GHz. – Bereitstellung von bis zu 72 vCores (mit Hyperthreading)	- 1,9 GB pro vCore - Bereitstellung von bis zu 136 GB
DC-Serie	- Intel® Xeon® E-2288G Prozessoren - Verfügt über Intel Software Guard Extension (Intel SGX) – Bereitstellung von bis zu 8 vCores (physisch)	4,5 GB pro vCore

* In der sys.dm_user_db_resource_governance dynamischen Management-Ansicht erscheint die Hardwaregenerierung für Datenbanken mit Intel® SP-8160 (Skylake)-Prozessoren als Gen6, Hardwaregenerierung für Datenbanken mit Intel® 8272CL (Cascade Lake) als Gen7 und Hardwaregenerierung für Datenbanken mit Intel® Case® Platinum 8370C (Ice Lake) oder AMD® EPYC® 7763v (Mailand) als Gen8. Bei einer bestimmten Berechnungsgröße und Hardwarekonfiguration sind Ressourcengrenzwerte unabhängig vom CPU-Typ (Intel Broadwell, Skylake, Ice Lake, Cascade Lake oder AMD Mailand) identisch.

Die Hardware der Fsv2-Serie wird am 1. Oktober 2026 eingestellt.

Weitere Informationen zu Ressourcengrenzwerten für einzelne Datenbanken und elastische Pools finden Sie hier.

Informationen zu Hyperscale-Datenbankberechnungsressourcen und -spezifikationen finden Sie unter Hyperscale-Computeressourcen.

Standard-Serie (Gen5)

Die Hardware der Standardreihe (Gen5) bietet ausgewogene Rechen- und Speicherressourcen und eignet sich für die meisten Datenbankworkloads.

Standard-Serie (Gen5)-Hardware ist in allen öffentlichen Regionen weltweit verfügbar.

Hyperscale Premium-Serie

Hardwareoptionen der Premium-Serie verwenden die neueste CPU- und Speichertechnologie von Intel und AMD. Premium-Serie bietet eine Steigerung der Rechenleistung im Vergleich zur Standard-Serie-Hardware.

Die Option Premium-Serie bietet eine schnellere CPU-Leistung im Vergleich zu Standardserien und einer höheren Anzahl von maximalen vCores.
Die speicherkapazität-optimierte Option der Premium-Serie bietet im Vergleich zur Standardserie doppelt so viel Arbeitsspeicher.

Standardserien-, Premium-Serien- und Premium-Serie optimierter Speicher sind für Hyperscale-elastische Pools verfügbar.

Weitere Informationen finden Sie in der Blogankündigung der Hyperscale Premium-Serie.

Verfügbare Regionen finden Sie unter Verfügbarkeit der Hyperscale Premium-Serie.

DC-Serie

DC-Serie Hardware verwendet Intel-Prozessoren mit Software Guard Extensions (Intel SGX)-Technologie.
DC-Serie ist für Always Encrypted mit sicheren Enklaven-Workloads erforderlich, die einen stärkeren Sicherheitsschutz für Hardwareenklaven im Vergleich zu Virtualisierungsbasierten Sicherheitsenklaven (VBS) erfordern.
DC-Serie wurde für Workloads entwickelt, die vertrauliche Daten verarbeiten und vertrauliche Abfrageverarbeitungsfunktionen erfordern, die von Always Encrypted mit sicheren Enklaven bereitgestellt werden.
Dc-Series-Hardware bietet ausgewogene Compute- und Speicherressourcen.

Die DC-Serie wird nur für bereitgestellte Computeressourcen (und nicht für „serverlos“) unterstützt. Außerdem unterstützt sie keine Zonenredundanz. Regionen, in denen DC-Serie verfügbar ist, finden Sie unter Verfügbarkeit der DC-Serie.

Von der DC-Serie unterstützte Azure-Angebotstypen

Zum Erstellen von Datenbanken oder Pools für elastische Datenbanken auf Hardware der DC-Serie muss das Abonnement ein kostenpflichtiger Angebotstyp sein, einschließlich nutzungsbasierter Zahlung oder Enterprise Agreement (EA). Eine vollständige Liste der von DC-Serie unterstützten Azure-Angebotstypen finden Sie unter aktuelle Angebote ohne Ausgabenbeschränkungen.

Hardwarekonfiguration auswählen

Sie können die Hardwarekonfiguration für eine Datenbank oder einen elastischen Pool in der SQL-Datenbank zum Zeitpunkt der Erstellung auswählen. Sie können auch die Hardwarekonfiguration einer vorhandenen Datenbank oder eines elastischen Pools ändern.

So wählen Sie beim Erstellen einer SQL-Datenbank oder eines SQL-Pools eine Hardwarekonfiguration aus

Ausführliche Informationen finden Sie unter Erstellen einer SQL-Datenbank.

Wählen Sie auf der Registerkarte " Grundlagen " den Link " Datenbank konfigurieren" im Abschnitt " Compute + Storage " aus, und wählen Sie dann den Link "Konfigurationsänderung" aus:

Wählen Sie die gewünschte Hardwarekonfiguration aus:

So ändern Sie die Hardwarekonfiguration einer vorhandenen SQL-Datenbank oder eines vorhandenen Pools

Wählen Sie für eine Datenbank auf der Seite "Übersicht" den Link " Preisebene " aus:

Wählen Sie für einen Pool auf der Seite "Übersicht " die Option "Konfigurieren" aus.

Führen Sie die Schritte aus, um die Konfiguration zu ändern, und wählen Sie die Hardwarekonfiguration aus, wie in den vorherigen Schritten beschrieben.

Hardwareverfügbarkeit

Informationen zur Verfügbarkeit der Hardware der aktuellen Generation finden Sie unter Featureverfügbarkeit nach Region für Azure SQL-Datenbank.

Hardware der vorherigen Generation

Fsv2-Serie

Fsv2-Serie-Hardware für Azure SQL-Datenbank wird am 1. Oktober 2026 eingestellt. Um Dienstunterbrechungen zu minimieren und die Preisleistung aufrechtzuerhalten, wechseln Sie zu Hyperscale Premium-Serie oder Standard-Serie (Gen5)-Hardware. Weitere Informationen finden Sie im Außerbetriebnahmehinweis: FSV2-Serie-Angebot der Azure SQL-Datenbank. Für die meisten Datenbanken und Workloads bieten Hyperscale Premium-Serie oder Standard-Serie (Gen5)-Hardware ähnliche oder bessere Preisleistung als Fsv2. Um sicherzustellen, überprüfen Sie dies bitte mit Ihrer spezifischen Datenbank und Ihren Workloads.

Fsv2 bietet weniger Arbeitsspeicher und tempdb pro vCore als andere Hardware, sodass Workloads, die auf diese Grenzwerte reagieren, bei Standardreihen (Gen5) möglicherweise besser funktionieren.
Fsv2-series wird nur in der Dienstebene „Universell“ unterstützt.

Gen4

Gen4-Hardware wurde eingestellt und steht für Bereitstellung sowie Hoch- oder Herunterskalierung nicht zur Verfügung. Migrieren Sie Ihre Datenbank zu einer unterstützten Hardwaregeneration, um eine größere Bandbreite bei der Skalierbarkeit von virtuellen Kernen und Arbeitsspeicher, beschleunigten Netzwerkbetrieb, optimale E/A-Leistung und minimale Latenz zu erzielen. Überprüfen Sie Hardwareoptionen für einzelne Datenbanken und Hardwareoptionen für elastische Pools. Weitere Informationen finden Sie unter Support-Ende für Gen4-Hardware auf der Azure SQL-Datenbank.

Nächster Schritt

Schnellstart: Erstellen einer Einzeldatenbank – Azure SQL-Datenbank

Freigeben über