Migrieren von Datenbanken von SQL Server mithilfe des Protokollwiedergabediensts – Azure SQL Managed Instance

  • Artikel

Gilt für:Azure SQL Managed Instance

Dieser Artikel erläutert, wie Sie Datenbanken zu Azure SQL Managed Instance migrieren, indem Sie den Protokollwiedergabedienst (LRS) verwenden. Der Protokollwiedergabedienst ist ein kostenloser Clouddienst, der für Azure SQL Managed Instance verfügbar ist und auf der Protokollversandtechnologie von SQL Server basiert.

Die folgenden Quellen werden unterstützt:

  • SQL Server auf virtuellen Computern
  • Amazon EC2 (Elastic Compute Cloud)
  • Amazon RDS (Relational Database Service) für SQL Server
  • Google Compute Engine
  • Cloud SQL für SQL Server – GCP (Google Cloud Platform)

Voraussetzungen

Bevor Sie beginnen, berücksichtigen Sie die folgenden Anforderungen sowohl für Ihre SQL Server-Instanz als auch für Azure.

SQL Server

Stellen Sie sicher, dass die folgenden Anforderungen für SQL Server erfüllt sind:

  • Sie verwenden eine der SQL Server-Versionen 2008 bis 2022.
  • Ihre SQL Server-Datenbank verwendet das vollständige Wiederherstellungsmodell (obligatorisch).
  • Sie verfügen über vollständige Sicherungen der Datenbanken (eine oder mehrere Dateien).
  • Sie verfügen über eine differenzielle Sicherung (eine oder mehrere Dateien).
  • Sie verfügen über eine Protokollsicherung (keine Aufteilung für eine Transaktionsprotokolldatei).
  • Wenn Sie eine der SQL Server-Versionen 2008 bis 2016 verwenden, führen Sie lokal eine Sicherung aus, und laden Sie diese manuell in Ihr Azure Blob Storage-Konto hoch.
  • Bei SQL Server 2016 und höher können Sie die Sicherung direkt im Azure Blob Storage-Konto ausführen.

Auch wenn die Aktivierung von CHECKSUM für Sicherungen nicht zwingend erforderlich ist, wird dies dringend empfohlen, damit die Wiederherstellungsvorgänge schneller ausgeführt werden.

Azure

Stellen Sie sicher, dass die folgenden Anforderungen für Azure erfüllt sind:

  • PowerShell Az.SQL-Modul, Version 4.0.0 oder höher (Installation oder Zugriff per Azure Cloud Shell)
  • Azure CLI, Version 2.42.0 oder höher (ist installiert)
  • Sie verfügen über einen bereitgestellten Azure Blob Storage-Container.
  • Sie verfügen über ein für den Blob Storage-Container generiertes SAS-Sicherheitstoken (Shared Access Signature) mit Berechtigungen zum Lesen und Auflisten oder über eine verwaltete Identität, die auf den Container zugreifen kann.
  • Speichern Sie Sicherungsdateien für eine einzelne Datenbank im Speicherkonto in einem separaten Ordner in einer Flatfilestruktur (obligatorisch). Das Schachteln von Ordnern innerhalb von Datenbankordnern wird nicht unterstützt.

Azure RBAC-Berechtigungen

Für die Ausführung des Protokollwiedergabediensts über die bereitgestellten Clients ist eine der folgenden Azure-RBAC-Rollen (Role-Based Access Control, rollenbasierte Zugriffssteuerung) erforderlich:

Bewährte Methoden

Berücksichtigen Sie bei der Verwendung des Protokollwiedergabediensts die folgenden Best Practices:

  • Führen Sie den Datenmigrations-Assistenten aus, um zu überprüfen, ob Ihre Datenbanken für die Migration zu SQL Managed Instance bereit sind.
  • Teilen Sie vollständige und differenzielle Sicherungen in mehrere Dateien auf, anstatt nur eine Datei zu verwenden.
  • Aktivieren Sie die Sicherungskomprimierung, um die Geschwindigkeit der Netzwerkübertragung zu erhöhen.
  • Verwenden Sie Cloud Shell zum Ausführen von PowerShell- oder CLI Skripts, da dieser Dienst immer auf die neuesten veröffentlichten Cmdlets aktualisiert wird.
  • Konfigurieren Sie ein Wartungsfenster, um Systemupdates an einem bestimmten Tag und zu einer bestimmten Uhrzeit zu planen. Diese Konfiguration hilft dabei, den Zeitrahmen für Datenbankmigrationen besser vorhersagen zu können, da Systemupgrades laufende Migrationen unterbrechen können.
  • Planen Sie, einen einzelnen LRS-Migrationsauftrag innerhalb von maximal 30 Tagen abzuschließen. Nach Ablauf dieses Zeitrahmens wird der LRS-Auftrag automatisch abgebrochen.
  • Um die Datenbankwiederherstellung zu beschleunigen, aktivieren Sie CHECKSUM, wenn Sie Ihre Sicherungen erstellen. SQL Managed Instance führt bei Sicherungen ohne CHECKSUM eine Integritätsprüfung durch, wodurch sich die Wiederherstellungszeit verlängert.

Systemupdates für SQL Managed Instance haben Vorrang vor laufenden Datenbankmigrationen. Während eines Systemupdates für eine Instanz werden alle ausstehenden Migrationen des Protokollwiedergabediensts angehalten und erst fortgesetzt, nachdem das Update angewendet wurde. Dieses Systemverhalten kann die Migrationszeit verlängern, insbesondere bei großen Datenbanken.

Um einen vorhersagbaren Zeitrahmen für Datenbankmigrationen zu erzielen, sollten Sie ein Wartungsfenster konfigurieren, um Systemupdates für einen bestimmten Tag und eine bestimmte Uhrzeit zu planen, und Migrationsaufträge außerhalb dieses Wartungsfensters ausführen und abschließen.

Wichtig

  • Sie können Datenbanken, die mit dem Protokollwiedergabedienst wiederhergestellt werden, erst verwenden, nachdem der Migrationsprozess abgeschlossen ist.
  • Für den Protokollwiedergabedienst wird der schreibgeschützte Zugriff auf Datenbanken während der Migration nicht unterstützt.
  • Nach Abschluss der Migration ist der Migrationsprozess endgültig abgeschlossen und kann nicht mit zusätzlichen differenziellen Sicherungen fortgesetzt werden.

Migrieren mehrerer Datenbanken

Wenn Sie mehrere Datenbanken mit demselben Azure Blob Storage-Container migrieren, müssen Sie die Sicherungsdateien für die verschiedenen Datenbanken in separaten Ordnern innerhalb des Containers speichern. Alle Sicherungsdateien für eine einzelne Datenbank müssen in einem Datenbankordner in einer Flatfilestruktur gespeichert werden, und die Ordner dürfen nicht geschachtelt sein. Das Schachteln von Ordnern innerhalb von Datenbankordnern wird nicht unterstützt.

Hier sehen Sie ein Beispiel für eine Ordnerstruktur in einem Azure Blob Storage-Container – eine Struktur, die zum Migrieren mehrerer Datenbanken mithilfe des Protokollwiedergabediensts erforderlich ist.

-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>

-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>

-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure. 
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>

Erstellen eines Speicherkontos

Sie verwenden ein Azure Blob Storage-Konto als Zwischenspeicher für Sicherungsdateien zwischen Ihrer SQL Server-Instanz und Ihrer SQL Managed Instance-Bereitstellung. So erstellen Sie ein neues Speicherkonto und einen Blobcontainer im Speicherkonto:

  1. Informationen zu Azure-Speicherkonten
  2. Erstellen Sie einen Blobcontainer im Speicherkonto.

Konfigurieren von Azure Storage hinter einer Firewall

Die Verwendung des Azure Blob Storage-Dienst, der hinter einer Firewall geschützt ist, wird unterstützt, erfordert jedoch eine zusätzliche Konfiguration. Zum Aktivieren des Lese-/Schreibzugriffs auf Azure Storage mit aktivierter Azure Firewall müssen Sie das Subnetz der verwalteten SQL-Instanz den Firewallregeln des VNet für das Speicherkonto hinzufügen, indem Sie die MI-Subnetzdelegierung und des Speicherdienstendpunkts verwenden. Das Speicherkonto und die verwaltete Instanz müssen sich in derselben Region oder in zwei Regionspaaren befinden.

Wenn sich Ihr Azure-Speicher hinter einer Firewall befindet, wird möglicherweise die folgende Meldung im Fehlerprotokoll der verwalteten SQL-Instanz angezeigt:

Audit: Storage access denied user fault. Creating an email notification:

Dadurch wird eine E-Mail generiert, die Sie darüber informiert, dass die Überwachung für die verwaltete SQL-Instanz keine Überwachungsprotokolle in das Speicherkonto schreibt. Wenn dieser Fehler angezeigt wird oder Sie diese E-Mail erhalten, führen Sie die Schritte in diesem Abschnitt aus, um Ihre Firewall zu konfigurieren.

Führen Sie die folgenden Schritte aus, um die Firewall zu konfigurieren:

  1. Wechseln Sie im Azure-Portal zu Ihrer verwalteten Instanz, und wählen Sie das Subnetz aus, um die Seite Subnetze zu öffnen.

    Screenshot of the SQL managed instance Overview page of the Azure portal, with the subnet selected.

  2. Wählen Sie auf der Seite Subnetze den Namen des Subnetzes aus, um die Seite für die Subnetzkonfiguration zu öffnen.

    Screenshot of the SQL managed instance Subnet page of the Azure portal, with the subnet selected.

  3. Wählen Sie unter Subnetzdelegierung im Dropdownmenü Subnetz an einen Dienst delegieren die Option Microsoft.Sql/managedInstances aus. Warten Sie etwa eine Stunde, bis die Berechtigungen verteilt werden, und wählen Sie dann unter Dienstendpunkte die Option Microsoft.Storage aus der Dropdownliste Dienste aus.

    Screenshot of the SQL managed instance Subnet configuration page of the Azure portal.

  4. Navigieren Sie als Nächstes im Azure-Portal zu Ihrem Speicherkonto, wählen Sie unter Sicherheit + Netzwerk die Option Netzwerk aus, und wählen Sie dann die Registerkarte Firewalls und virtuelle Netzwerke aus.

  5. Wählen Sie auf der Registerkarte Firewalls und virtuelle Netzwerke für Ihr Speicherkonto +Vorhandenes virtuelles Netzwerk hinzufügen aus, um die Seite Netzwerke hinzufügen zu öffnen.

    Screenshot of the Storage Account Networking page of the Azure portal, with Add existing virtual network selected.

  6. Wählen Sie in den Dropdownmenüs das entsprechende Abonnement, das virtuelle Netzwerk und das Subnetz der verwalteten Instanz aus, und wählen Sie dann Hinzufügen aus, um das virtuelle Netzwerk der verwalteten SQL-Instanz dem Speicherkonto hinzuzufügen.

Authentifizieren bei Ihrem Blob Storage-Konto

Verwenden Sie ein SAS-Token oder eine verwaltete Identität für den Zugriff auf Ihr Azure Blob Storage-Konto.

Warnung

Sie können für ein und dasselbe Speicherkonto nicht sowohl ein SAS-Token als auch eine verwaltete Identität verwenden. Sie können entweder ein SAS-Token oder eine verwaltete Identität verwenden, aber nicht beides.

Generieren eines SAS-Authentifizierungstokens für den Protokollwiedergabedienst zum Zugreifen auf Blob Storage

Greifen Sie unter Verwendung eines SAS-Tokens auf Ihr Azure Blob Storage-Konto zu.

Sie können ein Azure Blob Storage-Konto als Zwischenspeicher für Sicherungsdateien zwischen Ihrer SQL Server-Instanz und Ihrer SQL Managed Instance-Bereitstellung verwenden. Generieren Sie ein SAS-Authentifizierungstoken für den Protokollwiedergabedienst, das nur die Berechtigungen zum Lesen und Auflisten gewährt. Das Token ermöglicht dem Protokollwiedergabedienst den Zugriff auf Ihr Blob Storage-Konto und verwendet die Sicherungsdateien, um sie in Ihrer verwalteten Instanz wiederherzustellen.

Führen Sie die folgenden Schritte aus, um das Token zu generieren:

  1. Öffnen Sie im Azure-Portal den Storage-Explorer.

  2. Erweitern Sie die Option Blobcontainer.

  3. Klicken Sie mit der rechten Maustaste auf den Blobcontainer, und wählen Sie dann die Option Shared Access Signature abrufen aus.

    Screenshot that shows selections for generating a SAS authentication token.

  4. Wählen Sie den Zeitrahmen für den Tokenablauf aus. Stellen Sie sicher, dass das Token während der Migration gültig ist.

  5. Wählen Sie die Zeitzone für das Token aus: UTC oder Ortszeit.

    Wichtig

    Die Zeitzone des Tokens stimmt unter Umständen nicht mit Ihrer verwalteten Instanz überein. Stellen Sie sicher, dass das SAS-Token unter Berücksichtigung der Zeitzonen über die entsprechende Gültigkeit verfügt. Um Zeitzonenunterschiede zu berücksichtigen, legen Sie den Gültigkeitswert FROM auf einen Zeitpunkt deutlich vor dem Start Ihres Migrationsfensters fest, und legen Sie den Wert TO auf einen Zeitpunkt deutlich nach dem von Ihnen erwarteten Ende der Migration fest.

  6. Wählen Sie nur die Berechtigungen Lesen und Auflisten aus.

    Wichtig

    Wählen Sie keine anderen Berechtigungen aus. Wenn Sie dies nicht beachten, wird der Protokollwiedergabedienst nicht gestartet. Diese Sicherheitsanforderung ist entwurfsbedingt.

  7. Klicken Sie auf Erstellen.

    Screenshot that shows selections for SAS token expiration, time zone, and permissions, along with the Create button.

Die SAS-Authentifizierung wird mit der von Ihnen angegebenen Gültigkeitsdauer generiert. Sie benötigen die URI-Version des Tokens, wie im folgenden Screenshot gezeigt:

Screenshot that shows an example of the URI version of a SAS token.

Hinweis

Die Verwendung von SAS-Token, die mit Berechtigungen erstellt wurden, die durch Definieren einer gespeicherten Zugriffsrichtlinie festgelegt wurden, wird derzeit nicht unterstützt. Befolgen Sie die Anweisungen in diesem Verfahren, um die Berechtigungen zum Lesen und Auflisten für das SAS-Token manuell anzugeben.

Kopieren von Parametern aus dem SAS-Token

Greifen Sie unter Verwendung eines SAS-Tokens oder einer verwalteten Identität auf Ihr Azure Blob Storage-Konto zu.

Bevor Sie das SAS-Token zum Starten des Protokollwiedergabediensts verwenden, müssen Sie dessen Struktur verstehen. Der URI des generierten SAS-Tokens besteht aus zwei Teilen, die durch ein Fragezeichen (?) getrennt sind, wie in diesem Beispiel gezeigt:

Example URI for a generated SAS token for Log Replay Service.

Der erste Teil, der mit https:// beginnt und bis zum Fragezeichen (?) reicht, wird für den Parameter StorageContainerURI verwendet, der als Eingabe an den Protokollwiedergabedienst übergeben wird. Er liefert LRS-Informationen zu dem Ordner, in dem die Datenbanksicherungsdateien gespeichert werden.

Der zweite Teil – hinter dem Fragezeichen (?) bis zum Ende der Zeichenfolge – ist der StorageContainerSasToken-Parameter. Dieser Teil ist das eigentliche signierte Authentifizierungstoken, das für die angegebene Zeit gültig ist. Dieser Teil muss nicht unbedingt wie im Beispiel mit sp= beginnen. Ihr Szenario sieht möglicherweise anders aus.

Kopieren Sie die Parameter wie folgt:

  1. Kopieren Sie den ersten Teil des Tokens von https:// bis zum Fragezeichen (?), aber ohne dieses. Verwenden Sie diese Zeichenfolge als StorageContainerUri-Parameter in PowerShell oder der Azure CLI, wenn Sie den Protokollwiedergabedienst starten.

    Screenshot that shows where to copy the first part of the token.

  2. Kopieren Sie den zweiten Teil des Tokens hinter dem Fragezeichen (?) bis zum Ende der Zeichenfolge. Verwenden Sie diese Zeichenfolge als StorageContainerSasToken-Parameter in PowerShell oder der Azure CLI, wenn Sie den Protokollwiedergabedienst starten.

    Screenshot that shows where to copy the second part of the token.

Hinweis

Lassen Sie das Fragezeichen (?) beim Kopieren der beiden Teile des Tokens jeweils weg.

Überprüfen des Speicherzugriffs durch Ihre verwaltete Instanz

Überprüfen Sie, ob Ihre verwaltete Instanz auf Ihr Blob Storage-Konto zugreifen kann.

Laden Sie zunächst eine beliebige Datenbanksicherung, z. B. full_0_0.bak, in Ihren Azure Blob Storage-Container hoch.

Stellen Sie als Nächstes eine Verbindung mit Ihrer verwalteten Instanz her, und führen Sie eine Beispieltestabfrage aus, um festzustellen, ob Ihre verwaltete Instanz auf die Sicherung im Container zugreifen kann.

Wenn Sie ein SAS-Token zur Authentifizierung bei Ihrem Speicherkonto verwenden, ersetzen Sie <sastoken> durch Ihr SAS-Token, und führen Sie die folgende Abfrage für Ihre Instanz aus:

CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE' 
, SECRET = '<sastoken>' 

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

Hochladen von Sicherungen in das Blob Storage-Konto

Wenn Ihr Blobcontainer bereit ist und Sie sich davon überzeugt haben, dass Ihre verwaltete Instanz auf den Container zugreifen kann, können Sie mit dem Hochladen Ihrer Sicherungen in das Blob Storage-Konto beginnen. Sie haben folgende Möglichkeiten:

  • Kopieren Sie Ihre Sicherungen in Ihr Blob Storage-Konto.
  • Erstellen Sie Sicherungen von SQL Server mithilfe des Befehls BACKUP TO URL direkt in Ihrem Blob Storage-Konto, sofern Ihre Umgebung dies zulässt (ab SQL Server 2012 SP1 CU2 und SQL Server 2014).

Kopieren vorhandener Sicherungen in das Blob Storage-Konto

Wenn Sie eine frühere Version von SQL Server verwenden oder Ihre Umgebung direkte Sicherungen in eine URL nicht unterstützt, erstellen Sie Ihre Sicherungen wie gewohnt in Ihrer SQL Server-Instanz und kopieren diese dann in Ihr Blob Storage-Konto.

Erstellen von Sicherungen in einer 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

Verwenden Sie die folgenden T-SQL-Beispielskripts, um im lokalen Speicher manuell vollständige, differenzielle und Protokollsicherungen Ihrer Datenbank zu erstellen. CHECKSUM ist nicht erforderlich, wird aber empfohlen.

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 das Blob Storage-Konto

Wenn Ihre Sicherungen bereit sind und Sie die Migration von Datenbanken zu einer verwalteten Instanz mithilfe des Protokollwiedergabediensts starten möchten, können Sie vorhandene Sicherungen mit einer der folgenden Vorgehensweisen in Ihr Blob Storage-Konto kopieren:

Hinweis

Wenn Sie mehrere Datenbanken mithilfe ein und desselben Azure Blob Storage-Containers migrieren möchten, speichern Sie alle Sicherungsdateien für jede 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 direkt im Blob Storage-Konto

Wenn Sie eine unterstützte Version von SQL Server verwenden (ab SQL Server 2012 SP1 CU2 und SQL Server 2014) und Ihre Unternehmens- und Netzwerkrichtlinien dies zulassen, können Sie Sicherungen von SQL Server direkt in Ihrem Blob Storage-Konto erstellen, indem Sie die native SQL Server-Option BACKUP TO URL verwenden. Wenn Sie BACKUP TO URL verwenden können, müssen Sie Sicherungen nicht im lokalen Speicher erstellen und in Ihr Blob Storage-Konto hochladen.

Wenn Sie native Sicherungen direkt in Ihrem Blob Storage-Konto erstellen, müssen Sie sich beim Speicherkonto authentifizieren.

Verwenden Sie den folgenden Befehl, um Anmeldeinformationen zu erstellen, die das SAS-Token in Ihre SQL Server-Instanz importiert:

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',  
SECRET = '<SAS_TOKEN>';

Ausführliche Anweisungen zum Arbeiten mit SAS-Token finden Sie im Tutorial Verwenden von Azure Blob Storage mit SQL Server.

Nachdem Sie die Anmeldeinformationen zum Authentifizieren Ihrer SQL Server-Instanz mit Blob Storage erstellt haben, können Sie den Befehl BACKUP TO URL verwenden, um Sicherungen direkt für das Speicherkonto zu erstellen. Die Verwendung von CHECKSUM wird empfohlen, aber sie ist nicht zwingend erforderlich.

Im folgenden Beispiel wird eine vollständige Datenbanksicherung unter einer URL ausgeführt:

-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

Im folgenden Beispiel wird eine differenzielle Datenbanksicherung unter einer URL ausgeführt:

-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'  
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

Im folgenden Beispiel wird eine Transaktionsprotokollsicherung unter einer URL ausgeführt:

-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'  
WITH COMPRESSION, CHECKSUM

Anmelden bei Azure und Auswählen eines Abonnements

Verwenden Sie das folgende PowerShell-Cmdlet, um sich bei Azure anzumelden:

Login-AzAccount

Wählen Sie mit dem folgenden PowerShell-Cmdlet das Abonnement aus, in dem sich Ihre verwaltete Instanz befindet:

Select-AzSubscription -SubscriptionId <subscription ID>

Starten der Migration

Starten Sie die Migration, indem Sie den Protokollwiedergabedienst starten. Sie können den Dienst entweder im Modus Automatisches Abschließen oder im Modus Kontinuierlich starten.

Bei Verwendung des Modus zum automatischen Abschließen wird der Migrationsprozess automatisch beendet, nachdem die letzte angegebene Sicherungsdatei wiederhergestellt wurde. Bei dieser Option muss die gesamte Sicherungskette im Voraus verfügbar sein und in Ihr Blob Storage-Konto hochgeladen worden sein. Das Hinzufügen neuer Sicherungen während der Migration ist nicht möglich. Bei dieser Option muss der Dateiname der letzten Sicherungsdatei im start-Befehl angegeben werden. Dieser Modus empfiehlt sich für passive Workloads, bei denen keine Aufholphase für die Daten erforderlich ist.

Wenn Sie den kontinuierlichen Modus verwenden, überprüft der Dienst kontinuierlich den Azure Blob Storage-Ordner und stellt alle neuen Sicherungsdateien wieder her, die während der Migration hinzugefügt werden. Die Migration wird erst abgeschlossen, nachdem der manuelle Cutover angefordert wurde. Sie müssen die Migration im kontinuierlichen Modus verwenden, wenn Sie nicht im Voraus über die gesamte Sicherungskette verfügen und wenn Sie planen, neue Sicherungsdateien hinzuzufügen, nachdem die Migration gestartet wurde. Dieser Modus empfiehlt sich für aktive Workloads, bei denen eine Aufholphase für die Daten erforderlich ist.

Planen Sie, einen einzelnen LRS-Migrationsauftrag innerhalb von maximal 30 Tagen abzuschließen. Nach Ablauf dieses Zeitraums wird der LRS-Auftrag automatisch abgebrochen.

Hinweis

Wenn Sie mehrere Datenbanken migrieren, muss der Protokollwiedergabedienst für jede Datenbank separat gestartet werden und auf den vollständigen URI-Pfad des Azure Blob Storage-Containers und den jeweiligen Datenbankordner verweisen.

Starten von LRS im AutoVervollständigen-Modus

Vergewissern Sie sich, dass die gesamte Sicherungskette in Ihr Azure Blob Storage-Konto hochgeladen wurde. Bei dieser Option können keine neuen Sicherungsdateien hinzugefügt werden, während die Migration ausgeführt wird.

Verwenden Sie PowerShell- oder Azure CLI-Befehle, um den Protokollwiedergabedienst im Modus „AutoVervollständigen“ zu starten. Geben Sie den Namen der letzten Sicherungsdatei an, indem Sie den Parameter -LastBackupName verwenden. Nachdem die Wiederherstellung der letzten angegebenen Sicherungsdatei abgeschlossen ist, leitet der Dienst automatisch den Cutover ein.

Stellen Sie Ihre Datenbank aus dem Speicherkonto wieder her, indem Sie entweder ein SAS-Token oder eine verwaltete Identität verwenden.

Wichtig

  • Vergewissern Sie sich, dass die gesamte Sicherungskette in Ihr Azure Blob Storage-Konto hochgeladen wurde, bevor Sie die Migration im Modus zum automatischen Abschließen starten. In diesem Modus können keine neuen Sicherungsdateien hinzugefügt werden, sobald die Migration begonnen hat.
  • Vergewissern Sie sich, dass Sie die letzte Sicherungsdatei richtig angegeben und danach keine weiteren Dateien hochgeladen haben. Wenn das System über die letzte angegebene Sicherungsdatei hinaus weitere Sicherungsdateien entdeckt, tritt ein Fehler bei der Migration auf.

Das folgende PowerShell-Beispiel startet den Protokollwiedergabedienst unter Verwendung eines SAS-Tokens im Modus zum automatischen Abschließen:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

Das folgende Azure CLI-Beispiel startet den Protokollwiedergabedienst unter Verwendung eines SAS-Tokens im Modus zum automatischen Abschließen:

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Starten von LRS im kontinuierlichen Modus

Vergewissern Sie sich, dass Sie Ihre anfängliche Sicherungskette in Ihr Azure Blob Storage-Konto hochgeladen haben.

Wichtig

Nachdem Sie den Protokollwiedergabedienst im kontinuierlichen Modus gestartet haben, können Sie Ihrem Speicherkonto bis zum manuellen Cutover neue Protokoll- und differenzielle Sicherungen hinzufügen. Sobald der manuelle Cutover eingeleitet wurde, können keine weiteren differenziellen Dateien hinzugefügt oder wiederhergestellt werden.

Das folgende PowerShell-Beispiel startet den Protokollwiedergabedienst unter Verwendung eines SAS-Tokens im kontinuierlichen Modus:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Im folgenden Azure CLI-Beispiel wird der LRS im Modus „Kontinuierlich“ gestartet:

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Erstellen eines Skripts für den Migrationsauftrag

PowerShell- und Azure CLI-Clients, die den Protokollwiedergabedienst im kontinuierlichen Modus starten, funktionieren synchron. In diesem Modus warten PowerShell und die Azure CLI auf die API-Antwort, die den Erfolg oder Misserfolg beim Starten des Auftrags meldet.

Während dieser Wartezeit wird die Kontrolle vom Befehl nicht zurück an die Eingabeaufforderung gegeben. Wenn Sie ein Skript für die Migration erstellen und der Startbefehl des Protokollwiedergabediensts die Steuerung sofort wieder zurückgeben muss, damit das Skript fortgesetzt werden kann, können Sie PowerShell mit der Option -AsJob als Hintergrundauftrag ausführen. Beispiel:

$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob

Wenn Sie einen Hintergrundauftrag starten, wird selbst dann sofort ein Auftragsobjekt zurückgegeben, wenn der Abschluss des Auftrags längere Zeit in Anspruch nimmt. Sie können ohne Unterbrechung in der Sitzung weiterarbeiten, während der Auftrag abgeschlossen wird. Ausführliche Informationen zum Ausführen von PowerShell als Hintergrundauftrag finden Sie in der PowerShell-Dokumentation zu Start-Job.

Wenn Sie einen Azure CLI-Befehl unter Linux als Hintergrundprozess starten, verwenden Sie auf ähnliche Weise das kaufmännische Und-Zeichen (&) am Ende des Startbefehls für den Protokollwiedergabedienst:

az sql midb log-replay start <required parameters> &

Überwachen des Migrationsstatus

Az.SQL 4.0.0 und höher bietet einen detaillierten Fortschrittsbericht. Überprüfen Sie die Details zur Wiederherstellung verwalteter Datenbanken – Abrufen für eine Beispielausgabe.

Verwenden Sie den folgenden Befehl, um den Migrationsprozess mit PowerShell zu überwachen:

Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Verwenden Sie den folgenden Befehl, um den Migrationsprozess mit der Azure CLI zu überwachen:

az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb

Beenden der Migration (optional)

Verwenden Sie PowerShell oder die Azure CLI, falls Sie die Migration beenden müssen. Durch Beenden der Migration wird die wiederherzustellende Datenbank in Ihrer verwalteten Instanz gelöscht, sodass die Migration später nicht mehr fortgesetzt werden kann.

Verwenden Sie den folgenden Befehl, um den Migrationsprozess mit PowerShell zu beenden:

Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Verwenden Sie den folgenden Befehl, um den Migrationsprozess mit der Azure CLI zu beenden:

az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb

Abschließen der Migration (kontinuierlicher Modus)

Wenn Sie den Protokollwiedergabedienst im kontinuierlichen Modus gestartet haben, stellen Sie sicher, dass Ihre Anwendung und die SQL Server-Workload beendet wurden, um zu verhindern, dass neue Sicherungsdateien generiert werden. Vergewissern Sie sich, dass die letzte Sicherung von Ihrer SQL Server-Instanz in Ihr Azure Blob Storage-Konto hochgeladen wurde. Überwachen Sie den Status der Wiederherstellung in der verwalteten Instanz, und vergewissern Sie sich, dass die letzte Sicherung des Protokollendes wiederhergestellt wurde.

Sobald die letzte Sicherung des Protokollendes in der verwalteten Instanz wiederhergestellt wurde, initiieren Sie den manuellen Cutover, um die Migration abzuschließen. Wenn der Cutover abgeschlossen ist, wird die Datenbank für den Lese- und Schreibzugriff in der verwalteten Instanz verfügbar.

Verwenden Sie den folgenden Befehl, um den Migrationsprozess im Modus „Kontinuierlich“ des Protokollwiedergabediensts mit PowerShell abzuschließen:

Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"

Verwenden Sie den folgenden Befehl, um den Migrationsprozess im Modus „Kontinuierlich“ des Protokollwiedergabediensts mit der Azure CLI abzuschließen:

az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"

Behandeln von Problemen mit dem Protokollwiedergabedienst

Nachdem Sie den Protokollwiedergabedienst gestartet haben, verwenden Sie eines der folgenden Cmdlets zur Überwachung, um den Status des Vorgangs anzuzeigen:

  • Für PowerShell: get-azsqlinstancedatabaselogreplay
  • Für die Azure CLI: az_sql_midb_log_replay_show

Falls der Protokollwiedergabedienst nicht gestartet werden kann und ein Fehler angezeigt wird, sollten Sie eine Überprüfung auf die häufigsten Fehler durchführen:

  • Hat eine vorhandene Datenbank in Ihrer verwalteten Instanz den gleichen Namen wie die Datenbank, die von Ihrer SQL Server-Instanz migriert werden soll? Lösen Sie diesen Konflikt auf, indem Sie eine der Datenbanken umbenennen.
  • Wurden für das SAS-Token nur die Berechtigungen „Lesen“ und „Auflisten“ gewährt?
  • Haben Sie das SAS-Token für den Protokollwiedergabedienst hinter das Fragezeichen (?) kopiert, und sieht der Inhalt in etwa so aus: sv=2020-02-10...? 
  • Wurde die Gültigkeitsdauer des SAS-Tokens mit geeigneten Angaben zum Zeitfenster für das Starten und Abschließen der Migration festgelegt? Aufgrund der unterschiedlichen Zeitzonen, die für Ihre SQL Managed Instance-Bereitstellung und das SAS-Token gelten, können Abweichungen auftreten. Versuchen Sie, das SAS-Token erneut zu generieren und das Gültigkeitsdauer-Zeitfenster des Tokens vor und nach dem aktuellen Datum zu vergrößern.
  • Wenn mehrere Wiederherstellungsvorgänge für Protokollwiedergaben parallel gestartet werden, stellen Sie sicher, dass für jeden Wiederherstellungsvorgang das gleiche gültige SAS-Token bereitgestellt wird.
  • Sind der Datenbankname, der Ressourcengruppenname und der Name der verwalteten Instanz richtig geschrieben?
  • Wenn Sie den Protokollwiedergabedienst im Modus zum automatischen Abschließen gestartet haben: Wurde für die letzte Sicherungsdatei ein gültiger Dateiname angegeben?
  • Enthält der Sicherungs-URI-Pfad Schlüsselwörter backup oder backups? Benennen Sie den Container oder die Ordner um, die backup oder backups verwenden, um, da dies reservierte Schlüsselwörter sind.

Nächste Schritte