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

Eine Hyperscale-Datenbank ist eine Datenbank in SQL-Datenbank, die durch die Hyperscale-Technologie zur horizontalen Skalierung von Speichern unterstü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, Datenbank-Engine-Features usw. funktionieren wie bei jeder anderen Datenbank in Azure SQL-Datenbank.

Die Dienstebene „Hyperscale“ ist nur für Einzeldatenbanken verfügbar, bei denen das vCore-basierte Kaufmodell in Azure SQL-Datenbank zum Einsatz kommt. Sie ist im DTU-basierten Kaufmodell nicht verfügbar.

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.

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 auf bis zu 128 TB wachsen kann.
• Berechnen von vCore-Ressourcen von 2 vCores bis zu 128 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öheren Protokolldurchsatz unabhängig von der Datenbankgröße und der Anzahl der virtuellen Kerne
• 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 Option zum Bezahlen, die Sie mit serverloser Berechnung verwenden, wobei die Berechnung basierend auf der Nutzung in Rechnung gestellt wird.

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

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.

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

Hyperscale bietet schnelle Skalierbarkeit basierend auf Ihrem Workloadbedarf.

• Zentrales Hoch-/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 es sich beim Speicher um einen Remotespeicher handelt, ist das Hoch- und Herunterskalieren kein Vorgang, der von der Datengröße abhängig ist.

  Unterstützung für serverloses Computing ermöglicht automatisches Hoch- und Herunterskalieren, und Compute wird basierend auf der Nutzung abgerechnet.

• Horizontal herunter-/hochskalieren

  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.

Ja, das ist möglich.

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.

Für das primäre Replikat gilt die RCSI-Transaktionsisolationsstufe (Read Committed Snapshot Isolation, Isolation der READ COMMITTED-Momentaufnahme). In den sekundären Replikaten mit horizontaler Leseskalierung ist die Standardisolationsstufe die Momentaufnahme. Dies gilt auch für alle anderen Azure SQL-Datenbank-Instanzen.

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 der neuen, vereinfachten Preisgestaltung ist es nicht mehr notwendig, den Azure-Hybridvorteil (AHB) anzuwenden, um entsprechende Einsparungen zu erzielen. 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 unter Azure SQL-Datenbank Hyperscale – niedrigere, vereinfachte Preise!.

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

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 im großen Umfang mit komplexen Abfragen und nachhaltigen Erfassungsraten von mehr als 100 MB/s oder mithilfe von 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.

Erfassungs- oder Protokollgenerierungsrate von 150 MBit/s ist als Opt-In-Previewfunktion verfügbar. Weitere Informationen und die Möglichkeit, sich für 150 MB/s zu entscheiden, finden Sie im Blog: Hyperscale-Erweiterungen im November 2024.

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.

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

Bei Leseworkloads kann dies mithilfe von benannten Replikaten erreicht werden.

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.

Bei Hyperscale-Datenbanken wird Datenresilienz auf Speicherebene bereitgestellt. Sie benötigen nur ein Replikat (das primäre), um Resilienz bereitzustellen. Wenn das Computereplikat ausfällt, wird automatisch und ohne Datenverluste ein neues Replikat erstellt.

Wenn es jedoch nur das primäre Replikat gibt, kann es bis zu zwei Minuten dauern, ein neues Replikat nach dem Failover zu erstellen, wohingegen es nur Sekunden dauert, wenn ein sekundäres Hochverfügbarkeitsreplikat 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 Apps, die Hochverfügbarkeit bei minimalen Failoverauswirkungen erfordern, sollten Sie mindestens ein sekundäres HA-Replikat bereitstellen, um sicherzustellen, dass ein unmittelbar betriebsbereiter Standbyserver-Replikat als Failover-Ziel verfügbar ist.

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

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 ausgeführter Transaktionen oder aufgrund der Verarbeitung der Change Data Capture nicht mit der Datenänderungsrate schritthalten. 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. Allerdings wird bei kontinuierlichen intensiv schreibenden Workloads die Protokollgenerierungsrate möglicherweise gedrosselt. Die dauerhafte Protokollgenerierungsrate liegt bei 100 MB/Sek.

Protokollgenerierungsrate von 150 MB/s ist als Opt-In-Previewfunktion verfügbar. Weitere Informationen und die Möglichkeit, sich für 150 MB/s zu entscheiden, finden Sie im Blog: Hyperscale-Erweiterungen im November 2024.

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 kann nicht konfiguriert werden und wird für Sie verwaltet. Informationen zur Ermittlung der maximalen tempdb-Größe für Ihre Datenbank finden Sie im Artikel zum Hyperscale-Speicher und den Computegrößen.

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

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

Jede Datendatei wächst um 10 GB. Mehrere Datendateien können gleichzeitig wachsen.

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.

Nein. Datendateien werden automatisch zur Dateigruppe PRIMARY hinzugefügt. Die häufigsten Gründe für das Erstellen zusätzlicher Dateigruppen gelten nicht für die Hyperscale-Speicherarchitektur oder im weiteren Sinne für Azure SQL-Datenbank.

Nein.

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

Ja, genau wie bei allen anderen Azure SQL-Datenbank-Instanzen. Dies umfasst die Zeilen-, Seiten- und Columnstorekomprimierung.

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.

Ja. Sie können Ihre vorhandenen Datenbanken in Azure SQL-Datenbank zu Hyperscale migrieren. 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.

Beispielcode zum Migrieren vorhandener Azure SQL-Datenbanken zu Hyperscale in Azure-Portal, Azure CLI, PowerShell und Transact-SQL finden Sie unter Migrieren einer vorhandenen Datenbank zu Hyperscale.

Die umgekehrte Migration zur Dienstebene „Universell“ ermöglicht es Kunden, die vor kurzem eine vorhandene Datenbank in Azure SQL-Datenbank zur Dienstebene „Hyperscale“ migriert haben, wieder dorthin zurückzukehren, falls Hyperscale ihre Anforderungen nicht erfüllt. 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. Erfahren Sie mehr über die Einschränkungen für die umgekehrte Migration.

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. Die umgekehrte Migration ist ein von der Datengröße abhängiger Vorgang.

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.

Ja. Einige Azure SQL-Datenbank-Features werden in Hyperscale noch nicht unterstützt. Wenn einige dieser Features für Ihre Datenbank aktiviert sind, wird die Migration zu Hyperscale möglicherweise blockiert, oder diese Features werden nach der Migration beendet. Wir gehen davon aus, dass diese Einschränkungen nur temporär bestehen. Ausführlichere Informationen finden Sie unter Bekannte Einschränkungen.

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.

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.

Hyperscale kann 100 MB/Sek. neuer/geänderter Daten verarbeiten, aber die Zeit für das Migrieren von Daten in Datenbanken in Azure SQL-Datenbank wird auch durch den verfügbaren Netzwerkdurchsatz, die Lesegeschwindigkeit der Quelle und das Servicelevelziel der Zieldatenbank beeinflusst. Protokollgenerierungsrate von 150 MB/s ist als Opt-In-Previewfunktion verfügbar. Weitere Informationen und die Möglichkeit, sich für 150 MB/s zu entscheiden, finden Sie im Blog: Hyperscale-Erweiterungen im November 2024.

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. Als Alternative zum schnellen Laden können Sie entweder Azure Data Factory oder einen Spark-Auftrag in Azure Databricks mit dem Spark-Connector für SQL verwenden. Der Spark-Connector für SQL unterstützt Importe mit BULK INSERT.

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

Einfache Wiederherstellungen oder Massenprotokollierungsmodelle werden in Hyperscale nicht unterstützt. Ein vollständiges Wiederherstellungsmodell ist erforderlich, um Hochverfügbarkeit und Zeitpunktwiederherstellung bereitzustellen. Allerdings bietet die Hyperscale-Protokollarchitektur im Vergleich zu anderen Dienstebenen für Azure SQL-Datenbank eine bessere Datenerfassungsrate.

Nein Hyperscale ist eine SMP-Architektur (symmetrisches Multiprocessing) und keine MPP-Architektur (Massively Parallel Processing, parallele Massenverarbeitung) oder Multimasterarchitektur. Sie können nur mehrere Replikate erstellen, um schreibgeschützte Workloads aufzuskalieren.

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

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.

Ja.

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.

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.

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 Momentaufnahmenintervall führt dies zu einer transaktional konsistenten Datenbank ohne Datenverlust ab dem angegebenen Zeitpunkt innerhalb des Aufbewahrungszeitraums. Die Datenbanksicherung in Hyperscale ist faktisch kontinuierlich.

Ja.

Die RPO für Point-in-Time-Wiederherstellung beträgt 0 Minuten. 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 Ändern der Speicherredundanz beim Ausgeben einer Wiederherstellung kann zu längeren Wiederherstellungszeiten führen, da die Wiederherstellung die Größe der Daten hat und somit die Zeit proportional zur Datenbankgröße ist.

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

Ja. Geowiederherstellungen werden vollständig unterstützt, wenn ein georedundanter Speicher verwendet wird. Das ist die Standardeinstellung für neue Datenbanken. Anders als bei der Point-in-Time-Wiederherstellung erfordert die Geowiederherstellung einen zeitintensiven 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 deutlich kürzer, wenn die Datenbank in der Azure-Region wiederhergestellt wird, die mit der Region der Quelldatenbank gekoppelt ist.

Ja. Georeplikation kann für Hyperscale-Datenbanken eingerichtet werden.

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. Wenn Sie Ihre Daten aus einer Hyperscale-Datenbank entfernen möchten, können Sie sie mithilfe von Datenverschiebungstechnologien extrahieren, z.B. Azure Data Factory, Azure Databricks, SSIS usw.

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.

Details zum Ermitteln der Sicherungsspeichergröße finden Sie unter Automatisierte Sicherungen – Azure SQL-Datenbank und Azure SQL Managed Instance.

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.

Die Sicherungskosten sind für Workloads höher, die der Datenbank große Datenmengen hinzufügen oder große Datenmengen in der Datenbank ändern oder löschen. Umgekehrt fallen für Workloads, die zum Großteil schreibgeschützt sind, geringere Sicherungskosten an.

Details zum Minimieren der Sicherungsspeicherkosten finden Sie unter Automatisierte Sicherungen – Azure SQL-Datenbank und Azure SQL Managed Instance.

Das Durchsatzlimit für Transaktionsprotokolle ist auf 100 MB/Sek. für jede beliebige Hyperscale-Computegröße festgelegt. 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. Protokollgenerierungsrate von 150 MB/s ist als Opt-In-Previewfunktion verfügbar. Weitere Informationen und die Möglichkeit, sich für 150 MB/s zu entscheiden, finden Sie im Blog: Hyperscale-Erweiterungen im November 2024.

Die IOPS- bzw. IO-Wartezeit variiert abhängig von den Workloadmustern. Wenn die Daten, auf die zugegriffen wird, unter RBPEX auf dem Computereplikat zwischengespeichert werden, erzielen Sie eine ähnliche E/A-Leistung wie bei den Dienstebenen „Unternehmenskritisch“ oder „Premium“.

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

Weil der Speicher gemeinsam genutzt wird und es keine direkte physische Replikation zwischen primären und sekundären Computereplikaten gibt, wird der Durchsatz im primären Replikat durch das Hinzufügen von sekundären Replikaten nicht direkt beeinträchtigt. Allerdings können kontinuierliche und intensiv schreibende Workloads auf dem primären Replikat gedrosselt werden, damit Protokolle auf sekundäre Replikate angewendet werden und Seitenserver mit der Verarbeitung 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.

Ja. Wie bei anderen Azure SQL-Datenbank-Instanzen können Verbindungen jedoch aufgrund von sehr seltenen vorübergehenden Fehlern beendet werden, wodurch Abfragen mit langer Ausführungszeit abgebrochen werden und ein Rollback für Transaktionen ausgeführt wird. 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.

Für die meisten Leistungsprobleme (insbesondere für solche, die nicht durch die Speicherleistung entstehen) gelten allgemeine SQL-Diagnose- und -Problembehandlungsschritte. Informationen zur Hyperscale-spezifischen Speicherdiagnose finden Sie unter Diagnose zur Problembehandlung bei SQL-Hyperscale-Leistungsproblemen.

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.

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.

Nein Eine Datenbank bleibt während einer Skalierungsoperation nach oben oder unten online.

Das Hoch- oder Herunterskalieren von bereitgestellten Computereplikaten 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 Verbindungstrennungen auf dem primären Replikat.

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

Ja. Die Größe der tempdb-Datenbank und die Größe des RBPEX-Cache auf Computeknoten werden automatisch hochskaliert, wenn die Anzahl der Kerne erhöht wird. Ausführlichere Informationen finden Sie im Artikel zum Hyperscale-Speicher und den Computegrößen.

Nein Nur das primäre Computereplikat akzeptiert Lese-/Schreibanforderungen. Sekundäre Computereplikate akzeptieren nur schreibgeschützte Anforderungen.

Für Hyperscale werden Hochverfügbarkeitsreplikate, benannte Replikate und Georeplikate unterstützt. Ausführlichere Informationen finden Sie unter Sekundäre Hyperscale-Replikate.

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.

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 Hochverfügbarkeitsreplikate weitergeleitet, falls vorhanden. Ausführliche Informationen finden Sie unter Verwenden von schreibgeschützten Replikaten zum Lesen schreibgeschützter Abfrageworkloads.

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.

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.

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

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. Bei benannten Replikaten kann jedes Replikat einzeln skaliert werden.

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.

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 die einzelnen sekundären Replikate erstellen, um temporäre Daten zu speichern. Temporäre Tabellen haben Lese-/Schreibzugriff.

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 Datenbankzustand für verschiedene sekundäre Replikate jedoch unterschiedlich sein. Workloads, die committete Daten sofort lesen müssen, sollten auf dem primären Replikat ausgeführt werden.

Nein, benannte Replikate können nicht als Failoverziele für das primäre Replikat verwendet werden. Fügen Sie hierfür Hochverfügbarkeitsreplikate hinzu.

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.

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.

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. Es gilt dasselbe wie bei einem Hochverfügbarkeitsreplikat: Ein benanntes Replikat wird über den Transaktionsprotokolldienst mit dem primären Replikat synchron gehalten. Falls ein benanntes Replikat aus irgendeinem Grund das Transaktionsprotokoll nicht schnell genug verbrauchen kann, fordert es vom primären Replikat eine Verlangsamung (Drosselung) der Protokollgenerierung, damit es den Rückstand aufholen kann. Dieses Verhalten wirkt sich zwar nicht auf die Verfügbarkeit des primären Replikats aus, kann sich jedoch auf die Leistung der Schreibworkload des primären Replikats auswirken. Stellen Sie zur Vermeidung dieser Situation sicher, dass Ihre benannten Replikate über einen ausreichenden Toleranzbereich für Ressourcen (hauptsächlich in Bezug auf die CPU) verfügen, damit das Transaktionsprotokoll ohne Verzögerung verarbeitet werden kann. Falls vom primären Replikat beispielsweise eine größere Zahl von Datenänderungen verarbeitet wird, empfehlen wir Ihnen, für das benannte Replikat mindestens das gleiche Servicelevelziel wie für das primäre Replikat zu verwenden. Auf diese Weise wird eine Sättigung der CPU auf den Replikaten verhindert, sodass für das primäre Replikat die Verlangsamung erzwungen werden kann.

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

Benannte Replikate verfügen standardmäßig nicht über eigene Hochverfügbarkeitsreplikate. 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. Zum Festlegen der Anzahl von Hochverfügbarkeitsreplikaten für benannte Replikate können Sie den Parameter ha-replicas in der Azure CLI, den Parameter HighAvailabilityReplicaCount in PowerShell oder die highAvailabilityReplicaCount-Eigenschaft in der REST-API verwenden. Die Anzahl von Hochverfügbarkeitsreplikaten kann während der Erstellung eines benannten Replikats festgelegt werden. Diese Angabe kann nach der Erstellung des benannten Replikats jederzeit geändert werden (nur per Azure CLI, PowerShell oder REST-API). Die Preise für die Hochverfügbarkeitsreplikate, die für benannte Replikate genutzt werden, sind identisch mit den Preisen für Hochverfügbarkeitsreplikate für reguläre Hyperscale-Datenbanken.

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 das benannte Replikat und das sekundäre Replikat mit hoher Verfügbarkeit repliziert.

Die DATABASEPROPERTYEX()-Funktion kann, wenn sie im Kontext einer benannten Replik ausgeführt wird, das replica_id der entsprechenden benannten Replik zuordnen. Es ist jedoch derzeit nicht möglich, für jeden Datensatz in der dynamischen Verwaltungsansicht sys.dm_database_replica_states das replica_id mit der entsprechenden benannten Replik zu verknüpfen, wenn diese von dem primären Replikat abgefragt wird. Die folgende Beispielabfrage kann innerhalb des Kontexts eines benannten Replikats ausgeführt werden, um den Replikatnamen, die Replikat-ID und die Synchronisierungsdetails zu identifizieren.

  SELECT replica_id, DB_NAME() AS 'Database/Replica 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, secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE replica_id = DATABASEPROPERTYEX(DB_NAME(),'REPLICAID');

Zugehöriger Inhalt

Weitere Informationen zur Dienstebene „Hyperscale“ finden Sie unter Dienstebene „Hyperscale“ (Vorschau) für bis zu 100 TB.