Übersicht über den Protokollwiedergabedienst für Azure SQL Managed Instance

2025-04-18

Dieser Artikel bietet eine Übersicht über den Protokollwiedergabedienst (Log Replay Service, LRS), mit dem Sie Datenbanken von SQL Server zu Azure SQL Managed Instance migrieren können. LRS ist ein kostenloser Clouddienst, der für Azure SQL Managed Instance verfügbar ist und auf der Log-Versand-Technologie von SQL Server basiert.

Da LRS Standard-SQL-Server-Sicherungsdateien wiederherstellt, können Sie es verwenden, um von SQL Server, der irgendwo gehostet wird (entweder vor Ort oder in einer beliebigen Cloud), zu Azure SQL Managed Instance zu migrieren.

Um die Migration mit LRS zu starten, lesen Sie Migrieren von Datenbanken mithilfe des Log Replay Service.

Wichtig

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

Wann sollte der Protokollwiedergabedienst verwendet werden?

Azure Database Migration Service verwenden die Azure SQL-Migrationserweiterung für Azure Data Studio und LRS die gleiche zugrunde liegende Migrationstechnologie und die gleichen APIs. LRS ermöglicht zudem komplexe benutzerdefinierte Migrationen und Hybridarchitekturen zwischen lokalen SQL Server-Instanzen und SQL Managed Instance-Implementierungen.

Wenn Sie Azure Database Migration Service oder die Azure SQL-Erweiterung für die Migration nicht nutzen können, können Sie LRS (lokal redundanter Speicher) direkt mit PowerShell, Azure CLI-Cmdlets oder APIs verwenden, um Datenbankmigrationen zu einem SQL Managed Instance manuell zu erstellen und zu orchestrieren.

Ziehe in Betracht die Verwendung von LRS in den folgenden Fällen:

Sie benötigen eine bessere Kontrolle über Ihr Datenbankmigrationsprojekt.
Beim Cutover der Migration gibt es nur wenig Toleranz in Bezug auf Downtime.
Die ausführbare Datei von Database Migration Service kann in Ihrer Umgebung nicht installiert werden.
Für die ausführbare Datei von Database Migration Service besteht kein Zugriff auf Ihre Datenbanksicherungen.
Die Azure SQL-Migrationserweiterung kann nicht in Ihrer Umgebung installiert werden, oder sie kann nicht auf Ihre Datenbanksicherungen zugreifen.
Es besteht kein Zugriff auf das Hostbetriebssystem, oder es sind keine Administratorrechte vorhanden.
Sie können in Ihrer Umgebung keine Netzwerkports für Azure öffnen.
In Ihrer Umgebung bestehen Probleme aufgrund von Netzwerkdrosselung oder Proxyblockierung.
Sicherungen werden über die Option TO URL direkt in Azure Blob Storage-Konten gespeichert.
Sie müssen differenzielle Sicherungen verwenden.

Da LRS durch die Wiederherstellung von Standard-SQL-Server-Sicherungsdateien funktioniert, sollte es Migrationen aus jeder Quelle unterstützen. Die folgenden Quellen wurden getestet:

SQL Server vor Ort/Box
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)
Alibaba Cloud RDS für SQL Server

Wenn bei der Migration von einer nicht aufgelisteten Quelle unerwartete Probleme auftreten, öffnen Sie ein Supportticket, um Hilfe zu erhalten.

Hinweis

Wir empfehlen Ihnen, die Migration von Datenbanken von SQL Server zu Azure SQL Managed Instance mithilfe der Azure SQL-Migrationserweiterung für Azure Data Studio zu automatisieren. Erwägen Sie die Verwendung von LRS zum Orchestrieren von Migrationen, wenn die Azure SQL-Migrationserweiterung Ihre Szenarien nicht vollständig unterstützt.
LRS ist die einzige Methode zum Wiederherstellen von differenziellen Sicherungen in verwalteten Instanzen. Es ist nicht möglich, differenzielle Sicherungen in verwalteten Instanzen manuell wiederherzustellen oder den Modus NORECOVERY mithilfe von T-SQL manuell festzulegen.

Funktionsweise von LRS

Für das Erstellen einer benutzerdefinierten Lösung zum Migrieren von Datenbanken in die Cloud mit dem Protokollwiedergabedienst sind einige Orchestrierungsschritte erforderlich. Diese sind weiter unten in diesem Abschnitt im Diagramm und der zugehörigen Tabelle dargestellt.

Die Migration umfasst das Erstellen von Datenbanksicherungen in SQL Server und das Kopieren von Sicherungsdateien in ein Azure Blob Storage-Konto. Vollständige, Protokoll- und differenzielle Sicherungen werden unterstützt. Dann verwenden Sie den LRS-Cloud-Dienst, um Sicherungsdateien aus dem Azure Blob Storage-Speicherkonto in eine SQL Managed Instance wiederherzustellen. Das Blob Storage-Konto dient als Zwischenspeicher für Sicherungsdateien zwischen SQL Server und SQL Managed Instance.

Der LRS überwacht Ihr Blob Storage-Konto auf neue differenzielle Sicherungen oder Protokollsicherungen, die nach der Wiederherstellung der vollständigen Sicherung hinzugefügt wurden. LRS stellt diese neuen Dateien dann automatisch wieder her. Sie können den Dienst zum Überwachen des Status von Sicherungsdateien nutzen, die unter SQL Managed Instance wiederhergestellt werden, und den Prozess bei Bedarf anhalten.

LRS erfordert keine bestimmte Namenskonvention für Sicherungsdateien. Der Dienst überprüft alle im Azure Blob Storage-Konto gespeicherten Daten und erstellt die Sicherungskette. Dabei werden nur die Dateiheader gelesen. Datenbanken befinden sich während des Migrationsprozesses im Zustand der Wiederherstellung. Die Datenbanken werden im Modus NORECOVERY wiederhergestellt und können daher erst nach Abschluss des Migrationsprozesses wieder für Lese- oder Schreibworkloads verwendet werden.

Beachten Sie Folgendes, wenn Sie mehrere Datenbanken migrieren:

Speichern Sie Sicherungsdateien für jede Datenbank im Blob Storage-Konto in einem separaten Ordner in einer Flatfilestruktur. Verwenden Sie beispielsweise separate Datenbankordner: blobcontainer/datenbank1/dateien, blobcontainer/datenbank2/dateien usw.
Verwenden Sie keine geschachtelten Ordner innerhalb der Datenbankordner, da eine Struktur mit geschachtelten Ordnern nicht unterstützt wird. Verwenden Sie keine Unterordner wie z. B. blobcontainer/datenbank1/unterordner/dateien.
Starten Sie LRS separat für jede Datenbank.
Geben Sie verschiedene URI-Pfade an, um die Datenbankordner im Blob Storage-Konto zu trennen.

Die Aktivierung von CHECKSUM für Sicherungen ist zwar nicht erforderlich, wird aber dringend empfohlen. Die Wiederherstellung von Datenbanken ohne CHECKSUM dauert länger, da SQL Managed Instance bei Sicherungen, die ohne Aktivierung von CHECKSUM wiederhergestellt werden, eine Integritätsprüfung durchführt.

Weitere Informationen finden Sie unter Migrieren von Datenbanken aus SQL Server zu SQL Managed Instance mit dem Protokollwiedergabedienst.

Achtung

Das Erstellen von Sicherungen auf SQL Server mit aktivierter CHECKSUM wird dringend empfohlen, da die Gefahr besteht, dass ohne sie eine beschädigte Datenbank in Azure wiederhergestellt wird.

Vergleich der Migrationsmodi „AutoVervollständigen“ und „Kontinuierlich“

Sie können LRS entweder im Auto-Vervollständigungsmodus oder im kontinuierlichen Modus starten.

Verwenden Sie den Modus Automatisches Abschließen, wenn Sie die gesamte Sicherungskette im Voraus generiert haben und nicht planen, nach dem Start der Migration weitere Dateien hinzuzufügen. Dieser Migrationsmodus wird für passive Workloads empfohlen, die keine Aufholphase für die Daten erfordern. Laden Sie alle Sicherungsdateien in das Blob Storage-Konto hoch, und starten Sie die Migration im Modus zum automatischen Abschließen. Die Migration wird automatisch abgeschlossen, wenn die letzte angegebene Sicherungsdatei wiederhergestellt wurde. Die migrierte Datenbank wird für den Lese-/Schreibzugriff auf der Instanz von SQL Managed Instance verfügbar.

Falls Sie planen, während der Ausführung der Migration immer wieder neue Sicherungen hinzuzufügen, verwenden Sie den Modus Kontinuierlich. Dieser Modus empfiehlt sich für aktive Workloads, bei denen eine Aufholphase für die Daten erforderlich ist. Laden Sie die aktuell verfügbare Sicherungskette in das Blob Storage-Konto hoch, starten Sie die Migration im kontinuierlichen Modus, und fügen Sie bei Bedarf immer wieder neue Sicherungsdateien aus Ihrer Workload hinzu. Das System überprüft den Azure Blob Storage-Ordner regelmäßig und stellt alle gefundenen neuen Dateien aus Protokoll- oder differenziellen Sicherungen wieder her.

Wenn Sie für den Cutover bereit sind, beenden Sie die Workload in Ihrer SQL Server-Instanz, generieren Sie die letzte Sicherungsdatei, und laden Sie diese dann hoch. Vergewissern Sie sich, dass die letzte Sicherungsdatei wiederhergestellt wurde, indem Sie überprüfen, ob das letzte Log-Ende-Backup als wiederhergestellt in SQL Managed Instance angezeigt wird. Initiieren Sie dann den manuellen Cutover. Mit dem abschließenden Übernahmeschritt wird die Datenbank online geschaltet und ist für den Lese-/Schreibzugriff in SQL Managed Instance verfügbar.

Nachdem der LRS beendet wurde – entweder automatisch bei AutoVervollständigen oder manuell bei der Übernahme –, können Sie den Wiederherstellungsvorgang für eine Datenbank, die in SQL Managed Instance in den Onlinezustand versetzt wurde, nicht fortsetzen. Nach Abschluss der Migration können Sie beispielsweise keine weiteren differenziellen Sicherungen für eine Onlinedatenbank mehr wiederherstellen. Um nach Abschluss der Migration weitere Sicherungsdateien wiederherzustellen, müssen Sie die Datenbank in der verwalteten Instanz löschen und die Migration komplett neu starten.

Workflow bei der Migration

Die folgende Abbildung zeigt einen typischen Migrationsworkflow, die zugehörigen Schritte sind in der Tabelle aufgeführt.

Sie müssen den Modus zum automatischen Abschließen nur verwenden, wenn alle Sicherungskettendateien im Voraus verfügbar sind. Dieser Modus empfiehlt sich für passive Workloads, bei denen keine Aufholphase für die Daten erforderlich ist.

Verwenden Sie die Migration im kontinuierlichen Modus, 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.

Diagramm: Orchestrierungsschritte des Protokollwiedergabediensts für SQL Managed Instance

Vorgang	Einzelheiten
1. Kopieren Sie Datenbanksicherungen aus der SQL Server-Instanz in das Blob Storage-Konto.	Kopieren Sie vollständige, differenzielle und Protokollsicherungen aus der SQL Server-Instanz mit AzCopy oder über den Azure Storage-Explorer in den Blob Storage-Container. Hierbei können Sie beliebige Dateinamen verwenden. LRS erfordert keine bestimmte Namenskonvention für Dateien. Wenn Sie mehrere Datenbanken migrieren, verwenden Sie für jede Datenbank einen separaten Ordner.
2. Starten von LRS in der Cloud	Sie können den Dienst mit dem PowerShell-Cmdlet start-azsqlinstancedatabaselogreplay oder mit dem Azure CLI-Cmdlet az_sql_midb_log_replay_start neu starten. Wählen Sie zwischen den Migrationsmodi „Automatisches Abschließen“ oder „Kontinuierlich“ aus. Starten Sie LRS separat für jede Datenbank, die auf einen Sicherungsordner im Blob Storage-Konto verweist. Sobald der Dienst gestartet wird, beginnt er damit, Sicherungen aus dem Blob Storage-Container in SQL Managed Instance wiederherzustellen. Wenn LRS im Autovervollständigungsmodus gestartet wird, stellt es alle Sicherungen durch die angegebene letzte Sicherungsdatei wieder her. Alle Sicherungsdateien müssen im Voraus hochgeladen werden, und es ist nicht möglich, neue Sicherungsdateien hinzuzufügen, nachdem die Migration gestartet wurde. Dieser Modus wird für passive Workloads empfohlen, für die keine Aufholphase für die Daten erforderlich ist. Wenn der Protokollwiedergabedienst im kontinuierlichen Modus gestartet wird, stellt er alle anfangs hochgeladenen Sicherungen wieder her und wartet dann auf neue Dateien, die in den Ordner hochgeladen werden. Der Dienst wendet basierend auf der Kette mit Protokollfolgenummern (Log Sequence Number, LSN) fortlaufend Protokolle an, bis er manuell beendet wird. Dieser Modus empfiehlt sich für aktive Workloads, bei denen eine Aufholphase für die Daten erforderlich ist.
2.1. Überwachen des Fortschritts des Vorgangs.	Sie können den Status des laufenden Wiederherstellungsvorgangs mit dem PowerShell-Cmdlet get-azsqlinstancedatabaselogreplay oder dem Azure CLI-Cmdlet az_sql_midb_log_replay_show überwachen. 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.
2.2. Beenden des Vorgangs bei Bedarf (optional).	Falls Sie den Migrationsprozess beenden müssen, verwenden Sie das PowerShell-Cmdlet stop-azsqlinstancedatabaselogreplay oder das Azure CLI-Cmdlet az_sql_midb_log_replay_stop. Wenn Sie den Vorgang beenden, wird die Datenbank gelöscht, die Sie in SQL Managed Instance wiederherstellen. Nachdem Sie einen Vorgang beendet haben, können Sie LRS für eine Datenbank nicht fortsetzen. Sie müssen den Migrationsprozess ganz neu starten.
3. Wechsel in die Cloud, wenn Sie bereit sind	Wenn der Protokollwiedergabedienst im Modus zum automatischen Vervollständigen gestartet wurde, wird die Migration automatisch beendet, nachdem die angegebene letzte Sicherungsdatei wiederhergestellt wurde. Wenn LRS im kontinuierlichen Modus gestartet wurde, beenden Sie die Anwendung und die Workload. Führen Sie die letzte Sicherung des Protokollendes aus, und laden Sie sie in die Azure Blob Storage-Bereitstellung hoch. Stellen Sie sicher, dass die letzte Sicherung des Protokollendes in der verwalteten Instanz wiederhergestellt wurde. Beenden Sie den Cutover, indem Sie für LRS den Vorgang `complete` initiieren. Verwenden Sie hierzu das PowerShell-Cmdlet complete-azsqlinstancedatabaselogreplay oder das Azure CLI-Cmdlet az_sql_midb_log_replay_complete. Mit diesem Vorgang wird LRS beendet, wodurch die Datenbank in den Onlinezustand für Lese-/Schreibvorgänge in SQL Managed Instance versetzt wird. Ändern Sie die Anwendungsverbindungszeichenfolge so, dass sie nicht mehr auf die SQL Server-Instanz, sondern auf SQL Managed Instance zeigt. Sie müssen diesen Schritt selbst orchestrieren, entweder durch manuelle Änderung der Verbindungszeichenfolge in Ihrer Anwendung oder automatisch (wenn Ihre Anwendung beispielsweise die Verbindungszeichenfolge aus einer Eigenschaft oder einer Datenbank lesen kann).

Wichtig

Nach dem Cutover kann es bei der Dienstebene Unternehmenskritisch erheblich länger dauern, bis SQL Managed Instance wieder verfügbar ist, als bei der Dienstebene Universell, da drei sekundäre Replikate für die Verfügbarkeitsgruppe übertragen werden müssen. Die Dauer des Vorgangs hängt von der Datenmenge ab. Weitere Informationen finden Sie unter Dauer von Verwaltungsvorgängen.

Migrieren großer Datenbanken

Wenn Sie große Datenbanken mit einer Größe von mehreren Terabyte migrieren, sollten Sie Folgendes beachten:

Ein einzelner LRS-Auftrag kann bis zu 30 Tage lang ausgeführt werden. Nach Ablauf dieses Zeitraums wird der Auftrag automatisch abgebrochen.
Bei Aufträgen mit langer Ausführungsdauer werden Migrationsaufträge durch Systemupdates unterbrochen und verlängert. Es wird dringend empfohlen, für geplante Systemupdates ein Wartungsfenster einzurichten. Planen Sie Ihre Migration um das geplante Wartungsfenster herum.
Durch Systemupdates unterbrochene Migrationsaufträge werden bei verwalteten Instanzen der Ebene Universell automatisch angehalten und wieder aufgenommen und bei verwalteten Instanzen der Ebene Unternehmenskritisch neu gestartet. Diese Updates wirken sich auf den Zeitrahmen Ihrer Migration aus.
Um das Hochladen Ihrer SQL Server-Sicherungsdateien in das Blob Storage-Konto zu beschleunigen, erwägen Sie eine Parallelisierung mit mehreren Threads, sofern Ihre Infrastruktur über genügend Netzwerkbandbreite verfügt.

Migration starten

Sie starten die Migration, indem Sie LRS starten. Hierbei können Sie den Dienst entweder im Modus „AutoVervollständigen“ oder „Kontinuierlich“ starten. Ausführliche Informationen finden Sie unter Migrieren mit dem LRS.

Modus zum automatischen Abschließen. Bei Verwendung des Modus zum automatischen Abschließen wird der Migrationsprozess automatisch beendet, nachdem die letzte angegebene Sicherungsdatei wiederhergestellt wurde. Diese Option:
- Für diesen Modus muss die gesamte Sicherungskette im Voraus verfügbar sein und in das Azure Blob Storage-Konto hochgeladen worden sein.
- Das Hinzufügen neuer Sicherungsdateien während der Migration ist nicht möglich.
- In diesem Modus muss der Dateiname der letzten Sicherungsdatei im Startbefehl angegeben werden.
Der Modus zum automatischen Abschließen empfiehlt sich für passive Workloads, bei denen keine Aufholphase für die Daten erforderlich ist.
Fortlaufender Modus: 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.

Der kontinuierliche Modus wird für aktive Workloads empfohlen, 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. LRS muss für jede Datenbank separat gestartet werden und auf den vollständigen URI-Pfad des Azure Blob Storage-Containers sowie den jeweiligen Datenbankordner verweisen. Geschachtelte Ordner in Datenbankordnern werden nicht unterstützt.

Einschränkungen von LRS

Informationen hierzu können Sie unter Einschränkungen bei der Verwendung von LRS finden.

Freigeben über