Freigeben über


Verwalten einer Hyperscale-Datenbank

Gilt für: Azure SQL-Datenbank

Die Hyperscale-Dienstebene bietet eine hochgradig skalierbare Speicher- und Computeleistungsstufe, mit der die Speicher- und Computeressourcen für eine Azure SQL-Datenbank-Instanz mithilfe der Azure-Architektur weit über die Grenzen der Dienstebenen „Universell“ und „Unternehmenskritisch“ hinaus aufskaliert werden können. In diesem Artikel wird beschrieben, wie grundlegende Verwaltungsaufgaben für Hyperscale-Datenbanken durchgeführt werden, einschließlich der Migration einer vorhandenen Datenbank zu Hyperscale, der Wiederherstellung einer Hyperscale-Datenbank in einer anderen Region, der umgekehrten Migration von Hyperscale zu einer anderen Dienstebene und der Überwachung des Status aktueller und kürzlich durchgeführter Vorgänge mit einer Hyperscale-Datenbank.

Erfahren Sie, wie Sie eine neue Hyperscale-Datenbank erstellen: Schnellstart: Erstellen einer Hyperscale-Datenbank in Azure SQL-Datenbank.

Tipp

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

Migrieren einer vorhandenen Datenbank zu Hyperscale

Sie können vorhandene Datenbanken in Azure SQL-Datenbank über das Azure-Portal, die Azure CLI, PowerShell oder Transact-SQL zu Hyperscale 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. Es wird empfohlen, die Migration zu Hyperscale in einem Zeitraum mit geringerer Schreibaktivität durchzuführen, damit die Zeit für die Wiedergabe der aufgelaufenen Änderungen kürzer ist.

Während der endgültigen Umstellung auf die Dienstebene „Hyperscale“ kommt es nur zu einer kurzen Ausfallzeit, die in der Regel nur wenige Minuten dauert.

Voraussetzungen

Um eine Datenbank, die Teil einer Georeplikationsbeziehung ist, entweder als primäres oder als sekundäres Replikat zu Hyperscale zu verschieben, müssen Sie zunächst die Datenreplikation zwischen dem primären und dem sekundären Replikat beenden. Datenbanken in einer Failovergruppe müssen zuerst aus der Gruppe entfernt werden.

Nachdem eine Datenbank nach Hyperscale verschoben wurde, können Sie ein neues Hyperscale-Georeplikat für diese Datenbank erstellen.

Direkte Migration von der Standarddienstebene zur Hyperscale-Dienstebene wird nicht unterstützt. Um diese Migration durchzuführen, ändern Sie zuerst die Datenbank in eine andere Dienstebene als „Basic“ (z. B. „Allgemein“) und fahren Sie dann mit der Migration zu Hyperscale fort.

Migrieren einer Datenbank zur Hyperscale-Dienstebene

Um eine vorhandene Datenbank in Azure SQL-Datenbank zur Hyperscale-Dienstebene zu migrieren, identifizieren Sie zuerst Ihr Dienstziel. Ziehen Sie Ressourcengrenzen für einzelne Datenbanken zu Rate, wenn Sie nicht sicher sind, welches Dienstziel für Ihre Datenbank geeignet ist. In vielen Fällen können Sie ein Dienstziel mit derselben Anzahl von virtuellen Kernen und derselben Hardwaregeneration wie die ursprüngliche Datenbank auswählen. Bei Bedarf können Sie das Dienstziel ändern. Dies führt nur zu einer minimalen Ausfallzeit.

Wählen Sie die Registerkarte für Ihr bevorzugtes Tool aus, um Ihre Datenbank zu migrieren:

Mit dem Azure-Portal können Sie zur Hyperscale-Dienstebene migrieren, indem Sie den Tarif für Ihre Datenbank ändern.

Screenshot: Compute- und Speicherbereich einer Datenbank in Azure SQL-Datenbank. Das Dropdownmenü für die Dienstebene ist erweitert, und die Option für die Hyperscale-Dienstebene wird angezeigt.

  1. Navigieren Sie zur Datenbank, die Sie im Azure-Portal migrieren möchten.
  2. Wählen Sie in der linken Navigationsleiste Compute und Speicher aus.
  3. Wählen Sie die Dropdownliste Dienstebene aus, um die Optionen für Dienstebenen zu erweitern.
  4. Wählen Sie Hyperscale (skalierbarer Speicher nach Bedarf) im Dropdownlistenmenü aus.
  5. Überprüfen Sie die Liste Hardwarekonfiguration. Wählen Sie, falls gewünscht, Konfiguration ändern aus, um die geeignete Hardwarekonfiguration für Ihre Workloads auszuwählen.
  6. Wählen Sie den vCores-Schieberegler aus, wenn Sie die Anzahl der für Ihre Datenbank unter der Hyperscale-Dienstebene verfügbaren virtuellen Kerne ändern möchten.
  7. Wählen Sie den Schieberegler High-AvailabilitySecondaryReplicas aus, wenn Sie die Anzahl der Replikate unter der Hyperscale-Dienstebene ändern möchten.
  8. Wählen Sie Übernehmen.

Sie können Vorgänge für eine Hyperscale-Datenbank überwachen, während der Vorgang ausgeführt wird.

Umgekehrte Migration aus Hyperscale

Umgekehrte Migration zur Dienstebene „Universell“ ermöglicht es Kunden, die vor kurzem eine vorhandene Datenbank in Azure SQL-Datenbank zur Dienstebene „Hyperscale“ migriert haben, im Notfall 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 eine Verschiebung der Datengröße zwischen verschiedenen Architekturen.

Einschränkungen für die umgekehrte Migration

Umgekehrte Migration ist unter den folgenden Bedingungen verfügbar:

  • Umgekehrte Migration ist nur innerhalb von 45 Tagen nach der ursprünglichen Migration zu Hyperscale verfügbar.
  • Datenbanken, die ursprünglich mit der Dienstebene „Hyperscale“ erstellt wurden, sind von der umgekehrten Migration ausgeschlossen.
  • Sie können umgekehrte Migration nur zur Dienstebene Universell ausführen. Ihre Migration aus „Hyperscale“ zu „Universell“ kann entweder auf die serverlosen oder bereitgestellten Computeebenen abzielen. Wenn Sie die Datenbank zu einer anderen Dienstebene migrieren möchten, z. B. zu Unternehmenskritisch oder zu einer DTU-basierten Dienstebene, führen Sie zunächst eine umgekehrte Migration zur Dienstebene „Universell“ aus, und ändern Sie dann die Dienstebene.
  • Die umgekehrte Migration zu Datenbanken mit weniger als zwei virtuellen Kernen wird nicht unterstützt. Sie können die Datenbank nach Abschluss der Migration auf weniger als zwei virtuelle Kerne herunterskalieren.
  • Die direkte umgekehrte Migration von oder zu einem Pool für elastische Datenbanken wird nicht unterstützt. Sie können die Migration eines Singletons nur von „Hyperscale“ zu „Universell“ rückgängig machen.
    • Wenn die Hyperscale-Datenbank Teil eines Hyperscale-Pools für elastische Datenbanken ist, müssen Sie sie vor der umgekehrten Migration zunächst aus dem Hyperscale-Pool für elastische Datenbanken entfernen.
    • Nach Abschluss der umgekehrten Migration können Sie bei Bedarf den Singleton mit der Dienstebene „Universell“ einem Pool für elastische Datenbanken der Dienstebene „Universell“ hinzufügen.
  • Für Datenbanken, die nicht für die umgekehrte Migration in Frage kommen, besteht die einzige Möglichkeit der Migration von Hyperscale zu einer anderen Dienstebene im Export/Import mithilfe einer Bacpac-Datei oder anderer Datenverschiebungstechnologien (Massenkopieren, Azure Data Factory, Azure Databricks, SSIS usw.). Der Bacpac-Export/Import über das Azure-Portal, über PowerShell mit New-AzSqlDatabaseExport oder New-AzSqlDatabaseImport, über die Azure CLI mit az sql db export und az sql db import und über die REST-API wird nicht unterstützt. Der BACPAC-Import/-Export für kleinere Hyperscale-Datenbanken (bis zu 200 GB) wird über SSMS und SqlPackage Version 18.4 und höher unterstützt. Bei größeren Datenbanken kann der BACPAC-Export/-Import sehr lange dauern und aus verschiedenen Gründen gegebenenfalls zu Fehlern führen.

Dauer und Ausfallzeit

Im Gegensatz zu regulären Vorgängen zur Änderung von Zielen der Dienstebene in Hyperscale handelt es sich bei der Migration zu Hyperscale und der umgekehrten Migration zu „Universell“ um Vorgänge, die sich auf die Datengröße beziehen.

Die Dauer einer umgekehrten Migration hängt hauptsächlich von der Größe der Datenbank und den gleichzeitigen Schreibaktivitäten während der Migration ab. Die Anzahl der virtuellen Kerne, die Sie der Zieldatenbank auf Dienstebene „Universell“ zuweisen, wirkt sich auch auf die Dauer der umgekehrten Migration aus. Es wird empfohlen, die Zieldatenbank mit der Dienstebene „Universell“ mit einer Anzahl von virtuellen Kernen größer oder gleich der Anzahl von virtuellen Kernen bereitzustellen, die der Quelldatenbank der Dienstebene „Hyperscale“ zugewiesen sind, um ähnliche Workloads zu unterstützen.

Während der umgekehrten Migration kann es bei der Hyperscale-Quelldatenbank zu Leistungseinbußen kommen, wenn sie stark ausgelastet wird. Insbesondere kann die Transaktionsprotokollrate reduziert (gedrosselt) werden, um sicherzustellen, dass die umgekehrte Migration Fortschritte macht.

Während der endgültigen Umstellung auf die neue Zieldatenbank auf der Dienstebene „Universell“ kommt es nur zu einer kurzen Ausfallzeit, die in der Regel nur wenige Minuten beträgt.

Voraussetzungen

Bevor Sie eine umgekehrte Migration aus Hyperscale zur Dienstebene „Universell“ einleiten, müssen Sie sicherstellen, dass Ihre Datenbank die Einschränkungen für umgekehrte Migration und Folgendes erfüllt:

  • Für Ihre Datenbank ist keine Georeplikation aktiviert.
  • Ihre Datenbank verfügt nicht über benannte Replikate.
  • Ihre Datenbank (zugewiesene Größe) ist klein genug, um in die Zieldienstebene zu passen.
  • Wenn Sie die maximale Datenbankgröße für die Zieldatenbank „Universell“ angeben, stellen Sie sicher, dass die zugewiesene Größe der Datenbank klein genug ist, um in diese maximale Größe zu passen.

Die erforderlichen Überprüfungen erfolgen vor dem Start der umgekehrten Migration. Wenn bestimmte Voraussetzungen nicht erfüllt sind, löst die umgekehrte Migration sofort einen Fehler aus.

Sicherungsrichtlinien

Für alle vorhandenen Datenbanksicherungen innerhalb des konfigurierten Aufbewahrungszeitraums werden Ihnen die regulären Preise in Rechnung gestellt. Die Hyperscale-Momentaufnahmen im Sicherungsspeicher und die Datengrößen-Speicherblobs, die für die Wiederherstellung der Sicherung aufbewahrt werden müssen, werden Ihnen in Rechnung gestellt.

Sie können eine Datenbank zu Hyperscale migrieren und mehrmals eine umgekehrte Migration zu „Universell“ ausführen. Nur Sicherungen der aktuellen und der vorhergehenden Ebene Ihrer Datenbank sind für die Wiederherstellung verfügbar. Wenn Sie aus der Dienstebene „Universell“ zu „Hyperscale“ und dann zurück zu „Universell“ gewechselt sind, sind die nur Sicherungen aus der aktuellen Datenbank mit der Dienstebene „Universell“ und der unmittelbar vorhergehenden Hyperscale-Datenbank verfügbar. Diese aufbewahrten Sicherungen werden gemäß der Azure SQL-Datenbank-Abrechnung abgerechnet. Für alle vorherigen Ebenen, die Sie ausprobieren, sind keine Sicherungskopien verfügbar, und sie werden nicht in Rechnung gestellt.

Sie können z. B. zwischen Hyperscale- und Nicht-Hyperscale-Dienstebenen migrieren:

  1. Universell
  2. Migrieren zu „Hyperscale“
  3. Umgekehrte Migration zu „Universell“
  4. Änderung der Dienstebene in „Unternehmenskritisch“
  5. Migrieren zu „Hyperscale“
  6. Umgekehrte Migration zu „Universell“

In diesem Fall wären nur die Sicherungen aus den Schritten 5 und 6 der Zeitachse verfügbar, wenn sie noch innerhalb des konfigurierten Aufbewahrungszeitraums liegen. Alle Sicherungen aus früheren Schritten sind nicht verfügbar. Berücksichtigen Sie sorgfältig die Verfügbarkeit von Backups, wenn Sie versuchen, dieselbe Datenbank wiederholt zwischen den Dienstebenen „Hyperscale“ und „Universell“ zu migrieren. Backups von Datenbanken, die älter sind als die unmittelbar vorhergehende Datenbank, sind nicht mehr verfügbar, sobald eine Rückwärtsmigration gestartet wird, und bleiben auch dann nicht verfügbar, wenn die Migration abgebrochen wird.

Umgekehrte Migration einer Hyperscale-Datenbank zur Dienstebene „Universell“

Um eine umgekehrte Migration einer vorhandenen Hyperscale-Datenbank in Azure SQL-Datenbank zur Dienstebene „Universell“ vorzunehmen, müssen Sie zunächst Ihr Dienstziel auf der Dienstebene „Universell“ identifizieren und angeben, ob Sie zur bereitgestellten oder serverlosen Computeebene migrieren möchten. Ziehen Sie Ressourcengrenzen für einzelne Datenbanken zu Rate, wenn Sie nicht sicher sind, welches Dienstziel für Ihre Datenbank geeignet ist.

Wenn Sie nach der umgekehrten Migration zu „Universell“ eine weitere Änderung der Dienstebene vornehmen möchten, ermitteln Sie auch Ihr mögliches Dienstziel, und stellen Sie sicher, dass die zugewiesene Größe Ihrer Datenbank klein genug ist, um in dieses Dienstziel zu passen.

Wählen Sie die Registerkarte für Ihre bevorzugte Methode aus, um eine umgekehrte Migration Ihrer Datenbank auszuführen:

Das Azure-Portal ermöglicht Ihnen eine umgekehrte Migration zur Dienstebene „Universell“, indem Sie den Tarif für Ihre Datenbank ändern.

Screenshot: Compute- und Speicherbereich einer Hyperscale-Datenbank in Azure SQL-Datenbank.

  1. Navigieren Sie zur Datenbank, die Sie im Azure-Portal migrieren möchten.
  2. Wählen Sie in der linken Navigationsleiste Compute und Speicher aus.
  3. Wählen Sie die Dropdownliste Dienstebene aus, um die Optionen für Dienstebenen zu erweitern.
  4. Wählen Sie im Dropdownlistenmenü Universell (skalierbare Compute- und Speicheroptionen) aus.
  5. Überprüfen Sie die Liste Hardwarekonfiguration. Wählen Sie, falls gewünscht, Konfiguration ändern aus, um die geeignete Hardwarekonfiguration für Ihre Workloads auszuwählen.
  6. Wählen Sie den vCores-Schieberegler aus, wenn Sie die Anzahl der für Ihre Datenbank unter der Dienstebene „Universell“ verfügbaren virtuellen Kerne ändern möchten.
  7. Wählen Sie Übernehmen.

Überwachen von Vorgängen für eine Hyperscale-Datenbank

Sie können den Status aktueller oder kürzlich abgeschlossener Vorgänge für eine Azure SQL-Datenbank über das Azure-Portal, mit der Azure CLI, mit PowerShell oder mit Transact-SQL überwachen.

Wählen Sie die Registerkarte für ihre bevorzugte Methode aus, um Vorgänge zu überwachen.

Das Azure-Portal zeigt eine Benachrichtigung für eine Datenbank in Azure SQL-Datenbank an, wenn ein Vorgang wie eine Migration, umgekehrte Migration oder Wiederherstellung aktuell ausgeführt wird.

Screenshot: Übersichtsbereich einer Datenbank in Azure SQL-Datenbank. Im Benachrichtigungsbereich am unteren Rand wird ein Hinweis auf einen laufenden Vorgang angezeigt.

  1. Navigieren zur Datenbank im Azure-Portal.
  2. Klicken Sie in der linken Navigationsleiste auf Übersicht.
  3. Überprüfen Sie den Abschnitt Benachrichtigungen unten im rechten Bereich. Wenn aktuell Vorgänge ausgeführt werden, wird ein Benachrichtigungsfeld angezeigt.
  4. Wählen Sie das Benachrichtigungsfeld aus, um Details anzuzeigen.
  5. Der Bereich Laufende Vorgänge wird geöffnet. Überprüfen Sie die Details der laufenden Vorgänge.

Anzeigen von Datenbanken in der Hyperscale-Dienstebene

Nachdem Sie eine Datenbank zu Hyperscale migriert oder eine Datenbank innerhalb der Hyperscale-Dienstebene neu konfiguriert haben, möchten Sie die Konfiguration Ihrer Hyperscale-Datenbank möglicherweise anzeigen und/oder dokumentieren.

Das Azure-Portal zeigt eine Liste aller Datenbanken auf einem logischen Server an. Die Spalte Tarif enthält die Dienstebene für jede Datenbank.

Screenshot: Übersichtsbereich eines logischen Servers in Azure SQL-Datenbank. Unten auf der Seite werden Datenbanken angezeigt.

  1. Navigieren Sie im Azure-Portal zu Ihrem logischen Server.
  2. Klicken Sie in der linken Navigationsleiste auf Übersicht.
  3. Scrollen Sie zur Liste der Ressourcen am unteren Rand des Bereichs. Im Fenster werden Pools für elastische SQL-Datenbanken und Datenbanken auf dem logischen Server angezeigt.
  4. Überprüfen Sie die Spalte Tarif, um Datenbanken in der Hyperscale-Dienstebene zu identifizieren.

Weitere Informationen zu Hyperscale-Datenbanken finden Sie in den folgenden Artikeln: