Freigeben über


Vorbereiten der Umgebung für die LRS-Migration – SQL Server Migration in Azure Arc

Gilt für:SQL Server

In diesem Artikel wird Ihnen dabei geholfen, Ihre Umgebung für eine Migration der SQL Server-Instanz, die durch Azure Arc im Azure-Portal aktiviert wurde, zum Azure SQL Managed Instance unter Nutzung des Log Replay Service (LRS) vorzubereiten.

Mit LRS können Sie Ihre SQL Server Datenbanken mithilfe der Sicherung und Wiederherstellung über den Protokollversand (Onlinemigration) zu Azure SQL Managed Instance migrieren:

Diagramm, das die Migration des Log Replay-Dienstes darstellt.

Hinweis

Sie können Feedback zu Ihrer Migrationserfahrung direkt an die Produktgruppe senden.

Voraussetzungen

Um Ihre SQL Server Datenbanken über das Azure Portal zu Azure SQL Managed Instance zu migrieren, benötigen Sie die folgenden Voraussetzungen:

Unterstützte SQL Server Versionen

Die Migration mit LRS funktioniert mit jeder Edition von SQL Server auf Windows. Während die Migration zu den Dienstebenen "Allgemeiner Zweck" und "Geschäftskritischer Dienst" SQL Managed Instance unterstützt wird, hat die Migration direkt zur Business Critical-Dienstebene einige importanten Einschränkungen zu berücksichtigen.

In der folgenden Tabelle sind die mindestens unterstützten SQL Server Versionen für LRS aufgeführt:

SQL Server Version Minimale erforderliche Wartungsaktualisierung
SQL Server 2025 (17,x) SQL Server 2025 RTM (17.0.1000.7)
SQL Server 2022 (16.x) SQL Server 2022 RTM (16.0.1000.6)
SQL Server 2019 (15.x) SQL Server 2019 RTM (15.0.2000.5)
SQL Server 2017 (14.x) SQL Server 2017 RTM (14.0.1000.169)
SQL Server 2016 (13.x) SQL Server 2016 RTM (13.0.1400.361)
SQL Server 2014 (12.x) SQL Server 2014 RTM (12.0.2000.8)
SQL Server 2012 (11.x) SQL Server 2012 RTM (11.0.2100.60)

Die Reverse-Migration wird nur für SQL Server 2025 und SQL Server 2022 von SQL-verwalteten Instanzen mit der entsprechenden Update-Richtlinie unterstützt. Sie können eine Migration manuell über andere Tools wie systemeigene Sicherung und Wiederherstellung rückgängig machen oder einen Link in SSMS manuell konfigurieren.

Hinweis

Bei nicht unterstützten SQL Server Instanzen wie z. B. früher als SQL Server 2012 oder unter Linux sollten Sie die Verwendung von Log Replay Service direkt zum Migrieren zu Azure SQL Managed Instance in Betracht ziehen.

Erlaubnisse

In diesem Abschnitt werden die Berechtigungen beschrieben, die Sie zum Migrieren Ihrer SQL Server Instanz zum SQL Managed Instance über das Azure-Portal benötigen.

Für die Quellinstanz SQL Server benötigen Sie die folgenden Berechtigungen:

  • Wenn Sie das Prinzip der minimalen Berechtigung aktivieren, werden erforderliche Berechtigungen wie sysadmin während des Datenbankmigrationsprozesses nach Bedarf erteilt.
  • Wenn Sie das Prinzip der geringsten Privilegien nicht anwenden können, benötigen Sie sysadmin Berechtigungen für die Quellinstanz des SQL Server.

Zum Migrieren mit LRS benötigen Sie eine der folgenden Berechtigungen für das SQL Managed Instance Ziel:

Speicherkonto erstellen

Sie verwenden ein Azure Blob Storage Konto als zwischengeschalteten Speicher für Sicherungsdateien zwischen Ihrer SQL Server Instanz und Ihrer SQL Managed Instance Bereitstellung. Das Speicherkonto muss sich im selben Azure-Abonnement wie Ihr SQL Managed Instance Ziel befinden.

So erstellen Sie ein neues Speicherkonto und einen Blobcontainer im Speicherkonto:

  1. Erstellen eines Speicherkontos:
    1. Suchen Sie im Azure Portal nach Storage-Konten, und wählen Sie Create aus.
    2. Wählen Sie auf der Registerkarte " Grundlagen " Ihre Abonnement- und Ressourcengruppe aus. Die Region sollte mit Ihrem SQL Managed Instance Ziel identisch sein.
    3. Lassen Sie den bevorzugten Speichertyp leer.
    4. Verwenden Sie die Standardeinstellungen für die restlichen Registerkarten, und wählen Sie "Überprüfen+ erstellen" aus.
    5. Wenn die Überprüfung erfolgreich war, wählen Sie Erstellen aus.
  2. Erstellen Sie einen Blobcontainer im Speicherkonto.
    1. Wechseln Sie zum neuen Speicherkonto im Azure-Portal.
    2. Wählen Sie unter Datenspeicher die Option Container aus.
    3. Verwenden Sie "Container hinzufügen" , um den Bereich "Neuer Container " zu öffnen.
    4. Geben Sie einen Namen für Ihren Container ein, lassen Sie die Standardoptionen bei, und wählen Sie "Erstellen" aus, um Ihren Container zu erstellen.
  3. (Optional) Wenn sich Ihr Azure Storage hinter einer Firewall befindet, erfordert Ihr Azure Blob-Speicher zusätzliche Konfiguration, nachdem die verwaltete SQL-Instanz bereitgestellt wurde.

Erteilen von Berechtigungen für Azure Blob Storage

SQL Server Migration in Azure Arc mit LRS verwendet eine verwaltete Identität, um sich bei Azure Blob Storage zu authentifizieren.

Sie müssen die folgenden Berechtigungen erteilen:

Gewähren des Benutzerzugriffs auf das Speicherkonto

Um während des Migrationsprozesses auf Datenbanksicherungen zuzugreifen, müssen Sie den Benutzer, der sich beim Azure-Portal anmeldet und die Migration durchführt, der Rolle "Storage Blob Data Reader" für das Speicherkonto zuweisen, das die Sicherungen enthält.

Führen Sie die folgenden Schritte aus, um die Rolle zuzuweisen:

  1. Wechseln Sie im Azure-Portal zur Ressourcengruppe, die Ihr Speicherkonto enthält.

  2. Klicken Sie im Menü „Ressource“ auf Zugriffssteuerung (IAM).

  3. Verwenden Sie +Hinzufügen , um " Rollenzuweisung hinzufügen " auszuwählen und den Bereich "Rollenzuweisung hinzufügen " zu öffnen.

  4. Suchen Sie nach der Rolle "Storage Blob Data Reader ", und wählen Sie sie aus. Wählen Sie anschließend Weiter aus.

    Screenshot zum Auffinden der Rolle

  5. Verwenden Sie +Mitglieder auswählen , um den Bereich " Mitglieder auswählen " zu öffnen und nach dem Benutzerkonto der Person zu suchen, die die Migration durchführt. Wenn mehrere Personen Daten migrieren, gewähren Sie all diesen Benutzern diesen Zugriff. Wählen Sie das Benutzerkonto aus und verwenden Sie Auswählen, um Ihre Auswahl zu speichern. Aktivieren Sie die Option zum Zuweisen des Zugriffs auf Den Benutzer, die Gruppe oder den Dienstprinzipal.

  6. Wählen Sie "Überprüfen" und "Zuweisen " aus, um zur Registerkarte " Überprüfen+ Zuweisen " zu wechseln, und wählen Sie dann erneut "Überprüfen" aus , um die Rollenzuweisung abzuschließen.

Gewähren des Benutzerzugriffs auf die Ressourcengruppe

Um während des Migrationsprozesses auf Datenbanksicherungen zuzugreifen, muss dem Benutzer, der sich beim Azure Portal anmeldet und die Migration durchführt, die Rolle Reader in der Ressourcengruppe zugewiesen werden, die das Speicherkonto enthält.

Führen Sie die folgenden Schritte aus, um die Rolle zuzuweisen:

  1. Wechseln Sie im Azure-Portal zur Ressourcengruppe, die Ihr Speicherkonto enthält.

  2. Klicken Sie im Menü „Ressource“ auf Zugriffssteuerung (IAM).

  3. Verwenden Sie +Hinzufügen , um " Rollenzuweisung hinzufügen " auszuwählen und den Bereich "Rollenzuweisung hinzufügen " zu öffnen.

  4. Suchen Sie nach der Reader-Rolle , und wählen Sie sie aus. Wählen Sie anschließend Weiter aus.

    Screenshot zum Auffinden der Rolle „Reader“ auf der Seite „IAM“ für die Ressourcengruppe im Azure-Portal.

  5. Verwenden Sie +Mitglieder auswählen , um den Bereich " Mitglieder auswählen " zu öffnen und nach dem Benutzerkonto der Person zu suchen, die die Migration durchführt. Wenn mehrere Personen Daten migrieren, gewähren Sie all diesen Benutzern diesen Zugriff. Wählen Sie das Benutzerkonto aus und verwenden Sie Auswählen, um Ihre Auswahl zu speichern. Aktivieren Sie die Option zum Zuweisen des Zugriffs auf Den Benutzer, die Gruppe oder den Dienstprinzipal, und verwenden Sie dann "Weiter ", um fortzufahren.

  6. Legen Sie auf der Registerkarte " Zuordnungstyp " den Zuordnungstyp auf "Aktiv " und die Dauer der Zuordnung auf "Dauerhaft" fest:

    Screenshot zum Festlegen des Zuordnungstyps auf

  7. Wählen Sie "Überprüfen" und "Zuweisen " aus, um zur Registerkarte " Überprüfen+ Zuweisen " zu wechseln, und wählen Sie dann erneut "Überprüfen" aus , um die Rollenzuweisung abzuschließen.

Zugriff auf das Speicherkonto für verwaltete Identitäten gewähren

Nachdem Ihre sql verwaltete Instanz bereitgestellt wurde, müssen Sie die verwaltete Identität Ihrer sql-verwalteten Instanz dem Storage Blob Data Reader Rolle zuweisen, damit sie während des Migrationsprozesses auf Ihr Azure Blob Storage Konto zugreifen kann.

Zunächst müssen Sie bestimmen, welche Art verwalteter Identität Ihre verwaltete SQL-Instanz verwendet. Führen Sie dazu die folgenden Schritte aus:

  1. Wechseln Sie im Azure-Portal zu Ihrer SQL-verwalteten Instanz.
  2. Wählen Sie unter Sicherheit die Option Identität aus.
    1. Wenn unter der vom Benutzer zugewiesenen verwalteten Identität, keine vom Benutzer zugewiesenen verwalteten Identitäten gefunden werden, verwendet Ihre von SQL verwaltete Instanz die standardmäßige vom System zugewiesene verwaltete Identität.
    2. Wenn ein Eintrag im Feld "Primäre Identität " angezeigt wird, verwendet Ihre verwaltete SQL-Instanz eine benutzerdefinierte , vom Benutzer zugewiesene verwaltete Identität. Notieren Sie sich diese Identität, die Sie im Schritt verwenden möchten, in dem Sie diese verwaltete Identität auswählen, wenn Sie dem Speicher-Blob-Datenleser Zugriff auf das Speicherkonto gewähren.

Führen Sie die folgenden Schritte aus, um Zugriff auf das Speicherkonto zu gewähren:

  1. Wechseln Sie zum Azure Blob Storage Konto im Azure Portal, das Sie für die Migration verwenden möchten.
  2. Klicken Sie im Menü „Ressource“ auf Zugriffssteuerung (IAM).
  3. Verwenden Sie +Hinzufügen , um " Rollenzuweisung hinzufügen " auszuwählen und den Bereich "Rollenzuweisung hinzufügen " zu öffnen.
  4. Suchen Sie nach der Rolle "Storage Blob Data Reader ", und wählen Sie sie aus. Wählen Sie anschließend Weiter aus.
  5. Unter "Zugriff zuweisen" wählen Sie die Option "Verwaltete Identität" aus.
  6. Verwenden Sie "Mitglieder auswählen" , um den Bereich " Mitglieder auswählen " zu öffnen.
  7. Wenn Ihre von SQL verwaltete Instanz die standardmäßige vom System zugewiesene verwaltete Identität verwendet:
    1. Wählen Sie unter "Verwaltete Identität" die verwaltete SQL-Instanz aus.
    2. Suchen Und wählen Sie den Namen Ihrer sql-verwalteten Instanz aus.
    3. Verwenden Sie "Auswählen" , um Ihre Auswahl zu speichern.
  8. Wenn Ihre von SQL verwaltete Instanz eine vom Benutzer zugewiesene verwaltete Identität verwendet:
    1. Wählen Sie unter "Verwaltete Identität" die Option "Vom Benutzer zugewiesene verwaltete Identität" aus.
    2. Suchen Sie auf der Seite "Identität" Ihrer verwalteten SQL-Instanz nach dem Namen der primären Identität, den Sie zuvor erwähnt haben, und wählen Sie ihn aus.
    3. Verwenden Sie "Auswählen" , um Ihre Auswahl zu speichern.
  9. Wählen Sie "Überprüfen" und "Zuweisen " aus, um zur Registerkarte " Überprüfen+ Zuweisen " zu wechseln, und wählen Sie dann erneut "Überprüfen" aus , um die Rollenzuweisung abzuschließen.

Nachdem Sie mindestens eine vollständige Sicherung in dieses Speicherkonto hochgeladen haben, können Sie den folgenden Befehl in Ihrer sql-verwalteten Instanz ausführen, um zu überprüfen, ob sie auf Ihr Azure Blob Storage Konto zugreifen kann:

RESTORE HEADERONLY
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak';

Konfigurieren der Quell-SQL Server-Datenbank

Aktivieren Sie die beschleunigte Datenbankwiederherstellung und den Service Broker für Ihre Quell-SQL Server Instanz, wenn Sie beabsichtigen, diese Features für das Ziel SQL Managed Instance nach der Migration zu verwenden, da diese Features nach der Migration nicht aktiviert werden können, wenn sie noch nicht für die Quellinstanz SQL Server aktiviert sind.

Aktivieren der beschleunigten Datenbankwiederherstellung

Aktivieren Sie für SQL Server 2019 und höhere Versionen Accelerated Database Recovery, und stellen Sie sicher, dass der permanente Versionsspeicher (PVS) auf PRIMARY festgelegt ist. Wenn die beschleunigte Datenbankwiederherstellung für die Quelldatenbank SQL Server Datenbank nicht aktiviert ist, können Sie sie nicht für die von SQL verwaltete Zielinstanz aktivieren, nachdem die Datenbank migriert wurde. Wenn der permanente Versionsspeicher (PVS) nicht auf PRIMARY festgelegt ist, können Probleme mit Wiederherstellungsvorgängen auf der verwalteten SQL-Zielinstanz auftreten.

Bei SQL Server 2017 und früheren Versionen wird die beschleunigte Datenbankwiederherstellung nicht unterstützt, daher ist dieser Schritt nicht erforderlich.

Führen Sie die folgenden Schritte aus, um die beschleunigte Datenbankwiederherstellung für die Quelldatenbank SQL Server ordnungsgemäß zu konfigurieren:

  1. Aktivieren Sie die beschleunigte Datenbankwiederherstellung, indem Sie das folgende Transact-SQL Skript auf SQL Server ausführen:

    ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
    
  2. Der permanente Versionsspeicher (PVS) muss in der Quelldatenbank auf PRIMARY eingestellt werden, was die Standardkonfiguration darstellt. Wenn dies zuvor geändert wurde, müssen Sie sie wieder in PRIMARY ändern , bevor Sie die Migration starten.

Aktivieren des Dienstbrokers

Service Broker ist standardmäßig für alle Versionen von SQL Server aktiviert. Wenn Service Broker deaktiviert wurde und Sie ihn in SQL Managed Instance verwenden möchten, aktivieren Sie Service Broker auf der SQL Server Quelldatenbank, bevor Sie zu SQL Managed Instance migrieren. Wenn der Dienstbroker für die Quelldatenbank SQL Server nicht aktiviert ist, können Sie ihn nicht für die von SQL verwaltete Zielinstanz verwenden.

Um zu überprüfen, ob der Dienstbroker aktiviert ist, führen Sie das folgende Transact-SQL Skript auf SQL Server Instanz aus:

SELECT name AS [Database Name], is_broker_enabled AS [Service Broker Enabled]
FROM sys.databases
WHERE name = '<database name>';

Wenn der Dienstbroker deaktiviert ist, aktivieren Sie ihn, indem Sie das folgende Transact-SQL Skript in der Quelldatenbank SQL Server Datenbank ausführen:

USE master;
GO

ALTER DATABASE [<database name>]
    SET ENABLE_BROKER;
GO

Hochladen von Sicherungen in Ihr Blob Storage Konto

Wenn Ihr BLOB-Container bereit ist und Sie bestätigt haben, dass Ihre von SQL verwaltete Instanz auf den Container zugreifen kann, können Sie mit dem Hochladen Ihrer Sicherungen in Ihr Azure Blob Storage Konto beginnen. Wenn alle Ihre Sicherungen in Ihr Speicherkonto hochgeladen werden, können Sie mit der Migration fortfahren.

So laden Sie Ihre Sicherungen in Azure hoch:

Berücksichtigen Sie die folgenden bewährten Methoden:

  • Erstellen Sie Sicherungen mit COMPRESSION und CHECKSUM Optionen, um die Größe von Sicherungsdateien zu verringern und die Migration einer beschädigten Datenbank zu verhindern.
  • Nehmen Sie Sicherungen in kleineren Batches vor.
  • Verwenden Sie parallele Uploadthreads.
  • Erstellen Sie die letzte Sicherungsdatei so klein wie möglich.
  • Wenn Sie mehrere Datenbanken mithilfe desselben Azure Blob Storage-Containers migrieren möchten, platzieren Sie alle Sicherungsdateien für eine einzelne Datenbank in einem separaten Ordner im Container. Verwenden Sie für jeden Datenbankordner eine Flatfilestruktur. Das Schachteln von Ordnern innerhalb von Datenbankordnern wird nicht unterstützt.

Erstellen von Sicherungen für eine SQL Server Instanz

Legen Sie für Datenbanken, die Sie migrieren möchten, den Modus für die vollständige Wiederherstellung fest, um Protokollsicherungen zuzulassen.

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master;

ALTER DATABASE SampleDB
SET RECOVERY FULL;
GO

Wenn Sie noch nicht über vorhandene Sicherungen verfügen, verwenden Sie die folgenden T-SQL-Beispielskripts, um vollständige, differenzielle und protokollierte Sicherungen Ihrer Datenbank im lokalen Speicher manuell zu erstellen. CHECKSUM ist nicht erforderlich, aber es wird empfohlen, die Migration einer beschädigten Datenbank für schnellere Wiederherstellungszeiten zu verhindern.

Im folgenden Beispiel wird eine vollständige Datenbanksicherung auf dem lokalen Datenträger ausgeführt:

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_full.bak'
    WITH INIT, COMPRESSION, CHECKSUM;
GO

Im folgenden Beispiel wird eine differenzielle Sicherung auf dem lokalen Datenträger ausgeführt:

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_diff.bak'
    WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;
GO

Im folgenden Beispiel wird eine Transaktionsprotokollsicherung auf dem lokalen Datenträger ausgeführt:

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_log.trn'
    WITH COMPRESSION, CHECKSUM;
GO

Kopieren von Sicherungen in Ihr Blob Storage Konto

Nachdem Ihre Sicherungen fertig sind und Sie mit der Migration von Datenbanken zu einer sql-verwalteten Instanz mithilfe von LRS beginnen möchten, verwenden Sie die folgenden Ansätze, um vorhandene Sicherungen in Ihr Blob Storage Konto zu kopieren:

Hinweis

Wenn Sie mehrere Datenbanken mithilfe desselben Azure Blob Storage-Containers migrieren möchten, platzieren Sie alle Sicherungsdateien für eine einzelne Datenbank in einem separaten Ordner im Container. Verwenden Sie für jeden Datenbankordner eine Flatfilestruktur. Das Schachteln von Ordnern innerhalb von Datenbankordnern wird nicht unterstützt.

Einschränkungen

Die Einschränkungen von LRS gelten für Migrationen über das Azure-Portal.

Einschränkungen bei der Migration zur Business Critical-Dienstebene

Berücksichtigen Sie beim Migrieren zu einem SQL Managed Instance in der dienstebene Business Critical die folgenden Einschränkungen:

  • Bei der Migration großer Datenbanken kann es zu erheblichen Ausfallzeiten kommen, da Datenbanken nach dem Übergang nicht verfügbar sind, während sie auf sekundäre Replikate der Business Critical-Dienstebene repliziert werden. Problemumgehungen sind im Abschnitt Längere Cutover in der Dienstebene „Unternehmenskritisch“ aufgeführt.
  • Die Migration wird von Anfang an automatisch neu gestartet, wenn ungeplantes Failover, Systemupdate oder Sicherheitspatch die Migration unterbricht. Diese Einschränkung erschwert es, eine vorhersagbare Migration ohne Überraschungen der letzten Minute zu planen.

Von Bedeutung

Diese Einschränkungen gelten nur bei der Migration zu Azure SQL Managed Instance in der dienstebene Business Critical und nicht auf die dienstebene General Purpose.

Längere Umstellung in der geschäftskritischen Dienstebene.

Wenn Sie zu einer SQL Managed Instance im Business Critical-Dienstebene migrieren, müssen Sie die Verzögerung beim Onlinestellen der Datenbanken im primären Replikat berücksichtigen, während sie auf die sekundären Replikate gesetzt werden. Diese Verzögerung gilt insbesondere für größere Datenbanken.

Die Migration zu einem SQL Managed Instance im Business Critical Dienstebene dauert länger als in der Dienstebene für allgemeine Zwecke. Nach Abschluss der Übernahme auf Azure sind Datenbanken nicht verfügbar, bis sie vom primären Replikat auf die drei sekundären Replikate seeded werden. Je nach Datenbankgröße kann der Seedingprozess eine längere Zeit in Anspruch nehmen. Je größer die Datenbank ist, desto länger dauert das Übertragen an die sekundären Replikate – potenziell bis zu mehreren Stunden.

Wenn es wichtig ist, dass Datenbanken unmittelbar nach Abschluss der Umschaltung verfügbar sind, sollten Sie die folgenden Problemumgehungen in Erwägung ziehen:

  • Migrieren Sie zuerst zur Dienstebene "Allgemein", und führen Sie dann ein Upgrade auf die Dienstebene "Geschäftskritisch " aus. Das Upgrade Ihrer Dienstebene ist ein Onlinevorgang, der Ihre Datenbanken online hält, bis ein kurzes Failover als letzter Schritt des Upgradevorgangs erfolgt.
  • Verwenden Sie den Link verwaltete Instanz für eine Onlinemigration zu einer Business CriticalInstanz, ohne warten zu müssen, dass Datenbanken nach der Übernahme verfügbar sind.

Die Überwachung der Migration über das Azure-Portal ist nur für SQL-Server-Instanzen verfügbar, die die Überwachungs-Lizenzierungsanforderungen erfüllen.

Häufige Probleme beheben

Informationen zur Fehlerbehebung bei häufigen Problemen bei der Migration zu Azure SQL Managed Instance finden Sie unter Fehlerbehebung bei Migrationsproblemen.