Hyperscale-Dienstebene

Gilt für: Azure SQL-Datenbank

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:

• Allgemeiner Zweck‭
• 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.

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 Vergleich der vCore- und DTU-basierten Kaufmodelle – Azure SQL-Datenbank.

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.
• Optimiertes Preis-Leistungs-Verhältnis für eine Gruppe von Hyperscale-Datenbanken mit unterschiedlichen Ressourcenanforderungen mit Pools für elastische Datenbanken.
• Automatischer Speicher mit Unterstützung für eine Datenbank mit bis zu 128 TB oder 100 TB flexible Poolgröße.
• 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.

Preismodell für „Hyperscale“

Hinweis

Vereinfachte Preise für Azure SQL-Datenbank Hyperscale sind da! Überprüfen Sie die neue Preisstufe für Azure SQL-Datenbank Hyperscale-Ankündigung und Details zu Preisänderungen finden Sie unter Azure SQL-Datenbank Hyperscale – niedrigere, vereinfachte Preise!.

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. Benutzer könnten 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 Serverlose Computingebene für Azure SQL-Datenbank.

• 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 128 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.

Architektur mit verteilten Funktionen

Hyperscale trennt das Abfrageverarbeitungsmodul von den Komponenten, die langfristige Speicherung und Dauerhaftigkeit für die Daten bereitstellen. Diese Architektur ermöglicht es Ihnen, die Speicherkapazität so weit wie nötig (bis zu 128 TB) problemlos zu skalieren und auch die Computeressourcen schnell zu skalieren.

Die folgende Abbildung veranschaulicht die funktionale Hyperscale-Architektur:

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.

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 (z. B. bei 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 (z. B. 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.

Pufferpool, ausfallsichere Pufferpoolerweiterung und kontinuierliche Vorbereitung

In Azure Database Hyperscale gibt es eine klare Trennung zwischen Compute und Speicher. Der Speicher enthält alle Datenbankseiten in einer Datenbank und kann auf mehreren Computern zugeordnet werden, wenn die Datenbank wächst. Der Computeknoten speichert jedoch nur zwischen, was kürzlich verwendet wurde. Die heißesten Seiten in der Berechnung werden im Arbeitsspeicher in einer Struktur namens Pufferpool (BP) verwaltet. Sie werden auch auf der lokalen SSD gespeichert, der ausfallsicheren Pufferpoolerweiterung (RBPEX), sodass Daten schneller abgerufen werden können, wenn der Computeprozess neu gestartet wird.

In einem Cloudsystem kann Compute bei Bedarf zu verschiedenen Computern wechseln. Die Computeebene kann über mehrere Replikate verfügen. Eines ist primär und empfängt alle Updates, während andere sekundäre Replikate sind. Im Falle eines primären Fehlers können sekundäre Replikate mit Hochverfügbarkeit schnell höhergestuft werden; dieser Prozess nennt sich Failover. Das sekundäre Replikat verfügt möglicherweise nicht über einen Cache im BP und RBPEX, der für die primäre Workload optimiert ist.

Die kontinuierliche Vorbereitung ist ein Prozess, der Informationen darüber sammelt, welche Seiten in allen Computereplikaten am heißesten sind. Diese Informationen werden aggregiert, und sekundäre Replikate mit Hochverfügbarkeit verwenden die Liste der heißesten Seiten, die der typischen Kundenworkload entsprechen. Auf diese Weise werden sowohl der BP als auch der RBPEX kontinuierlich mit den aktuellsten Seiten gefüllt, um mit den Änderungen der Kundenworkload Schritt zu halten.

Ohne kontinuierliche Vorbereitung werden der BP und RBPEX nicht von neuen Hochverfügbarkeitsreplikaten geerbt und nur während der Benutzerworkload wieder aufgebaut. Die kontinuierliche Vorbereitung spart Zeit und verhindert eine inkonsistente Leistung, da es keine Wartezeit gibt, bevor die Caches wieder vollständig hydriert werden. Mit der kontinuierlichen Vorbereitung beginnen neue sekundäre Replikate mit Hochverfügbarkeit sofort mit der Vorbereitung ihres BP und RBPEX. Dies trägt dazu bei, die Leistung bei Ausfällen konstant zu halten.

Die kontinuierliche Vorbereitung funktioniert in beide Richtungen: Sekundäre Hochverfügbarkeitsreplikate speichern Seiten, die im primären Replikat verwendet werden, und die primären speichern Seiten mit der Workload aus den sekundären Replikaten zwischen.

Hinweis

Die kontinuierliche Vorbereitung befindet sich derzeit in einer Gated Preview und ist für serverlose Datenbanken nicht verfügbar. Weitere Informationen und die Möglichkeit, sich für die kontinuierliche Vorbereitung zu entscheiden, finden Sie im Blog: Hyperscale-Erweiterungen im November 2024.

Sicherung und Wiederherstellung

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 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.

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 auf bis zu 128 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 – 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. Die tatsächlichen IOPS-Werte hängen 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 7 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 7 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 7 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.
Rabattmodelle1	Reservierte Instanzen Azure-Hybridvorteil2 Enterprise- und Dev/Test Pay-As-You-Go-Subscriptions	Reservierte Instanzen Azure-Hybridvorteil2 Enterprise- und Dev/Test Pay-As-You-Go-Subscriptions	Reservierte Instanzen Azure-Hybridvorteil2 Enterprise- und Dev/Test Pay-As-You-Go-Subscriptions

¹ Vereinfachte Preise für SQL-Datenbank-Hyperscale ab Dezember 2023. Ausführlichere Informationen dazu finden Sie im Hyperscale-Preisblog.

² Ab Dezember 2023 ist Azure-Hybridvorteil nicht mehr für neue Hyperscale-Datenbanken oder in Dev-/Test-Subscriptions verfügbar. Bestehende Hyperscale Single-Datenbanken mit bereitgestellter Berechnung können Azure-Hybridvorteil weiterhin nutzen, um bis Dezember 2026 Berechungskosten zu sparen. Weitere Informationen finden Sie im Blog zu den Hyperscale Preisen.

Computeressourcen

Hardwarekonfiguration	CPU	Arbeitsspeicher
Standard-Serie (Gen5)	Bereitgestelltes Computing – Prozessoren: Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1 und AMD EPYC 7763v (Milan) – Bereitstellung von bis zu 80 virtuellen Kernen (mit Hyperthreading) Serverloses Computing: – Prozessoren: Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1 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 ein 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 - Autoskalierung auf bis zu 240 GB
Premium-Serie	– Prozessoren: Intel® Xeon® Platinum 8370C (Ice Lake) und AMD EPYC 7763v (Milan) – Bereitstellung von bis zu 128 virtuellen Kernen (mit Hyperthreading)	- 5,1 GB pro virtuellem Kern
Premium-Serie – Arbeitsspeicheroptimiert	– Prozessoren: Intel® Xeon® Platinum 8370C (Ice Lake) und AMD EPYC 7763v (Milan) – Bereitstellung von bis zu 80 virtuellen Kernen (mit Hyperthreading)	– 10,2 GB pro virtuellem Kern

¹ 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. Und die Hardwaregeneration für Datenbanken mit Intel® Xeon® Platinum 8370C (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.

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. Weitere Informationen finden Sie unter 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.

Verkleinern

Vorgänge zur Verkleinerung von Datenbanken und Dateien befinden sich für Azure SQL-Datenbank Hyperscale derzeit in der Vorschau. Weitere Informationen zur Vorschau finden Sie unter Verkleinern für Azure SQL-Datenbank Hyperscale.

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
Verkleinern wird blockiert, wenn TDE deaktiviert ist.	Derzeit werden Vorgänge zur Verkleinerung von Datenbanken und Dateien nicht unterstützt, wenn die transparente Datenverschlüsselung (Transparent Data Encryption, TDE) in Azure SQL-Datenbank Hyperscale deaktiviert ist.
Wiederherstellen einer Datenbank aus anderen Dienstebenen	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“).
Migration von Datenbanken mit In-Memory-OLTP-Objekten	Hyperscale unterstützt eine Teilmenge von In-Memory-OLTP-Objekten, einschließlich speicheroptimierter Tabellentypen, Tabellenvariablen und systemintern 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.
Datenbankintegritätsprüfung	DBCC CHECKDB wird für Hyperscale-Datenbanken derzeit nicht unterstützt. Als Problemumgehung könnten 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-Serie und arbeitsspeicheroptimierte Hardware der Premium-Serie bietet derzeit keine Unterstützung für den serverlosen Computing-Ebene.
Regionale Verfügbarkeit	Die Hyperscale-Dienstebene ist für die Premium-Serie und die arbeitsspeicheroptimierte Premium-Serie in eingeschränkten Azure-Regionen verfügbar. Eine Liste finden Sie unter Verfügbarkeit der Hyperscale Premium-Serie.

Zugehöriger Inhalt

• Häufig gestellte Fragen zu Hyperscale
• vCore- und DTU-basierte Kaufmodelle von Azure SQL-Datenbank im Vergleich
• Ressourcenverwaltung in Azure SQL-Datenbank
• Ressourcenlimits für Singletons mit dem auf virtuellen Kernen (V-Kernen) basierenden Kaufmodell
• Featurevergleich: Azure SQL-Datenbank und Azure SQL Managed Instance
• Hyperscale-Architektur mit verteilten Funktionen
• Verwalten einer Hyperscale-Datenbank