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 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ö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 Option zum Bezahlen, die Sie mit serverloser Berechnung verwenden, wobei die Berechnung basierend auf der Nutzung in Rechnung gestellt 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.
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 der Speicher remote ist, ist die Skalierung nach oben und nach unten keine Datengröße.
Unterstützung für serverlosen Compute- bietet automatische Skalierungs- und Skalierungs- und Berechnungsabrechnung basierend auf der Nutzung.
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.
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?
Im primären Replikat wird die Standardtransaktionsisolationsstufe READ COMMITTED, wobei die READ_COMMITTED_SNAPSHOT-Datenbankoption (RCSI) aktiviert ist. Auf den sekundären Replikaten wird die Isolationsebene SNAPSHOT. Dies gilt auch für alle anderen Azure SQL-Datenbank-Instanzen.
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 150 MiB/s pro Datenbank für Premium-Serien- und Premium-Serie speicheroptimierte Hardware 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 Protokollrate 150 MiB/s pro Pool für optimierte Hardware der Premium-Serie und 125 MiB/s pro Pool für andere Hardware.
Fragen zu Hyperscale Compute
Kann ich die Computebereitstellung jederzeit anhalten?
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 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.
Kann ich mehrere Computereplikate unterschiedlicher Größe bereitstellen?
Bei Leseworkloads kann dies mithilfe von benannten Replikaten erreicht werden.
Wie viele Replikate mit horizontaler Leseskalierung 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. Jedes benannte Replikat kann bis zu 4 HA sekundäre Replikate aufweisen.
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 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. Die Protokollgenerierungsrate kann jedoch bei kontinuierlichen aggressiven Schreibvorgängen reduziert werden. Protokollgenerierungsrate von 150 MiB/s für premium-serie und Premium-Serie speicheroptimierte Hardware und 100 MiB/s für andere Hardware.
Wird tempdb mit zunehmendem Wachstum der Datenbank skaliert?
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 ist tempdb nicht konfigurierbar 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.
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 10 GB. Mehrere Datendateien können gleichzeitig wachsen.
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 allen anderen Azure SQL-Datenbank-Instanzen. 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. Die Möglichkeit, eine georeplizierte Datenbank ohne Hyperscale-Datenbank mithilfe von T-SQL, REST-API, PowerShell oder Azure CLI in Hyperscale zu konvertieren, ist derzeit ein Vorschaufeature.
Umgekehrte Migration zur Dienstebene "Allgemeiner Zweck" ermöglicht Es Kunden, die kürzlich eine vorhandene Datenbank in azure SQL-Datenbank in die Hyperscale-Dienstebene migriert haben, zurückzuziehen, 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 Reverse migrate from Hyperscale.
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 Datengröße-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.
Müssen bei der Migration zur Dienstebene „Hyperscale“ Einbußen hinsichtlich des Funktionsumfangs in Kauf genommen werden?
Ja. Einige Azure SQL-Datenbankfeatures werden in Hyperscale nicht unterstützt. Wenn einige dieser 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 verbrauchen, aber die Zeit, die zum Verschieben von Daten in Datenbanken in Azure SQL-Datenbank erforderlich ist, ist auch durch den verfügbaren Netzwerkdurchsatz, die Quelllesegeschwindigkeit, den Typ der Last (Massen- und Zeilen-nach-Zeile) und das Ziel der Zieldatenbankdienstebene betroffen.
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.
Einfache oder Massenprotokoll-Wiederherstellungsmodelle 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.
Ermöglicht Hyperscale die Bereitstellung mehrerer Knoten für die parallele Erfassung von großen Datenmengen?
Nein. Hyperscale ist eine symmetrische SMP-Architektur (Multi-Processing) und keine massive parallele Verarbeitung (MPP) oder eine Multimasterarchitektur. Sie können mehrere Replikate erstellen, um schreibgeschützte Workloads 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 nach Abschluss einer Konvertierung beginnt erst nach Abschluss des Übernahmevorgangs.
Wenn ich in Hyperscale konvertiert habe, kann ich die Unterbrechung meiner Datenbank steuern?
Ja. Wenn Sie die Konvertierung starten, haben Sie die Möglichkeit, die Art der Übernahme 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 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 Pools für elastische Datenbanken?
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 Zeitpunktwiederherstellungen?
Ja.
Wie lange dauert die Recovery Point Objective (RPO)/Recovery Time Objective (RTO) bei einer Datenbankwiederherstellung in Hyperscale?
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 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. Geowiederherstellung 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 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 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 Database.
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 die Höhe 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 fallen für Workloads, die zum Großteil schreibgeschützt sind, geringere Sicherungskosten an.
Wie kann ich die Sicherungsspeicherkosten minimieren?
Ausführliche Informationen zum Minimieren der Sicherungsspeicherkosten finden Sie unter Automatisierte Sicherungen.
Kann ich eine Geowiederherstellung für eine Hyperscale-Datenbank auf einer anderen Dienstebene durchführen (und umgekehrt)?
Derzeit können Nicht-Hyperscale-Dienstebenen (Basic/Standard/Premium/General Purpose/Business Critical) keine Geo-Wiederherstellung in einer Hyperscale-Dienstebene und umgekehrt erfolgen. 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 Erfassungs- oder Protokollgenerierungsrate beträgt 150 MiB/s pro Datenbank für Premium-Serien- und Premium-Serie speicheroptimierte Hardware 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 Protokollrate 150 MiB/s pro Pool für optimierte 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 auf die daten, auf die zugegriffen wird, im lokalen SSD-Speicher auf dem Computereplikat zwischengespeichert wird, werden ähnliche E/A-Leistung wie in Business Critical- oder Premium-Dienstebenen angezeigt.
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 Protokollrate für fortlaufende und aggressive Schreibworkloads ist jedoch möglicherweise auf der primären Seite beschränkt, damit die Anmeldung auf sekundären Replikaten und Seitenservern angewendet werden kann. 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 profitiert die kontinuierliche Primierung von Kunden?
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.
Hat die fortlaufende Primierung den Vorteil benannter Replikate?
Benannte Replikate profitieren nicht von der kontinuierlichen Primierung.
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 die Datenbank während des Vorgangs zum zentralen Hoch- bzw. Herunterskalieren offline geschaltet?
Nein. Eine Datenbank bleibt während der Skalierungs- oder Skalierungsvorgänge online.
Ist ein Verbindungsabbruch zu erwarten, wenn die Skalierungsvorgänge im Gange sind?
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.
Erfolgt das zentrale Hoch- und Herunterskalieren 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 berechnen ssd cache Größe auf Computeknoten werden automatisch skaliert, wenn die Anzahl der Kerne erhöht wird. Ausführlichere Informationen finden Sie im Artikel zum Hyperscale-Speicher und den Computegrößen.
Kann ich mehrere primäre Computereplikate, z. B. ein Multimastersystem, bereitstellen, bei dem mehrere primäre Computeheads zu einem höheren Maß an Parallelität führen können?
Nein. Nur das primäre Computereplikat akzeptiert Lese-/Schreibanforderungen. Sekundäre Computereplikate akzeptieren nur schreibgeschützte Anforderungen.
Fragen zur horizontalen Leseskalierung
Welche Arten von sekundären Replikaten (Leseskalierung) sind in Hyperscale verfügbar?
Für Hyperscale werden Hochverfügbarkeitsreplikate, benannte Replikate und Georeplikate unterstützt. Ausführlichere Informationen finden Sie unter Sekundäre Hyperscale-Replikate.
Wie viele sekundäre Hochverfügbarkeitsreplikate 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 Hochverfügbarkeitsreplikate weitergeleitet, falls 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. benannten Replikaten die Möglichkeit bieten, jedes benannte Replikat unabhängig voneinander zu skalieren.
Erhalte ich eine unterschiedliche tempdb-Dimensionierung für meine primären Compute- und meine sekundären Hochverfügbarkeitsreplikate?
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 auf tempdb 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 Sichten 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 HA-Replikate für das primäre Replikat zu diesem Zweck 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. Es gilt dasselbe wie bei einem Hochverfügbarkeitsreplikat: Ein benanntes Replikat wird über den Transaktionsprotokolldienst mit dem primären Replikat synchron gehalten. 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 der primären Daten aus, kann sich jedoch auf die Leistung von Schreibarbeitslasten auf der primären Seite auswirken. Um diese Situation zu vermeiden, stellen Sie sicher, dass ihre benannten Replikate über genügend Ressourcenkopf verfügen – hauptsächlich CPU - zum Verarbeiten des Transaktionsprotokolls ohne Verzögerung. Wenn z. B. die primäre Datenänderung verarbeitet, empfiehlt es sich, benannte Replikate mit mindestens der gleichen Berechnungsgröße wie die primäre zu verwenden, um eine Sättigung der CPU für die Replikate zu vermeiden und die primäre Zulangsamung zu erzwingen.
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 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 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. Sie können HA-Replikate für ein benanntes Replikat im Azure-Portal hinzufügen oder den Parameter ha-replicas mit AZ CLI-oder den Parameter HighAvailabilityReplicaCount mit PowerShell-oder die eigenschaft highAvailabilityReplicaCount mit REST-API. 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 von HA-Replikaten für benannte Replikate sind identisch mit HA-Replikaten für primäre Replikate.
Wenn "Always Encrypted" in der Hyperscale-Datenbank aktiviert ist, wird der Spaltenmasterschlüssel (COLUMN Master Key, CMK) in der primären Datenbank ebenfalls für sekundäre Replikate 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.
Kann ich den Namen eines benannten Replikats bestimmen, das einem Wert in der Spalte replica_id in sys.dm_database_replica_states zugeordnet ist?
Nicht, wenn Sie sys.dm_database_replica_states für das primäre Replikat abfragen. Sie können jedoch eine Verbindung mit einem benannten Replikat herstellen, um die Replikat-ID und andere Details mithilfe der folgenden Beispielabfrage zu ermitteln:
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 Dienstebene „Hyperscale“ (Vorschau) für bis zu 100 TB.