Hyperscale-Dienstebene

Artikel
08/21/2023

Azure SQL-Datenbank basiert auf der an die Cloudumgebung angepasste Architektur der SQL Server-Datenbank-Engine, um Hochverfügbarkeit selbst bei Infrastrukturausfällen sicherzustellen. Im vCore-Kaufmodell für Azure SQL-Datenbank gibt es drei Optionen für die Dienstebene:

Universell
Unternehmenskritisch
Hyperscale

Die Dienstebene „Hyperscale“ ist für alle Workloadtypen geeignet. Die cloudnative Architektur bietet unabhängig skalierbare Compute- und Speicherressourcen, um die verschiedensten 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.

Hinweis

Ausführliche Informationen zu den Dienstebenen „Universell“ und „Unternehmenskritisch“ im vCore-basierten Kaufmodell finden Sie in den Dienstebenen Universell und Unternehmenskritisch. Einen Vergleich zwischen vCore-basiertem Kaufmodell und DTU-basiertem Kaufmodell finden Sie unter Kaufmodelle für Azure SQL-Datenbank und Ressourcen.
Die Hyperscale-Dienstebene ist derzeit nur für Azure SQL-Datenbank und nicht für Azure SQL Managed Instance verfügbar.

Welche Funktionen bietet Hyperscale?

Die Dienstebene „Hyperscale“ in Azure SQL-Datenbank bietet folgende zusätzliche Funktionen:

Schnelle Hochskalierung: Sie können Ihre Computeressourcen in konstanter Zeit hochskalieren, um hohe Workloads nach Bedarf zu bewältigen, und anschließend wieder herunterskalieren, sobald sie nicht mehr benötigt werden.
Schnelle Aufskalierung: Sie können ein oder mehrere schreibgeschützte Replikate zum Abladen Ihrer Leseworkload und zur Verwendung als unmittelbar betriebsbereite Standbyserver bereitstellen.
Automatisches Hochskalieren, Herunterskalieren und automatische Abrechnung für Compute basierend auf der Nutzung mit serverlosem Compute (in der Vorschau)
Optimiertes Preis-Leistungs-Verhältnis für eine Gruppe von Hyperscale-Datenbanken mit unterschiedlichen Ressourcenanforderungen mit Pools für elastische Datenbanken (in der Vorschau)
Automatisches Skalieren von Speicher mit Unterstützung von Pools für elastische Datenbanken mit einer Größe von bis zu 100 TB
Höhere Gesamtleistung aufgrund eines höheren Transaktionsprotokolldurchsatzes und schnellerer Transaktionscommits unabhängig von Datenmengen.
Schnelle Datenbanksicherungen (basierend auf Dateimomentaufnahmen) unabhängig von der Größe und ohne E/A-Auswirkung auf Compute-Ressourcen
Schnelle Datenbankwiederherstellungen oder -kopien (basierend auf Dateimomentaufnahmen) in Minuten statt Stunden oder Tagen

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. Aufgrund der flexiblen Speicherarchitektur wächst der Speicher nach Bedarf. Hyperscale-Datenbanken werden ohne Definition einer maximalen Größe erstellt. Eine Hyperscale-Datenbank wächst nach Bedarf – und Ihnen wird nur die tatsächlich verwendete Speicherkapazität in Rechnung gestellt. Für leseintensive Workloads bietet die Dienstebene „Hyperscale“ eine schnelle horizontale Skalierung, indem nach Bedarf zusätzliche Replikate zur Abladung von Leseworkloads bereitgestellt werden.

Darüber hinaus ist die Zeit, die zum Erstellen von Datenbanksicherungen oder zum Hoch- oder Herunterskalieren erforderlich ist, nicht mehr an die Menge der Daten in der Datenbank gebunden. Hyperscale-Datenbanken werden praktisch sofort gesichert. Sie können eine Datenbank auch innerhalb weniger Minuten in Schritten von jeweils 10 Terabyte auf der bereitgestellten Computeebene hoch- oder herunterskalieren oder serverlos verwenden, um Compute automatisch zu skalieren. Durch diese Funktion müssen Sie nicht befürchten, durch Ihre Auswahl bei der Anfangskonfiguration eingeschränkt zu werden.

Weitere Informationen zu den Computegrößen für die Dienstebene „Hyperscale“ finden Sie unter Merkmale der Dienstebene.

Wer sollte die Dienstebene „Hyperscale“ in Betracht ziehen?

Die Dienstebene „Hyperscale“ ist für all jene Kunden geeignet, die eine höhere Leistung und Verfügbarkeit, eine schnelle Sicherung und Wiederherstellung und/oder eine schnelle Skalierbarkeit von Speicher und Compute benötigen. Hierzu zählen Kunden, die zur Modernisierung ihrer Anwendungen in die Cloud wechseln sowie Kunden, die bereits andere Dienstebenen in Azure SQL-Datenbank verwenden. Die Hyperscale-Dienstebene unterstützt eine breite Palette von Datenbankworkloads, von reinem OLTP bis hin zu reinen Analysen. Sie ist für OLTP- und Hybridtransaktions- und Analyseverarbeitungsworkloads (HTAP) optimiert.

Hinweis

Pools für elastische Hyperscale-Datenbanken befinden sich derzeit in der Vorschauphase.

Preismodell für „Hyperscale“

Die Dienstebene „Hyperscale“ ist nur im V-Kern-Modell verfügbar. In Anpassung an die neue Architektur ist das Preismodell etwas anders gestaltet als bei den Dienstebenen „Universell“ oder „Unternehmenskritisch“:

Bereitgestelltes Computing:

Der Preis für Compute-Einheiten bei „Hyperscale“ ist pro Replikat. Der Preis für den Azure-Hybridvorteil wird automatisch auf Hochverfügbarkeits- und benannte Replikate angewandt. Benutzer können die Gesamtzahl der sekundären Replikate mit hoher Verfügbarkeit von 0 bis 4 anpassen, je nach Verfügbarkeits- und Skalierbarkeitsanforderungen, und erstellen Sie bis zu 30 benannte Replikate, um eine Vielzahl von Skalierungs-Workloads zu unterstützen.
Serverloses Computing:

Die Abrechnung für serverloses Computing basiert auf der Nutzung. Weitere Informationen finden Sie unter serverloses Computing.
Storage:

Beim Konfigurieren einer Hyperscale-Datenbank müssen Sie keine maximale Datengröße angeben. Im Hyperscale-Tarif werden Gebühren für den Speicher Ihrer Datenbank basierend auf der tatsächlichen Zuordnung berechnet. Speicher wird automatisch zwischen 10 GB und 100 TB zugewiesen und erhöht sich bei Bedarf in 10-GB-Schritten.

Weitere Informationen zu den Hyperscale-Preisen finden Sie unter Preise für Azure SQL-Datenbank.

Vergleichen von Ressourcengrenzwerten

Die auf virtuellen Kernen basierenden Dienstebenen unterscheiden sich im Hinblick auf Datenbankverfügbarkeit, Speichertyp, Leistung und maximaler Speichergröße. Die Unterschiede werden in der folgenden Tabelle beschrieben:

ㅤ	Allgemeiner Zweck	Unternehmenskritisch	Hyperscale
Am besten geeignet für	Bietet budgetorientierte ausgewogene Compute- und Speicheroptionen.	OLTP-Anwendungen mit hoher Transaktionsrate und geringen Latenzen bei E/A-Vorgängen. Bietet mit mehreren unmittelbar betriebsbereiten Standbyreplikaten hohe Resilienz gegenüber Fehlern und schnelle Failover	Die größte Vielfalt an Workloads Automatische Skalierung der Speichergröße bis zu 100 TB, schnelle vertikale und horizontale Computeskalierung, schnelle Datenbankwiederherstellung.
Computegröße	2 bis 128 virtuelle Kerne	2 bis 128 virtuelle Kerne	2 bis 128 virtuelle Kerne¹
Speichertyp	Storage Premium (remote, 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 bis 100 TB
IOPS	500 IOPS pro virtuellem Kern mit maximal 7.000 IOPS	8.000 IOPS pro virtuellem Kern mit maximal 200.000 IOPS.	327.680 IOPS mit max. lokaler SSD Hyperscale ist eine mehrstufige Architektur mit Caching auf mehreren Ebenen. Der tatsächliche IOPS-Wert hängt von der Workload ab.
Arbeitsspeicher/virtuelle Kerne	5,1 GB	5,1 GB	5.1 GB oder 10.2 GB⁴
Verfügbarkeit	1 Replikat, keine horizontale Leseskalierung, zonenredundante Hochverfügbarkeit	3 Replikate, 1 Replikat mit horizontaler Leseskalierung, zonenredundante Hochverfügbarkeit	Mehrere Replikate, bis zu vier Replikate mit horizontaler Leseskalierung, zonenredundante Hochverfügbarkeit
Sicherungen	Auswahl zwischen lokal redundantem Speicher (LRS), zonenredundantem Speicher (ZRS) oder georedundantem Speicher (GRS) Aufbewahrungsdauer von 1 bis 35 Tagen (standardmäßig sieben Tage) mit bis zu 10 Jahren Langzeitaufbewahrung	Auswahl zwischen lokal redundantem Speicher (LRS), zonenredundantem Speicher (ZRS) oder georedundantem Speicher (GRS) Aufbewahrungsdauer von 1 bis 35 Tagen (standardmäßig sieben Tage) mit bis zu 10 Jahren Langzeitaufbewahrung	Auswahl zwischen lokal redundantem Speicher (LRS), zonenredundantem Speicher (ZRS) oder georedundantem Speicher (GRS) Aufbewahrungsdauer von 1 bis 35 Tagen (standardmäßig sieben Tage)² mit bis zu 10 Jahren Langzeitaufbewahrung³
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.	Virtueller Kern für jedes Replikat, belegter Speicher und Sicherungsspeicher werden in Rechnung gestellt. IOPS werden nicht in Rechnung gestellt.
Rabattmodelle	Reservierte Instanzen Azure-Hybridvorteil (nicht verfügbar für Dev/Test-Abonnements) Enterprise- und Pay-as-you-Go-Dev/Test-Abonnements	Reservierte Instanzen Azure-Hybridvorteil (nicht verfügbar für Dev/Test-Abonnements) Enterprise- und Pay-as-you-Go-Dev/Test-Abonnements	Reservierte Instanzen Azure-Hybridvorteil (nicht verfügbar für Dev/Test-Abonnements) Enterprise- und Pay-as-you-Go-Dev/Test-Abonnements

¹Pools für elastische Hyperscale-Datenbanken befinden sich derzeit in der Vorschauphase. ² Die kurzfristige Sicherungsaufbewahrung für 1 bis 35 Tage für Hyperscale-Datenbanken ist jetzt als Vorschauversion verfügbar.
³ Die Langzeitaufbewahrung für Hyperscale-Datenbanken ist jetzt als Vorschauversion verfügbar.
⁴ 10,2 GB/virtuellem Kern sind mit arbeitsspeicheroptimierter Hardware der Premium-Serie (Vorschau) verfügbar.

Computeressourcen

Hardwarekonfiguration	CPU	Arbeitsspeicher
Standard-Serie (Gen5)	Bereitgestelltes Computing – Prozessoren: Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), Intel® 8272CL (Cascade Lake) 2,5 GHz, Intel® Xeon Platinum 8307C (Ice Lake)* und AMD EPYC 7763v (Milan) – Bereitstellung von bis zu 128 virtuellen Kernen (mit Hyperthreading) Serverloses Computing: – Prozessoren: Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), Intel® 8272CL (Cascade Lake) 2,5 GHz, Intel Xeon® Platinum 8307C (Ice Lake)* und AMD EPYC 7763v (Milan) - 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 virtuelle Kerne verwenden, was entsprechend in Rechnung gestellt wird.	Bereitgestelltes Computing - 5,1 GB pro virtuellem Kern – Bereitstellung von bis zu 625 GB Serverloses Computing: - Autoskalierung auf bis zu 24 GB pro virtuellem Kern – Automatisches Hochskalieren auf bis zu 240 GB
Premium-Serie	– Prozessoren: Intel® Xeon Platinum 8307C (Ice Lake) und AMD EPYC 7763v (Milan)	- 5,1 GB pro virtuellem Kern – Bereitstellung von bis zu 128 virtuellen Kernen (mit Hyperthreading)
Arbeitsspeicheroptimierte Premium-Serie	– Prozessoren: Intel® Xeon Platinum 8307C (Ice Lake) und AMD EPYC 7763v (Milan)	– 10,2 GB pro virtuellem Kern – Bereitstellung von bis zu 80 virtuellen Kernen (mit Hyperthreading)

* In der dynamischen Verwaltungssicht sys.dm_user_db_resource_governance wird die Hardwaregeneration für Datenbanken mit Intel® SP-8160-Prozessoren (Skylake) als „Gen6“ angezeigt. Die Hardwaregeneration für Datenbanken mit Intel® 8272CL-Prozessoren (Cascade Lake) wird als „Gen7“ angezeigt. Die Hardwaregeneration für Datenbanken mit Intel Xeon® Platinum 8307C (Ice Lake) oder AMD® EPYC® 7763v (Milan) wird als „Gen8“ angezeigt. Bei einer bestimmten Computegröße und Hardwarekonfiguration sind die Ressourcengrenzwerte unabhängig vom CPU-Typ identisch. Informationen zu Ressourcengrenzwerten für Singletons finden Sie hier, und Informationen zu Ressourcengrenzwerten für Pools für elastische Datenbanken finden Sie hier.

Serverlos wird nur auf Hardware der Standardserie (Gen5) unterstützt.

Architektur mit verteilten Funktionen

Hyperscale trennt das Abfrageverarbeitungsmodul von den Komponenten, die langfristige Speicherung und Dauerhaftigkeit für die Daten bereitstellen. Diese Architektur bietet die Möglichkeit, die Speicherkapazität problemlos nach Bedarf (ursprüngliches Ziel sind 100 TB) und auch die Computeressourcen schnell zu skalieren.

Die folgende Abbildung veranschaulicht die funktionale Hyperscale-Architektur:

architecture

Erfahren Sie mehr über die Hyperscale-Architektur mit verteilten Funktionen.

Skalierungs- und Leistungsvorteile

Mit der Möglichkeit, weitere Computeknoten schnell hoch- bzw. herunterzufahren, erlaubt die Hyperscale-Architektur eine erhebliche horizontale Leseskalierung und kann außerdem den primären Computeknoten freigeben, um weitere Schreibanforderungen zu verarbeiten. Darüber hinaus können die Computeknoten aufgrund der Hyperscale-Architektur mit freigegebenem Speicher schnell zentral hoch- oder herunterskaliert werden. Schreibgeschützte Computeknoten in Hyperscale sind auch auf der Ebene für serverloses Computing verfügbar, die den Computevorgang automatisch basierend auf der Workloadanforderungen skaliert.

Erstellen und Verwalten von Hyperscale-Datenbanken

Sie können Hyperscale-Datenbanken mithilfe des Azure-Portals, mit Transact-SQL, PowerShell und der Azure CLI erstellen und verwalten. Siehe Schnellstart: Erstellen einer Hyperscale-Datenbank.

Vorgang	Details	Weitere Informationen
Erstellen einer Hyperscale-Datenbank	Hyperscale-Datenbanken stehen nur bei Verwendung des vCore-basierten Kaufmodells zur Verfügung.	Sehen Sie sich Beispiele an, wie Sie eine neue Hyperscale-Datenbank erstellen: Schnellstart: Erstellen einer Hyperscale-Datenbank in Azure SQL-Datenbank.
Ausführen eines Upgrades einer vorhandenen Datenbank auf Hyperscale	Das Migrieren einer vorhandenen Azure SQL-Datenbank-Instanz zur Hyperscale-Ebene ist ein von der Größe der Daten abhängiger Vorgang.	Erfahren Sie mehr über das Migrieren einer vorhandenen Datenbank zu Hyperscale.
Umgekehrte Migration einer Hyperscale-Datenbank zur Dienstebene „Universell“	Wenn Sie zuvor eine vorhandene Azure SQL-Datenbank zur Dienstebene „Hyperscale“ migriert haben, können Sie innerhalb von 45 Tagen nach der ursprünglichen Migration zu Hyperscale eine umgekehrte Migration der Datenbank zur Dienstebene „Universell“ durchführen. Wenn Sie die Datenbank zu einer anderen Dienstebene migrieren möchten, z. B. zu „Unternehmenskritisch“, führen Sie zunächst umgekehrte Migration zur Dienstebene „Universell“ aus, und ändern Sie dann die Dienstebene.	Erfahren Sie mehr über umgekehrte Migration aus Hyperscale, einschließlich der Einschränkungen für umgekehrte Migration.

Hochverfügbarkeit von Datenbanken in Hyperscale

Wie bei allen anderen Dienstebenen gewährleistet Hyperscale die Dauerhaftigkeit von Daten für committete Transaktionen unabhängig von der Verfügbarkeit des Computereplikats. Das Ausmaß der Ausfallzeiten aufgrund der Nichtverfügbarkeit des primären Replikats hängt von der Art des Failovers (geplant oder ungeplant), von einer eventuellen Konfiguration der Zonenredundanz und vom Vorhandensein mindestens eines Replikats mit Hochverfügbarkeit ab. Bei einem geplanten Failover (d. h. einem Wartungsereignis) erstellt das System entweder das neue primäre Replikat, bevor ein Failover initiiert wird, oder es verwendet ein vorhandenes Hochverfügbarkeitsreplikat als Failoverziel. Bei einem ungeplanten Failover (d. h. bei einem Hardwarefehler auf dem primären Replikat) verwendet das System ein Hochverfügbarkeitsreplikat als Failoverziel (sofern vorhanden), oder es erstellt ein neues primäres Replikat aus dem Pool der verfügbaren Computekapazität. Im letzteren Fall ist die Dauer der Ausfallzeit länger, da zusätzliche Schritte erforderlich sind, um das neue primäre Replikat zu erstellen.

Sie können ein Wartungsfenster auswählen, mit dem Sie wirkungsvolle Wartungsereignisse vorhersehbar und weniger störend für Ihre Workload machen können.

Weitere Informationen zur Hyperscale-SLA finden Sie unter SLA für Azure SQL-Datenbank.

Sichern und Wiederherstellen

Sicherungs- und Wiederherstellungsvorgänge für Hyperscale-Datenbanken basieren auf Dateimomentaufnahmen. Dadurch können diese Vorgänge nahezu sofort durchgeführt werden. Da die Hyperscale-Architektur die Speicherebene für Sicherung und Wiederherstellung nutzt, werden die Verarbeitungslast und die Auswirkungen auf die Leistung der Computereplikate erheblich verringert. Weitere Informationen finden Sie unter Hyperscale-Sicherungen und Speicherredundanz.

Notfallwiederherstellung für Hyperscale-Datenbanken

Wenn Sie im Rahmen der Wiederherstellung einer Hyperscale-Datenbank in Azure SQL-Datenbank im Notfall oder im Rahmen einer Übung, wegen eines Umzugs oder aus einem sonstigen Grund in einer anderen Region wiederherstellen müssen als der, in der sie gerade gehostet wird, besteht die primäre Methode in einer Geowiederherstellung der Datenbank. Die Geowiederherstellung ist nur verfügbar, wenn georedundanter Speicher (RA-GRS) für die Speicherredundanz ausgewählt wurde.

Weitere Informationen finden Sie unter Wiederherstellen einer Hyperscale-Datenbank in einer anderen Region.

Bekannte Einschränkungen

Hierbei handelt es sich um die aktuellen Einschränkungen der Hyperscale-Dienstebene. Wir arbeiten daran, möglichst viele dieser Einschränkungen zu beseitigen.

Problem	BESCHREIBUNG
Kurzfristige Sicherungsaufbewahrung	Die kurzfristige Sicherungsaufbewahrung für 1 bis 35 Tage für Hyperscale-Datenbanken ist ab sofort in der Vorschauversion verfügbar. Datenbanken mit einer anderen Dienstebene als Hyperscale können nicht als Hyperscale-Datenbanken wiederhergestellt werden, und eine Hyperscale-Datenbank kann nicht als eine Datenbank mit einer anderen Dienstebene wiederhergestellt werden. Bei Datenbanken, die von anderen Dienstebenen von Azure SQL-Datenbank zu Hyperscale migriert wurden, werden Sicherungen vor der Migration so lange aufbewahrt, wie in der Aufbewahrungsdauer für Sicherungen der Quelldatenbank angegeben (einschließlich Richtlinien für die Langzeitaufbewahrung). Das Wiederherstellen einer Sicherung vor der Migration innerhalb des Aufbewahrungszeitraums für Sicherungen der Datenbank wird über die Befehlszeile unterstützt. Diese Sicherungen können auf jeder beliebigen Dienstebene wiederhergestellt werden (mit Ausnahme von „Hyperscale“).
Langfristiges Aufbewahren von Sicherungen	Die langfristige Sicherungsaufbewahrung für Hyperscale-Datenbanken ist ab sofort in der Vorschauversion verfügbar.
Pools für elastische Datenbanken	Pools für elastische Datenbanken befinden sich jetzt in der Vorschau.
Migration von Datenbanken mit In-Memory-OLTP-Objekten	Hyperscale unterstützt eine Teilmenge der In-Memory-OLTP-Objekte, einschließlich arbeitsspeicheroptimierter Tabellentypen, Tabellenvariablen und nativ kompilierter Module. Wenn aber In-Memory-OLTP-Objekte in der gerade migrierten Datenbank vorhanden sind, wird die Migration von der Dienstebene „Premium“ oder „Unternehmenskritisch“ zu „Hyperscale“ nicht unterstützt. Für die Migration solch einer Datenbank zu Hyperscale müssen alle In-Memory-OLTP-Objekte und deren Abhängigkeiten gelöscht werden. Nachdem die Datenbank migriert wurde, können diese Objekte neu erstellt werden. Arbeitsspeicheroptimierte dauerhafte und nicht dauerhafte Tabellen werden zurzeit in Hyperscale nicht unterstützt und müssen in Datenträgertabellen geändert werden.
Verkleinern der Datenbank	DBCC SHRINKDATABASE, DBCC SHRINKFILE oder die Einstellung von AUTO_SHRINK auf ON auf Datenbankebene werden derzeit nicht für Hyperscale-Datenbanken unterstützt.
Datenbankintegritätsprüfung	DBCC CHECKDB wird für Hyperscale-Datenbanken derzeit nicht unterstützt. Als Problemumgehung können DBCC CHECKTABLE ('TableName') WITH TABLOCK und DBCC CHECKFILEGROUP WITH TABLOCK verwendet werden. Ausführliche Informationen zur Datenintegritätsverwaltung in Azure SQL-Datenbank finden Sie unter Datenintegrität in Azure SQL-Datenbank.
Elastische Aufträge	Die Verwendung einer Hyperscale-Datenbank als Auftragsdatenbank wird nicht unterstützt. Elastische Aufträge können jedoch Hyperscale-Datenbanken auf die gleiche Weise wie jede andere Datenbank in Azure SQL-Datenbank als Ziel verwenden.
Datensynchronisierung	Die Verwendung einer Hyperscale-Datenbank als Hubdatenbank oder als Datenbank für Synchronisierungsmetadaten wird nicht unterstützt. Eine Hyperscale-Datenbank kann jedoch eine Mitgliedsdatenbank in einer Datensynchronisierungstopologie sein.
Hardware der Hyperscale-Dienstebene der Premium-Serie	Hardware der Premium-Serien und speicheroptimierte Hardware der Premium-Serien wird derzeit nicht unterstützt: – Zonenredundanz – Ebene „Serverloses Computing“
Regionale Verfügbarkeit	Die Hyperscale-Dienstebene ist für die Premium-Serie und die arbeitsspeicheroptimierte Premium-Serie in eingeschränkten Azure-RegionRegionen verfügbar: Eine Liste finden Sie unter Verfügbarkeit der Hyperscale Premium-Serie.

Nächste Schritte

Weitere Informationen zu Hyperscale in Azure SQL-Datenbank finden Sie in den folgenden Artikeln:

Häufig gestellte Fragen zu diesem Thema finden Sie unter Häufig gestellte Fragen zu Hyperscale.
Informationen zu Dienstebenen finden Sie unter Verfügbare Leistungsoptionen für eine Azure SQL-Datenbank.
Informationen zu Grenzwerten auf Server- und Abonnementebene finden Sie unter Übersicht über Ressourcenlimits auf einem Server.
Informationen zu Einschränkungen des Kaufmodells für eine Einzeldatenbank finden Sie unter Limits des vCore-basierten Kaufmodells für eine Einzeldatenbank in Azure SQL-Datenbank.
Eine Liste der Features und einen Funktionsvergleich finden Sie unter Allgemeine SQL-Features.
Erfahren Sie mehr über die Hyperscale-Architektur mit verteilten Funktionen.
Erfahren Sie mehr über das Verwalten einer Hyperscale-Datenbank.