Migrieren mit dem Link – Azure SQL Managed Instance

Gilt für:Azure SQL Managed Instance

In diesem Artikel erfahren Sie, wie Sie Ihre SQL Server-Datenbank mithilfe des Links verwaltete Instanz zu Azure SQL Managed Instance migrieren.

Einen detaillierten Migrationsleitfaden finden Sie unter Migrate zu Azure SQL Managed Instance. Um Migrationstools zu vergleichen, überprüfen Sie Compare LRS mit verwaltete Instanz Link.

Hinweis

Sie können jetzt Ihre Azure Arc-unterstützte SQL Server-Instanz direkt über das Azure-Portal auf die Azure SQL Managed Instance migrieren. Weitere Informationen finden Sie unter Migrate to Azure SQL Managed Instance.

Übersicht

Der Link zur verwaltete Instanz ermöglicht die Migration von einem SQL Server, der überall gehostet wird, zu Azure SQL Managed Instance. Der Link verwendet die Always On-Verfügbarkeitsgruppentechnologie, um Änderungen nahezu in Echtzeit von der primären SQL Server Instanz in die sekundäre SQL Managed Instance zu replizieren. Die Verknüpfung bietet die einzige wirklich online Migrationsoption zwischen SQL Server und Azure SQL Managed Instance, da die einzige Ausfallzeit auf die von SQL verwaltete Zielinstanz reduziert wird.

Die Migration mit dem Link bietet Folgendes:

  • Die Möglichkeit, schreibgeschützte Workloads auf SQL Managed Instance zu testen, bevor Sie die Migration zum Azure abschließen.
  • Die Möglichkeit, die Verknüpfung und die Migration so lange wie nötig laufen zu lassen, d. h. Wochen und sogar Monate.
  • Beinahe-Echtzeit-Replikation von Daten, die die schnellste verfügbare Datenreplikation für Azure ermöglicht.
  • Die Migration mit minimalster Ausfallzeit im Vergleich zu allen anderen derzeit verfügbaren Lösungen.
  • Sofortige Umstellung zu der Ziel-SQL Managed Instance.
  • Die Möglichkeit, jederzeit zu migrieren, wenn Sie bereit sind.
  • Die Möglichkeit, einzelne oder mehrere Datenbanken aus einer oder mehreren SQL Server Instanzen zu derselben oder mehreren SQL-verwalteten Instanzen in Azure zu migrieren.
  • Die einzige echte Online-Migration zur Dienstebene „Unternehmenskritisch“.

Hinweis

Sie können zwar nur eine Datenbank pro Link migrieren, aber Sie können mehrere Verknüpfungen von derselben SQL Server Instanz zu derselben SQL Managed Instance einrichten.

Cutover-Verhalten

Das Wechselverhalten hängt von der SQL-Server-Version ab, von der Sie migrieren, und von der Aktualisierungsrichtlinie Ihrer Ziel-SQL Managed Instance:

  • Von SQL Server 2016 bis SQL Server 2019 wird bei der Umstellung auf SQL Managed Instance die Verknüpfung getrennt.
  • Bei SQL Server 2022 oder höher kann bei der Umstellung auf SQL Managed Instance die Verknüpfung während des Failovers je nach Ihrer Auswahl entweder aufgehoben oder beibehalten werden. Wenn Sie den Link beibehalten möchten und Ihre sql-verwaltete Instanz mit einer übereinstimmenden Updaterichtlinie konfiguriert ist, können Sie die Migration bei Bedarf zurück zu SQL Server rückgängig machen.

Für die Migration ist das Entfernen des Links die empfohlene Option. Wenn Sie den Link beibehalten, aber später die Verknüpfung entfernen möchten, warten Sie, bis Azure die erste vollständige Sicherung der Datenbank nach dem Failover abschließen, bevor Sie die Verknüpfung entfernen. Mit diesem Schritt wird sichergestellt, dass die Datenbank für SQL Managed Instance fehlerfrei und voll funktionsfähig ist. Es hilft auch, ein seltenes bekanntes Problem zu vermeiden, bei dem die Datenbank nach einem Serverneustart vorübergehend nicht verfügbar werden kann, wenn die Verknüpfung zu früh entfernt wird. Weitere Informationen finden Sie unter Datenbank ist nach Serverneustart infolge eines MI-Link-Failovers nicht mehr verfügbar.

Umkehren einer Migration

Die Rückwärtsmigration von SQL Server von Azure SQL Managed Instance kann je nach Aktualisierungsrichtlinie Ihrer SQL Managed Instance unterstützt werden. Beispiel:

  • SQL Server 2022-Updaterichtlinie: Datenbanken aus Instanzen, die mit der SQL Server 2022 Updaterichtlinie konfiguriert sind, können wieder in SQL Server 2022-Instanzen wiederhergestellt werden.
  • SQL Server 2025-Updaterichtlinie: Datenbanken aus Instanzen, die mit der SQL Server 2025 Updaterichtlinie konfiguriert sind, können wieder in SQL Server 2025-Instanzen wiederhergestellt werden.
  • Always-up-to-date update policy: Datenbanken aus Instanzen, die mit der Always-up-to-date Updaterichtlinie konfiguriert sind, können nicht wieder auf SQL Server wiederhergestellt werden.

Wenn die Quellversion von SQL Server älter als SQL Server 2022 ist, ist die Reverse-Migration nicht möglich. Wenn Sie Ihre Datenbank zu SQL Managed Instance migrieren, wird ein internes Upgrade auf eine neuere Datenbankversion durchgeführt, die nicht mit früheren SQL Server Versionen kompatibel ist. Die Kompatibilität der Reversemigrationsdatenbank ist nur verfügbar, wenn SQL Managed Instance mit der entsprechenden Updaterichtlinie konfiguriert ist.

Voraussetzungen

Um den Link mit Azure SQL Managed Instance für die Migration zu verwenden, benötigen Sie die folgenden Voraussetzungen:

Bewerten und entdecken

Sobald Sie sich davon überzeugt haben, dass Ihre Quellumgebung unterstützt wird, können Sie mit der Vorbereitungsphase zur Migration beginnen. Ermitteln Sie alle vorhandenen Datenquellen, bewerten Sie die Umsetzbarkeit der Migration, und identifizieren Sie Probleme, die der Migration möglicherweise im Weg stehen. Scannen Sie in der Ermittlungsphase das Netzwerk, um alle SQL Server Instanzen und Features zu identifizieren, die von Ihrer Organisation verwendet werden.

Sie können die folgenden Tools verwenden, um SQL-Quellen in Ihrer Umgebung zu entdecken:

  • SQL Server aktiviert durch Azure Arc: SQL Server, das von Azure Arc aktiviert wird, erzeugt automatisch ein Assessment für die Migration zu Azure, um den Erkennungsprozess und die Bereitschaftsbewertung für die Migration zu vereinfachen.
  • Azure Migrate um die Migrationseignung von lokalen Servern zu bewerten, leistungsbasierte Größenanpassungen durchzuführen und Kostenschätzungen für die Ausführung in Azure bereitzustellen.
  • Microsoft Assessment and Planning Toolkit (das "MAP Toolkit"), um Ihre aktuelle IT-Infrastruktur zu bewerten. Das Toolkit bietet leistungsfähige Optionen zur Bestandserfassung, Bewertung und Berichterstellung, die den Planungsprozess für die Migration erleichtern.

Nachdem Datenquellen ermittelt wurden, bewerten Sie alle lokalen SQL Server Instanzen, die zu Azure SQL Managed Instance migriert werden können, um Migrationsblocker oder Kompatibilitätsprobleme zu identifizieren.

Sie können die Migrationsbereitschaftsbewertung verwenden, um Ihre Quelle SQL Server Instanz zu bewerten.

Ausführliche Anleitungen finden Sie unter Vorabmigration.

Zielinstanz erstellen

Nachdem Sie Ihre vorhandene Umgebung bewertet und die entsprechende Dienstebenen- und Hardwarekonfiguration für die von SQL verwaltete Zielinstanz ermittelt haben, stellen Sie Ihre Zielinstanz über das portal Azure, PowerShell oder das Azure CLI bereit.

Konfigurieren Sie nach dem Erstellen der verwalteten SQL-Zielinstanz eine Verknüpfung zwischen der Datenbank in Ihrer SQL Server Instanz und Azure SQL Managed Instance. Konfigurieren Sie zunächst Ihre Umgebung und konfigurieren Sie dann einen Link mithilfe von SQL Server Management Studio (SSMS) oder scripts.

Replikationsverzögerung überprüfen

Es ist wichtig, dass das sekundäre Replikat das primäre Replikat aufnimmt, bevor ein geplantes Migrationsfailover ausgeführt wird. Geplantes Failover kann ablaufen und fehlschlagen, wenn das sekundäre Replikat dem primären Replikat weit hinterherhinkt.

Verwenden Sie die folgende T-SQL-Abfrage sowohl für SQL Server als auch für SQL Managed Instance, um den Replikationsabstand zwischen den Replikaten zu überwachen:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

Wenn die Replikationsverzögerung hoch ist, warten Sie, bis die sekundäre Replik die primäre Replik einholt. Möglicherweise müssen Sie zusätzliche Schritte zur Problembehandlung ausführen, wenn die Verzögerung weiterhin besteht, z. B. das Anhalten von Arbeitslasten für das primäre Replikat, die Verbesserung des Verbindungsnetzwerkdurchsatzes zwischen den beiden Instanzen oder das Erhöhen der Ressourcenkapazität für das sekundäre Replikat. Die einfachste Möglichkeit zum Beenden von Arbeitslasten in einem SQL Server primären Replikat ist das Ausschneiden von Anwendungsverbindungen mit der Instanz.

Migrieren mehrerer Datenbanken

Wenn Sie beabsichtigen, mehrere Datenbanken von Instanzen auf demselben Server zu migrieren, um optimale Leistung und Vorhersagbarkeit zu erzielen, migrieren Sie jeweils 8 Datenbanken pro Instanz. Wenn Sie z. B. über 10 Instanzen mit jeweils 32 verknüpften Datenbanken verfügen, migrieren Sie jeweils 8 Datenbanken nach jeder Instanz mithilfe geplanter Failovers, und wiederholen Sie den Vorgang, bis alle Datenbanken migriert werden.

Datensynchronisierung und Übernahme

Nachdem der Link eingerichtet wurde und Sie bereit sind, zu migrieren, führen Sie die folgenden Schritte aus (in der Regel während eines Wartungsfensters):

  1. Beenden Sie die Arbeitsauslastung in der primären SQL Server-Datenbank, damit die sekundäre Datenbank auf SQL Managed Instance aufholen kann. Die einfachste Möglichkeit zum Beenden von Arbeitslasten in einem SQL Server primären Replikat ist das Ausschneiden von Anwendungsverbindungen mit der Instanz.
  2. Überprüfen Sie, ob alle Daten in die sekundäre Datenbank auf SQL Managed Instance übertragen wurden. Überprüfen Sie die Replikationsverzögerung, um sicherzustellen, dass das sekundäre Replikat mit dem primären Replikat synchronisiert ist.
  3. Führen Sie den Failover-Vorgang über den Link zur sekundären SQL Managed Instance aus, indem Sie den geplanten Failover auswählen.
  4. (Optional) Aktivieren Sie das Kontrollkästchen zum Entfernen der Verknüpfung nach erfolgreichem Failover, um sicherzustellen, dass das Failover einseitig ist und die Verknüpfung entfernt wird.
  5. (Optional) Wenn Sie eine unterstützte SQL Server Version mit einer übereinstimmenden SQL Managed Instance Update-Richtlinie verwenden, können Sie den Link nach dem Failover beibehalten, um eine Migration bei Bedarf rückgängig zu machen. Überprüfen Sie den Abschnitt zur Rücksetzung einer Migration auf spezifische Versionsdetails.
  6. Leiten Sie die Anwendung um, um eine Verbindung zum Endpunkt der verwalteten SQL-Instanz herzustellen.
  7. (Optional) Wenn Sie sich nicht entschieden haben, den Link während des Failovers zu entfernen, können Sie den Link nach der Umschaltung entfernen, sobald Sie ihn nicht mehr benötigen.

Überprüfen Sie die Migration

Nachdem Sie das Ziel der SQL Managed Instance geändert haben, überwachen Sie Ihre Anwendung, testen Sie die Leistung, und beheben Sie alle Probleme.

Ausführliche Informationen erhalten Sie nach der Migration.

Bekannte Probleme bei der Migration

Überprüfen Sie die folgenden bekannten Probleme im Zusammenhang mit der Migration mit dem Link.

In seltenen Fällen ist Ihre Datenbank nach einem Serverneustart infolge des Failovers der Verknüpfung auf einer SQL Managed Instance vorübergehend nicht verfügbar. Dieses bekannte Problem tritt auf, wenn Sie einen Link ablegen, bevor Azure eine vollständige Sicherung der Datenbank nach dem anfänglichen Failover zum SQL Managed Instance abgeschlossen hat.

Die Datenbank wird nach Microsoft Intervention automatisch wiederhergestellt, diese Wiederherstellung kann jedoch einige Zeit in Anspruch nehmen.

Um dieses Problem zu vermeiden, legen Sie den Link erst ab, wenn die erste vollständige Sicherung abgeschlossen ist, nachdem das Failover von SQL Server auf SQL Managed Instance erfolgt ist. Weitere Informationen finden Sie unter Datenbank, die nach dem Neustart des Servers nicht verfügbar ist.

Wiederherstellen von Vorgangsfehlern nach der Migration zu SQL Managed Instance

Wenn Sie eine Datenbank aus SQL Server 2019 und höheren Versionen mit aktivierter beschleunigter Datenbankwiederherstellung zu Azure SQL Managed Instance migrieren, die jedoch mit dem Persistent Version Store (PVS) auf etwas anderes als die PRIMARY Dateigruppe konfiguriert ist, können in der SQL Managed Instanz bei Wiederherstellungsvorgängen Fehler auftreten.

Um dieses Problem zu umgehen, stellen Sie sicher, dass Sie den persistenten Versionsspeicher (PVS) auf PRIMARY in der SQL Server-Quelldatenbank festlegen, bevor Sie es 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.

Beginnend mit SQL Server 2019, können Sie, wenn Sie eine Datenbank zu einer Azure SQL Managed Instance migrieren und die Quelldatenbank die beschleunigte Datenbankwiederherstellung deaktiviert hat, keine beschleunigte Datenbankwiederherstellung auf der Zielinstanz von SQL Managed Instance 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 in der SQL Server-Quelldatenbank 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 den Service Broker für die Quelldatenbank SQL Server aktivieren, bevor Sie es 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.

Zugehöriger Inhalt

So verwenden Sie den Link:

Weitere Informationen zum Link finden Sie unter:

Informationen zu anderen Replikations- und Migrationsszenarios finden Sie unter:

  • Last updated on