Azure SQL-Datenbank Hyperscale – Häufig gestellte Fragen (FAQs)

Gilt für:Azure SQL-Datenbank

Dieser Artikel enthält Antworten auf häufig gestellte Fragen für Kunden, die in Erwägung ziehen, eine Datenbank in Azure SQL-Datenbank mit der Dienstebene „Hyperscale“ zu verwenden, die im weiteren Verlauf dieses Artikels einfach als „Hyperscale“ bezeichnet wird. In diesem Artikel werden die von Hyperscale unterstützten Szenarien und die Features beschrieben, die mit Hyperscale kompatibel sind.

  • Diese FAQs richten sich an Leser, die einen allgemeinen Überblick über die Dienstebene „Hyperscale“ besitzen und auf der Suche nach Antworten auf ihre Fragen und Probleme sind.
  • Diese FAQs sind nicht als Handbuch oder zur Beantwortung von Fragen im Zusammenhang mit der Verwendung einer Hyperscale-Datenbank zu verstehen. Eine Einführung in Hyperscale finden Sie unter Azure SQL-Datenbank hyperscale.

Allgemeine Fragen

Was ist eine Hyperscale-Datenbank?

Eine Hyperscale-Datenbank ist eine Datenbank in der Azure SQL-Datenbank, die von der Hyperscale-Scaleout-Speichertechnologieunterstützt wird. Eine Hyperscale-Datenbank unterstützt bis zu 128 TB Daten, zeichnet sich durch einen hohen Durchsatz sowie eine hohe Leistung aus und bietet eine schnelle Skalierung, um sich rasch an die Workloadanforderungen anzupassen. Konnektivität, Abfrageverarbeitung, Datenbankmodulfeatures usw. funktionieren wie in jeder anderen Datenbank in azure SQL-Datenbank.

Welche Computeebenen und Einkaufsmodelle unterstützen Hyperscale?

Die Hyperscale-Dienstebene ist für einzelne Datenbanken (sowohl bereitgestellt als auch serverlos) und für elastische Pools mit dem vCore-basierten Einkaufsmodell verfügbar. Sie ist im DTU-basierten Kaufmodell nicht verfügbar.

Inwiefern unterscheidet sich die Dienstebene „Hyperscale“ von den Dienstebenen „Universell“ und „Unternehmenskritisch“?

Die auf virtuellen Kernen basierenden Dienstebenen unterscheiden sich im Hinblick auf Datenbankverfügbarkeit, Speichertyp, Leistung und maximaler Speichergröße, wie unter Ressourcengrenzwerte im Vergleich beschrieben.

Wer sollte die Dienstebene „Hyperscale“ verwenden?

Die Dienstebene „Hyperscale“ ist für alle Kunden gedacht, die eine höhere Leistung und Verfügbarkeit, schnelle Backups und Wiederherstellungen, schnellen Speicher und Skalierbarkeit der Datenverarbeitung wünschen. Hierzu zählen Kunden, die klein anfangen und wachsen, Kunden, die große geschäftskritische Datenbanken betreiben, Kunden, die zur Modernisierung ihrer Anwendungen in die Cloud wechseln, sowie Kunden, die bereits andere Dienstebenen in Azure SQL-Datenbank verwenden.

Mit Hyperscale erhalten Sie Folgendes:

  • Datenbankgröße, die von 10 GB bis zu 128 TB wachsen kann, unabhängig von der Berechnungsgröße.
  • Berechnen Sie vCore-Ressourcen von 2 vCores bis zu 192 vCores.
  • Schnelle Datenbanksicherungen unabhängig von der Datenbankgröße (Sicherungen basieren auf Speichermomentaufnahmen)
  • Schnelle Datenbankwiederherstellungen unabhängig von der Datenbankgröße (Wiederherstellungen stammen aus Speichermomentaufnahmen)
  • Höherer Transaktionsprotokolldurchsatz unabhängig von der Datenbankgröße und der Anzahl von vCores.
  • Horizontale Leseskalierung mit einem oder mehreren schreibgeschützten Replikaten, die für das Auslagern schreibgeschützter Workloads oder als unmittelbar betriebsbereite Datenbanken verwendet werden.
  • Schnelles Hochskalieren der Computeleistung in konstanter Zeit, um eine höhere Leistung bei der Verarbeitung umfangreicher Workloads bereitzustellen, und anschließendes Herunterskalieren in konstanter Zeit. Skalierungsvorgänge benötigen im Falle von bereitgestelltem Computing einen Zeitraum im einstelligen Minutenbereich und beim serverlosen Computing weniger als eine Sekunde, und dies unabhängig von der Datenbankgröße.
  • Die Möglichkeit, nach Nutzung zu zahlen mit serverlosem Computing, bei dem die Rechenleistung auf Basis der Nutzung berechnet wird.

Welche Regionen unterstützen derzeit Hyperscale?

Die Dienstebene „Hyperscale“ ist in allen Regionen verfügbar, in denen Azure SQL-Datenbank verfügbar ist.

Können mehrere Hyperscale-Datenbanken pro Server erstellt werden?

Ja. Weitere Informationen und Beschränkungen hinsichtlich der Anzahl von Datenbanken pro Server finden Sie unter Ressourceneinschränkungen in SQL-Datenbank für Einzeldatenbanken und Pooldatenbanken auf einem Server.

Welche Leistungsmerkmale weist eine Hyperscale-Datenbank auf?

Die Hyperscale-Architektur bietet eine hohe Leistung und einen hohen Durchsatz und unterstützt außerdem große Datenbankgrößen.

Was beinhaltet die Skalierbarkeit einer Hyperscale-Datenbank?

Hyperscale bietet schnelle Skalierbarkeit basierend auf Ihrem Workloadbedarf.

  • Hochskalieren/Herunterskalieren

    Bei Hyperscale können Sie die primäre Computegröße im Hinblick auf Ressourcen wie CPU und Arbeitsspeicher in konstanter Zeit hochskalieren und anschließend herunterskalieren. Da der Speicher remote ist, ist die Skalierung nach oben und unten kein Vorgang, der auf die Datengröße beschränkt ist.

    Unterstützung für serverlose Berechnung bietet automatische Skalierung (hoch und runter) und Abrechnung basierend auf der Nutzung.

  • Skalierung nach innen/außen

    Bei Hyperscale können Sie drei Arten von sekundären Replikaten verwenden, um die Anforderungen in Bezug auf die horizontale Leseskalierung, die Hochverfügbarkeit und Georeplikationen zu erfüllen. Dies schließt Folgendes ein:

    • Bis zu vier Hochverfügbarkeitsreplikate mit derselben Computegröße wie die primäre. Diese dienen als Hot-Standbys-Replikate, um schnell ein Failover von der primären Computegröße ausführen zu können. Sie können mit diesen außerdem Leseworkloads von der primären Computegröße auslagern.
    • Bis zu 30 benannte Replikate mit derselben Computegröße wie die primäre oder einer anderen Computegröße als die primäre, um viele Szenarien mit horizontaler Leseskalierung zu bieten.
    • Ein Georeplikat in einer anderen Azure-Region zum Schutz vor regionalen Ausfällen und zur Ermöglichung der geografischen horizontalen Leseskalierung.

KI-Fragen

Ist Azure SQL-Datenbank Hyperscale eine KI-fähige Datenbank?

Ja, Hyperscale unterstützt moderne KI-Anwendungen mit Multimodellfunktionen , die relationale und nicht relationale Daten in derselben Datenbank unterstützen, einschließlich Vektor-, Graph-, JSON- oder XML-, Räumliche Daten- und Schlüsselwertpaare. Mit modernen Cloudanwendungen können Sie die Komplexität mehrerer Plattformen und Programmiersprachen vermeiden.

Unterstützt Azure SQL-Datenbank Hyperscale Vektordaten?

Ja. Die Vektorfunktionen der SQL-Datenbank-Engine sind in Hyperscale-Datenbanken verfügbar. Sie benötigen keinen separaten Vektordatenspeicher. Hyperscale unterstützt das Abfragen von Vektordaten und die Verwendung nativer Vektorsuchfunktionen, einschließlich eines nativen Vektordatentyps für effiziente Abfragen von Vektordaten. Weitere Informationen zum Arbeiten mit systemeigenen T-SQL-Vektorsuchfunktionen finden VECTOR_SEARCHVECTOR_DISTANCESie unter "Vektorsuche" und "Vektorindizes" in der SQL-Datenbank-Engine.

Warum Azure SQL-Datenbank Hyperscale für Retrieval-Augmented Generation (RAG) anstelle eines dedizierten Vektorspeichers verwenden?

Dedizierte Vektorspeicher erfordern, dass Ihre Betriebsdaten auf zwei Systemen dupliziert und synchronisiert werden. Mit Hyperscale leben Vektoren zusammen mit den relationalen Daten, die sie beschreiben. Weitere Informationen finden Sie unter Implementieren von RAG mit Azure OpenAI in der SQL-Datenbank-Engine.

Die nativen Vektordatentyp- und Vektorfunktionen wie semantische Suche direkt in Live-Geschäftsdaten bereitstellen, Datenduplizierung beseitigen, Risiken aus veraltetem Kontext reduzieren und KI-Ergebnisse beschleunigen, ohne neue Plattformen hinzuzufügen.VECTOR_DISTANCE

Sie können relationale und Vektordaten in denselben ACID-konformen Transaktionen verarbeiten, dasselbe Sicherheitsmodell verwenden und alle Daten konsistent mit derselben HA/DR-Lösung schützen.

Ihre Agents können Kontextdaten abrufen und den Status der Transaktion in einem einzigen Roundtrip schreiben, wodurch der Synchronisierungsaufwand entfällt, der zu Latenz führt.

Verfügt Azure SQL-Datenbank Hyperscale über native MCP-Unterstützung für KI-Agents?

Ja, der SQL MCP-Server basiert auf dem Daten-API-Generator. Agents können über HTTP eine Verbindung zu Hyperscale-Daten herstellen, für produktive, cloudgehostete Agent-Bereitstellungen oder stdio für die lokale Entwicklung und CLI-Workflows.

Mit dem SQL MCP-Server können Agents sichere CRUD-Vorgänge ausführen, gespeicherte Prozeduren aufrufen sowie Abfragetabellen und -ansichten – mit vollständiger Protokollierung jedes Toolaufrufs für Überwachungszwecke. Es ist in Microsoft Foundry, GitHub Copilot und alle MCP-kompatiblen Orchestrierungsframeworks integriert.

Welche KI-Agent-Frameworks werden im SQL-Datenbank-Engine unterstützt?

Die neuesten SQL-Datenbank-Engine-Plattformen, einschließlich Azure SQL-Datenbank Hyperscale, verfügen über Integrationen mit den führenden Agentframeworks, darunter:

Wie behandelt Hyperscale die unvorhersehbare, stürmige Art von Agent-Workloads?

Die Kernarchitektur von Hyperscale – entkoppelter Compute und Speicher – wurde für dieses Muster entwickelt. Da es sich bei der Speicherschicht um ein gemeinsam genutztes, verteiltes Page-Server-System handelt, kann die Berechnung ohne Datenverschiebung skaliert werden:

  • Schnelle Skalierung: Das Hoch- oder Herunterskalieren der Rechenkapazität dauert bei bereitgestellten Ressourcen weniger als zehn Minuten und bei serverlosen Ressourcen weniger als eine Sekunde, da keine Daten verschoben werden müssen.
  • Bis zu 30 benannte Lese-Replikate: Verlagern Sie schreibgeschützte Workloads auf Replikate. Jedes benannte Replikat lässt sich mit derselben oder einer anderen Rechenkapazität als der primären Instanz konfigurieren, was eine unabhängige Skalierung der Rechenkapazität für Lese-/Schreib- und schreibgeschützte Vorgänge ermöglicht.

Wie skaliert Hyperscale in leselastigen Agent-Architekturen?

Hyperscale unterstützt bis zu 30 benannte Replikate, jeweils mit konfigurierbarer Rechenleistung. Dies ermöglicht mehrere Muster, die für Multi-Agent-Systeme besonders nützlich sind:

  • Weisen Sie eine oder mehrere Replikate ausschließlich für RAG-Abruf-Workloads zu, sodass die Compute-Kapazität des primären Servers für transaktionale Schreibvorgänge von Agents frei bleibt.
  • Dimensionieren Sie Lese-Replikate unabhängig voneinander – größere Replikate für analytische Abfragen, serverlose Replikate für „spitzenbelastete“ Lese-Workloads, die nur zu bestimmten Tages- oder Monatszeiten auftreten.
  • Leiten Sie gleichzeitige Sub-Agent-Abfragen an verschiedene Replikate weiter, um Ressourcenkonflikte zu vermeiden.
  • Konfigurieren Sie Geo-Replikate in verschiedenen Azure-Regionen für globale, schreibgeschützte Agents-Workloads mit geringer Latenz.

Wie liefert Hyperscale transaktionsale Integrität für Agentanwendungen?

KI-Agenten sind zustandsbehaftete Systeme mit mehrstufiger Schlussfolgerung. Zwischen jedem Schlussfolgerungsschritt schreibt ein Agent einen Zwischenzustand – Aufgabenwarteschlangen, Verlauf der Tool-Aufrufe, Teilergebnisse, Aktualisierungen des Speichers. Fällt ein Schritt während des Schreibvorgangs aus, liest der nächste Schritt möglicherweise einen inkonsistenten oder fehlerhaften Status aus, was zu Fehlinterpretationen oder falschen Entscheidungen führt, die schwer nachzuverfolgen sind. Hyperscale basiert auf der SQL-Datenbank-Engine und auf drei Jahrzehnten Erfahrung mit SQL Server-Transaktionen, einschließlich versionsbasierter Transaktionsisolation, optimistischer Parallelitätskontrolle und automatischer zeitpunktgenauer Wiederherstellung. Dadurch wird sichergestellt, dass der Status des Agenten immer konsistent ist und fehlgeschlagene Schritte keine unvollständigen Schreibvorgänge hinterlassen.

Können KI- und Transaktionsworkloads in derselben Datenbank ausgeführt werden?

Ja, standardmäßig eine einzelne Datenbank.

Wenn die Ressource einer einzelnen Datenbank nicht ausreichend ist, können Sie bis zu 30 benannte Replikate der primären Datenbank zentrale Schreibvorgänge von leseintensiven KI-, Analyse- und Berichtsarbeitslasten isolieren. Jede schreibgeschützte Replik verfügt über eine eigene Verbindungszeichenfolge und eine unabhängige Skalierungskonfiguration. Benannte Repliken bieten integrierte HTAP-Isolation: Die primäre Replik verarbeitet transaktionale Schreibvorgänge von Agents, während dedizierte Leserepliken analytische Abfragen (Extraktion von Trainingsdaten, Telemetrie, Trendberichte) bedienen, ohne um Rechenkapazität zu konkurrieren.

Vertiefende Fragen

Kann ich Hyperscale- und Nicht-Hyperscale-Datenbanken auf demselben logischen SQL-Server kombinieren?

Ja, das ist möglich.

Müssen für Hyperscale Änderungen am Anwendungsprogrammiermodell vorgenommen werden?

Nein, Ihr Anwendungsprogrammiermodell bleibt unverändert wie für alle anderen MS SQL-Datenbanken. Sie verwenden Ihre Verbindungszeichenfolge wie gewohnt und die anderen regulären Modi, um mit Ihrer Hyperscale-Datenbank zu interagieren. Sobald Ihre Anwendung die Hyperscale-Datenbank nutzt, kann Ihre Anwendung Funktionen wie sekundäre Replikate nutzen.

Welche Transaktionsisolationsstufe ist die Standardeinstellung in einer Hyperscale-Datenbank?

Auf dem primären Replikat ist die Standardtransaktionsisolationsstufe READ COMMITTED aktiviert, wobei die Datenbankoption READ_COMMITTED_SNAPSHOT (RCSI) eingeschaltet ist. Auf den sekundären Replikaten wird die Isolationsebene SNAPSHOT. Dies ist dasselbe wie bei jeder anderen Azure SQL-Datenbank.

Kann ich meine lokalen oder IaaS-basierten SQL Server-Lizenzen zu Hyperscale migrieren?

Mit der neuen, vereinfachten Preisgestaltung, die seit dem 15. Dezember 2023 in Kraft ist, wurde der Preis für Compute für neu erstellte Hyperscale-Datenbanken, alle serverlosen Hyperscale-Datenbanken und alle Hyperscale Elastic Pools gesenkt. Mit den neuen, vereinfachten Preisen müssen Sie keinen Azure-Hybridvorteil (AHB) anwenden, um entsprechende Einsparungen zu erhalten. Azure-Hybridvorteil (AHB) kann nur auf ältere (vor dem 15. Dezember 2023 erstellte) Hyperscale-Einzeldatenbanken mit bereitgestellter Berechnung angewendet werden. Für diese älteren Datenbanken gilt die AHB nur bis Dezember 2026, danach werden auch diese Datenbanken nach der neuen, vereinfachten Preisgestaltung abgerechnet.

Weitere Informationen finden Sie im Hyperscale-Preisblog und Azure SQL-Datenbank Hyperscale – niedrigere, vereinfachte Preise.

Für welche Art von Workloads ist Hyperscale konzipiert?

Hyperscale eignet sich gut für alle Workloadtypen, z. B. OLTP, Hybrid (HTAP) und Analyse (Data Mart).

Wie kann ich zwischen Azure Synapse Analytics und Azure SQL-Datenbank Hyperscale wählen?

Wenn Sie derzeit interaktive Analyseabfragen mit SQL Server als Data Warehouse ausführen, stellt Hyperscale eine hervorragende Option dar, weil Sie kleine und mittelgroße Data Warehouses (z. B. von wenigen TB bis hin zu 128 TB) zu geringeren Kosten hosten und Ihre SQL Server Data Warehouse-Workloads mit nur minimalen Änderungen am T-SQL-Code zu Hyperscale migrieren können.

Wenn Sie Datenanalysen in großem Umfang mit komplexen Abfragen und anhaltenden Aufnahmeraten von mehr als 100 MiB/s oder mit Parallel Data Warehouse (PDW), Teradata oder anderen Massively Parallel Processing (MPP)-Data Warehouses wie Azure Synapse Analytics ausführen, könnte Microsoft Fabric die beste Wahl sein.

Die Erfassungs- oder Protokollgenerierungsrate beträgt bei Hardware der Premium-Serie und der speicheroptimierten Premium-Serie in Hyperscale 150 MiB/s pro Datenbank. Für Hardware der Standardreihe beträgt die maximale Protokollrate 100 MiB/s pro Datenbank. Bei elastischen Pools beträgt die maximale Protokollgeschwindigkeit 150 MiB/s pro Pool für speicheroptimierte Hardware der Premium-Serie und 125 MiB/s pro Pool für andere Hardware.

Fragen zu Hyperscale Compute

Kann ich meine Rechenressourcen jederzeit pausieren?

Derzeit leider nicht. Sie können Ihre Computeressourcen und die Anzahl der Replikate jedoch herunterskalieren, um die Kosten außerhalb von Spitzenzeiten zu senken, oder serverloses Computing verwenden, um Compute basierend auf der Nutzung automatisch zu skalieren.

Kann ich ein Computereplikat mit zusätzlichem RAM für meine speicherintensive Workload bereitstellen?

Für Leseworkloads können Sie ein benanntes Replikat mit einer höheren Rechenkapazität (mehr Kerne und Arbeitsspeicher) als das primäre Replikat erstellen. Weitere Informationen zu verfügbaren Computegrößen finden Sie unter Hyperscale – bereitgestellte Computegrößen – Gen5.

Kann ich mehrere Computereplikate unterschiedlicher Größe bereitstellen?

Bei Leseworkloads kann dies mithilfe von benannten Replikaten erreicht werden.

Wie viele Read Scale-out-Replikas werden unterstützt?

Sie können die Anzahl der sekundären Hochverfügbarkeitsreplikate zwischen 0 und 4 über das Azure-Portal oder die REST-API skalieren. Darüber hinaus können Sie bis zu 30 benannte Replikate für viele Szenarien mit horizontaler Leseskalierung erstellen. Jede benannte Replik kann über bis zu 4 HA-Sekundärrepliken verfügen.

Muss ich zur Erzielung von Hochverfügbarkeit zusätzliche Computereplikate bereitstellen?

Bei Hyperscale-Datenbanken wird Datenresilienz auf Speicherebene bereitgestellt. Sie benötigen nur ein Replikat (das primäre), um Resilienz bereitzustellen. Wenn das Computereplikat fehlschlägt oder gewartet wird, wird automatisch ein neues Replikat ohne Datenverlust erstellt.

Wenn es jedoch nur das primäre Replikat gibt, kann es eine oder zwei Minuten dauern, bis ein neues Replikat erstellt wird, im Vergleich zu Sekunden, wenn ein sekundäres HA-Replikat verfügbar ist. Das neue Replikat verfügt zunächst über Caches für kalte Daten, was unmittelbar nach dem Failover möglicherweise zu einer höheren Speicherlatenz und einer geringeren Abfrageleistung führen kann.

Für unternehmenskritische Anwendungen, die eine hohe Verfügbarkeit mit minimalem Failovereffekt erfordern, sollten Sie mindestens ein HA-sekundäres Replikat bereitstellen, um sicherzustellen, dass ein Hot-Standby-Replikat als Failoverziel verfügbar ist.

Fragen zur Datengröße und Speicherkapazität

Welche maximale Datenbankgröße wird mit Hyperscale unterstützt?

Die maximale Größe einer einzelnen Hyperscale-Datenbank beträgt derzeit 128 TB, unabhängig von der Berechnungsgröße. Die maximale Größe einer Datenbank in einem Pool für elastische Hyperscale-Datenbanken beträgt derzeit 100 TB.

Wie groß ist das Transaktionsprotokoll bei Hyperscale?

Das Transaktionsprotokoll in Hyperscale ist praktisch unbegrenzt (mit einer Einschränkung, dass ein aktiver Teil des Protokolls nicht 1 TB überschreiten kann). Der aktive Teil des Protokolls kann aufgrund lang andauernder Transaktionen oder weil die Verarbeitung von Change Data Capture nicht mit der Datenänderungsrate schritthält, wachsen. Vermeiden Sie unnötig lange und große Transaktionen, damit dieser Grenzwert nicht überschritten wird. Abgesehen von dieser Einschränkungen müssen Sie sich keine Gedanken darum machen, dass der Protokollspeicherplatz bei einem System mit hohem Protokolldurchsatz ausgeschöpft werden könnte. Die Protokollgenerierungsrate kann jedoch bei kontinuierlichen aggressiven Schreibvorgängen reduziert werden. Die Protokollierungsrate beträgt 150 MiB/s für Hardware der Premium-Series und der Premium-Series Memory Optimized sowie 100 MiB/s für sonstige Hardware.

Skaliert tempdb mit wachsender Datenbank?

Ihre tempdb-Datenbank befindet sich im lokalen SSD-Speicher. Ihre Größe ist proportional zu der Computegröße (der Anzahl von Kernen), die Sie bereitstellen. Die Größe von tempdb ist nicht konfigurierbar und wird für Sie verwaltet. Um die maximale tempdb-Größe für Ihre Datenbank zu ermitteln, siehe Hyperscale-Speicher- und Computegrößen.

Wird die Datenbankgröße automatisch skaliert, oder muss ich die Größe von Datendateien verwalten?

Die Datenbankgröße nimmt automatisch zu, je mehr Daten Sie einfügen bzw. erfassen.

Was ist die kleinste Datenbankgröße, die Hyperscale unterstützt?

10 GB. Eine Hyperscale-Datenbank wird mit einer Anfangsgröße von 10 GB erstellt und bei Bedarf wächst.

In welchen Schritten wird die Datenbankgröße erhöht?

Jede Datendatei wächst um mindestens 10 GB. Wenn eine Transaktion mehr als 10 GB neuen Speicherplatz benötigt, wachsen Die Dateien jeweils um 10 GB, jeweils eine Datei, bis die Nachfrage nach neuem Speicher erfüllt ist. Wenn der freie Speicherplatz in den vorhandenen Dateien unter einen Schwellenwert fällt, werden neue Dateien im Hintergrund hinzugefügt. Jede neue Datei ist anfänglich 10 GB groß und wächst nach Bedarf.

Ist der Speicher in Hyperscale lokal oder remote?

In Hyperscale werden Datendateien im Azure-Standardspeicher gespeichert. Daten werden im lokalen SSD-Speicher auf Seitenservern, die sich fern von Computereplikaten befinden, vollständig zwischengespeichert. Außerdem verfügen Computereplikate über Datencaches auf lokalem SSD und im Arbeitsspeicher, damit Daten von Remoteseitenservern seltener abgerufen werden müssen.

Können bei Hyperscale Dateien oder Dateigruppen verwaltet oder definiert werden?

Nein. Datendateien werden automatisch zur Dateigruppe PRIMARY hinzugefügt. Die allgemeinen Gründe für das Erstellen zusätzlicher Dateigruppen gelten nicht in der Hyperscale-Speicherarchitektur oder in der Azure SQL-Datenbank.

Kann für meine Datenbank eine feste Obergrenze für das Datenwachstum festgelegt werden?

Nein.

Wird die Verkleinerung von Datenbanken unterstützt?

Ja, Datenbank- und Dateischrumpfvorgänge werden in Azure SQL-Datenbank Hyperscale unterstützt.

Wird Datenkomprimierung unterstützt?

Ja, genau wie bei jeder anderen Azure SQL-Datenbank. Dazu gehören Zeilen-, Seiten- und Spaltenspeicher Komprimierung.

Werden Daten in einer großen Tabelle auf mehrere Datendateien verteilt?

Ja. Die Datenseiten einer bestimmten Tabelle können auf mehrere Datendateien, die Teil der gleichen Dateigruppe sind, verteilt werden. Bei der MS SQL-Datenbank-Engine kommt eine proportionale Füllstrategie zum Einsatz, um Daten auf Datendateien zu verteilen.

Fragen zur Datenmigration

Können vorhandene Datenbanken in Azure SQL-Datenbank zur Dienstebene „Hyperscale“ migriert werden?

Ja. Für Proof of Concepts (POCs) wird empfohlen, eine Kopie Ihrer Datenbank zu erstellen und die Kopie zu Hyperscale zu migrieren.

Die Zeit zum Verschieben einer vorhandenen Datenbank zu Hyperscale umfasst die Zeit zum Kopieren der Daten und die Zeit zum Wiedergeben der Änderungen, die beim Kopieren von Daten in der Quelldatenbank vorgenommen wurden. Die Zeit für das Kopieren der Daten verhält sich proportional zur Datenmenge. Die Zeit für die Wiedergabe von Änderungen ist kürzer, wenn die Verschiebung während geringer Schreibaktivitäten erfolgt.

Sie können eine vorhandene Azure SQL-Datenbank in Hyperscale im Azure-Portal, azure CLI, PowerShell und Transact-SQL konvertieren. Weitere Informationen finden Sie unter Konvertieren einer vorhandenen Datenbank in Hyperscale.

Umgekehrte Migration zur Dienstebene "Allgemeiner Zweck" ermöglicht Kunden, die kürzlich eine vorhandene Datenbank in der Azure SQL-Datenbank in die Hyperscale-Dienstebene migriert haben, zurückzukehren, sollte Hyperscale ihre Anforderungen nicht erfüllen. Während die umgekehrte Migration durch eine Änderung der Dienstebene eingeleitet wird, handelt es sich im Wesentlichen um einen von der Datengröße abhängigen Vorgang zwischen verschiedenen Architekturen. Ähnlich wie bei der Migration zu Hyperscale geht die umgekehrte Migration schneller vonstatten, wenn sie während eines Zeitraums mit geringer Schreibaktivität durchgeführt wird. Weitere Informationen finden Sie unter Von Hyperscale zurück migrieren.

Kann ich meine Hyperscale-Datenbanken zu anderen Dienstebenen migrieren?

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 zur Dienstebene „Universell“ durchführen. Wenn Sie die Datenbank zu einer anderen Dienstebene migrieren möchten, z. B. Unternehmenskritisch, migrieren Sie zuerst zur Dienstebene Universell zurück, und ändern Sie dann die Dienstebene. Bei der umgekehrten Migration handelt es sich um einen Datenmengenoperation.

Datenbanken, die in der Dienstebene Hyperscale erstellt wurden, können nicht zu anderen Dienstebenen migriert werden.

Erfahren Sie mehr über die umgekehrte Migration aus Hyperscale, einschließlich der Einschränkungen für die umgekehrte Migration und betroffenen Sicherungsrichtlinien.

Müssen bei der Migration zur Dienstebene „Hyperscale“ Einbußen hinsichtlich des Funktionsumfangs in Kauf genommen werden?

Ja, bei einigen Workloads. Einige Azure SQL-Datenbankfeatures werden in Hyperscale nicht unterstützt. Wenn diese Features für Ihre Datenbank aktiviert sind, kann die Migration zu Hyperscale blockiert werden, oder diese Features funktionieren nach der Migration nicht mehr. Ausführlichere Informationen finden Sie unter Bekannte Einschränkungen.

Kann ich meine lokale SQL Server-Datenbank oder meine SQL Server-Datenbank in einem virtuellen Cloudcomputer in Hyperscale verschieben?

Ja. Sie können alle vorhandenen Migrationstechnologien verwenden, um zu Hyperscale zu migrieren, einschließlich Transaktionsreplikation und anderen Technologien zur Datenverschiebung (Massenkopieren, Azure Data Factory, Azure Databricks, SSIS). Lesen Sie auch die Informationen zum Azure Database Migration Service, der viele Migrationsszenarien unterstützt.

Wie lange ist die Downtime bei der Migration aus einer lokalen Umgebung oder der Umgebung eines virtuellen Computers zu Hyperscale, und wie kann ich sie minimieren?

Die Ausfallzeit bei der Migration zu Hyperscale ist identisch mit der Ausfallzeit bei der Migration Ihrer Datenbanken zu anderen Dienstebenen von Azure SQL-Datenbank. Mithilfe von Transaktionsreplikationen können Sie die Ausfallzeit bei der Migration von Datenbanken mit einer Größe von mehreren TB minimieren. Bei sehr großen Datenbanken (über 10 TB) empfiehlt es sich eventuell, den Migrationsvorgang mit ADF, Spark oder anderen Technologien zur Massendatenverschiebung zu implementieren.

Wie lange würde es dauern, bis eine bestimmte Datenmenge zu Hyperscale migriert ist?

Hyperscale ist in der Lage, bis zu 150 MiB/s neuer/geänderter Daten zu verarbeiten. Die Zeit, die benötigt wird, um Daten in Datenbanken innerhalb der Azure SQL-Datenbank zu verschieben, wird jedoch auch durch den verfügbaren Netzwerkdurchsatz, die Quelllesegeschwindigkeit, die Art des Ladens (Massen- vs. zeilenweises Laden) und das angestrebte Service Level der Zieldatenbank beeinflusst.

Können Daten aus Blob Storage gelesen und schnell geladen werden (wie PolyBase in Azure Synapse Analytics)?

Sie können festlegen, dass eine Clientanwendung Daten aus Azure Storage lesen und Daten in eine Hyperscale-Datenbank laden soll (genauso, wie dies bei jeder anderen Datenbank in Azure SQL-Datenbank möglich ist). PolyBase wird in Azure SQL-Datenbank derzeit nicht unterstützt. Verwenden Sie als Alternative zum schnellen Laden Azure Data Factory.

Es ist auch möglich, Daten mithilfe von BULK INSERT oder OPENROWSET aus Azure Blob Store zu lesen: Beispiele für den Massenzugriff auf Daten in Azure Blob Storage.

Wiederherstellungsmodelle mit einfacher oder Bulk-Protokollierung werden in Hyperscale nicht unterstützt. Ein vollständiges Wiederherstellungsmodell ist erforderlich, um eine hohe Verfügbarkeit und eine Wiederherstellung zu einem bestimmten Zeitpunkt bereitzustellen. Allerdings bietet die Hyperscale-Protokollarchitektur im Vergleich zu anderen Dienstebenen für Azure SQL-Datenbank eine bessere Datenerfassungsrate.

Ermöglicht Hyperscale die Bereitstellung mehrerer Knoten für die parallele Erfassung von großen Datenmengen?

Nein. Hyperscale ist eine symmetrische Multiprocessing-Architektur (SMP) und keine massiv parallele Verarbeitung (MPP) oder eine Multi-Master-Architektur. Sie können mehrere Repliken erstellen, um schreibgeschützte Workloads horizontal zu skalieren.

Unterstützt Hyperscale die Migration aus anderen Datenquellen wie Amazon Aurora, MySQL, PostgreSQL, Oracle, DB2 und anderen Datenbankplattformen?

Ja. Azure Database Migration Service unterstützt viele Migrationsszenarien.

Wenn ich eine Datenbank in Hyperscale konvertiert, wann beginnt die Hyperscale-Abrechnung?

Die Hyperscale-Abrechnung beginnt nach einer Konvertierung erst, nachdem der Übernahmevorgang vollständig abgeschlossen ist.

Kann ich bei der Umstellung auf Hyperscale die Unterbrechung bei meiner Datenbank steuern?

Ja. Wenn Sie die Konvertierung starten, haben Sie die Möglichkeit, die Art der Umschaltung anzugeben. Es kann automatisch sein, sobald es bereit ist oder manuell initiiert wird, wenn Sie bereit sind. Weitere Informationen finden Sie unter Konvertieren einer Datenbank in Hyperscale. Sie können die Übernahme manuell über das Azure-Portal, PowerShell, Azure CLI oder T-SQL initiieren. Während des endgültigen Übernahmevorgangs auf Hyperscale erleben Sie nur einen kurzen Zeitraum von Ausfallzeiten, im Allgemeinen weniger als eine Minute.

Fragen zur Geschäftskontinuität und Notfallwiederherstellung

Welche SLAs werden für eine Hyperscale-Datenbank bereitgestellt?

Lesen Sie dazu SLA für Azure SQL-Datenbank. Es wird empfohlen, sekundäre Hochverfügbarkeitsreplikate für kritische Workloads hinzuzufügen. Dies ermöglicht ein schnelleres Failover und reduziert potenzielle Leistungsbeeinträchtigungen unmittelbar nach dem Failover.

Werden Datenbanksicherungen für mich von Azure SQL-Datenbank verwaltet?

Ja.

Unterstützt Hyperscale Verfügbarkeitszonen?

Ja, Hyperscale unterstützt zonenredundante Konfiguration. Mindestens ein sekundäres Hochverfügbarkeitsreplikat und die Nutzung von zonenredundantem oder geozonenreduntantem Speicher sind erforderlich, um die zonenredundante Konfiguration für Hyperscale zu ermöglichen.

Unterstützt Hyperscale elastische Pools?

Ja. Weitere Informationen finden Sie unter Hyperscale-Pools für elastische Datenbanken and Blog: Hyperscale-Pools für elastische Datenbanken sind jetzt allgemein verfügbar.

Wie oft werden Datenbanksicherungen durchgeführt?

Für Hyperscale-Datenbanken sind keine herkömmlichen vollständigen, differenziellen und Transaktionsprotokollsicherungen möglich. Stattdessen werden regelmäßig Speichermomentaufnahmen von Datendateien erstellt, wobei für jede Datei ein separates Momentaufnahmenintervall gilt. Das generierte Transaktionsprotokoll wird für den konfigurierten Aufbewahrungszeitraum im unveränderten Zustand gespeichert. Bei der Wiederherstellung werden relevante Transaktionsprotokolldatensätze auf wiederhergestellte Speichermomentaufnahmen angewendet. Unabhängig vom Momentaufnahmerhythmen führt dies zu einer transaktionskonsensären Datenbank ab dem angegebenen Zeitpunkt innerhalb des Aufbewahrungszeitraums, ohne dass Datenverlust besteht. Die Datenbanksicherung in Hyperscale ist faktisch kontinuierlich.

Unterstützt Hyperscale die Wiederherstellung zu einem bestimmten Zeitpunkt?

Ja.

Was ist das Recovery Point Objective (RPO) bzw. Recovery Time Objective (RTO) für die Wiederherstellung von Datenbanken in Hyperscale?

Die RPO für die Wiederherstellung zu einem bestimmten Zeitpunkt beträgt 0 Min. Die meisten Point-in-Time-Wiederherstellungsvorgänge werden unabhängig von der Datenbankgröße innerhalb von 60 Minuten abgeschlossen. Die Wiederherstellungszeit kann für größere Datenbanken und dann länger sein, wenn für die Datenbank vor und bis zum Wiederherstellungszeitpunkt beträchtliche Schreibaktivitäten aufgetreten sind. Das Ausstellen einer Wiederherstellung nach einer letzten Änderung der Speicherredundanz kann zu längeren Wiederherstellungszeiten führen, da die Wiederherstellung in diesem Fall ein Datengröße-Vorgang sein kann, und die Wiederherstellungszeit kann proportional zur Datenbankgröße sein.

Wirkt sich die Datenbanksicherung auf die Computeleistung auf primären oder sekundären Replikaten aus?

Nein. Sicherungen werden vom Speichersubsystem verwaltet und nutzen Speichermomentaufnahmen. Sie wirken sich nicht auf Benutzerworkloads aus.

Kann ich bei einer Hyperscale-Datenbank eine Geowiederherstellung durchführen?

Ja. Geo-Wiederherstellung wird vollständig unterstützt, wenn georedundanter oder geozonenredundanter Speicher verwendet wird. Georedundanter Speicher ist die Standardeinstellung für neue Datenbanken. Anders als bei der Point-in-Time-Wiederherstellung erfordert die Geowiederherstellung einen datenintensiven Vorgang. Weil Datendateien parallel kopiert werden, hängt die Dauer dieses Vorgangs also hauptsächlich von der Größe der größten Datei in der Datenbank und nicht von der Gesamtgröße der Datenbank ab. Die Geowiederherstellungszeit ist erheblich kürzer, wenn die Datenbank in der Azure-Region wiederhergestellt wird, die mit der Region der Quelldatenbank gekoppelt ist. Weitere Informationen finden Sie unter geo-restore for Azure SQL-Datenbank.

Kann ich die Georeplikation einrichten oder Failovergruppen mit einer Hyperscale-Datenbank verwenden?

Ja. Georeplikation und Failovergruppen können für Hyperscale-Datenbanken eingerichtet werden.

Kann ich eine Hyperscale-Datenbanksicherung auf meinem lokalen Server oder unter SQL Server auf einem virtuellen Computer wiederherstellen?

Nein. Das Speicherformat für Hyperscale-Datenbanken unterscheidet sich von jeder veröffentlichten SQL Server-Version. Dabei steuern Sie keine Sicherungen und können nicht darauf zugreifen. Um Ihre Daten aus einer Hyperscale-Datenbank zu entfernen, können Sie Daten mithilfe von Datenbewegungentechnologien wie Azure Data Factory, Azure Databricks, SSIS usw. extrahieren.

Werden mir Sicherungsspeicherkosten in Hyperscale in Rechnung gestellt?

Ja. Ab dem 4. Mai 2022 werden Sicherungen für alle neuen Datenbanken basierend auf dem verbrauchten Sicherungsspeicher und der ausgewählten Speicherredundanz zu den Preisen berechnet, die auf der Seite Azure SQL-Datenbank – Preise angegeben sind. Bei Hyperscale-Datenbanken, die vor dem 4. Mai 2022 erstellt wurden, werden Sicherungen nur dann berechnet, wenn die Aufbewahrung von Sicherungen auf mehr als sieben Tagen eingestellt ist. Weitere Informationen finden Sie unter Hyperscale-Sicherungen und Speicherredundanz.

Wie kann ich die Größe des Sicherungsspeichers in meiner Hyperscale-Datenbank ermitteln?

Ausführliche Informationen zum Messen der Größe des Sicherungsspeichers finden Sie unter Automatisierte Sicherungen.

Wie kann ich den Betrag meiner zu erwartenden Sicherungsrechnung ermitteln?

Um die Höhe Ihrer Sicherungsspeicherrechnung zu ermitteln, wird regelmäßig die Größe des Sicherungsspeichers berechnet und mit dem Sicherungsspeicherpreis und der Anzahl der Stunden seit der letzten Berechnung multipliziert. Um Ihre Sicherungsrechnung für einen bestimmten Zeitraum zu schätzen, multiplizieren Sie die der Rechnung zugrundeliegenden Sicherungsspeichergröße für jede Stunde des Zeitraums mit dem Sicherungsspeicherpreis, und addieren Sie alle Stundenbeträge. Verwenden Sie die REST-API von Azure Monitor, um relevante Azure Monitor-Metriken programmgesteuert für mehrere Stundenintervalle abzufragen. Die Sicherungsabrechnung auf der serverlosen Computingebene ist identisch mit der bereitgestellten Computeebene.

Inwiefern beeinflusst meine Workload meine Sicherungsspeicherkosten?

Die Sicherungskosten sind für Workloads höher, die große Datenmengen in der Datenbank hinzufügen, ändern oder löschen. Umgekehrt haben Workloads, die hauptsächlich Read-Only sind, möglicherweise geringere Sicherungskosten.

Wie kann ich die Sicherungsspeicherkosten minimieren?

Ausführliche Informationen zum Minimieren der Sicherungsspeicherkosten finden Sie unter Automatisierte Sicherungen.

Kann ich meine Hyperscale-Datenbank geografisch auf ein anderes Service-Tier wiederherstellen oder umgekehrt?

Derzeit können Sicherungen von Nicht-Hyperscale-Dienstebenen (Basic/Standard/Premium/General Purpose/Business Critical) nicht in einer Hyperscale-Dienstebene geo-wiederhergestellt werden und umgekehrt. Um eine Datenbank ohne Hyperscale in eine mit Hyperscale zu konvertieren, ändern Sie die Dienstebene nach der Wiederherstellung.

Fragen zur Leistung

Wie viel Schreibdurchsatz kann ich in einer Hyperscale-Datenbank pushen?

Der Durchsatzgrenzwert für Transaktionsprotokolle beträgt 100 MiB/s für jede Hyperscale-Computegröße. Die Möglichkeit zur Erzielung dieser Rate hängt von mehreren Faktoren ab, wie u.a. von Workloadtyp, Clientkonfiguration und -leistung sowie einer ausreichenden Computekapazität im primären Computereplikat, um Protokolldatensätze mit dieser Rate generieren zu können. Die Erfassungsrate oder Protokollgenerierungsrate beträgt 150 MiB/s pro Datenbank für die Premium-Serie und die speicheroptimierte Hardware der Premium-Serie von Azure SQL-Datenbank Hyperscale. Für Hardware der Standardreihe beträgt die maximale Protokollrate 100 MiB/s pro Datenbank. Bei elastischen Pools beträgt die maximale Protokollgeschwindigkeit 150 MiB/s pro Pool für speicheroptimierte Hardware der Premium-Serie und 125 MiB/s pro Pool für andere Hardware.

Wie viele IOPS erhalte ich im größten Computevorgang?

IOPS- und E/A-Latenz variieren je nach Workloadmuster. Wenn die Daten, auf die zugegriffen wird, im lokalen SSD-Speicher des Computereplikats zwischengespeichert sind, wird eine ähnliche IO-Leistung angezeigt wie bei den Serviceebenen Business Critical oder Premium.

Beeinträchtigen Sicherungen meinen Durchsatz?

Nein. Compute ist von der Speicherebene entkoppelt. Dadurch kommt es zu keiner Leistungsbeeinträchtigung bei Sicherungen.

Beeinträchtigt die Bereitstellung zusätzlicher Computereplikate meinen Durchsatz?

Da der Speicher freigegeben ist und keine direkte physische Replikation zwischen primären und sekundären Computereplikaten stattfindet, wird der Durchsatz des primären Replikats nicht direkt durch das Hinzufügen von sekundären Replikaten beeinflusst. Die Protokollierungsrate für kontinuierliche und aggressive Schreib-Workloads kann jedoch auf der primären Instanz begrenzt sein, um die Protokollanwendung auf sekundären Repliken und Seitenservern zu zulassen, damit diese den Rückstand aufholen können. Dadurch werden eine schlechte Leseleistung für sekundäre Replikate und lange Wiederherstellungszeiten nach einem Failover auf ein sekundäres Hochverfügbarkeitsreplikat vermieden.

Eignet sich Hyperscale gut für ressourcen- und zeitintensive Abfragen und Transaktionen?

Ja. Wie in anderen Azure SQL-Datenbanken können Verbindungen jedoch durch sehr seltene vorübergehende Fehler beendet werden, wodurch lange ausgeführte Abfragen abgebrochen und Transaktionen zurückgerollt werden können. Eine Ursache für vorübergehende Fehler ist, wenn das System die Datenbank schnell auf einen anderen Serverknoten verlagert, um die kontinuierliche Verfügbarkeit von Compute- und Speicherressourcen sicherzustellen oder eine geplante Wartung durchzuführen. Die meisten dieser Neukonfigurationsereignisse sind in weniger als zehn Sekunden abgeschlossen. Anwendungen, die eine Verbindung mit Ihrer Datenbank herstellen, sollten so erstellt werden, dass diese seltenen vorübergehenden Fehler erwartet und toleriert werden, indem Wiederholungslogik implementiert wird. Konfigurieren Sie zudem ggf. ein Wartungsfenster, das Ihrem Workloadzeitplan entspricht, um vorübergehende Fehler aufgrund einer geplanten Wartung zu vermeiden.

Wie diagnostiziere und behebe ich Leistungsprobleme in einer Hyperscale-Datenbank?

Bei den meisten Leistungsproblemen gelten häufig verwendete MSSQL-Diagnose- und Problembehandlungsschritte, insbesondere diejenigen, die nicht in der Speicherleistung verwurzelt sind. Informationen zur Hyperscale-spezifischen Speicherdiagnose finden Sie unter Diagnose zur Problembehandlung bei SQL-Hyperscale-Leistungsproblemen.

Wie hoch ist der maximale Arbeitsspeichergrenzwert bei serverlosem im Vergleich zu bereitgestelltem Computing?

Die maximale Arbeitsspeichermenge, auf die eine serverlose Datenbank hochskaliert werden kann, beträgt 3 GB/virtueller Kern, multipliziert mit der maximalen Anzahl von virtuellen Kernen, die konfiguriert wurden, im Vergleich zu mehr als 5 GB/virtueller Kern, multipliziert mit der gleichen Anzahl von virtuellen Kernen in den bereitgestellten Computeressourcen. Details finden Sie unter Grenzwerte für serverlose Hyperscale-Ressourcen.

Wie profitieren Kunden von kontinuierlichem Priming?

Die kontinuierliche Primierung trägt dazu bei, eine höhere RBPEX-Auslastung (Resilient Buffer Pool Extension) aufrechtzuerhalten, was zu einer besseren Leistung führt. Dadurch wird sichergestellt, dass die sekundäre Datenbank immer ohne Verzögerung übernommen werden kann, um Failoverzeiten und die Gesamtsystemzuverlässigkeit zu verbessern.

Welche Computeebenen unterstützen die kontinuierliche Primierung?

Kontinuierliches Priming ist auf der bereitgestellten Hyperscale Compute Tier Premium-Serie Hardware und speicheroptimierter Premium-Serienhardware verfügbar. Die fortlaufende Primierung ist derzeit für die Serverebene ohne Hyperscale-Server nicht verfügbar.

Ist kontinuierliches Priming für benannte Repliken von Vorteil?

Benannte Repliken profitieren nicht von kontinuierlichem Priming.

Fragen zur Skalierbarkeit

Wie lange dauert es, um ein Computereplikat nach oben oder unten zu skalieren?

Das Hoch- oder Herunterskalieren dauert in der bereitgestellten Computeebene in der Regel bis zu 2 Minuten, unabhängig von der Datengröße. In der serverlosen Computeebene, in der Compute basierend auf der Workloadanforderung automatisch skaliert wird, beträgt die Skalierungszeit in der Regel weniger als eine Sekunde, kann aber gelegentlich so lange dauern, wie das Skalieren bereitgestellter Computeressourcen.

Wird meine Datenbank während des Hoch- oder Herunterskalierenvorgangs offline genommen?

Nein. Eine Datenbank bleibt während der Hochskalierung oder Herunterskalierung online.

Ist ein Verbindungsabbruch zu erwarten, wenn die Skalierungsvorgänge im Gange sind?

Das Hoch- oder Herunterskalieren der bereitgestellten Rechenkapazität führt dazu, dass Verbindungen getrennt werden, wenn am Ende des Skalierungsvorgangs ein Failover auftritt. Bei serverlosem Computing führt die automatische Skalierung in der Regel nicht dazu, dass eine Verbindung unterbrochen wird. Dies kann jedoch gelegentlich auftreten. Das Hinzufügen oder Entfernen von sekundären Replikaten führt nicht zu Verbindungsabbrüchen auf dem primären Replikat.

Ist die Skalierung der Computereplikate automatisch oder wird dieser Vorgang durch den Endbenutzer ausgelöst?

Die Skalierung bei bereitgestelltem Compute erfolgt durch den Endbenutzer. Automatische Skalierung bei serverlosem Computing wird vom Dienst ausgeführt.

Wächst auch die Größe meiner tempdb-Datenbank und der Compute-SSD-Cache, wenn die Berechnung skaliert wird?

Ja. Die tempdb Datenbank und die SSD-Cache-Größe auf Rechenknoten werden automatisch skaliert, wenn die Anzahl der Kerne erhöht wird. Weitere Informationen finden Sie unter Hyperscale-Speicher- und Compute-Größen.

Kann ich mehrere primäre Computereplikate bereitstellen, wie z. B. ein Multimastersystem, bei dem mehrere primäre Computeköpfe ein höheres Maß an Parallelität ermöglichen?

Nein. Nur das primäre Computereplikat akzeptiert Lese-/Schreibanforderungen. Sekundäre Computereplikate akzeptieren nur Leseanforderungen.

Fragen zur horizontalen Leseskalierung

Welche Arten von sekundären Replikaten (Leseskalierung) sind in Hyperscale verfügbar?

Hyperscale bietet Unterstützung für Hochverfügbarkeitsreplikate, benannte Replikate und Georeplikate. Ausführlichere Informationen finden Sie unter Sekundäre Hyperscale-Replikate.

Wie viele sekundäre HA-Replikate kann ich bereitstellen?

Zwischen 0 und 4. Wenn Sie die Anzahl von Replikaten anpassen möchten, können Sie dies über das Azure-Portal oder die REST-API erledigen.

Wie stelle ich eine Verbindung mit einem sekundären Hochverfügbarkeitsreplikat her?

Sie können eine Verbindung mit diesen zusätzlichen schreibgeschützten Computereplikaten herstellen, indem Sie die Eigenschaft ApplicationIntent in Ihrer Verbindungszeichenfolge auf ReadOnly festlegen. Alle Verbindungen, die mit ReadOnly gekennzeichnet sind, werden automatisch an eines der sekundären HA-Replikate weitergeleitet, sofern vorhanden. Ausführliche Informationen finden Sie unter Verwenden von schreibgeschützten Replikaten zum Lesen schreibgeschützter Abfrageworkloads.

Wie kann ich überprüfen, ob ich mithilfe von SQL Server Management Studio (SSMS) oder anderen Clienttools erfolgreich eine Verbindung mit einem sekundären Computereplikat hergestellt habe?

Sie können die folgende T-SQL-Abfrage ausführen: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Das Ergebnis lautet READ_ONLY, wenn Sie mit einem schreibgeschützten sekundären Replikat verbunden sind, und READ_WRITE bei einer Verbindung mit dem primären Replikat. Der Datenbankkontext muss auf den Namen Ihrer Datenbank (und nicht auf die master-Datenbank) festgelegt werden.

Kann ich einen dedizierten Endpunkt für ein sekundäres Hochverfügbarkeitsreplikat erstellen?

Nein. Sie können eine Verbindung mit sekundären Hochverfügbarkeitsreplikaten nur herstellen, indem Sie ApplicationIntent=ReadOnly angeben. Sie können aber dedizierte Endpunkte für benannte Replikate verwenden.

Wird vom System für die schreibgeschützte Workload auf sekundären Hochverfügbarkeitsreplikaten ein intelligenter Lastenausgleich durchgeführt?

Nein. Eine neue Verbindung mit Schreibschutzabsicht wird an ein beliebiges sekundäres Hochverfügbarkeitsreplikat umgeleitet.

Kann ich sekundäre Hochverfügbarkeitsreplikate unabhängig vom primären Replikat hoch- und herunterskalieren?

Nicht auf der bereitgestellten Computeebene. Da sekundäre Hochverfügbarkeitsreplikate als Failoverziele mit Hochverfügbarkeit verwendet werden, müssen sie dieselbe Konfiguration wie das primäre Replikat aufweisen, um die erwartete Leistung nach einem Failover bereitstellen zu können. Bei serverlosem Computing erfolgt die Skalierung für jedes Hochverfügbarkeitsreplikat basierend auf dem individuellen Workloadbedarf automatisch. Jedes sekundäre Hochverfügbarkeitsreplikat kann weiterhin automatisch auf die konfigurierte maximale Anzahl von Kernen skaliert werden, um die Rolle nach dem Failover zu berücksichtigen. Benannte Replikate bieten die Möglichkeit, jedes Replikat unabhängig voneinander zu skalieren.

Erhalte ich unterschiedliche TempDB-Größen für meine primäre Compute-Instanz und meine HA-Sekundärrepliken?

Nein. Ihre tempdb-Datenbank wird basierend auf der bereitgestellten Computegröße konfiguriert, und Ihre sekundären Hochverfügbarkeitsreplikate haben die gleiche Größe wie das primäre Computereplikat (einschließlich tempdb). Da tempdb auf benannten Replikaten gemäß der Computegröße des Replikats dimensioniert wird, kann die Größe geringer oder höher als für tempdb auf dem primären Replikat ausfallen.

Kann ich Indizes und Views in meinen sekundären Computereplikaten hinzufügen?

Nein. Hyperscale-Datenbank-Replikate teilen sich den Speicher, was bedeutet, dass alle Replikate dieselben Tabellen, Indizes und anderen Datenbankobjekte sehen. Wenn Sie zusätzliche für Lesevorgänge optimierte Indizes im sekundären Replikat benötigen, müssen Sie sie im primären Replikat hinzufügen. Sie können weiterhin temporäre Tabellen (Tabellennamen mit dem Präfix #oder ##) für jedes sekundäre Replikat erstellen, um temporäre Daten in der tempdb-Datenbank zu speichern. Temporäre Tabellen haben Lese-/Schreibzugriff.

Wie lange dauert die Verzögerung zwischen dem primären und dem sekundären Computereplikat?

Die Datenlatenz ab dem Zeitpunkt, zu dem eine Transaktion auf dem primären Replikat committet wird, bis zu dem Zeitpunkt, zu dem sie auf einem sekundären Replikat lesbar ist, hängt von den aktuellen Werten für Protokollgenerierungsrate, Transaktionsgröße und Last auf dem Replikat sowie anderen Faktoren ab. Die typische Datenlatenz bei kleinen Transaktionen liegt im Bereich einiger Zehntel Millisekunden, es gibt jedoch keine obere Grenze für die Datenlatenz. Daten in einem bestimmten sekundären Replikat sind immer transaktionskonsistent, sodass größere Transaktionen länger dauern, bis sie verteilt werden. Zu einem bestimmten Zeitpunkt kann die Datenlatenz und der Datenbankstatus für verschiedene sekundäre Replikate unterschiedlich sein. Workloads, die committete Daten sofort lesen müssen, sollten auf dem primären Replikat ausgeführt werden.

Kann ein benanntes Replikat als Failoverziel verwendet werden?

Nein, benannte Replikate können nicht als Failoverziele für das primäre Replikat verwendet werden. Fügen Sie zu diesem Zweck HA-Replikate für das primäre Replikat hinzu.

Wie kann ich eine schreibgeschützte Workload auf meine benannten Replikate verteilen?

Da jedes benannte Replikat ein anderes Servicelevelziel haben und daher für unterschiedliche Anwendungsfälle genutzt werden kann, gibt es keine integrierte Möglichkeit, den an das primäre Replikat gesendeten schreibgeschützten Datenverkehr an benannte Replikate weiterzuleiten. Es kann beispielsweise sein, dass Sie über acht benannte Replikate verfügen und die OLTP-Workload nur an die benannten Replikate 1 bis 4 weiterleiten möchten. Für Power BI-Analyseworkloads verwenden Sie die benannten Replikate 5 und 6 und für die Data Science-Workload die Replikate 7 und 8. In Abhängigkeit davon, welches Tool bzw. welche Programmiersprache Sie verwenden, können die Strategien zum Verteilen von Workloads dieser Art jeweils variieren. Als Beispiel für die Erstellung einer Lösung für das Routing von Workloads, um für ein REST-Back-End das Aufskalieren zu ermöglichen, sehen Sie sich Folgendes an: Beispiel für OLTP-Aufskalierung.

Kann sich ein benanntes Replikat in einer anderen Region als der Region des primären Replikats befinden?

Nein. Da für benannte Replikate dieselben Seitenserver wie für das primäre Replikat verwendet werden, müssen sich diese in derselben Region befinden. Wenn Sie jedoch ein Georeplikat für das primäre Replikat in einer anderen Region erstellt haben, können Sie benannte Replikate für das Georeplikat erstellen.

Kann ein benanntes Replikat die Verfügbarkeit oder Leistung des primären Replikats beeinträchtigen?

Durch ein benanntes Replikat kann die Verfügbarkeit des primären Replikats nicht beeinträchtigt werden. Für benannte Replikate ist es unter normalen Umständen unwahrscheinlich, dass diese eine negative Auswirkung auf die Leistung des primären Replikats haben. Dies ist aber ggf. möglich, wenn rechenintensive Workloads ausgeführt werden. Wie beim HA-Replikat wird ein benanntes Replikat über den Transaktionsprotokolldienst mit dem primären System synchronisiert. Wenn ein benanntes Replikat aus irgendeinem Grund nicht in der Lage ist, das Transaktionsprotokoll schnell genug zu nutzen, wird das primäre Replikat aufgefordert, seine Protokollgenerierungsrate zu verringern, damit es aufholen kann. Dieses Verhalten wirkt sich zwar nicht auf die Verfügbarkeit des Primärsystems aus, kann sich jedoch auf die Leistung von Schreiboperationen auf dem Primärsystem auswirken. Um diese Situation zu vermeiden, stellen Sie sicher, dass Ihre benannten Replikate über genügend Ressourcenreserven – hauptsächlich CPU – zum Verarbeiten des Transaktionsprotokolls ohne Verzögerung verfügen. Wenn der primäre Knoten zahlreiche Datenänderungen verarbeitet, empfiehlt es sich, benannte Replikate mit mindestens der gleichen Rechenkapazität wie der primäre Knoten zu verwenden, um eine Sättigung der CPU bei den Replikaten zu vermeiden und dadurch zu verhindern, dass der primäre Knoten verlangsamt wird.

Was geschieht mit benannten Replikaten, wenn das primäre Replikat nicht verfügbar ist, z. B. aufgrund einer geplanten Wartung?

Benannte Replikate sind weiterhin für den schreibgeschützten Zugriff verfügbar, wie gewohnt.

Wie kann ich die Verfügbarkeit von benannten Replikaten verbessern?

Benannte Replikate verfügen standardmäßig nicht über eigene HA-Replikate. Für einen Failover eines benannten Replikats muss zuerst ein neues Replikat erstellt werden, was in der Regel etwa 1 bis 2 Minuten dauert. Benannte Replikate können jedoch auch von höherer Verfügbarkeit und kürzeren Failoverzeiten profitieren, die von Hochverfügbarkeitsreplikaten ermöglicht werden. Sie können HA-Replikate für ein benanntes Replikat im Azure-Portal hinzufügen oder mit dem Parameter ha-replicas der Azure CLI, dem Parameter HighAvailabilityReplicaCount von PowerShell oder der Eigenschaft highAvailabilityReplicaCountder REST-API verwenden. Die Anzahl der HA-Replikate kann während der Erstellung eines benannten Replikats festgelegt werden und kann jederzeit geändert werden, nachdem das benannte Replikat erstellt wurde. Die Preise für HA-Replikate bei benannten Replikaten entsprechen denen für HA-Replikate bei primären Replikaten.

Wenn „Always Encrypted“ für eine Hyperscale-Datenbank aktiviert ist, wird durch das Rotieren des Spalten-Hauptschlüssels (CMK) in der primären Datenbank auch der Schlüssel auf den sekundären Repliken aktualisiert?

Ja. Der Spaltenmasterschlüssel wird in der Benutzerdatenbank gespeichert und kann durch Ausführen der Abfrage SELECT * FROM sys.column_master_keys überprüft werden. Benannte Replikate und sekundäre Replikate mit hoher Verfügbarkeit lesen Daten von derselben Seitenserver/Speicherebene wie die primäre Hyperscale-Datenbank. Beide Replikattypen werden über den Protokolldienst mit der primären Hyperscale-Datenbank synchronisiert. Eine Schlüsseländerung gilt als Transaktion und wird automatisch in alle sekundären Replikate repliziert.

Wie frage ich Informationen zu sekundären Replikaten der Hyperscale-Datenbank ab?

Sie können eine Verbindung mit dem primären Replikat herstellen und die Replikat-ID und die Details anderer sekundärer Replikate mithilfe der sys.dm_hs_database_replicas DMF ermitteln. Weitere Informationen finden Sie unter sys.dm_hs_database_replicas. Im folgenden Beispiel wird eine Zeile für jedes Replikat einer Hyperscale-Datenbank mit dem Namen Contosodbzurückgegeben.

SELECT replica_role_desc, replica_server_name, replica_id
FROM sys.dm_hs_database_replicas(DB_ID(N'Contosodb'));

Sie können auch eine Verbindung mit einem sekundären Replikat herstellen, um die Replikat-ID und andere Details zu ermitteln. Die folgende Beispielabfrage von sys.dm_database_replica_states zeigt die Details für den aktuellen Replikatkontext an:

  SELECT replica_id,
         DB_NAME() AS named_replica_database_name,
         synchronization_state_desc,
         log_send_queue_size / 1024.0 / 1024.0 AS log_send_queue_size_gb,
         last_sent_time,
         last_received_time,
         last_commit_time,
         redo_queue_size / 1024.0 / 1024.0 AS redo_queue_size_gb,
         redo_rate,
         secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE is_local = 1
        AND
        replica_id = DATABASEPROPERTYEX(DB_NAME(), 'ReplicaID');

Zugehöriger Inhalt

Weitere Informationen zur Dienstebene „Hyperscale“ finden Sie unter Hyperscale service tier.

  • Last updated on