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

Gilt für:Azure SQL Managed Instance

Dieser Artikel erläutert, wie Sie SQL Server-Datenbanken mithilfe des Log Replay Service (LRS) auf Azure SQL Managed Instance migrieren. LRS ist ein kostenloser Clouddienst für Azure SQL Managed Instance Migrationen, der auf SQL Server Protokollversandtechnologie basiert. Lernen Sie den vollständigen Prozess von den Voraussetzungen bis hin zur Umstellung kennen, einschließlich bester Praktiken für eine erfolgreiche Datenbankmigration.

Die folgenden Quellen werden unterstützt:

• SQL Server auf virtuellen Maschinen
• 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, sollten Sie die Anforderungen in diesem Abschnitt sowohl für Ihre SQL Server Instanz als auch für Azure berücksichtigen. Sehen Sie sich sorgfältig die Abschnitte Einschränkungen und bewährten Methoden durch, um eine erfolgreiche Migration sicherzustellen.

SQL Server

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

• SQL Server Versionen 2008 bis 2022.
• Ihre SQL Server-Datenbank verwendet das vollständige Wiederherstellungsmodell (obligatorisch).
• Eine vollständige Sicherung der Datenbanken (eine oder mehrere Dateien).
• Eine differenzielle Sicherung (eine oder mehrere Dateien).
• Eine Protokollsicherung (keine Aufteilung für eine Transaktionsprotokolldatei).
• Erstellen Sie für SQL Server-Versionen 2008 bis 2016 eine lokale Sicherung und laden Sie sie manuell in Ihr Azure Blob Storage-Konto hoch.
• Für SQL Server 2016 und höher können Sie Ihre Sicherung direkt in Ihrem Azure Blob Storage-Konto ablegen.
• Obwohl CHECKSUM für Backups nicht erforderlich ist, wird es dringend empfohlen, um unbeabsichtigte Migrationen einer beschädigten Datenbank zu verhindern und damit schnellere Wiederherstellungsvorgänge zu ermöglichen.
• Jede Version von Windows Server wird basierend auf der SQL Server Versionsunterstützung unterstützt.
• Für SQL Server 2019 und höher sollte die beschleunigte Datenbankwiederherstellung aktiviert sein, wobei der permanente Versionsspeicher auf PRIMARY festgelegt ist. Weitere Informationen finden Sie im Abschnitt Bekannte Probleme nach der Migration zu SQL Managed Instance in diesem Artikel.
• Um den Dienstbroker für eine Datenbank zu verwenden, die zu Azure SQL Managed Instance migriert wurde, muss der Dienstbroker vor der Migration in der Quelldatenbank aktiviert sein. Weitere Informationen finden Sie unter Bekannte Probleme nach der Migration zu SQL Managed Instance, in diesem Artikel.

Azure

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

• PowerShell Az.SQL Modul, Version 4.0.0 oder höher (installiert oder über Azure Cloud Shell).
• Azure CLI Version 2.42.0 oder höher (installiert).
• Ein bereitgestellter Azure Blob Storage Container.
• Ein SAS-Sicherheitstoken (Shared Access Signature) mit Read und List Berechtigungen, generiert für den Blob Storage-Container, oder 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

Das Ausführen von LRS über die bereitgestellten Clients erfordert eine der folgenden Azure rollenbasierten Zugriffssteuerungsrollen (RBAC):

• Rolle SQL Managed Instance Mitwirkender
• Eine Rolle mit der folgenden Berechtigung: Microsoft.Sql/managedInstances/databases/*

Bewährte Methoden

Berücksichtigen Sie bei der Verwendung von LRS die folgenden bewährten Methoden:

• 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, um PowerShell- oder CLI-Skripts auszuführen, da sie immer aktualisiert werden, um die neuesten veröffentlichten Cmdlets zu verwenden.
• 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 grundlegende Integritätsprüfung für Sicherungen ohne CHECKSUM durchführt, ist das Abfangen aller Formen von Beschädigungen nicht gewährleistet. Das Erstellen von Sicherungen mit CHECKSUM ist die einzige Möglichkeit, um sicherzustellen, dass die Sicherung auf SQL Managed Instance 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 für Datenbanken das Seeding in sekundären Replikaten durchgeführt wird. Für besonders große Datenbanken mit minimalen Ausfallzeiten sollten Sie zuerst zur Dienstebene für allgemeine Zwecke migrieren und dann ein Upgrade auf die Business Critical Serviceebene durchführen oder den Link verwaltete Instanz link 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.
• Um die Cutoverzeit zu minimieren und das Ausfallrisiko zu verringern, sorgen Sie dafür, dass Ihre letzte Sicherung so klein wie möglich ist.

Konfigurieren eines Wartungsfensters

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

Die Migration ist je nach Dienstebene unterschiedlich betroffen:

• 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.

Migrieren mehrerer Datenbanken

Wenn Sie mehrere Datenbanken mithilfe desselben Azure Blob Storage-Containers migrieren, müssen Sie Sicherungsdateien für verschiedene Datenbanken in separaten Ordnern innerhalb des Containers platzieren. 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 ist ein Beispiel für eine Ordnerstruktur innerhalb eines Azure Blob Storage-Containers, eine Struktur, die zum Migrieren mehrerer Datenbanken mithilfe von LRS 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 zwischengeschalteten Speicher 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. Ein Speicherkonto erstellen
2. Erstellen Sie einen Blobcontainer im Speicherkonto.

Konfigurieren Azure Speichers hinter einer Firewall

Die Verwendung Azure BLOB-Speichers, 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 SQL-verwalteten Instanz den Firewallregeln des virtuellen Netzwerks für das Speicherkonto mithilfe der MI-Subnetzdelegierung und des Speicherdienstendpunkts hinzufügen. 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 für verwaltete SQL-Instanzen angezeigt:

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

Dadurch wird eine E-Mail generiert, die Sie darüber informiert, dass das Audit für die verwaltete SQL-Instanz daran scheitert, Überwachungsprotokolle in das Speicherkonto zu schreiben. 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 SQL-Instanz und wählen Sie das Subnetz aus, um die Seite Subnets zu öffnen.

   

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

   

3. Wählen Sie unter SubnetzdelegierungMicrosoft.Sql/managedInstances aus der Dropdown-Liste Subnetz einem Dienst delegieren. Warten Sie etwa eine Stunde, bis die Berechtigungen verbreitet sind, und wählen Sie dann unter Service-EndpunktenMicrosoft.Storage aus der Dropdown-Liste Services.

   

4. Wechseln Sie dann im Azure-Portal zu Ihrem Speicherkonto, wählen Sie Networking unter Security + networking 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.

   

6. Wählen Sie das entsprechende Abonnement, virtuelles Netzwerk und das verwaltete Instanzsubnetz aus den Dropdownlistenmenüs aus, und wählen Sie dann "Hinzufügen" aus, um das virtuelle Netzwerk der sql-verwalteten Instanz dem Speicherkonto hinzuzufügen.

Authentifizieren bei Ihrem Blob Storage Konto

Verwenden Sie entweder ein SAS-Token oder eine verwaltete Identität, um auf Ihr Azure Blob Storage Konto zuzugreifen.

Überprüfen des Speicherzugriffs Ihrer verwalteten Instanz

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

Laden Sie zunächst eine 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.

CREATE CREDENTIAL [https://<mystorageaccountname>.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';

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

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>]
    WITH IDENTITY = 'MANAGED IDENTITY';

Hochladen von Sicherungen in Ihr Blob Storage Konto

Wenn Ihr BLOB-Container bereit ist und Sie bestätigt haben, dass Ihre verwaltete Instanz auf den Container zugreifen kann, können Sie mit dem Hochladen Ihrer Sicherungen in Ihr Blob Storage Konto beginnen. Sie haben folgende Möglichkeiten:

• Kopieren Sie Ihre Sicherungen in Ihr Blob Storage Konto.
• Erstellen Sie Sicherungen von SQL Server direkt in Ihr Blob Storage-Konto, indem Sie den Befehl BACKUP TO URL verwenden, wenn Ihre Umgebung dies zulässt (beginnend mit den SQL Server-Versionen 2012 SP1 CU2 und 2014).

Kopieren vorhandener Sicherungen in Ihr Blob Storage Konto

Wenn Sie eine frühere Version von SQL Server verwenden oder wenn Ihre Umgebung die direkte Sicherung einer URL nicht unterstützt, übernehmen Sie Ihre Sicherungen wie gewohnt auf Ihrer SQL Server Instanz, und kopieren Sie sie dann in Ihr Blob Storage Konto.

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

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

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

• Laden Sie AzCopy herunter, und installieren Sie sie.
• Laden Sie Azure Storage-Explorer herunter, und installieren Sie sie.
• Verwenden Sie Storage-Explorer im Azure-Portal.

Sicherungen direkt in Ihrem Blob Storage-Konto erstellen

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 mithilfe der systemeigenen SQL Server-Option BACKUP TO URL erstellen. Wenn Sie BACKUP TO URL verwenden können, müssen Sie keine Sicherungen in den lokalen Speicher übernehmen und sie in Ihr Blob Storage Konto hochladen.

Wenn Sie systemeigene Sicherungen direkt auf Ihr Blob Storage Konto anwenden, 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 Lernprogramm Use Azure Blob Storage with SQL Server.

Nachdem Sie die Anmeldeinformationen erstellt haben, um Ihre SQL Server Instanz mit Blob Storage zu authentifizieren, können Sie den Befehl BACKUP TO URL verwenden, um Sicherungen direkt auf das Speicherkonto zu übernehmen. 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;

Melden Sie sich bei Azure an, und wählen Sie ein Abonnement aus.

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>

Migration starten

Starten Sie die Migration, indem Sie LRS 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. Diese Option erfordert, dass die gesamte Sicherungskette im Voraus verfügbar und in Ihr Blob Storage Konto hochgeladen wird. 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 fortlaufenden 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 Umschaltvorgang 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.

Starten von LRS im AutoVervollständigen-Modus

Stellen Sie sicher, 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.

Um LRS im AutoVervollständigen-Modus zu starten, verwenden Sie PowerShell oder Azure CLI Befehle. 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.

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"

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"

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity  `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

Starten von LRS im kontinuierlichen Modus

Stellen Sie sicher, dass Sie Ihre erste Sicherungskette in Ihr Azure Blob Storage Konto hochgeladen haben.

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"

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"

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity

Erstellen eines Skripts für den Migrationsauftrag

PowerShell- und Azure CLI-Clients, die LRS im fortlaufenden Modus starten, sind synchron. In diesem Modus warten PowerShell und die Azure CLI auf die API-Antwort, um Erfolg oder Fehler zu melden, bevor sie den Auftrag starten.

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 der Rest des Skripts 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 ausgeführt 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 möchten, verwenden Sie das Ampersand (&) am Ende des LRS-Start-Befehls:

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

Überwachen des Migrationsfortschritts

Az.SQL 4.0.0 und höher bietet einen detaillierten Fortschrittsbericht. Eine Beispielausgabe finden Sie unter Details zur Wiederherstellung verwalteter Datenbanken – Abrufen.

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 Migrationsfortschritt über die 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 verwenden Sie Azure CLI Befehl az sql mi op show.

Beenden der Migration (optional)

Wenn Sie die Migration beenden müssen, verwenden Sie PowerShell oder die Azure CLI. 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 über die Azure CLI zu beenden:

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

Abschließen der Migration (kontinuierlicher Modus)

Wenn Sie LRS im fortlaufenden Modus starten, stellen Sie sicher, dass Ihre Anwendung und SQL Server Workload beendet wurden, um zu verhindern, dass neue Sicherungsdateien generiert werden. Stellen Sie sicher, dass die letzte Sicherung ihrer SQL Server Instanz in Ihr Azure Blob Storage Konto hochgeladen wurde. Überwachen Sie den Fortschritt der Wiederherstellung auf Ihrer verwalteten Instanz und stellen Sie sicher, dass das letzte Log-Tail-Backup restauriert wurde.

Sobald die letzte Sicherung des Protokollfragments 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 LRS-Kontinuierlich-Modus 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 kontinuierlichen LRS-Modus über die 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 über LRS (lokal redundanten Speicher) wiederhergestellt werden, erst verwenden, nachdem der Migrationsprozess abgeschlossen ist.
• Während des Migrationsprozesses können datenbanken, die migriert werden, nicht für 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 CHECKSUM-Aktivierung.
• Das SAS-Token (Shared Access Signature), das LRS verwendet, muss für den gesamten Azure Blob Storage-Container generiert werden, und es muss nur über berechtigungen 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 Datenbanken in separaten Ordnern auf dem Blob Storage Konto in einer flachen Dateistruktur platzieren. Das Schachteln von Ordnern innerhalb von Datenbankordnern wird nicht unterstützt.
• Wenn Sie den AutoVervollständigen-Modus verwenden, muss die gesamte Sicherungskette im Voraus auf dem 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 LRS getrennt für jede Datenbank starten, die auf den vollständigen URI-Pfad verweist, der einen einzelnen Ordner für eine Datenbank enthält.
• Der Sicherungs-URI-Pfad, containername oder Ordnernamen können nicht enthalten backup oder Backup sind reservierte Schlüsselwörter.
• Wenn mehrere Wiederherstellungsvorgänge für Protokollwiedergaben parallel gestartet werden, die auf denselben Speichercontainer abzielen, stellen Sie sicher, dass für jede Wiederherstellung das gleiche gültige SAS-Token (Shared Access Signature) bereitgestellt wird.
• LRS unterstützt die Migration einer Gesamtanzahl von Datenbanken zu einer einzelnen Instanz bis zu den Ressourcengrenzwerten der Dienstebene. Sie können z. B. bis zu 100 Datenbanken auf der Dienstebene " Allgemein" und bis zu 500 Datenbanken auf der Dienstebene der nächsten Generation wiederherstellen.
• LRS unterstützt 100 gleichzeitige Datenbankwiederherstellungen in einer einzelnen Instanz und 150 gleichzeitige Datenbankwiederherstellungen für alle Instanzen in einem einzigen Abonnement. Sie können beispielsweise 100 Datenbanken parallel zu zwei Instanzen im selben Abonnement wiederherstellen, oder 50 Datenbanken in drei gleichzeitigen Batches parallel zu vier separaten Instanzen innerhalb desselben Abonnements.
• Ein einzelner LRS-Job 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 gekoppelten Regionen befinden. Weitere Informationen finden Sie unter Konfigurieren einer Firewall.
• Die maximale Anzahl von Datenbanken, die Sie parallel wiederherstellen können, beträgt 150 pro einzelnes Abonnement. 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.
• Am Anfang und Ende des Migrationsprozesses gibt es zwei Szenarien, in denen eine Migration abgebrochen wird, wenn ein Failover auftritt, und der Migrationsauftrag muss von Anfang an manuell neu gestartet werden, da die Datenbank aus SQL Managed Instance gelöscht wird:
  • Wenn es zu einem Failover kommt, während die erste vollständige Datenbanksicherung gerade in SQL Managed Instance wiederhergestellt wird und der Migrationsauftrag gerade gestartet wurde, muss der Migrationsauftrag von Anfang an manuell neu gestartet werden.
  • Wenn ein Failover auftritt, nachdem der Migrationscutover initiiert wurde, muss der Migrationsauftrag manuell von Anfang an neu gestartet werden. Stellen Sie sicher, dass die letzte Sicherungsdatei so klein wie möglich ist, um die Umschaltzeit zu minimieren und das Risiko eines Failovers während des Umschaltvorgangs zu verringern.
• Wenn Accelerated Database Recovery für Ihre Quellinstanzen SQL Server 2019 und höher deaktiviert ist, können Sie sie nach der Migration zu Azure SQL Managed Instance nicht mehr aktivieren. Wenn der permanente Versionsspeicher (PVS) nicht auf PRIMARY festgelegt ist, können Sie außerdem Probleme mit Wiederherstellungsvorgängen auf der SQL-verwalteten Zielinstanz feststellen.
• Wenn Service Broker für die Quellinstanz SQL Server deaktiviert ist, können Sie den Dienstbroker nach der Migration nicht für die sql verwaltete Zielinstanz verwenden.

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 die Datenbanken nach der Umschaltung nicht verfügbar sind, während sie auf die sekundären Replikate der Dienstebene Business Critical initialisiert werden. Problemumgehungen sind im Abschnitt Längere Cutover in der Dienstebene „Unternehmenskritisch“ 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.

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. Dies gilt insbesondere für große 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 Umstellung auf Azure sind Datenbanken nicht verfügbar, bis sie vom primären Replikat auf die drei sekundären Replikate übertragen wurden, was je nach Größe Ihrer Datenbank 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 sofort nach Abschluss des Cutovers verfügbar sind, sollten Sie die folgenden Problemumgehungen in Betracht ziehen:

• Migrieren Sie zuerst zur Dienstebene „Universell“, und führen Sie dann 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 Business CriticalInstanz, ohne warten zu müssen, dass Datenbanken nach der Übernahme verfügbar sind.

Bekannte Probleme nach der Migration zu SQL Managed Instance

Berücksichtigen Sie die folgenden bekannten Probleme nach der Migration zu Azure SQL Managed Instance:

Wiederherstellen von Vorgangsfehlern nach der Migration zu SQL Managed Instance

Wenn Sie eine Datenbank in einer Azure SQL Managed Instance von SQL Server 2019 und höheren Versionen mit aktivierter accelerated database recovery migrieren, aber der beständige Versionsspeicher (PVS) auf einen anderen Speicherort als die PRIMARY-Dateigruppe konfiguriert ist, können Fehler bei Wiederherstellungsoperationen in der verwalteten SQL-Zielinstanz auftreten.

Um dieses Problem zu umgehen, stellen Sie sicher, dass Sie den persistent-Versionsspeicher (PVS) auf PRIMARY für die SQL Server Quelldatenbank festlegen, bevor Sie sie zu SQL Managed Instance migrieren. Wenn Sie die Datenbank bereits migriert haben, ohne die PVS auf PRIMARY festzulegen, können Sie diese Einstellung in der Quelldatenbank auf dem SQL Server vornehmen und die Datenbank dann erneut zur SQL Managed Instance migrieren.

Die beschleunigte Datenbankwiederherstellung kann nach der Migration zu SQL Managed Instance nicht verwendet werden.

Ab SQL Server 2019 können Sie, wenn Sie eine Datenbank zu Azure SQL Managed Instance migrieren und die Quelldatenbank Accelerated database recovery deaktiviert ist, keine beschleunigte Datenbankwiederherstellung für die verwaltete SQL-Zielinstanz verwenden.

Um dieses Problem zu umgehen, vergewissern Sie sich, dass Sie die beschleunigte Datenbankwiederherstellung aktivieren für die SQL Server Quelldatenbank, bevor Sie sie zu SQL Managed Instance migrieren. Wenn Sie die Datenbank bereits migriert haben, ohne eine beschleunigte Datenbankwiederherstellung zu aktivieren, können Sie sie für die Quelldatenbank SQL Server aktivieren und dann die Datenbank erneut zu sql managed instance migrieren.

SQL Server 2017 und frühere Versionen unterstützen keine beschleunigte Datenbankwiederherstellung, daher gilt dieses Problem nicht für Datenbanken, die aus diesen Versionen von SQL Server migriert wurden.

Der Dienstbroker kann nach der Migration zu SQL Managed Instance nicht verwendet werden.

Wenn Sie eine Datenbank zu Azure SQL Managed Instance migrieren und ServiceBroker in der Quelldatenbank deaktiviert ist, können Sie den Dienstbroker nicht für die verwaltete SQL-Zielinstanz verwenden.

Um dieses Problem zu umgehen, stellen Sie sicher, dass Sie service broker für die Quelldatenbank SQL Server aktivieren, bevor Sie sie zu SQL Managed Instance migrieren. Wenn Sie die Datenbank bereits migriert haben, ohne den Service Broker zu aktivieren, können Sie sie für die Quelldatenbank SQL Server aktivieren und dann die Datenbank erneut zu SQL Managed Instance migrieren.

Behandeln von Problemen mit dem Protokollwiedergabedienst

Nachdem Sie LRS gestartet haben, verwenden Sie entweder eines der folgenden Überwachungs-Cmdlets, 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:

• Für PowerShell: Get-AzSqlInstanceOperation
• Für Azure CLI: az sql mi op show

Falls der Protokollwiedergabedienst nach einiger Zeit 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 denselben Namen wie die Datenbank, die Sie von Ihrer SQL Server Instanz migrieren möchten? 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 LRS nach dem Fragezeichen (?) kopiert, und sieht der Inhalt etwa so aus: sv=2020-02-10...?
• Ist die Gültigkeitsdauer des SAS-Tokens für das Zeitfenster, in dem die Migration gestartet und abgeschlossen wird, angemessen? Aufgrund der verschiedenen Zeitzonen, die für Ihre SQL Managed Instance Bereitstellung und das SAS-Token verwendet werden, gibt es möglicherweise Unterschiede. 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 Log-Wiederherstellungen parallel gestartet werden, die auf denselben Speichercontainer abzielen, 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 LRS 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, da dies reservierte Schlüsselwörter sind.

Verwandte Inhalte

• Übersicht des Protokollwiederholungsdienstes mit Azure SQL Managed Instance
• Übersicht über den verwaltete Instanz Link
• Migrate von SQL Server zu Azure SQL Managed Instance
• T-SQL-Unterschiede zwischen SQL Server und Azure SQL Managed Instance
• Beste Praktiken zur Kalkulation und Dimensionierung von Arbeitslasten, die zu Azure migriert wurden
• Vergleich von LRS mit verwaltete Instanz-Verknüpfung