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

Gilt für:Azure SQL Managed Instance

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. Der Protokollwiedergabedienst ist ein kostenloser Clouddienst, der für Azure SQL Managed Instance verfügbar ist und auf der Protokollversandtechnologie von SQL Server basiert.

Lesen Sie zum Einstieg den Artikel Migrieren von Datenbanken aus SQL Server zu Azure SQL Managed Instance mit dem Protokollwiedergabedienst.

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. Der Protokollwiedergabedienst erweitert komplexe benutzerdefinierte Migrationen und Hybridarchitekturen zwischen lokalen SQL Server-Instanzen und SQL Managed Instance-Bereitstellungen.

Wenn die Verwendung von Azure Database Migration Service oder der Azure SQL-Erweiterung für die Migration nicht möglich ist, können Sie den lokal redundanten Speicher direkt mit PowerShell, Azure CLI-Cmdlets oder APIs nutzen, um Datenbankmigrationen zu SQL Managed Instance manuell zu erstellen und zu orchestrieren.

Erwägen Sie die Verwendung des Protokollwiedergabediensts in den folgenden Fällen:

• Sie benötigen eine bessere Kontrolle über Ihr Datenbankmigrationsprojekt.
• Es besteht nur eine geringe Toleranz in Bezug auf Ausfallzeiten während der Migrationsübernahme.
• 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.

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)

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 des lokal rendundanten Speichers zum Orchestrieren von Migrationen, falls Ihre Szenarios der Azure SQL-Migrationserweiterung nicht vollständig unterstützt werden.
• Der Protokollwiedergabedienst ist die einzige Methode zum Wiederherstellen differenzieller 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 des Protokollwiedergabediensts

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 Protokollwiedergabedienst in der Cloud, um Sicherungsdateien aus dem Azure Blob Storage-Konto in SQL Managed Instance wiederherzustellen. Das Blob Storage-Konto dient als Zwischenspeicher für Sicherungsdateien zwischen SQL Server und SQL Managed Instance.

Der Protokollwiedergabedienst überwacht Ihr Blob Storage-Konto auf neue differenzielle oder Protokollsicherungen, die nach der Wiederherstellung der vollständigen Sicherung hinzugefügt wurden. Diese neuen Dateien werden vom Protokollwiedergabedienst dann automatisch wiederhergestellt. 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.

Für den Protokollwiedergabedienst ist für Sicherungsdateien keine bestimmte Namenskonvention erforderlich. Der Dienst überprüft alle im Azure Blob Storage-Konto gespeicherten Daten und erstellt die Sicherungskette. Dabei werden nur die Dateiheader gelesen. Datenbanken weisen während des Migrationsprozesses den Zustand Wird wiederhergestellt auf. 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 den Protokollwiedergabedienst für jede Datenbank separat.
• 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 „Automatisches Abschließen“ und „Kontinuierlich“

Sie können den Protokollwiedergabedienst entweder im Modus AutoVervollständigen oder Kontinuierlich 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 die letzte Sicherung des Protokollendes in SQL Managed Instance als wiederhergestellt 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 Protokollwiedergabedienst 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.

Vorgang	Details
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. Für den Protokollwiedergabedienst muss keine bestimmte Namenskonvention für Dateien befolgt werden. Wenn Sie mehrere Datenbanken migrieren, verwenden Sie für jede Datenbank einen separaten Ordner.
2. Starten des Protokollwiedergabediensts 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 den Protokollwiedergabedienst separat für jede Datenbank, die auf einen Sicherungsordner im Blob Storage-Ordner verweist. Sobald der Dienst gestartet wird, beginnt er damit, Sicherungen aus dem Blob Storage-Container in SQL Managed Instance wiederherzustellen. Wenn der Protokollwiedergabedienst im Modus zum automatischen Abschließen gestartet wird, stellt er alle Sicherungen bis einschließlich der angegebenen letzten 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 Vorgangsstatus.	Sie können den Status des Wiederherstellungsvorgangs mit dem PowerShell-Cmdlet get-azsqlinstancedatabaselogreplay oder dem Azure CLI-Cmdlet az_sql_midb_log_replay_show überwachen.
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 den Protokollwiedergabedienst für eine Datenbank nicht fortsetzen. Sie müssen den Migrationsprozess ganz neu starten.
3. Durchführen der Übernahme in die Cloud (bei entsprechender Bereitschaft)	Wenn der Protokollwiedergabedienst im Modus zum automatischen Abschließen 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 die Übernahme, indem Sie für den Protokollwiedergabedienst 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 der Protokollwiedergabedienst 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 der Übernahme kann die Verfügbarkeit von SQL Managed Instance mit der Dienstebene „Unternehmenskritisch“ erheblich länger dauern als mit „Universell“, da das Seeding von drei sekundären Replikaten für eine Verfügbarkeitsgruppe mit Hochverfügbarkeit ausgeführt werden muss. 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 Auftrag des Protokollwiedergabediensts 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.

Starten der Migration

Sie starten die Migration, indem Sie den Protokollwiedergabedienst 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 Migrationsauftrag des Protokollwiedergabediensts innerhalb von maximal 30 Tagen abzuschließen. Nach Ablauf dieses Zeitraums wird der Auftrag automatisch abgebrochen.

Hinweis

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

Einschränkungen von LRS

Beachten Sie die folgenden Einschränkungen des Protokollwiedergabediensts:

• Nur .bak-, .log- und .diff-Datenbankdateien werden von LRS unterstützt. Dacpac- und Bacpac-Dateien werden nicht unterstützt.
• Während des Migrationsprozesses können Datenbanken, die migriert werden, nicht für den schreibgeschützten Zugriff auf SQL Managed Instance verwendet werden.
• 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.
• Bei Datenbanksicherungen, die ohne CHECKSUM durchgeführt werden, dauert die Wiederherstellung länger als bei Datenbanksicherungen mit 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 Lesen und Auflisten verfügen. Wenn Sie z. B. Berechtigungen zum Lesen, Auflisten und Schreiben gewähren, kann der Protokollwiedergabedienst aufgrund der zusätzlichen Schreibberechtigung 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, der Containername oder Ordnernamen dürfen nicht backup oder backups enthalten, da es sich um reservierte Schlüsselwörter handelt.
• 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.

Tipp

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.

Nächste Schritte

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

• Erfahren Sie mehr über das Migrieren von Datenbanken zu SQL Managed Instance mithilfe des Verbindungsfeatures.

• Erfahren Sie mehr über das Migrieren von Datenbanken aus SQL Server zu SQL Managed Instance.

• Erfahren Sie mehr über die Unterschiede zwischen SQL Server und SQL Managed Instance.

• Erfahren Sie mehr über bewährte Methoden für Kostenermittlung und Größenanpassung von zu Azure migrierten Workloads.