Migrieren von Datenbanken im großen Stil mithilfe von Automatisierung (Vorschau)

Die Azure SQL-Migrationserweiterung in Azure Data Studio vereint eine vereinfachte Funktionalität für Bewertung, Empfehlung und Migration, die die folgenden Funktionen bietet:

• Ein erweiterter Bewertungsmechanismus, der SQL Server-Instanzen auswerten kann und Datenbanken identifiziert, die für die Migration zu den verschiedenen Azure SQL-Zielen bereit sind.

• Eine SKU-Empfehlungs-Engine (Preview), die Leistungsdaten aus der SQL Server-Quellinstanz lokal sammelt und basierend auf Ihrem Azure SQL-Ziel die richtigen SKU-Empfehlungen generiert.

• Ein zuverlässiger Azure-Dienst, der von Azure Database Migration Service unterstützt wird und Datenverschiebungsaktivitäten orchestriert, um eine nahtlose Migrationserfahrung bereitzustellen.

• Die Möglichkeit, Migrationen entweder im Onlinemodus (für Migrationen, die minimale Ausfallzeiten erfordern) oder Offlinemodus (für Migrationen, bei denen die Ausfallzeit die gesamte Dauer der Migration anhält) auszuführen, um Ihre Geschäftsanforderungen zu erfüllen.

• Die Flexibilität, die selbstgehostete Integration Runtime zu erstellen und zu konfigurieren, um Ihre eigene Computeinstanz für den Zugriff auf SQL Server-Quellen und -Sicherungen in Ihrer lokalen Umgebung bereitzustellen.

Mit Automatisierungstools wie dem PowerShell-Modul für Azure Database Migration Service oder Azure CLI können Sie die Funktionen der Azure SQL-Migrationserweiterung zusammen mit Azure Database Migration Service anwenden, um eine oder mehrere Datenbanken im großen Stil zu migrieren (auch Datenbanken über mehrere SQL Server-Instanzen hinweg).

Auf die folgenden Beispielskripts kann mithilfe von Azure PowerShell oder der Azure CLI für Ihr Migrationsszenario verwiesen werden:

Voraussetzungen

Zu den Voraussetzungen, die für alle unterstützten Migrationsszenarien mit Azure PowerShell oder der Azure CLI gelten, zählen Folgende:

• Verwenden Sie ein Azure-Konto, das einer der unten aufgeführten integrierten Rollen zugewiesen ist:

  • Mitwirkender für die Zielinstanz von Azure SQL Managed Instance, SQL Server in Azure Virtual Machines oder Azure SQL-Datenbank und für das Speicherkonto, um Ihre Datenbanksicherungsdateien aus der SMB-Netzwerkfreigabe hochzuladen (nicht zutreffend für Azure SQL-Datenbank).

  • Leserrolle für die Azure-Ressourcengruppen, die das Ziel Azure SQL Managed Instance, SQL Server auf Azure Virtual Machines oder Azure SQL-Datenbank enthalten.

  • Rolle „Besitzer“ oder „Mitwirkender“ für das Azure-Abonnement.

  Das Azure-Konto ist nur erforderlich, wenn Sie die Migrationsschritte ausführen, und es ist nicht für Bewertungsvorgänge oder Azure-Empfehlungsschritte erforderlich.

• Erstellen einer Zielinstanz von Azure SQL Managed Instance, SQL Server in Azure Virtual Machine oder Azure SQL-Datenbank

  Wenn Azure SQL-Datenbank als Ziel verwendet wird, müssen Sie das Datenbankschema mithilfe der dacpac-Erweiterung von SQL Server oder der SQL-Datenbank-Erweiterung für Projekte für Azure Data Studio von der Quelle zum Ziel migrieren.

  Wenn Sie über eine vorhandene Azure-VM verfügen, sollte diese mit der SQL IaaS Agent-Erweiterung im vollständigen Verwaltungsmodus registriert sein.

• Wenn Azure SQL Managed Instance oder SQL Server auf Azure Virtual Machine als Ziel verwendet wird, müssen die Anmeldenamen zum Herstellen der Verbindung mit der SQL Server-Quelle Mitglieder der sysadmin-Serverrolle sein oder über die Berechtigung CONTROL SERVER verfügen.

• Wenn Azure SQL-Datenbank als Ziel verwendet wird, muss der Anmeldename zum Herstellen der Verbindung mit der SQL Server-Quelle ein Mitglied von db_datareader und der Anmeldename für den SQL-Zielserver muss db_owner sein.

• Verwenden Sie eine der folgenden Speicheroptionen für die vollständigen Datenbank- und Transaktionsprotokoll-Sicherungsdateien:

  • SMB-Netzwerkfreigabe

  • Dateifreigabe oder Blobcontainer des Azure-Speicherkontos

    • Wenn Ihre Datenbanksicherungsdateien in einer SMB-Netzwerkfreigabe bereitgestellt werden, erstellen Sie ein Azure Storage-Konto, mit dem der DMS-Dienst die Datenbanksicherungsdateien hochladen kann. Achten Sie darauf, das Azure Storage-Konto in der gleichen Region zu erstellen, in der auch die Azure Database Migration Service-Instanz erstellt wird.

    • Achten Sie darauf, dass der Blobcontainer des Azure-Speicherkontos ausschließlich zum Speichern von Sicherungsdateien verwendet wird. Alle anderen Dateitypen (TXT, PNG, JPG usw.) stören den Wiederherstellungsvorgang und führen zu einem Fehler.

    • Azure Database Migration Service initiiert keine Sicherungen, sondern verwendet für die Migration vorhandene Sicherungen, die Sie im Rahmen Ihres Notfallwiederherstellungsplans möglicherweise bereits besitzen.

    • Jede Sicherung kann entweder in eine separate Sicherungsdatei oder in mehrere Sicherungsdateien geschrieben werden. Das Anfügen mehrerer Sicherungen (vollständig und Transaktionsprotokoll) an ein einzelnes Sicherungsmedium wird jedoch nicht unterstützt.

    • Verwenden Sie komprimierte Sicherungen, um die Wahrscheinlichkeit von potenziellen Problemen bei der Migration großer Sicherungen zu verringern.

• Stellen Sie sicher, dass das Dienstkonto, das die SQL Server-Quellinstanz ausführt, über Lese- und Schreibberechtigungen für die SMB-Netzwerkfreigabe verfügt, die Datenbanksicherungsdateien enthält.

• Das Quellzertifikat der SQL Server-Instanz einer durch Transparent Data Encryption (TDE) geschützten Datenbank muss vor der Datenmigration zur Zielinstanz von Azure SQL Managed Instance oder zu SQL Server in Azure Virtual Machine migriert werden. Weitere Informationen zum Migrieren von TDE-fähigen Datenbanken finden Sie unter Tutorial: Migrieren von TDE-fähigen Datenbanken (Vorschau) zu Azure SQL in Azure Data Studio.

  Tipp

  Wenn Ihre Datenbank vertrauliche Daten enthält, die durch Always Encrypted geschützt sind, wird der Migrationsprozess unter Verwendung von Azure Data Studio mit DMS automatisch Ihre Always Encrypted-Schlüssel zu Azure SQL Managed Instance oder SQL Server in Azure Virtual Machine migrieren.

• Wenn sich Ihre Datenbanksicherungen in einer Netzwerkfreigabe befinden, stellen Sie einen Computer zur Installation der selbstgehosteten Integration Runtime bereit, um auf Datenbanksicherungen zuzugreifen und sie zu migrieren. Die Module Azure PowerShell oder die Azure CLI stellen die Authentifizierungsschlüssel bereit, um Ihre selbstgehostete Integration Runtime zu registrieren. Stellen Sie als Vorbereitung für die Migration sicher, dass auf dem Computer, auf dem Sie die selbstgehostete Integration Runtime installieren möchten, die folgenden Firewallregeln für ausgehenden Datenverkehr und Domänennamen aktiviert sind:

  Domänennamen	Ausgehende Ports	BESCHREIBUNG
  Öffentliche Cloud: {datafactory}.{region}.datafactory.azure.net oder *.frontend.clouddatahub.net Azure Government: {datafactory}.{region}.datafactory.azure.us China: {datafactory}.{region}.datafactory.azure.cn	443	Erforderlich für die selbstgehostete Integration Runtime, um eine Verbindung mit dem Datenmigrationsdienst herzustellen. Suchen Sie für eine neu erstellte Data Factory-Instanz in der öffentlichen Cloud den FQDN im Schlüssel Ihrer selbstgehosteten Integration Runtime im Format {datafactory}.{region}.datafactory.azure.net. Für eine alte Data Factory-Instanz verwenden Sie stattdessen *.frontend.clouddatahub.net, wenn Sie den FQDN nicht im Schlüssel für die selbstgehostete Integration Runtime sehen.
  download.microsoft.com	443	Erforderlich für die selbstgehostete Integration Runtime zum Herunterladen der Aktualisierungen. Wenn Sie die automatische Aktualisierung deaktiviert haben, können Sie die Konfiguration dieser Domäne überspringen.
  *.core.windows.net	443	Wird von der selbstgehosteten Integration Runtime verwendet, die eine Verbindung mit dem Azure-Speicherkonto herstellt, um Datenbanksicherungen von Ihrer Netzwerkfreigabe hochzuladen.

  Wenn Ihre Datenbanksicherungsdateien bereits in einem Azure-Speicherkonto bereitgestellt wurden, ist während des Migrationsvorgangs keine selbstgehostete Integration Runtime erforderlich.

• Stellen Sie bei Verwendung der selbstgehosteten Integration Runtime sicher, dass der Computer, auf dem die Runtime installiert ist, eine Verbindung mit der SQL Server-Quellinstanz und der Netzwerkdateifreigabe herstellen kann, auf der sich Sicherungsdateien befinden.

• Der ausgehende Port 445 muss aktiviert sein, um Zugriff auf die Netzwerkdateifreigabe zu ermöglichen.

• Wenn Sie Azure Database Migration Service zum ersten Mal verwenden, stellen Sie sicher, dass der Ressourcenanbieter Microsoft.DataMigration in Ihrem Abonnement registriert ist. Sie können die Schritte zum Registrieren des Ressourcenanbieters ausführen.

  Wenn Ihr Migrationsziel Azure SQL-Datenbank ist, benötigen Sie keine Sicherungen, um diese Migration auszuführen. Die Migration zu Azure SQL-Datenbank wird als logische Migration betrachtet, die die Voraberstellung und Datenverschiebung der Datenbank (von DMS durchgeführt) beinhaltet.

Automatisieren von Datenbankmigrationen

Mit Azure PowerShell Az.DataMigration oder der Azure CLI az datamigration können Sie Datenbanken migrieren, indem Sie die Erstellung der Azure Database Migration Service-Instanzen automatisieren, Datenbankmigrationen für die Onlinemigration konfigurieren und einen Cutover durchführen. Es gibt mehrere weitere Befehle und Funktionen, die in Azure-Beispielen dokumentiert sind.

Beispiel für die Automatisierung der Migration einer SQL Server-Datenbank mit Azure CLI: Schritt 1: Erstellen einer Azure Database Migration Service-Instanz, die die Migrationsaktivitäten Ihrer Datenbank orchestriert.

#STEP 1: Create Database Migration Service
az datamigration sql-service create --resource-group "myRG" --sql-migration-service-name "myMigrationService" --location "EastUS2"

Schritt 2: Konfigurieren und starten Sie die Onlinedatenbankmigration von der lokalen SQL Server-Instanz (mit Sicherungen in Azure Storage) zu Azure SQL Managed Instance.

#STEP 2: Start Migration
az datamigration sql-managed-instance create `
--source-location '{\"AzureBlob\":{\"storageAccountResourceId\":\"/subscriptions/mySubscriptionID/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/dbbackupssqlbits\",\"accountKey\":\"myAccountKey\",\"blobContainerName\":\"dbbackups\"}}' `
--migration-service "/subscriptions/mySubscriptionID/resourceGroups/myRG/providers/Microsoft.DataMigration/SqlMigrationServices/myMigrationService" `
--scope "/subscriptions/mySubscriptionID/resourceGroups/myRG/providers/Microsoft.Sql/managedInstances/mySQLMI" `
--source-database-name "AdventureWorks2008" `
--source-sql-connection authentication="SqlAuthentication" data-source="mySQLServer" password="myPassword" user-name="sqluser" `
--target-db-name "AdventureWorks2008" `
--resource-group myRG `
--managed-instance-name mySQLMI

Schritt 3: Führen Sie eine Cutover-Migration durch, sobald alle Sicherungen in Azure SQL Managed Instance wiederhergestellt wurden.

#STEP 3: Get migration ID and perform Cutover
$migOpId = az datamigration sql-managed-instance show --managed-instance-name "mySQLMI" --resource-group "myRG" --target-db-name "AdventureWorks2008" --expand=MigrationStatusDetails --query "properties.migrationOperationId"
az datamigration sql-managed-instance cutover --managed-instance-name "mySQLMI" --resource-group "myRG" --target-db-name "AdventureWorks2008" --migration-operation-id $migOpId

Führen Sie den folgenden Befehl aus, wenn der Fehler angezeigt wird, dass das Abonnement nicht für die Verwendung des Namespace „Microsoft.DataMigration“ registriert ist und Sie auf https://aka.ms/rps-not-found verwiesen werden, um Abonnements zu registrieren:

Register-AzResourceProvider -ProviderNamespace "Microsoft.DataMigration"

Zugehöriger Inhalt

• Az.DataMigration
• az datamigration
• data-migration-sql