Rückmigration einer Datenbank von Hyperscale

Gilt für:Azure SQL-Datenbank

Sie können eine vorhandene Hyperscale-Datenbank in der Azure SQL-Datenbank mithilfe des Azure-Portals, der Azure CLI, PowerShell oder Transact-SQL zur Dienstebene des allgemeinen Zwecks migrieren.

Die umgekehrte Migration zur Serviceebene "General Purpose" ermöglicht Kunden, die kürzlich eine vorhandene Datenbank in Azure SQL-Datenbank in "Hyperscale" konvertiert haben, im Notfall zurückzuwechseln, 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 2 virtuellen Kernen wird nicht unterstützt. Sie können die Datenbank nach Abschluss der Migration auf weniger als 2 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 umgekehrte Migration in Frage kommen, besteht die einzige Möglichkeit der Migration aus Hyperscale zu einer anderen Dienstebene als Hyperscale 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 mehrmals in Hyperscale konvertieren und mehrfach zurück zu General Purpose migrieren. 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:

Allgemeiner Zweck
In Hyperscale konvertieren
Umgekehrte Migration zu „Universell“
Änderung der Dienstebene in „Unternehmenskritisch“
In Hyperscale konvertieren
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 einer umgekehrten Migration zu „Universell“ eine weitere Dienstebenenänderung vornehmen möchten, identifizieren Sie ihr endgültiges Dienstziel. Stellen Sie sicher, dass die zugewiesene Größe Ihrer Datenbank klein genug ist, um dieses Dienstziel zu erreichen.

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.

Navigieren zur Datenbank im Azure-Portal.
Wählen Sie in der linken Navigationsleiste Compute und Speicher aus.
Wählen Sie die Dropdownliste Dienstebene aus, um die Optionen für Dienstebenen zu erweitern.
Wählen Sie im Dropdownlistenmenü Universell (skalierbare Compute- und Speicheroptionen) aus.
Überprüfen Sie die aufgeführte Hardwarekonfiguration. Wählen Sie, falls gewünscht, Konfiguration ändern aus, um die geeignete Hardwarekonfiguration für Ihre Workloads auszuwählen.
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.
Wählen Sie Anwenden.
Überwachen Sie die Konvertierung im Azure-Portal.
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. Um Details anzuzeigen, wählen Sie das Benachrichtigungsfeld aus.
5. Der Bereich Laufende Vorgänge wird geöffnet. Überprüfen Sie die Details der laufenden Vorgänge.

In diesem Codebeispiel wird az sql db update aufgerufen, um eine umgekehrte Migration einer vorhandenen Hyperscale-Datenbank zur Dienstebene „Universell“auszuführen. Sie müssen sowohl die Edition als auch das Dienstziel angeben. Sie können Provisioned oder Serverless für das Computezielmodell auswählen.

Ersetzen Sie resourceGroupName, serverName, databaseName und serviceObjective durch die entsprechenden Werte, bevor Sie das folgende Codebeispiel ausführen:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel

Sie können optional das maxsize-Argument einschließen. Wenn der maxsize-Wert die maximal zulässige Größe für das Dienstziel überschreitet, wird ein Fehler zurückgegeben. Wenn das maxsize-Argument nicht angegeben wird, wird der Vorgang standardmäßig auf die maximale Größe festgelegt, die für das angegebene Dienstziel verfügbar ist. Im folgenden Beispiel wird maxsize angegeben:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"
maxsize="200GB"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel --max-size $maxsize

Überwachen Sie den laufenden Vorgang mit az sql db op list. So geben Sie aktuelle oder laufende Vorgänge für eine Datenbank in der Azure SQL-Datenbank zurück:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"

az sql db op list -g $resourceGroupName -s $serverName -n $databaseName

In diesem Codebeispiel wird das Cmdlet Set-AzSqlDatabase verwendet, um die Migration einer vorhandenen Datenbank von Hyperscale auf die Dienstebene für allgemeine Zwecke rückgängig zu machen. Sie müssen sowohl die Edition als auch das Dienstziel angeben. Sie können Provisioned oder Serverless für die Computezielebene auswählen.

Ersetzen Sie $resourceGroupName, $serverName, $databaseName, $serviceObjective und $computeModel durch die entsprechenden Werte, bevor Sie dieses Codebeispiel ausführen:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"
$maxSizeBytes = "268435456000"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective -MaxSizeBytes $maxSizeBytes

Überwachen Sie den laufenden Vorgang mit dem Cmdlet Get-AzSqlDatabaseActivity , das aktuelle oder laufende Vorgänge für eine Datenbank in azure SQL-Datenbank zurückgibt. Legen Sie die $resourceGroupName-, $serverName- und $databaseName-Parameter auf die entsprechenden Werte für Ihre Datenbank fest, bevor Sie den Beispielcode ausführen:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"

Get-AzSqlDatabaseActivity -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -DatabaseName $databaseName

Um die Migration einer Hyperscale-Datenbank auf die Dienstebene für allgemeine Zwecke mit Transact-SQL rückgängig zu machen, stellen Sie zunächst eine Verbindung mit der master Datenbank auf Ihrem logischen SQL-Server mithilfe von SQL Server Management Studio (SSMS) her.

Sie müssen sowohl die Edition als auch das Dienstziel in der ALTER DATABASE-Anweisung angeben.

In dieser Beispielausweisung wird eine Datenbank namens mySampleDatabase zur Dienstebene „Universell“ mit dem Dienstziel GP_Gen5_4 migriert. Ersetzen Sie den Datenbanknamen und das Dienstziel durch die entsprechenden Werte, bevor Sie die Anweisung ausführen.

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2');
GO

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2', MAXSIZE = 200 GB);
GO

Um Vorgänge für eine Hyperscale-Datenbank zu überwachen, stellen Sie mithilfe von master, der Mssql-Erweiterung für Visual Studio Code oder dem Client Ihrer Wahl eine Verbindung mit der Datenbank Ihres logischen Servers her, um Transact-SQL Befehle auszuführen.

Fragen Sie die sys.dm_operation_status Dynamische Verwaltungsansicht ab, um Informationen über aktuelle Vorgänge zu überprüfen, die für Datenbanken auf Ihrem logischen Server ausgeführt wurden.

Die sys.dm_operation_status dynamische Verwaltungsansicht gibt Vorgänge zurück, die nach Aktualität sortiert sind. Ersetzen Sie den Datenbanknamen durch den entsprechenden Wert, bevor Sie das Codebeispiel ausführen.

SELECT *
FROM sys.dm_operation_status
WHERE major_resource_id = 'mySampleDatabase'
ORDER BY start_time DESC;
GO

Feedback

War diese Seite hilfreich?

Last updated on 2025-07-18