Freigeben über

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. Sehen Sie sich sorgfältig die Abschnitte Einschränkungen und bewährten Methoden durch, um eine erfolgreiche Migration sicherzustellen.

Wichtig

  • Bevor Sie Datenbanken zur Dienstebene Unternehmenskritisch migrieren, sollten Sie diese Einschränkungen, die nicht auf die Universelle Dienstebene angewendet werden, berücksichtigen.
  • 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.

Bevor Sie Datenbanken zur Dienstebene Unternehmenskritisch migrieren, sollten Sie diese Einschränkungen, die nicht auf die Universelle Dienstebene angewendet werden, berücksichtigen.

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.
  • Obwohl CHECKSUM für Sicherungen aktiviert ist, wird dringend empfohlen, unbeabsichtigte Migrationen einer beschädigten Datenbank und für schnellere Wiederherstellungsvorgänge zu verhindern.

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 Read und List oder über eine verwaltete Identität, die auf den Container zugreifen kann. Die Gewährung von mehr Berechtigungen als Read und List führt dazu, dass LRS fehlschlägt.
  • 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 so, dass Systemupdates an einem bestimmten Tag und zu einem bestimmten Zeitpunkt außerhalb des Migrationsfensters geplant werden, um zu verhindern, dass die Migration verzögert oder unterbrochen wird.
  • Planen Sie, einen einzelnen LRS-Migrationsauftrag innerhalb von maximal 30 Tagen abzuschließen. Nach Ablauf dieses Zeitrahmens wird der LRS-Auftrag automatisch abgebrochen.
  • Um eine unbeabsichtigte Migration einer beschädigten Datenbank zu verhindern und für eine schnellere Datenbankwiederherstellung, aktivieren Sie CHECKSUM, wenn Sie Ihre Sicherungen erstellen. Obwohl SQL Managed Instance eine grundsätzliche Integritätsprüfung für Sicherungen ohne CHECKSUM durchführt, ist das Abfangen aller Formen von Beschädigungen nicht garantiert. Das Erstellen von Sicherungen mit CHECKSUM ist die einzige Möglichkeit, sicherzustellen, dass die Sicherung, die in der SQL Managed Instance wiederhergestellt wurde, nicht beschädigt ist. Die grundlegende Integritätsprüfung für Sicherungen ohne CHECKSUM erhöht die Wiederherstellungszeit einer Datenbank.
  • Beachten Sie, dass es beim Migrieren zur Dienstebene Unternehmenskritisch eine längere Verzögerung in der Datenbankverfügbarkeit nach dem Cutover gibt, während Datenbanken an sekundäre Replikate übertragen werden. Für besonders große Datenbanken mit minimalen Ausfallzeiten sollten Sie zuerst zur Dienstebene „Universell“ migrieren und dann auf die Dienstebene Unternehmenskritisch aktualisieren oder den Link „Managed Instance“ verwenden, um Ihre Daten zu migrieren.
  • Das Hochladen von Tausenden von Datenbankdateien zur Wiederherstellung kann zu übermäßigen Migrationszeiten und sogar zu Fehlern führen. Konsolidieren Sie Datenbanken in weniger Dateien, um den Migrationsprozess zu beschleunigen und sicherzustellen, dass er erfolgreich ist.

Konfigurieren eines Wartungsfensters

Systemupdates für SQL Managed Instance haben Vorrang vor laufenden Datenbankmigrationen.

Die Migration wirkt sich je nach Dienstebene unterschiedlich aus:

  • In der Dienstebene „Universell“ werden alle ausstehenden LRS-Migrationen angehalten und erst nach Anwendung des Updates fortgesetzt. Dieses Systemverhalten kann die Migrationszeit verlängern, insbesondere bei großen Datenbanken.
  • In der Dienstebene Business Critical werden alle ausstehenden LRS-Migrationen abgebrochen und nach Anwendung des Updates automatisch neu gestartet. 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. Konfigurieren Sie beispielsweise für eine Migration, die am Montag beginnt, Ihr benutzerdefiniertes Wartungsfenster am Sonntag so, dass die meiste Zeit für den Abschluss der Migration zur Verfügung steht.

Das Konfigurieren eines Wartungsfensters ist nicht erforderlich, wird jedoch für große Datenbanken dringend empfohlen.

Hinweis

Während ein Wartungsfenster die Vorhersehbarkeit geplanter Updates steuert, garantiert es nicht, dass keine ungeplanten Failover oder Sicherheitsupdates auftreten. Ein ungeplantes Failover oder ein Sicherheitspatch (der Vorrang vor allen anderen Updates hat) kann Ihre Migration weiterhin unterbrechen.

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 virtuellen Netzwerks 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 der Seite „Übersicht“ der verwalteten SQL-Instanz im Azure-Portal mit ausgewähltem Subnetz

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

    Screenshot der Seite „Subnetz“ der verwalteten SQL-Instanz im Azure-Portal mit ausgewähltem Subnetz

  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 der Subnetzkonfigurationsseite der verwalteten SQL-Instanz im 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 der Seite „Speicherkontonetzwerke“ im Azure-Portal mit ausgewählter Option „Vorhandenes virtuelles Netzwerk hinzufügen“

  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: Auswahloptionen für das Generieren eines SAS-Authentifizierungstokens

  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: Auswahloptionen für Ablauf, Zeitzone und Berechtigungen des SAS-Tokens und die Schaltfläche „Erstellen“

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: Beispiel für die URI-Version eines SAS-Tokens

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:

Beispiel-URI für ein generiertes SAS-Token für den Protokollwiedergabedienst

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: Kopierziel für den ersten Teil des Tokens

  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: Kopierziel für den zweiten Teil des Tokens

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, 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 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 sich jede Datenbank in einem eigenen Ordner befinden. Der Protokollwiedergabedienst muss für jede Datenbank separat gestartet werden, die auf den vollständigen URI-Pfad des Azure Blob Storage-Containers und den jeweiligen Datenbankordner verweist. Geschachtelte Ordner in Datenbankordnern werden nicht unterstützt.

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 laufenden Migrationsprozess mit PowerShell zu überwachen:

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

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

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

Um weitere Details zu einer fehlgeschlagenen Anforderung nachzuverfolgen, verwenden Sie den PowerShell-Befehl Get-AzSqlInstanceOperation oder den Azure CLI-Befehl az sql mi op show.

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"

Begrenzungen

Beachten Sie die folgenden Einschränkungen bei der Migration mit LRS:

  • Sie können Datenbanken, die mit dem Protokollwiedergabedienst wiederhergestellt werden, erst verwenden, nachdem der Migrationsprozess abgeschlossen ist.
  • Während des Migrationsprozesses können Datenbanken, die migriert werden, nicht für den schreibgeschützten Zugriff auf SQL Managed Instance verwendet werden.
  • Nach Abschluss der Migration ist der Migrationsprozess endgültig abgeschlossen und kann nicht mit zusätzlichen differenziellen Sicherungen fortgesetzt werden.
  • Nur .bak-, .log- und .diff-Datenbankdateien werden von LRS unterstützt. Dacpac- und Bacpac-Dateien werden nicht unterstützt.
  • Sie müssen ein Wartungsfenster konfigurieren, um Systemupdates an einem bestimmten Tag und zu einer bestimmten Uhrzeit zu planen. Planen Sie Ausführung und Abschluss von Migrationen außerhalb des Fensters für die geplante Wartung.
  • Datenbanksicherungen, die ohne CHECKSUM ausgeführt werden:
    • können potenziell beschädigte Datenbanken migrieren.
    • dauern länger als Datenbanksicherungen mit aktivierter CHECKSUM.
  • Das vom Protokollwiedergabedienst verwendete SAS-Token (Shared Access Token) muss für den gesamten Azure Blob Storage-Container generiert werden und darf nur über die Berechtigungen zum Read und List verfügen. Wenn Sie z. B. Read-, List- und Write-Berechtigungen erteilen, kann LRS aufgrund der zusätzlichen Write-Berechtigung nicht gestartet werden.
  • Die Verwendung von SAS-Token, die mit Berechtigungen erstellt wurden, die durch Definieren einer gespeicherten Zugriffsrichtlinie festgelegt wurden, wird nicht unterstützt. Befolgen Sie die Anweisungen in diesem Artikel, um die Berechtigungen zum Lesen und Auflisten für das SAS-Token manuell anzugeben.
  • Sie müssen Sicherungsdateien für verschiedene Datenbank im Blob Storage-Konto in separaten Ordnern in einer Flatfilestruktur speichern. Das Schachteln von Ordnern innerhalb von Datenbankordnern wird nicht unterstützt.
  • Wenn Sie den Modus zum automatischen Abschließen verwenden, muss die gesamte Sicherungskette im Voraus im Blob Storage-Konto verfügbar sein. Es ist nicht möglich, neue Sicherungsdateien im AutoVervollständigen-Modus hinzuzufügen. Verwenden Sie den kontinuierlichen Modus, wenn Sie neue Sicherungsdateien hinzufügen müssen, während die Migration ausgeführt wird.
  • Sie müssen den Protokollwiedergabedienst separat für jede Datenbank starten, die auf den vollständigen URI-Pfad verweist, der einen einzelnen Datenbankordner enthält.
  • Der Sicherungs-URI-Pfad, Containername oder die Ordnernamen sollten nicht backup oder backups enthalten, da diese reservierte Schlüsselwörter sind.
  • 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.
  • Für den Protokollwiedergabedienst können bis zu 100 gleichzeitige Wiederherstellungsprozesse pro verwalteter Instanz unterstützt werden.
  • Ein einzelner Protokollwiedergabedienstauftrag kann maximal 30 Tage lang ausgeführt werden, danach wird er automatisch abgebrochen.
  • Obwohl es möglich ist, ein Azure Storage-Konto hinter einer Firewall zu verwenden, ist eine zusätzliche Konfiguration erforderlich, und das Speicherkonto und die verwaltete Instanz müssen sich entweder in derselben Region oder in zwei Regionspaaren befinden. Weitere Informationen finden Sie unter Konfigurieren einer Firewall.
  • Die maximale Anzahl von Datenbanken, die Sie parallel wiederherstellen können, beträgt 200 pro Einzelabonnement. In einigen Fällen ist es möglich, diesen Grenzwert durch Öffnen eines Supporttickets zu erhöhen.
  • Das Hochladen von Tausenden von Datenbankdateien zur Wiederherstellung kann zu übermäßigen Migrationszeiten und sogar zu Fehlern führen. Konsolidieren Sie Datenbanken in weniger Dateien, um den Migrationsprozess zu beschleunigen und sicherzustellen, dass er erfolgreich ist.

Hinweis

Wenn während des Migrationsprozesses schreibgeschützter Zugriff auf eine Datenbank erforderlich ist, wobei die Migration über einen wesentlich längeren Zeitraum und mit minimalen Ausfallzeiten ausgeführt wird, sollten Sie das Azure SQL Managed Instance-Verbindungsfeature als empfohlene Migrationslösung in Betracht ziehen.

Einschränkungen bei der Migration zur Dienstebene Unternehmenskritisch

Berücksichtigen Sie bei der Migration zu einer SQL Managed Instance in der Dienstebene Unternehmenskritisch die folgenden Einschränkungen:

  • Bei der Migration großer Datenbanken kann es zu erheblichen Ausfallzeiten kommen, da Datenbanken nach dem Cutover nicht verfügbar sind, während Datenbanken an sekundäre Replikate der Dienstebene Unternehmenskritisch übertragen werden. Problemumgehungen werden im Abschnitt längere Cutover aufgeführt.
  • Die Migration wird automatisch am Anfang neu gestartet, wenn die Migration durch ein nicht geplantes Failover, Systemupdate oder Sicherheitspatch unterbrochen wird, wodurch es schwierig ist, eine vorhersagbare Migration ohne Überraschungen in der letzten Minute zu planen.

Wichtig

Diese Einschränkungen gelten nur bei der Migration zur Dienstebene Unternehmenskritisch und nicht auf die Dienstebene Universell.

Längere Cutover in der Dienstebene Unternehmenskritisch

Wenn Sie zu einer SQL Managed Instance in der Dienstebene Unternehmenskritisch migrieren, müssen Sie die Verzögerung bei der Versetzung der Datenbanken in einen aktiven Zustand im primären Replikat berücksichtigen, während sie auf die sekundären Replikate übertragen werden. Dies gilt insbesondere für große Datenbanken.

Die Migration zu einer SQL Managed Instance in der Dienstebene Unternehmenskritisch dauert länger als in der Dienstebene „Universell“. Nach Abschluss des Cutover zu Azure sind Datenbanken nicht verfügbar, bis sie vom primären Replikat auf die drei sekundären Replikate übertragen wurden, was je nach Datenbankgröße eine längere Zeit in Anspruch nehmen kann. 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 nach Abschluss des Cutover verfügbar sind, sollten Sie die folgenden Problemumgehungen in Betracht ziehen:

  • Migrieren Sie zuerst zur Dienstebene „Universell“, und führen Sie dann während eines nachfolgenden Wartungsfensters ein Upgrade auf die Dienstebene Unternehmenskritisch durch. 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 Unternehmenskritischen Instanz, ohne warten zu müssen, bis Datenbanken nach dem Cutover verfügbar sind.

Behandeln von Problemen mit dem Protokollwiedergabedienst

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

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

So überprüfen Sie Details zu einem fehlgeschlagenen Vorgang:

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? Die Gewährung von mehr Berechtigungen als Read und List führt dazu, dass LRS fehlschlägt.
  • 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