Hyperscale-Dienstebene

Gilt für:Azure SQL-Datenbank

Azure SQL-Datenbank Hyperscale ist eine kostengünstige, leistungsstarke Clouddatenbank.

Azure SQL-Datenbank basiert auf dem SQL-Datenbank-Engine. Hyperscale unterscheidet sich von anderen Azure SQL-Datenbank Dienstebenen:

  • Im Gegensatz zu anderen Dienstebenen verfügt Hyperscale über keine SQL-Softwarelizenzgebühr, was einen erheblichen Preisvorteil gegenüber anderen Azure SQL-Datenbank Dienstebenen für Hochleistungsdatenbanken bietet.
  • Die Hyperscale-Architektur unterscheidet sich: Sie bietet nahezu sofortige Sicherungen, schnelle Wiederherstellungen und hohen Durchsatz für Lese- und Schreibvorgänge.
  • Hyperscale bietet schnelle Computeskalierung bei Bedarf ohne Datenverschiebung.
  • Strategien zur Leseskalierung sind problemlos möglich: mit bis zu 30 benannten Replikaten mit unabhängig konfigurierbarer Rechenkapazität sowie integrierten Hochverfügbarkeitsreplikaten und konfigurierbaren Georeplikaten weltweit.

Die Dienstebene „Hyperscale“ ist für alle Workloadtypen geeignet. Die Rechen- und Speicherressourcen in Hyperscale übertreffen die in den Azure SQL-Datenbank-Dienstebenen „Universell“ und „Unternehmenskritisch“ verfügbaren Ressourcen bei Weitem.

Sie können eine vorhandene Datenbank in Azure SQL-Datenbank einfach in Hyperscale konvertieren oder von einer beliebigen SQL Server Datenbank zu Hyperscale migrieren. Informationen zum Migrieren anderer Datenbanken zu Azure SQL-Datenbank finden Sie unter Azure Datenbankmigrationshandbücher.

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 Hyperscale-Dienstebene in Azure SQL-Datenbank bietet die folgenden zusätzlichen Funktionen:

  • Schnelles Hochskalieren – Skalieren Sie Ihre Rechenressourcen bei Bedarf hoch, um starke Arbeitslasten zu bewältigen, und skalieren Sie sie anschließend wieder herunter, wenn sie nicht benötigt werden.
  • Schnelles Skalieren – Stellen Sie ein oder mehrere schreibgeschützte Replikate zum Entladen Ihrer Leseauslastung und für die Verwendung als Hot-Standbys bereit.
  • Automatisches Hochskalieren, Herunterskalieren und automatische Abrechnung für Computeressourcen basierend auf dem Verbrauch mit serverlosem Computing
  • Optimiertes Preis-Leistungs-Verhältnis für eine Gruppe von Hyperscale-Datenbanken mit unterschiedlichen Ressourcenanforderungen mit Pools für elastische Datenbanken.
  • Automatische Skalierung des Speichers mit Unterstützung für bis zu 128 TB Datenbank oder 100 TB Größe des Pools für elastische Datenbanken.
  • 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.

Ausführliche Informationen zu den Dienstebenen „Universell“ und „Unternehmenskritisch“ im vCore-basierten Kaufmodell finden Sie in den Dienstebenen Universell und Unternehmenskritisch. Einen Vergleich des vCore-basierten Einkaufsmodells mit dem DTU-basierten Einkaufsmodell finden Sie unter Compare vCore- und DTU-basierte Einkaufsmodelle von Azure SQL-Datenbank.

Wer sollte die Dienstebene „Hyperscale“ in Betracht ziehen?

Die Hyperscale-Dienstebene ist für alle Kunden vorgesehen, die höhere Leistung und Verfügbarkeit, schnelle Sicherung und Wiederherstellung sowie schnelle Speicher- und Computeskalierbarkeit erfordern. Hyperscale ist ideal für Kunden, die in die Cloud wechseln, um ihre Anwendungen zu modernisieren, oder für 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“

Bei Hochleistungsdatenbanken bietet Hyperscale gegenüber anderen Azure SQL-Datenbank Dienstebenen einen erheblichen Preisvorteil. Weitere Informationen finden Sie im Blog: Azure SQL-Datenbank Hyperscale-Preisankündigung von Ignite 2023. Details zu Preisänderungen finden Sie im Blog: Azure SQL-Datenbank Hyperscale – niedrigere, vereinfachte Preise!

Die Hyperscale-Dienstebene ist nur im vCore-Modell verfügbar und wird in zwei Computeebenen bereitgestellt. Die Abrechnung für Hyperscale basiert auf der bereitgestellten oder serverlosen Computeebene:

Sie geben beim Konfigurieren einer Hyperscale-Datenbank nicht die maximale Datengröße an. In der Hyperscale-Ebene bezahlen Sie basierend auf der tatsächlichen Zuordnung für den Speicher. Der Speicher wird automatisch zwischen 10 GB und 128 TB zugewiesen und wächst nach Bedarf. Weitere Informationen finden Sie unter "In welchen Schritten wächst meine Datenbankgröße?"

Skalierungs- und Leistungsvorteile

Hyperscale trennt das Hauptdatenbankmodul von den Komponenten, die eine langfristige Speicherung und Haltbarkeit für die Daten bieten. Diese Architektur ermöglicht es Ihnen, Rechenressourcen schnell und ohne Datenverschiebung zu skalieren und den Speicher (bis zu 128 TB) unabhängig von der Berechnung zu skalieren. Weitere Details, einschließlich eines Architekturdiagramms, finden Sie unter Hyperscale-Architektur.

  • Mit der Möglichkeit, zusätzliche schreibgeschützte Compute-Knoten schnell hoch- und herunterskalieren zu können, ermöglicht die Hyperscale-Architektur eine erhebliche Leseskalierung und kann zudem den primären Compute-Knoten entlasten, damit er mehr Anforderungen verarbeiten kann.
  • Sie können die Rechenkapazität für sekundäre Knoten bereitstellen oder die serverlose Rechenkapazität verwenden. In beiden Fällen können Sie sie aufgrund der gemeinsam genutzten Speicherarchitektur von Hyperscale schnell nach oben oder unten skalieren.
    • Replikate sekundärer Hochverfügbarkeits-Computeknoten in Hyperscale folgen der Compute-Ebene des primären Knotens, was zu Failovern mit geringen Auswirkungen führt.
  • Wenn Sie serverlose, primäre oder sekundäre Computeknoten verwenden, skalieren Sie automatisch basierend auf Ihrer Workloadnachfrage.

Die primäre Azure SQL-Datenbank Hyperscale-Datenbank verarbeitet Lese- und Schreibarbeitslasten, aber Sie können schreibgeschützte Replikate im Rahmen Ihrer Anwendungsstrategie ganz einfach erstellen:

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. einem Wartungsereignis) erstellt das System entweder das neue primäre Replikat vor dem Initiieren eines Failovers oder 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 , um wirkungsvolle Wartungsereignisse vorhersehbar und weniger störend für Ihre Workload zu machen.

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

Pufferpool und ausfallsichere Pufferpoolerweiterung

In Azure Datenbank Hyperscale gibt es eine deutliche Trennung zwischen Rechenleistung und Speicher. Der Speicher enthält alle Datenbankseiten in einer Datenbank und kann mit zunehmender Größe der Datenbank auf mehrere Computer verteilt werden. Der Serverknoten speichert jedoch nur zwischen, was kürzlich verwendet wurde. Die am häufigsten verwendeten Seiten in Compute werden im Arbeitsspeicher in einer Struktur namens Pufferpool (Buffer Pool, BP) gespeichert. Sie werden auch auf der lokalen SSD, der resilienten Pufferpoolerweiterung (RBPEX), gespeichert, sodass Daten bei einem Neustart des Computeprozesses schneller abgerufen werden können.

In einem Cloudsystem kann Compute je nach Bedarf auf verschiedene Computer verlagert werden. Die Computeebene kann mehrere Replikate haben Ein Replikat ist primär und empfängt alle Updates, während die anderen sekundäre Replikate sind. Wenn das primäre Replikat ausfällt, stuft das System eines der sekundären Replikate mit hoher Verfügbarkeit in einem als Failover bezeichneten Prozess zum primären Replikat hoch. Das sekundäre Replikat verfügt möglicherweise nicht über einen Cache in BP und RBPEX, der für die primäre Arbeitslast optimiert ist.

Kontinuierliche Primierung

Kontinuierliches Priming ist ein Prozess, der Informationen darüber sammelt, auf welche Seiten in allen Computereplikaten am häufigsten zugegriffen wird (heißest). Der Prozess aggregiert diese Informationen, und sekundäre Replikate mit hoher Verfügbarkeit verwenden die Liste der heißesten Seiten, die der typischen Kundenarbeitsauslastung entsprechen. Dieser Prozess füllt kontinuierlich sowohl den BP als auch den RBPEX mit den am häufigsten verwendeten Seiten, um mit Änderungen in der Workload des Kunden 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 Leistungsschwankungen, da keine Wartezeiten entstehen, bis die Caches wieder vollständig gefüllt sind. 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 Failovers konsistenter aufrechtzuerhalten.

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

Die kontinuierliche Vorbereitung ist derzeit auf der bereitgestellten Computeebene von Hyperscale verfügbar.

Sichern und Wiederherstellen

Sicherungs- und Wiederherstellungsvorgänge für Hyperscale-Datenbanken basieren auf Dateimomentaufnahmen. Dieser Ansatz macht diese Vorgänge nahezu augenblicklich. Da die Hyperscale-Architektur die Speicherschicht für die Sicherung und Wiederherstellung verwendet, reduziert sie die Verarbeitungslast und die Leistungseinbußen auf computereplikate. Weitere Informationen finden Sie unter Hyperscale-Sicherungen und Speicherredundanz.

Notfallwiederherstellung für Hyperscale-Datenbanken

Führen Sie eine Geowiederherstellung aus, um eine Hyperscale-Datenbank in Azure SQL-Datenbank in einer anderen Region als der Region wiederherzustellen, in der sie derzeit gehostet wird. Diese Methode funktioniert für Notfallwiederherstellungsvorgänge, Drills, Verlagerungen oder andere Gründe. Geowiederherstellung ist nur verfügbar, wenn Sie georedundanten Speicher (RA-GRS) für Speicherredundanz auswählen.

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

Vergleichen von Ressourcengrenzwerten

Die vCore-basierten Dienstebenen unterscheiden sich in der Datenbankverfügbarkeit, dem Speichertyp, der Leistung und der maximalen Speichergröße. In der folgenden Tabelle werden die folgenden Unterschiede beschrieben:

ㅤ Universell Unternehmenskritisch Hyperscale
Am besten geeignet für Budgetorientierte ausgewogene Berechnungs- und Speicheroptionen. OLTP-Anwendungen mit hoher Transaktionsrate und geringen Latenzen bei E/A-Vorgängen. Hohe Resilienz gegenüber Fehlern und schnellen Failovers mithilfe mehrerer Hot-Standby-Replikate. Die empfohlene und standardmäßige Dienstebene für alle neuen und modernisierenden OLTP- und HTAP-Workloads. Am besten geeignet für 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.
Computegröße 2 bis 128 virtuelle Kerne 2 bis 128 virtuelle Kerne 2 bis 192 vCores3
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
Max. IOPS 320 IOPS pro virtuellem Kern mit maximal 16.000 IOPS 4.000 IOPS pro virtuellem Kern mit maximal 327.680 IOPS 5.500 IOPS pro vCore mit maximal 544.000 lokalen SSD-IOPS.
Hyperscale ist eine mehrstufige Architektur mit Caching auf mehreren Ebenen. Effektive IOPS sind von der Arbeitsauslastung abhängig.
Arbeitsspeicher/virtueller Kern 5,1 GB 5,1 GB 5,1 GB oder 10,2 GB
Sicherungen Auswahl zwischen lokal redundantem Speicher (LRS), zonenredundantem Speicher (ZRS) oder georedundantem Speicher (GRS)
Aufbewahrung von 1 bis 35 Tagen (standardmäßig 7 Tage) mit bis zu 10 Jahren langfristiger Aufbewahrung		 Auswahl zwischen lokal redundantem Speicher (LRS), zonenredundantem Speicher (ZRS) oder georedundantem Speicher (GRS)
Aufbewahrung von 1 bis 35 Tagen (standardmäßig 7 Tage) mit bis zu 10 Jahren langfristiger Aufbewahrung		 Auswahl zwischen lokal redundantem Speicher (LRS), zonenredundantem Speicher (ZRS) oder georedundantem Speicher (GRS)
Aufbewahrung von 1 bis 35 Tagen (standardmäßig 7 Tage) mit bis zu 10 Jahren langfristiger Aufbewahrung
Verfügbarkeit Ein Replikat, keine Leseskalierungsreplikate. Zonenredundante Hochverfügbarkeit Drei Replikate, ein read scale-out-Replikat. Zonenredundante Hochverfügbarkeit Mehrere Replikate, bis zu 4 Replikate für die Leseskalierung. Zonenredundante Hochverfügbarkeit
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 Azure-Reservierungen
Azure-Hybridvorteil2
Abonnements von Enterprise- und Dev/Test Pay-As-You-Go-Angeboten		 Azure-Reservierungen
Azure-Hybridvorteil2
Abonnements von Enterprise- und Dev/Test Pay-As-You-Go-Angeboten		 Da Hyperscale keine SQL-Softwarelizenzgebühr1 hat, ist Azure-Hybridvorteil für neue Hyperscale-Datenbanken2 nicht verfügbar.
In-Memory-Tabellen Nein Ja Nein

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

2 Ab Dezember 2023 ist Azure-Hybridvorteil nicht für neue Hyperscale-Datenbanken oder in Entwicklungs-/Testabonnements verfügbar. Vorhandene Einzelne Hyperscale-Datenbanken mit bereitgestellter Berechnung können weiterhin Azure-Hybridvorteil verwenden, um die Berechnungskosten bis Dezember 2026 zu sparen. Weitere Informationen finden Sie im Blog zu den Hyperscale Preisen.

3 Derzeit sind die 160- und 192 vCore-Optionen ein Vorschaufeature.

Computeressourcen

In der folgenden Tabelle werden Computeressourcen in verschiedenen Hardwarekonfigurationen und Computeebenen für Azure SQL-Datenbank Hyperscale verglichen. Informationen zur Nicht-Hyperscale Azure SQL-Datenbank finden Sie unter vCore-Einkaufsmodell – Azure SQL-Datenbank.

Hardwarekonfiguration Prozessor Arbeitsspeicher
Standard-Serie (Gen5) Bereitgestelltes Compute
- 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)*, AMD EPYC 9004 (Genoa)*, Intel® Xeon® Platinum 8573C (Emerald Rapids)* Prozessoren
– Bereitstellung von bis zu 128 vCores (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)*, AMD EPYC 9004 (Genoa)*, Intel® Xeon® Platinum 8573C (Emerald Rapids)* 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.		 Bereitgestelltes Compute
- 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 Bereitgestelltes Compute
- Intel® Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC™ 7763v (Milan)*, AMD EPYC 9004 (Genoa)*, Intel® Xeon® Platinum 8573C (Emerald Rapids)* Prozessoren
- Bereitstellen von bis zu 192 vCores (hyperthreaded).		 5,2 GB pro vCore
Premium-Serie – arbeitsspeicheroptimiert Bereitgestelltes Compute
- Intel® Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC™ 7763v (Milan)*, AMD EPYC 9004 (Genoa)*, Intel® Xeon® Platinum 8573C (Emerald Rapids)* Prozessoren
- Bereitstellung von bis zu 80 vCores (mit Hyper-Threading).		 10,2 GB pro vCore

* Bei einer bestimmten Berechnungsgröße und Hardwarekonfiguration sind Ressourcengrenzwerte unabhängig vom CPU-Typ (Intel® Broadwell, Skylake, Ice Lake, Cascade Lake, Smaragd Rapid oder AMD Mailand, Genoa) identisch. In der sys.dm_user_db_resource_governance dynamischen Verwaltungsansicht verwendet die Hardwaregenerierung für Datenbanken folgendes:

  • Intel® SP-8160 (Skylake) Prozessoren erscheinen als Gen6
  • Intel® 8272CL (Cascade Lake) erscheint als Gen7
  • Intel® Xeon® Platinum 8370C (Ice Lake) oder AMD EPYC™ 7763v (Milan) erscheinen als Gen8
  • AMD EPYC™ 9004 (Genoa) werden als Gen9 dargestellt oder Intel® Xeon® Platinum 8573C (Emerald Rapids) als Gen10.

Informationen finden Sie unter den Ressourcengrenzwerten für Singletons und Pools für elastische Datenbanken.

Erstellen und Verwalten von Hyperscale-Datenbanken

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

Vorgang Details Erfahren Sie mehr
Erstellen einer Hyperscale-Datenbank Hyperscale-Datenbanken sind nur mithilfe des vCore-basierten Einkaufsmodells verfügbar. Hier finden Sie Beispiele zum Erstellen einer Hyperscale-Datenbank in Quickstart: Erstellen einer Hyperscale-Datenbank in Azure SQL-Datenbank.
Konvertieren einer vorhandenen Datenbank in Hyperscale Sie können eine vorhandene Datenbank in die Azure SQL-Datenbank Hyperscale-Ebene konvertieren. Die Konvertierungsdauer hängt von der Größe der Daten ab. Weitere Informationen finden Sie unter Konvertieren einer vorhandenen Datenbank in Hyperscale.
Umgekehrte Migration einer Hyperscale-Datenbank zur Dienstebene „Universell“ Wenn Sie zuvor eine vorhandene Azure SQL-Datenbank zu Hyperscale migriert haben, können Sie die Datenbank innerhalb von 45 Tagen nach der ursprünglichen Migration zu Hyperscale auf die Dienstebene "Allgemein" umstellen.

Wenn Sie die Datenbank zu einer anderen Dienstebene migrieren möchten, z. B. "Geschäftskritisch", führen Sie zuerst eine Umgekehrte Migration zur Dienstebene für allgemeine Zwecke durch, und ändern Sie dann die Dienstebene.		 Erfahren Sie mehr über umgekehrte Migration aus Hyperscale, einschließlich der Einschränkungen für umgekehrte Migration.

Einschränkungen

Diese Einschränkungen gelten derzeit für die Hyperscale-Dienstebene. Das Produktteam arbeitet aktiv daran, so viele dieser Einschränkungen wie möglich zu entfernen.

Problem Beschreibung
Verkleinern wird blockiert, wenn TDE deaktiviert ist Derzeit unterstützt Azure SQL-Datenbank Hyperscale keine Datenbank- und Dateischrumpfvorgänge, wenn Transparent Data Encryption (TDE) deaktiviert ist.
Wiederherstellen einer Datenbank aus anderen Dienstebenen Sie können eine Nicht-Hyperscale-Datenbank nicht als Hyperscale-Datenbank wiederherstellen. Sie können eine Hyperscale-Datenbank auch nicht als Nicht-Hyperscale-Datenbank wiederherstellen.

Bei Datenbanken, die von anderen Azure SQL-Datenbank Dienstebenen zu Hyperscale migriert wurden, werden Sicherungen vor der Migration für die Dauer des Aufbewahrungszeitraums für die Sicherung der Quelldatenbank beibehalten, einschließlich langfristiger Aufbewahrungsrichtlinien. Sie können eine Vormigrationssicherung innerhalb des Sicherungsaufbewahrungszeitraums der Datenbank über die Befehlszeile wiederherstellen. 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. Um eine solche Datenbank zu Hyperscale zu migrieren, müssen Sie alle In-Memory OLTP-Objekte und deren Abhängigkeiten ablegen. Nachdem die Datenbank migriert wurde, können Sie diese Objekte neu erstellen. 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 verwenden DBCC CHECKTABLE ('TableName') WITH TABLOCK und DBCC CHECKFILEGROUP WITH TABLOCK. 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 in der gleichen Weise wie jede andere Datenbank in Azure SQL-Datenbank anvisieren.
Daten-Synchronisation Die Verwendung einer Hyperscale-Datenbank als Hubdatenbank oder als Datenbank für Synchronisierungsmetadaten wird nicht unterstützt. Eine Hyperscale-Datenbank kann jedoch eine Member-Datenbank in einer Data-Sync-Topologie 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 die Dienstebene mit serverlosem Computing. Serverlos wird nur auf Hardware der Standardserie (Gen5) unterstützt.
Regionale Verfügbarkeit Hyperscale-Dienststufe der Premium-Serie und speicheroptimierte Premium-Serie-Hardware sind in begrenzten Azure-Regionen verfügbar. Eine Liste finden Sie unter Verfügbarkeit der Hyperscale Premium-Serie.

Zugehöriger Inhalt

  • Last updated on