Tutorial: Migration von SQL Server zu SQL Server auf Azure-VMs mit DMS

  • Artikel

Sie können Azure Database Migration Service und die Azure SQL Migration-Erweiterung in Azure Data Studio verwenden, um Datenbanken mit minimaler Ausfallzeit von einer lokalen Instanz von SQL Server zu SQL Server in Azure Virtual Machines (SQL Server 2016 und höher) zu migrieren.

Informationen zu Methoden zur Datenbankmigration, für die etwas manueller Aufwand erforderlich ist, finden Sie im Artikel Migration von SQL Server-Instanzen zu SQL Server auf Azure Virtual Machines.

In diesem Tutorial migrieren Sie die Datenbank AdventureWorks2022 mithilfe von Azure Data Studio mit dem Azure Database Migration Service mit minimaler Downtime von einer lokalen SQL Server-Instanz zu einer SQL Server-Instanz auf Azure Virtual Machines.

Dieses Tutorial behandelt sowohl die Offline- als auch die Onlinemigration, einschließlich einer akzeptablen Downtime während des Migrationsprozesses.

In diesem Tutorial lernen Sie Folgendes:

  • Starten des Assistenten zum Migrieren zu Azure SQL in Azure Data Studio
  • Ausführen einer Bewertung Ihrer SQL Server-Quelldatenbanken.
  • Sammeln von Leistungsdaten aus Ihrer SQL Server-Quellinstanz.
  • Erhalten einer Empfehlung für die SKU von SQL Server auf Azure-VM, die sich am besten für Ihre Workload eignet
  • Angeben von Details zu Ihrer SQL Server-Quellinstanz, dem Sicherungsspeicherort und der SQL Server-Zielinstanz auf Azure Virtual Machines.
  • Erstellen einer neuen Azure Database Migration Service-Instanz und Installieren der selbstgehosteten Integration Runtime, um auf den Quellserver und die Sicherungen zuzugreifen
  • Starten und Überwachen des Fortschritts der Migration
  • Führen Sie die Migrationsübernahme durch, wenn Sie bereit sind.

Voraussetzungen

Vorbereitungsmaßnahmen vor dem Ausführen des Tutorials:

  • Herunterladen und Installieren von Azure Data Studio.

  • Installieren der Azure SQL-Migrationserweiterung aus Azure Data Studio Marketplace.

  • Verwenden Sie ein Azure-Konto, das einer der folgenden integrierten Rollen zugewiesen ist:

    • Mitwirkender für die Zielinstanz von SQL Server in Azure Virtual Machines und für das Speicherkonto, auf das Sie Ihre Datenbanksicherungsdateien aus einer SMB-Netzwerkfreigabe (Server Message Block) hochladen

    • Leserrolle für die Azure-Ressourcengruppe, die die Zielinstanz von SQL Server in Azure Virtual Machines oder für Ihr Azure Storage-Konto enthält

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

    Alternativ zur Verwendung einer dieser integrierten Rollen können Sie benutzerdefinierte Rollen zuweisen.

    Wichtig

    Ein Azure-Konto ist nur erforderlich, wenn Sie die Migrationsschritte konfigurieren. Ein Azure-Konto ist für die Bewertung oder zum Anzeigen von Azure-Empfehlungen im Migrations-Assistenten in Azure Data Studio nicht erforderlich.

  • Erstellen Sie eine Zielinstanz von SQL Server in Azure Virtual Machines.

    Wichtig

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

  • Achten Sie darauf, dass die Anmeldungen, die Sie zum Verbinden der SQL Server-Quellinstanz verwenden, Mitglieder der sysadmin-Serverrolle sind oder über CONTROL SERVER-Berechtigungen verfügen.

  • Stellen Sie eine SMB-Netzwerkfreigabe, eine Dateifreigabe des Azure-Speicherkontos oder einen Blobcontainer des Azure-Speicherkontos bereit, die bzw. der alle vollständigen Datenbanksicherungsdateien Ihrer Datenbank sowie nachfolgende Sicherungsdateien des Transaktionsprotokolls enthält. Database Migration Service verwendet den Sicherungsspeicherort während der Datenbankmigration.

    • Die Azure SQL-Migrationserweiterung für Azure Data Studio führt keine Datenbanksicherungen aus und initiiert keine Datenbanksicherungen in Ihrem Namen. Vielmehr verwendet der Dienst vorhandene Datenbanksicherungsdateien für die Migration.

    • Wenn sich Ihre Datenbanksicherungsdateien in einer SMB-Netzwerkfreigabe befinden, erstellen Sie ein Azure Storage-Konto, in das der Database Migration Service die Datenbanksicherungsdateien hochladen und für das Migrieren von Datenbanken verwenden kann. Achten Sie darauf, das Azure-Speicherkonto in derselben Region zu erstellen, in der Sie Ihre Instanz von Database Migration Service erstellen.

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

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

  • Vergewissern Sie sich, 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.

  • Wenn Sie eine Datenbank migrieren, die durch Transparent Data Encryption (TDE) geschützt ist, muss das Zertifikat von der SQL Server-Quellinstanz vor der Migration von Daten zur SQL Server in Azure Virtual Machines migriert werden. Weitere Informationen finden Sie unter Verschieben einer TDE-geschützten Datenbank auf einen anderen SQL-Server.

    Tipp

    Wenn Ihre Datenbank vertrauliche Daten enthält, die durch Always Encrypted geschützt sind, migriert der Migrationsprozess Ihre Always Encrypted-Schlüssel automatisch zu Ihrer SQL Server-Zielinstanz in Azure Virtual Machines.

  • Wenn sich Ihre Datenbanksicherungen in einer Netzwerkfreigabe befinden, stellen Sie einen Computer zur Installation der selbstgehosteten Integration Runtime zur Verfügung, um auf Datenbanksicherungen zuzugreifen und sie zu migrieren. Der Migrations-Assistent stellt den Downloadlink und die Authentifizierungsschlüssel zur Verfügung, um Ihre selbstgehostete Integration Runtime herunterzuladen und zu installieren.

    Stellen Sie als Vorbereitung für die Migration sicher, dass auf dem Computer, auf dem Sie die selbstgehostete Integration Runtime installieren, die folgenden Firewallregeln für ausgehenden Datenverkehr und Domänennamen aktiviert sind:

    Domänennamen Ausgehender Port BESCHREIBUNG
    Öffentliche Cloud: {datafactory}.{region}.datafactory.azure.net
    oder *.frontend.clouddatahub.net

    Azure Government: {datafactory}.{region}.datafactory.azure.us
    Microsoft Azure, betrieben von 21Vianet: {datafactory}.{region}.datafactory.azure.cn    		 443 Für die selbstgehostete Integration Runtime erforderlich, um eine Verbindung mit dem Datenmigrationsdienst herzustellen.
    Suchen Sie für eine neu erstellte Data Factory in einer öffentlichen Cloud den vollqualifizierten Domänennamen (FQDN) im Schlüssel Ihrer selbstgehosteten Integration Runtime im Format {datafactory}.{region}.datafactory.azure.net.
    Wenn Sie im Fall einer vorhandenen Data Factory den FQDN nicht im Schlüssel der selbstgehosteten Integration finden, verwenden Sie stattdessen *.frontend.clouddatahub.net.
    download.microsoft.com 443 Erforderlich für die selbstgehostete Integration Runtime zum Herunterladen der Aktualisierungen. Falls Sie die automatische Aktualisierung deaktiviert haben, können Sie die Konfiguration dieser Domain überspringen.
    .core.windows.net 443 Wird von der selbstgehosteten Integration Runtime verwendet, die eine Verbindung mit dem Azure-Speicherkonto herstellt, um Datenbanksicherungen aus Ihrer Netzwerkfreigabe hochzuladen

    Tipp

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

  • Stellen Sie bei Verwendung einer 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.

  • Aktivieren Sie den ausgehenden Port 445, um Zugriff auf die Netzwerkdateifreigabe zu ermöglichen. Weitere Informationen finden Sie unter Empfehlungen für die Verwendung einer selbstgehosteten Integration Runtime.

  • Wenn Sie Azure Database Migration Service zum ersten Mal verwenden, vergewissern Sie sich, dass der Microsoft.DataMigration Ressourcenanbieter in Ihrem Abonnement registriert ist.

In diesem Tutorial wird eine Offlinemigration von einer SQL Server-Instanz zu einer SQL Server-Instanz in Azure Virtual Machines beschrieben.

Öffnen des Assistenten zum Migrieren zu Azure SQL in Azure Data Studio

So öffnen Sie den Assistenten zum Migrieren zu Azure SQL:

  1. Navigieren Sie in Azure Data Studio zu Verbindungen. Wählen Ihre lokale Instanz von SQL Server aus, und stellen Sie eine Verbindung mit ihr her. Sie können auch eine Verbindung mit SQL Server auf einem virtuellen Azure-Computer herstellen.

  2. Klicken Sie mit der rechten Maustaste auf die Serververbindung, und wählen Sie Verwalten aus.

  3. Wählen Sie im Servermenü unter Allgemein die Option Azure SQL Migration aus.

  4. Wählen Sie im Azure SQL Migration-Dashboard die Option Zu Azure SQL migrieren aus, um den Migrations-Assistenten zu öffnen.

    Screenshot: Öffnen des Assistenten zum Migrieren zu Azure SQL.

  5. Starten Sie auf der ersten Seite des Assistenten eine neue Sitzung, oder setzen Sie eine zuvor gespeicherte Sitzung fort.

Ausführen einer Datenbankbewertung, Sammeln von Leistungsdaten und Abrufen von Azure-Empfehlungen

  1. Wählen Sie unter Schritt 1: Datenbanken für die Bewertung im Assistenten zum Migrieren zu Azure SQL die Datenbanken aus, die Sie bewerten möchten. Klicken Sie anschließend auf Weiter.

  2. Führen Sie in Schritt 2: Bewertungsergebnisse und Empfehlungen die folgenden Schritte aus:

    1. Wählen Sie unter Azure SQL-Ziel auswählen die Option SQL Server in Azure Virtual Machine aus.

      Screenshot: Bestätigung einer Bewertung.

    2. Wählen Sie Anzeigen/Auswählen aus, um die Bewertungsergebnisse anzuzeigen.

    3. Wählen Sie in den Bewertungsergebnissen die Datenbank aus, und überprüfen Sie dann den Bewertungsbericht, um sicherzugehen, dass keine Probleme gefunden wurden.

    4. Wählen Sie Azure-Empfehlung abrufen aus, um den Empfehlungsbereich zu öffnen.

    5. Wählen Sie Jetzt Leistungsdaten sammeln aus. Wählen Sie einen Ordner auf Ihrem lokalen Computer aus, um die Leistungsprotokolle zu speichern, und wählen Sie dann Start aus.

      Azure Data Studio sammelt Leistungsdaten, bis Sie die Datenerfassung beenden oder Azure Data Studio schließen.

      Nach 10 Minuten gibt Azure Data Studio an, dass eine Empfehlung für SQL Server in Azure Virtual Machines verfügbar ist. Nachdem die erste Empfehlung generiert wurde, können Sie Datensammlung neu starten auswählen, um den Datenerfassungsprozess fortzusetzen und die SKU-Empfehlung zu präzisieren. Eine erweiterte Bewertung ist insbesondere dann nützlich, wenn Ihre Nutzungsmuster im Lauf der Zeit variieren.

    6. Wählen Sie im ausgewählten SQL Server in Azure Virtual Machines-Ziel Details anzeigen aus, um den detaillierten SKU-Empfehlungsbericht zu öffnen:

    7. Überprüfen Sie unter Empfehlungen zu SQL Server in Azure Virtual Machines überprüfen die Empfehlung. Wenn Sie eine Kopie der Empfehlung speichern möchten, aktivieren Sie das Kontrollkästchen Empfehlungsbericht speichern.

  3. Wählen Sie Schließen aus, um den Empfehlungsbereich zu schließen.

  4. Wählen Sie Weiter aus, um Ihre Datenbankmigration im Assistenten fortzusetzen.

Konfigurieren von Migrationseinstellungen

  1. Wählen Sie in Schritt 3: Azure SQL-Ziel im Assistenten zum Migrieren zu Azure SQL Ihr Azure-Konto, Ihr Azure-Abonnement, die Azure-Region oder den Speicherort sowie die Ressourcengruppe aus, die die Zielinstanz von SQL Server in Azure Virtual Machines enthält. Klicken Sie anschließend auf Weiter.

  2. Wählen Sie in Schritt 4: Migrationsmodus die Option Offlinemigration und dann Weiter aus.

    Hinweis

    Im Offlinemigrationsmodus sollte die SQL Server-Quelldatenbank nicht für Schreibaktivitäten verwendet werden, während Datenbanksicherungsdateien in der Zielinstanz von SQL Server in Azure Virtual Machines wiederhergestellt werden. Die Ausfallzeit der Anwendung hält vom Anfang des Migrationsprozesses bis zu seinem Abschluss an.

  3. Wählen Sie in Schritt 5: Datenquellenkonfiguration den Speicherort Ihrer Datenbanksicherungen aus. Ihre Datenbanksicherungen können sich entweder in einer lokalen Netzwerkfreigabe oder in einem Azure-Speicherblobcontainer befinden.

    Hinweis

    Wenn Ihre Datenbanksicherungen in einer lokalen Netzwerkfreigabe bereitgestellt werden, müssen Sie im nächsten Schritt des Assistenten eine selbstgehostete Integration Runtime einrichten. Eine selbstgehostete Integration Runtime ist erforderlich, um auf Ihre Quelldatenbanksicherungen zuzugreifen, die Gültigkeit des Sicherungssatzes zu überprüfen und Sicherungen in das Azure-Speicherkonto hochzuladen.

    Wenn sich Ihre Datenbanksicherungen bereits in einem Azure-Speicherblobcontainer befinden, brauchen Sie keine selbstgehostete Integration Runtime einzurichten.

  • Geben Sie für Sicherungen, die sich auf einer Netzwerkfreigabe befinden, die folgenden Informationen ein, oder wählen Sie sie aus:

    Name BESCHREIBUNG
    Anmeldeinformationen für die Quelle: Benutzername Die Anmeldeinformationen (Windows- und SQL-Authentifizierung) zum Herstellen einer Verbindung mit der SQL Server-Quellinstanz und Überprüfen der Sicherungsdateien.
    Anmeldeinformationen für die Quelle: Kennwort Die Anmeldeinformationen (Windows- und SQL-Authentifizierung) zum Herstellen einer Verbindung mit der SQL Server-Quellinstanz und Überprüfen der Sicherungsdateien.
    Speicherort der Netzwerkfreigabe, die Sicherungen enthält Der Speicherort der Netzwerkfreigabe, der die vollständigen und Transaktionsprotokoll-Sicherungsdateien enthält. Alle ungültigen Dateien oder Sicherungsdateien in der Netzwerkfreigabe, die nicht zum gültigen Sicherungssatz gehören, werden während des Migrationsprozesses automatisch ignoriert.
    Windows-Benutzerkonto mit Lesezugriff auf den Speicherort der Netzwerkfreigabe Die Windows-Anmeldeinformationen (Benutzername), die zum Abrufen der Sicherungsdateien über Lesezugriff auf die Netzwerkfreigabe verfügen.
    Kennwort Die Windows-Anmeldeinformationen (Kennwort), die zum Abrufen der Sicherungsdateien über Lesezugriff auf die Netzwerkfreigabe verfügen.
    Name der Zieldatenbank Sie können den Namen der Zieldatenbank während des Migrationsprozesses ändern.

  • Geben Sie für Sicherungen, die in einem Azure-Speicherblobcontainer gespeichert sind, die folgenden Informationen ein, oder wählen Sie sie aus:

    Name BESCHREIBUNG
    Name der Zieldatenbank Sie können den Namen der Zieldatenbank während des Migrationsprozesses ändern.
    Speicherkontodetails Die Ressourcengruppe, das Speicherkonto und der Container, in denen sich Sicherungsdateien befinden.
    Letzte Sicherungsdatei Der Dateiname der letzten Sicherung der Datenbank, die Sie migrieren.

    Wichtig

    Wenn die Funktion für die Überprüfung von Loopbacks aktiviert ist und sich die SQL Server-Quellinstanz und die Dateifreigabe auf dem gleichen Computer befinden, kann die Quelle nicht unter Verwendung des FQDN auf die Dateifreigabe zugreifen. Zum Beheben dieses Problems deaktivieren Sie die Loopback-Überprüfungsfunktionalität.

  • Die Azure SQL Migrationserweiterung für Azure Data Studio erfordert keine spezifischen Konfigurationen der Netzwerkeinstellungen Ihres Azure Storage-Kontos mehr, um Ihre SQL Server-Datenbanken nach Azure zu migrieren. Je nach Datenbanksicherungsspeicherort und gewünschten Netzwerkeinstellungen des Speicherkontos sind jedoch einige Schritte erforderlich, um sicherzustellen, dass Ihre Ressourcen auf das Azure Storage-Konto zugreifen können. Die folgende Tabelle enthält die verschiedenen Migrationsszenarien und Netzwerkkonfigurationen:

    Szenario SMB-Netzwerkfreigabe Azure Speicherkontocontainer
    Von allen Netzwerken aus aktiviert Keine zusätzlichen Schritte Keine zusätzlichen Schritte
    Aktiviert von ausgewählten virtuellen Netzwerken und IP-Adressen Siehe 1a Siehe 2a
    Aktiviert von ausgewählten virtuellen Netzwerken und IP-Adressen + privater Endpunkt Siehe 1b Siehe 2b

1a: Konfiguration des Azure Blob-Speicher-Netzwerks

Falls Sie Ihre selbstgehostete Integration Runtime (SHIR) auf einer Azure VM installiert haben, lesen Sie bitte Abschnitt 1b: Konfiguration des Azure Blob-Speicher-Netzwerks. Falls Sie Ihre selbstgehostete Integration Runtime (SHIR) in Ihrem lokalen Netzwerk installiert haben, müssen Sie die Client-IP-Adresse des Hosting-Rechners in Ihrem Azure Storage-Konto als solche hinzufügen:

Der Screenshot zeigt die Netzwerkdetails des Speicherkontos.

Um diese spezielle Konfiguration anzuwenden, verbinden Sie sich vom SHIR-Rechner aus mit dem Azure-Portal, öffnen Sie die Konfiguration des Azure-Speicherkontos, wählen Sie Networking und markieren Sie das Kontrollkästchen Client-IP-Adresse hinzufügen. Wählen Sie Speichern, um die Änderung zu übernehmen. Die restlichen Schritte finden Sie inAbschnitt 2a - Konfiguration des Azure Blob-Storage-Netzwerks (Privater Endpunkt).

1b - Konfiguration des Azure Blob-Speicher-Netzwerks

Falls Ihr SHIR auf einer Azure VM gehostet wird, müssen Sie das virtuelle Netzwerk der VM zum Azure Storage-Konto hinzufügen, da die virtuelle Maschine eine nicht-öffentliche IP-Adresse hat, die nicht zum Abschnitt IP-Adressbereich hinzugefügt werden kann.

Der Screenshot zeigt die Konfiguration der Netzwerk-Firewall des Speicherkontos.

Um diese spezielle Konfiguration anzuwenden, rufen Sie Ihr Azure Storage-Konto auf, wählen Sie im Fenster Datenspeicher die Option Netzwerk und markieren Sie dann das Kontrollkästchen Vorhandenes virtuelles Netzwerk hinzufügen. Es öffnet sich ein neues Fenster. Wählen Sie das Abonnement, das virtuelle Netzwerk und das Subnetz der Azure-VM, die die Integration Runtime hostet. Sie finden diese Informationen im Azure-Portal auf der Übersichtsseite für Ihre Azure Virtual Machine. Im Subnetz steht möglicherweise Service-Endpunkt erforderlich. Falls ja, wählen Sie Aktivieren. Sobald alles bereit ist, speichern Sie die Updates. Die restlichen Schritte finden Sie inA2a - Konfiguration des Azure Blob-Speicher-Netzwerks (Privater Endpunkt).

2a: Konfiguration des Azure Blob-Speicher-Netzwerks (Privater Endpunkt)

Wenn Ihre Backups direkt in einem Azure Storage Container abgelegt werden, sind alle oben genannten Schritte überflüssig, da es keine Integration Runtime gibt, die mit dem Azure Storage-Konto kommuniziert. Allerdings müssen wir immer noch sicherstellen, dass die Ziel-SQL Server-Instanz mit dem Azure Storage-Konto kommunizieren kann, um die Backups aus dem Container wiederherzustellen. Um diese spezielle Konfiguration anzuwenden, folgen Sie den Anweisungen in Abschnitt 1b: Konfiguration des Azure Blob-Storage-Netzwerks und geben Sie das virtuelle Netzwerk der Ziel-SQL-Instanz an, wenn Sie das Popup „Vorhandenes virtuelles Netzwerk hinzufügen“ ausfüllen.

2b: Konfiguration des Azure Blob-Speicher-Netzwerks (Privater Endpunkt)

Wenn Sie in Ihrem Azure Storage-Konto einen privaten Endpunkt eingerichtet haben, führen Sie die in 2a: Azure Blob Storage-Netzwerkkonfiguration (privater Endpunkt) beschriebenen Schritte aus. Sie müssen jedoch das Subnetz des privaten Endpunkts auswählen, nicht nur das Ziel-SQL-Server-Subnetz. Stellen Sie sicher, dass der private Endpunkt im selben VNet gehostet wird wie die Ziel-SQL Server-Instanz. Wenn dies nicht der Fall ist, erstellen Sie einen anderen privaten Endpunkt, indem Sie das Verfahren im Abschnitt zur Konfiguration des Azure Storage-Kontos anwenden.

Erstellen einer Database Migration Service-Instanz

Erstellen Sie in Schritt 6: Azure Database Migration Service im Assistenten zum Migrieren zu Azure SQL eine neue Instanz von Azure Database Migration Service, oder verwenden Sie eine vorhandene Instanz, die Sie zuvor erstellt haben.

Hinweis

Wenn Sie zuvor mithilfe des Azure-Portals eine Database Migration Service-Instanz erstellt haben, können Sie die Instanz nicht im Migrations-Assistenten in Azure Data Studio wiederverwenden. Sie können eine Instanz nur dann wiederverwenden, wenn Sie sie mithilfe von Azure Data Studio erstellt haben.

Verwenden einer vorhandenen Instanz von Database Migration Service

So verwenden Sie eine vorhandene Instanz von Database Migration Service:

  1. Wählen Sie unter Ressourcengruppe die Ressourcengruppe aus, die eine vorhandene Instanz von Database Migration Service enthält.

  2. Wählen Sie in Azure Database Migration Service eine vorhandene Instanz von Database Migration Service aus, die sich in der ausgewählten Ressourcengruppe befindet.

  3. Wählen Sie Weiter aus.

Erstellen einer neuen Instanz von Database Migration Service

So erstellen Sie eine neue Instanz von Database Migration Service:

  1. Erstellen Sie in Ressourcengruppe eine neue Ressourcengruppe zur Aufnahme einer neuen Instanz von Database Migration Service.

  2. Wählen Sie unter Azure Database Migration Service die Schaltfläche Erstellen aus.

  3. Geben Sie unter Azure Database Migration Service erstellen einen Namen für Ihre Database Migration Service-Instanz ein, und wählen Sie dann Erstellen aus.

  4. Führen Sie unter Integration Runtime einrichten die folgenden Schritte aus:

    1. Wählen Sie den Link Integration Runtime herunterladen und installieren aus, um den Downloadlink in einem Webbrowser zu öffnen. Laden Sie die Integration Runtime herunter, und installieren Sie sie dann auf einem Computer, der die Voraussetzungen für eine Verbindung mit der SQL Server-Quellinstanz erfüllt.

      Nach Abschluss der Installation wird der Konfigurations-Manager für Microsoft Integration Runtime automatisch geöffnet, um den Registrierungsprozess zu starten.

    2. Kopieren Sie in der Tabelle Authentifizierungsschlüssel einen der im Assistenten bereitgestellten Authentifizierungsschlüssel, und fügen Sie ihn in Azure Data Studio ein. Wenn der Authentifizierungsschlüssel gültig ist, wird im Integration Runtime Configuration Manager ein grünes Häkchensymbol angezeigt. Ein grünes Häkchen zeigt an, dass Sie mit der Registrierung fortfahren können.

      Schließen Sie nach dem Registrieren der selbstgehosteten Integration Runtime den Konfigurations-Manager für Microsoft Integration Runtime.

      Hinweis

      Weitere Informationen zur Verwendung der selbstgehosteten Integration Runtime finden Sie unter Erstellen und Konfigurieren einer selbstgehosteten Integration Runtime.

  5. Wählen Sie unter Azure Database Migration Service erstellen in Azure Data Studio die Option Verbindung testen aus, um zu überprüfen, ob die neu erstellte Instanz von Database Migration Service mit der neu registrierten selbstgehosteten Integration Runtime verbunden ist.

  6. Kehren Sie zum Migrations-Assistenten in Azure Data Studio zurück.

Starten der Datenbankmigration

Überprüfen Sie in Schritt 7: Zusammenfassung im Assistenten zum Migrieren zu Azure SQL die von Ihnen erstellte Konfiguration, und wählen Sie dann Migration starten aus, um die Datenbankmigration zu starten.

Überwachen der Datenbankmigration

  1. Wählen Sie in Azure Data Studio im Servermenü unter Allgemein die Option Azure SQL-Migration aus, um zum Dashboard für Ihre Azure SQL-Migrationen zu wechseln.

    Unter Datenbankmigrationsstatus können Sie Migrationen nachverfolgen, die aktuell ausgeführt werden, abgeschlossen oder fehlgeschlagen sind (falls vorhanden), oder Sie können alle Datenbankmigrationen anzeigen.

    Screenshot der Überwachung des Migrationsdashboards.

  2. Wählen Sie Datenbankmigrationen werden ausgeführt aus, um aktive Migrationen anzuzeigen.

    Wenn Sie weitere Informationen zu einer bestimmten Migration erhalten möchten, wählen Sie den Datenbanknamen aus.

    Im Bereich mit den Migrationsdetails werden die Sicherungsdateien und der entsprechende Status angezeigt:

    Status BESCHREIBUNG
    Angekommen Die Sicherungsdatei ist am Speicherort der Quellsicherung eingegangen und wurde überprüft.
    Hochladen Die Integration Runtime lädt die Sicherungsdatei in Azure Storage hoch.
    Hochgeladen Die Sicherungsdatei wurde in Azure Storage hochgeladen.
    Wiederherstellen Der Dienst stellt die Sicherungsdatei in SQL Server in Azure Virtual Machines wieder her.
    Wiederhergestellt Die Sicherungsdatei wurde erfolgreich in SQL Server in Azure Virtual Machines wiederhergestellt.
    Canceled Der Migrationsprozess wurde abgebrochen.
    Wird ignoriert Die Sicherungsdatei wurde ignoriert, da sie nicht zu einer gültigen Datenbanksicherungskette gehört

Nachdem alle Datenbanksicherungen in der Instanz von SQL Server in Azure Virtual Machines wiederhergestellt wurden, wird vom Database Migration Service eine automatische Umstellung auf die Migration eingeleitet, um sicherzustellen, dass die migrierte Datenbank einsatzbereit ist. Der Migrationsstatus ändert sich von In Bearbeitung in Erfolgreich.

Begrenzungen

– Beim Migrieren einer einzelnen Datenbank müssen die Datenbanksicherungen in einer Flatfilestruktur in einem Datenbankordner (einschließlich Stammordner des Containers) abgelegt werden, und die Ordner können nicht geschachtelt werden, da dies nicht unterstützt wird.

– Wenn Sie mehrere Datenbanken mit demselben Azure BLOB Storage-Container migrieren, müssen Sie Sicherungsdateien für unterschiedliche Datenbanken in separate Ordner innerhalb des Containers platzieren.

– Das Überschreiben vorhandener Datenbanken mit DMS in Ihrer SQL Server-Zielinstanz in Azure Virtual Machines wird nicht unterstützt.

– Das Konfigurieren von Hochverfügbarkeit und Notfallwiederherstellung auf Ihrem Ziel entsprechend der Quelltopologie wird von DMS nicht unterstützt.

Die folgenden Serverobjekte werden nicht unterstützt:

  • Aufträge des SQL Server-Agents
  • Anmeldeinformationen
  • SSIS-Pakete
  • Serverüberwachung

– Sie können keine vorhandene selbstgehostete Integration Runtime verwenden, die aus Azure Data Factory für Datenbankmigrationen mit DMS erstellt wurde. Anfänglich sollte die selbstgehostete Integration Runtime mithilfe der Azure SQL-Migrationserweiterung in Azure Data Studio erstellt werden. Sie kann für weitere Datenbankmigrationen wiederverwendet werden.

– Bei der Migration zu SQL Server in Azure Virtual Machines werden VMs mit SQL Server 2008 und niedriger als Zielversionen nicht unterstützt.

– Wenn Sie eine VM mit SQL Server 2012 oder SQL Server 2014 verwenden, müssen Sie die Sicherungsdateien Ihrer Quelldatenbank in einem Azure Storage Blob-Container speichern, anstatt die Netzwerkfreigabeoption zu verwenden. Speichern Sie die Sicherungsdateien als Seitenblobs, weil Blockblobs nur in SQL 2016 und höher unterstützt werden.

– Sie müssen sicherstellen, dass sich die SQL-IaaS-Agent-Erweiterung auf dem virtuellen Azure-Zielcomputer nicht im Lightweightmodus, sondern im vollständigen Modus befindet.

– Bei der Migration zur Azure SQL-VM mit DMS wird intern SQL-IaaS-Agent verwendet. Die SQL-IaaS-Agent-Erweiterung unterstützt nur die Verwaltung der Standardserverinstanz oder einer einzelnen benannten Instanz.

– Sie können maximal 100 Datenbanken zu derselben Azure SQL Server-VM wie das Ziel migrieren, indem Sie mindestens eine Migration gleichzeitig verwenden. Warten Sie außerdem nach Abschluss einer (oder mehrerer) Migration mit 100 Datenbanken mindestens 30 Minuten, bevor Sie eine neue Migration zur gleichen Azure SQL Server-VM wie das Ziel starten. Jeder Migrationsvorgang (Migrationsstart, Cutover) für jede Datenbank dauert einige Minuten. Zum Migrieren von 100 Datenbanken kann es beispielsweise ca. 200 (2 · 100) Minuten dauern, bis die Migrationswarteschlangen erstellt wurden, und ca. 100 (1 ·100) Minuten, bis ein Cutover für alle 100 Datenbanken (mit Ausnahme des Zeitraums für Sicherung und Wiederherstellung) ausgeführt wurde. Daher wird die Migration langsamer, wenn die Anzahl der Datenbanken zunimmt. Sie sollten entweder im Voraus ein längeres Migrationsfenster auf der Grundlage strenger Migrationstests planen oder eine große Anzahl von Datenbanken in Batches partitionieren, wenn sie zu einem virtuellen Azure-Computer mit SQL Server migriert werden.

– Sie müssen das Netzwerk/die Firewall Ihres Azure Storage-Kontos so konfigurieren, dass Ihr virtueller Computer auf Sicherungsdateien zugreifen kann. Außerdem müssen Sie das Netzwerk/die Firewall Ihres SQL Servers auf dem virtuellen Azure-Computer so einrichten, dass eine ausgehende Verbindung mit Ihrem Speicherkonto möglich ist.

– Sie müssen den SQL-Zielserver auf dem virtuellen Azure-Computer aktiviert lassen, während die SQL-Migration ausgeführt wird. Wenn Sie eine neue Migration erstellen, führen Sie außerdem ein Failover aus, oder brechen Sie die Migration ab.

Mögliche Fehlermeldungen

Fehler bei der Anmeldung für Benutzer 'NT Service\SQLIaaSExtensionQuery

Fehler: Login failed for user 'NT Service\SQLIaaSExtensionQuery

Grund: SQL Server-Instanz befindet sich im Einzelbenutzermodus. Ein möglicher Grund ist, dass sich der SQL-Zielserver auf einem virtuellen Azure-Computer im Upgrade-Modus befindet.

Lösung: Warten Sie, bis der SQL-Zielserver auf einem virtuellen Azure-Computer den Upgrade-Modus beendet, und starten Sie die Migration erneut.

Fehler beim Erstellen eines Wiederherstellungsauftrags

Fehler: Ext_RestoreSettingsError, message: Failed to create restore job.;Cannot create file 'F:\data\XXX.mdf' because it already exists.

Lösung: Stellen Sie eine Verbindung mit dem SQL-Zielserver auf dem virtuellen Azure-Computer her, und löschen Sie die Datei XXX.mdf. Starten Sie dann die Migration erneut.

Zugehöriger Inhalt