Freigeben über

Vorbereitung der Umgebung für eine verwaltete Instanzlink-Migration – SQL Server-Migration in Azure Arc

Gilt für:SQL Server

Dieser Artikel hilft Ihnen, Ihre Umgebung für eine Migration der verwalteten Instanz Ihrer SQL Server-Instanz vorzubereiten, die durch Azure Arc zu einer Azure SQL Managed Instance im Azure-Portal ermöglicht wird.

Mit dem Link können Sie Ihre SQL Server-Datenbanken mithilfe der Echtzeitreplikation mit einer verteilten Verfügbarkeitsgruppe (Onlinemigration) zu Azure SQL Managed Instance migrieren:

Diagramm mit verwalteter Instanzverknüpfungsmigration.

Hinweis

Sie können Feedback zu Ihrer Migrationserfahrung direkt an die Produktgruppe senden.

Voraussetzungen

Um Ihre SQL Server-Datenbanken über das Azure-Portal zu Azure SQL Managed Instance zu migrieren, benötigen Sie die folgenden Voraussetzungen:

Unterstützte SQL Server-Versionen

Sowohl die Dienstebenen "Allgemeiner Zweck" als auch "Geschäftskritischer Dienst" der verwalteten Instanz von Azure SQL unterstützen den Link "Verwaltete Instanz". Die Migration mit dem Linkfeature funktioniert mit den Editionen Enterprise, Developer und Standard von SQL Server unter Windows Server.

In der folgenden Tabelle sind die mindestens unterstützten SQL Server-Versionen für den Link aufgeführt:

SQL Server-Version Minimale erforderliche Wartungsaktualisierung
SQL Server 2025 (17.x) SQL Server 2025 RTM (17.0.1000.7)
SQL Server 2022 (16.x) SQL Server 2022 RTM (16.0.1000.6)
SQL Server 2019 (15.x) SQL Server 2019 CU20 (15.0.4312.2)
SQL Server 2017 (14.x) SQL Server 2017 CU31 (14.0.3456.2) oder höher und das entsprechende SQL Server 2017 Azure Connect Pack (14.0.3490.10) Build
SQL Server 2016 (13.x) SQL Server 2016 SP3 (13.0.6300.2) und das entsprechende SQL Server 2016 Azure Connect Pack (13.0.7000.253)
SQL Server 2014 (12.x) und früher Versionen vor SQL Server 2016 werden nicht unterstützt.

Die Reverse-Migration wird nur in SQL Server 2025 und SQL Server 2022 von verwalteten SQL-Instanzen mit der entsprechenden Updaterichtlinie unterstützt. Sie können eine Migration manuell über andere Tools wie systemeigene Sicherung und Wiederherstellung rückgängig machen oder einen Link in SSMS manuell konfigurieren.

Erlaubnisse

In diesem Abschnitt werden die Berechtigungen beschrieben, die Sie zum Migrieren Ihrer SQL Server-Instanz zu SQL Managed Instance über das Azure-Portal benötigen.

Für die SQL Server-Quellinstanz benötigen Sie die folgenden Berechtigungen:

  • Wenn Sie das Prinzip der minimalen Berechtigung aktivieren, werden erforderliche Berechtigungen wie sysadmin während des Datenbankmigrationsprozesses nach Bedarf erteilt.
  • Wenn Sie die geringsten Berechtigungen nicht verwenden können, benötigt die Person, die die Migration ausführt, Sysadmin-Berechtigungen für die SQL Server-Quellinstanz. Wenn Sie eine Migration abbrechen müssen, weisen Sie dem Konto NT AUTHORITY\SYSTEM ebenfalls manuell sysadmin-Berechtigungen zu.

Um mit dem Link "Verwaltete Instanz" zu migrieren, benötigen Sie eine der folgenden Berechtigungen für das ZIEL der verwalteten SQL-Instanz:

Mindestberechtigungen finden Sie unter "Benutzerdefinierte Berechtigungen".

Hinweis

Benutzer mit den SqlServerAvailabilityGroups_CreateManagedInstanceLink, SqlServerAvailabilityGroups_failoverMiLinkund SqlServerAvailabilityGroups_deleteMiLink Berechtigungen in Azure können während des Migrationsprozesses Aktionen im Datenbankmigrationsbereich ausführen, die die SQL Server-Berechtigungen des kontos erhöhen, das von der Erweiterung verwendet wird, einschließlich der sysadmin Rolle.

Vorbereiten der SQL Server-Instanz

Führen Sie die folgenden Schritte aus, um Ihre SQL Server-Instanz vorzubereiten:

Sie müssen SQL Server neu starten , damit diese Änderungen wirksam werden.

Installieren von Dienstupdates

Vergewissern Sie sich, dass auf Ihrer SQL Server-Version das entsprechende Wartungsupdate installiert ist, wie in der folgenden Tabelle der Versionsunterstützung aufgeführt. Wenn Sie Updates installieren, müssen Sie Ihre SQL Server-Instanz während des Updates neu starten.

Führen Sie das folgende Transact-SQL-Skript (T-SQL) in SQL Server aus, um zu überprüfen, welche SQL Server-Version Sie verwenden:

-- Run on SQL Server
-- Shows the version and CU of the SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';

Erstellen eines Datenbankmasterschlüssels in der Masterdatenbank

Die Verknüpfung verwendet Zertifikate zum Verschlüsseln der Authentifizierung und Kommunikation zwischen SQL Server und SQL Managed Instance. Der Datenbankmasterschlüssel schützt die von der Verknüpfung verwendeten Zertifikate. Wenn Sie bereits über einen Datenbankmasterschlüssel verfügen, können Sie diesen Schritt überspringen.

Erstellen Sie einen Datenbankmasterschlüssel in der master Datenbank. Geben Sie Ihr Kennwort anstelle von <strong_password> in das nachfolgende Skript ein, und bewahren Sie es an einem vertraulichen und sicheren Ort auf. Führen Sie dieses T-SQL-Skript unter SQL Server aus:

-- Run on SQL Server
-- Create a master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>';

Verwenden Sie das folgende T-SQL-Skript in SQL Server, um sich zu vergewissern, dass Sie über den Datenbankhauptschlüssel verfügen:

-- Run on SQL Server
USE master;
GO
SELECT * FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%';

Vorbereiten von SQL Server 2016-Instanzen

Für SQL Server 2016 (13.x) müssen Sie die zusätzlichen Schritte ausführen, die in den Voraussetzungen für die Vorbereitung von SQL Server 2016 für den Link dokumentiert sind. Diese zusätzlichen Schritte sind für SQL Server 2017 (14.x) und höhere Versionen, die von der Verknüpfung unterstützt werden, nicht erforderlich.

Aktivieren von Verfügbarkeitsgruppen

Das Linkfeature basiert auf der Funktion für Always On-Verfügbarkeitsgruppen, die standardmäßig deaktiviert ist. Weitere Informationen finden Sie unter Aktivieren des Features für Always On-Verfügbarkeitsgruppen.

Führen Sie das folgende T-SQL-Skript in SQL Server aus, um sich zu vergewissern, dass die Funktion Verfügbarkeitsgruppen aktiviert ist:

-- Run on SQL Server
-- Is the availability groups feature enabled on this SQL Server
DECLARE @IsHadrEnabled sql_variant = (select SERVERPROPERTY('IsHadrEnabled'))
SELECT
    @IsHadrEnabled as 'Is HADR enabled',
    CASE @IsHadrEnabled
        WHEN 0 THEN 'Availability groups DISABLED.'
        WHEN 1 THEN 'Availability groups ENABLED.'
        ELSE 'Unknown status.'
    END
    as 'HADR status'

Wenn das Feature für Verfügbarkeitsgruppen nicht aktiviert ist, führen Sie die folgenden Schritte aus, um es zu aktivieren:

  1. Öffnen Sie SQL Server-Konfigurations-Manager.

  2. Wählen Sie im linken Bereich SQL Server-Dienste aus.

  3. Klicken Sie mit der rechten Maustaste auf den SQL Server-Dienst, und wählen Sie dann "Eigenschaften" aus:

    Screenshot: SQL Server-Konfigurations-Manager mit Auswahlmöglichkeiten zum Öffnen der Eigenschaften des Diensts

  4. Wechseln Sie zur Registerkarte Always On-Verfügbarkeitsgruppen.

  5. Aktivieren Sie das Kontrollkästchen "AlwaysOn-Verfügbarkeitsgruppen aktivieren " und dann "OK".

    Screenshot: Eigenschaften von Always On-Verfügbarkeitsgruppen

    • Wenn Sie SQL Server 2016 (13.x) verwenden und die Option "AlwaysOn-Verfügbarkeitsgruppen aktivieren" mit der Meldung This computer is not a node in a failover clusterdeaktiviert ist, führen Sie die unter "Vorbereiten von SQL Server 2016"-Voraussetzungen für den Link beschriebenen Schritte aus. Nachdem Sie diese Schritte ausgeführt haben, kehren Sie zu diesem Schritt zurück, und versuchen Sie es erneut.

  6. Wählen Sie im Dialogfeld OK aus.

  7. Starten Sie den SQL Server-Dienst neu.

Aktivieren von Flags für die Ablaufverfolgung beim Starten

Um die Leistung Ihres Links zu optimieren, aktivieren Sie beim Start die folgenden Trace Flags:

  • -T1800: Dieses Ablaufverfolgungskennzeichen optimiert die Leistung, wenn sich die Protokolldateien für die primären und sekundären Replikaten in einer Verfügbarkeitsgruppe auf Datenträgern mit unterschiedlichen Sektorgrößen befinden, z. B. 512 Byte und 4 KB. Wenn sowohl primäre als auch sekundäre Replikate eine Datenträgersektorgröße von 4 KB verwenden, benötigen Sie dieses Ablaufverfolgungskennzeichen nicht. Weitere Informationen finden Sie unter KB3009974.
  • -T9567: Dieses Ablaufverfolgungsflag aktiviert die Komprimierung des Datenstroms für Verfügbarkeitsgruppen während des automatischen Seedings. Die Komprimierung erhöht die Auslastung des Prozessors, kann jedoch die Übertragungszeit während des Seedings erheblich reduzieren.

Führen Sie die folgenden Schritte aus, um diese Ablaufverfolgungsflags beim Start zu aktivieren:

  1. Öffnen Sie den SQL Server-Konfigurations-Manager.

  2. Wählen Sie im linken Bereich SQL Server-Dienste aus.

  3. Klicken Sie mit der rechten Maustaste auf den SQL Server-Dienst, und wählen Sie dann "Eigenschaften" aus.

    Screenshot: SQL Server-Konfigurations-Manager

  4. Wechseln Sie zur Registerkarte Startparameter. Geben Sie unter Startparameter angeben -T1800 ein, und wählen Sie Hinzufügen aus, um den Startparameter hinzuzufügen. Geben Sie dann -T9567 ein, und wählen Sie Hinzufügen aus, um das andere Ablaufverfolgungsflag hinzuzufügen. Wählen Sie Übernehmen aus, um die Änderungen zu speichern.

    Screenshot: Eigenschaften der Startparameter

  5. Wählen Sie OK aus, um das Fenster Eigenschaften zu schließen.

Weitere Informationen finden Sie in der Syntax zum Aktivieren von Ablaufverfolgungs-Flags.

Neustarten von SQL Server und Überprüfen der Konfiguration

Wenn Sie die Version von SQL Server nicht aktualisieren müssen, aktivieren Sie das Verfügbarkeitsgruppenfeature, oder fügen Sie Startablaufverfolgungskennzeichnungen hinzu, können Sie diesen Abschnitt überspringen.

Nachdem Sie sichergestellt haben, dass Sie eine unterstützte Version von SQL Server verwenden, aktivieren Sie das Feature "AlwaysOn-Verfügbarkeitsgruppen", und fügen Sie Ihre Startablaufverfolgungskennzeichnungen hinzu, starten Sie Die SQL Server-Instanz neu, um alle diese Änderungen anzuwenden:

  1. Öffnen Sie SQL Server-Konfigurations-Manager.

  2. Wählen Sie im linken Bereich SQL Server-Dienste aus.

  3. Klicken Sie mit der rechten Maustaste auf den SQL Server-Dienst, und wählen Sie dann "Neu starten" aus.

    Screenshot: Aufruf des SQL Server-Neustartbefehls

Führen Sie nach dem Neustart das folgende T-SQL-Skript in SQL Server aus, um die Konfiguration Ihrer SQL Server-Instanz zu überprüfen:

-- Run on SQL Server
-- Shows the version and CU of SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';
GO
-- Shows if the Always On availability groups feature is enabled
SELECT SERVERPROPERTY ('IsHadrEnabled') as 'Is Always On enabled? (1 true, 0 false)';
GO
-- Lists all trace flags enabled on SQL Server
DBCC TRACESTATUS;

Ihre SQL Server-Version sollte eine der unterstützten Versionen sein, auf die die entsprechenden Dienstupdates angewendet wurden. Das Feature "Always On-Verfügbarkeitsgruppen" sollte aktiviert sein, und Sie sollten die Traceflags -T1800 und -T9567 aktiviert haben. Der folgende Screenshot ist ein Beispiel für das erwartete Ergebnis für eine ordnungsgemäß konfigurierte SQL Server-Instanz:

Screenshot: Erwartetes Ergebnis in SSMS

Datenbank auf vollständiges Wiederherstellungsmodell festlegen

Datenbanken, die über den Link migriert wurden, müssen sich im vollständigen Wiederherstellungsmodell befinden und mindestens eine Sicherung aufweisen.

Führen Sie den folgenden Code auf SQL Server für alle Datenbanken aus, die Sie migrieren möchten. Ersetzen Sie <DatabaseName> durch den eigentlichen Namen der Datenbank.

-- Run on SQL Server
-- Set full recovery model for all databases you want to migrate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to migrate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

Importieren von in Azure vertrauenswürdigen Stammzertifizierungsstellenschlüsseln in SQL Server

Um den von Azure bereitgestellten öffentlichen Schlüsselzertifikaten der SQL Managed Instance Vertrauen zu schenken, müssen Sie Azure-vertrauenswürdige Stammzertifikate (CA) in den SQL Server importieren.

Sie können die Stammzertifizierungsstellenschlüssel aus den Angaben der Azure-Zertifizierungsstelle herunterladen. Laden Sie mindestens die Zertifikate DigiCert Global Root G2 und Microsoft RSA Root Certificate Authority 2017 herunter, und importieren Sie sie in Ihre SQL Server-Instanz.

Hinweis

Das Stammzertifikat im Zertifizierungspfad für ein öffentliches SQL-Instanzzertifikat wird von einer vertrauenswürdigen Azure-Stammzertifizierungsstelle ausgestellt. Die spezifische Stammzertifizierungsstelle kann sich im Laufe der Zeit ändern, wenn Azure seine Liste der vertrauenswürdigen Zertifizierungsstellen aktualisiert. Für ein vereinfachtes Setup installieren Sie alle in Azure-Stammzertifizierungsstellen aufgeführten Stammzertifikate. Sie können nur den erforderlichen Zertifizierungsstellenschlüssel installieren, indem Sie den Aussteller eines zuvor importierten öffentlichen Schlüssels der SQL-Verwaltungsinstanz identifizieren.

Speichern Sie die Zertifikate lokal in der SQL Server-Instanz, z. B. im Beispielpfad C:\certs\<name of certificate>.crt , und importieren Sie dann die Zertifikate aus diesem Pfad mithilfe des folgenden Transact-SQL Skripts. Ersetzen Sie durch <name of certificate> den tatsächlichen Zertifikatnamen: DigiCert Global Root G2 und Microsoft RSA Root Certificate Authority 2017, die die erforderlichen Namen für diese beiden Zertifikate sind.

-- Run on SQL Server-- Import <name of certificate> root-authority certificate (trusted by Azure), if not already present
CREATE CERTIFICATE [DigiCertPKI] FROM FILE = 'C:\certs\DigiCertGlobalRootG2.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('DigiCertPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO
CREATE CERTIFICATE [MicrosoftPKI] FROM FILE = 'C:\certs\Microsoft RSA Root Certificate Authority 2017.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('MicrosoftPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO

Tipp

Wenn die sp_certificate_add_issuer gespeicherte Prozedur in Ihrer SQL Server-Umgebung fehlt, verfügt Ihre SQL Server-Instanz wahrscheinlich nicht über das entsprechende Dienstupdate.

Überprüfen Sie schließlich alle erstellten Zertifikate mithilfe der folgenden dynamischen Verwaltungsansicht (DMV):

-- Run on SQL Server
USE master
SELECT * FROM sys.certificates

Konfigurieren der Netzwerkverbindung

Damit der Link funktioniert, muss zwischen SQL Server und SQL Managed Instance eine Netzwerkverbindung bestehen. Die von Ihnen ausgewählte Netzwerkoption hängt davon ab, ob sich Ihre SQL Server-Instanz in einem Azure-Netzwerk befindet.

SQL Server außerhalb von Azure

Wenn Sie Ihre SQL Server-Instanz außerhalb von Azure hosten, können Sie eine VPN-Verbindung zwischen SQL Server und SQL Managed Instance herstellen, indem Sie eine der folgenden Optionen verwenden:

Tipp

Verwenden Sie ExpressRoute, um die beste Netzwerkleistung beim Replizieren von Daten zu erzielen. Stellen Sie ein Gateway mit genügend Bandbreite für Ihren Anwendungsfall bereit.

SQL Server auf Azure-VMs

Die Bereitstellung von SQL Server auf virtuellen Azure-Computern im selben virtuellen Azure-Netzwerk, das SQL Managed Instance hostet, ist die einfachste Methode, da die Netzwerkkonnektivität zwischen den beiden Instanzen automatisch vorhanden ist. Weitere Informationen finden Sie unter Schnellstart: Konfigurieren einer Azure-VM für das Herstellen einer Verbindung mit Azure SQL Managed Instance.

Wenn sich Ihre SQL Server-Instanz auf virtuellen Azure-Computern in einem anderen virtuellen Netzwerk von Ihrer verwalteten SQL-Instanz befindet, müssen Sie die beiden virtuellen Netzwerke verbinden. Virtuelle Netzwerke müssen sich nicht im gleichen Abonnement befinden, damit dieses Szenario funktioniert.

Sie haben zwei Optionen zum Verbinden virtueller Netzwerke:

Peering ist vorzuziehen, da es das Microsoft-Backbone-Netzwerk verwendet. Aus Konnektivitätsperspektive gibt es also keinen spürbaren Unterschied bei der Latenz zwischen virtuellen Computern in einem virtuellen Peered-Netzwerk und im gleichen virtuellen Netzwerk. Virtuelles Netzwerk-Peering wird zwischen Netzwerken in derselben Region unterstützt. Das globale Peering virtueller Netzwerke wird für Instanzen unterstützt, die in Subnetzen gehostet werden, die ab dem 22. September 2020 erstellt wurden. Weitere Informationen finden Sie unter Häufig gestellte Fragen (FAQ).

Netzwerkports zwischen den Umgebungen

Unabhängig vom Verbindungsmechanismus müssen Sie die folgenden Anforderungen erfüllen, damit der Netzwerkdatenverkehr zwischen den Umgebungen fließt:

Die Regeln für die Netzwerksicherheitsgruppe (Network Security Group, NSG) für das Subnetz, das die verwaltete SQL-Instanz hostet, müssen Folgendes zulassen:

  • Eingehender Port 5022 und Portbereich 11000-11999, um Datenverkehr von der SQL Server-IP-Quelladresse zu empfangen
  • Ausgehender Port 5022 zum Senden von Datenverkehr an die SQL Server-ZIEL-IP-Adresse

Der Port 5022 kann in sql Managed Instance nicht geändert werden.

Alle Firewalls im Netzwerk, die SQL Server hostet, und das Hostbetriebssystem muss Folgendes zulassen:

  • Offener eingehender Port 5022 zum Empfang von Datenverkehr aus dem Quell-IP-Adressbereich des /24-Subnetzes der verwalteten Instanz (z. B. 10.0.0.0/24)
  • Offener ausgehender Port 5022 und Portbereich 11000–11999 zum Senden von Datenverkehr an den Ziel-IP-Adressbereich des Subnetzes der verwalteten Instanz (z. B. 10.0.0.0/24)

Der Port 5022 kann auf der SQL Server-Seite angepasst werden, aber der Portbereich 11000-11999 muss wie folgt geöffnet werden.

Diagramm mit Netzwerkanforderungen zum Einrichten der Verbindung zwischen SQL Server und sql managed instance.

In der folgenden Tabelle werden Portaktionen für die einzelnen Umgebungen beschrieben:

Umwelt Aktion
SQL Server (außerhalb von Azure) Öffnen Sie für die Netzwerkfirewall sowohl eingehenden als auch ausgehenden Datenverkehr am Port 5022 für den gesamten IP-Adressbereich des Subnetzes von SQL Managed Instance. Führen Sie dies bei Bedarf in der WINDOWS-Firewall des SQL Server-Hostbetriebssystems aus.
SQL Server (in Azure) Öffnen Sie für die Netzwerkfirewall sowohl eingehenden als auch ausgehenden Datenverkehr am Port 5022 für den gesamten IP-Adressbereich des Subnetzes von SQL Managed Instance. Führen Sie dies bei Bedarf in der WINDOWS-Firewall des SQL Server-Hostbetriebssystems aus. Um die Kommunikation am Port 5022 zuzulassen, erstellen Sie eine NSG-Regel (Network Security Group) im virtuellen Netzwerk, die den virtuellen Computer (VM) hostet.
Verwaltete SQL-Instanz Erstellen Sie eine NSG-Regel im Azure-Portal, um eingehenden und ausgehenden Datenverkehr von der IP-Adresse und dem Netzwerk zuzulassen, das SQL Server auf Port 5022 und Portbereich 11000-11999 hostet.

Verwenden Sie zum Öffnen von Ports in der Windows-Firewall das folgende PowerShell-Skript auf dem Windows-Hostbetriebssystem der SQL Server-Instanz:

New-NetFirewallRule -DisplayName "Allow TCP port 5022 inbound" -Direction inbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP
New-NetFirewallRule -DisplayName "Allow TCP port 5022 outbound" -Direction outbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP

Das folgende Diagramm zeigt ein Beispiel für eine lokale Netzwerkumgebung, die angibt, dass alle Firewalls in der Umgebung über offene Ports verfügen müssen, einschließlich der Betriebssystemfirewall, die die SQL Server-Instanz hostet, sowie alle Unternehmensfirewalls und Gateways:

Diagramm, das die Netzwerkinfrastruktur zum Einrichten der Verbindung zwischen SQL Server und sql managed instance zeigt.

Von Bedeutung

  • Sie müssen Ports in jeder Firewall in der Netzwerkumgebung öffnen, einschließlich des Hostservers und aller Unternehmensfirewalls oder Gateways im Netzwerk. In Unternehmensumgebungen müssen Sie möglicherweise den Netzwerkadministrator*innen die Informationen in diesem Abschnitt zeigen, damit sie die zusätzlichen Ports auf Ebene des Unternehmensnetzwerks öffnen.
  • Sie können den Endpunkt zwar auf der SQL Server-Seite anpassen, sie können jedoch keine Portnummern für die verwaltete SQL-Instanz ändern oder anpassen.
  • Die IP-Adressbereiche der Subnetze zum Hosten der verwalteten Instanz und von SQL Server dürfen sich nicht überschneiden.

Hinzufügen von URLs zur Zulassungsliste

Je nach Ihren Netzwerksicherheitseinstellungen müssen Sie möglicherweise URLs zu Ihrer Zulassungsliste für den FQDN der verwalteten SQL-Instanz und einige der von Azure verwendeten Ressourcenverwaltungsendpunkte hinzufügen.

Fügen Sie Ihrer Allowlist die folgenden Ressourcen hinzu:

  • Der Vollqualifizierter Domänenname (FQDN) der SQL Managed Instance Beispiel: managedinstance.a1b2c3d4e5f6.database.windows.net.
  • Microsoft Entra-Autorität
  • Microsoft Entra Endpoint Resource ID (Ressourcen-ID des Endpunktes)
  • Resource Manager-Endpunkt
  • Dienstendpunkt

Führen Sie die Schritte im Abschnitt "Konfigurieren von SSMS für Government Clouds " aus, um auf die Tools-Schnittstelle in SQL Server Management Studio (SSMS) zuzugreifen und bestimmte URLs für die Ressourcen in Ihrer Cloud zu identifizieren, die Sie ihrer Zulassungsliste hinzufügen müssen.

Migrieren eines Zertifikats einer durch TDE geschützten Datenbank (optional)

Wenn Sie eine SQL Server-Datenbank verknüpfen, die durch transparente Datenverschlüsselung (Transparent Data Encryption, TDE) geschützt ist, müssen Sie das entsprechende Verschlüsselungszertifikat aus der lokalen oder Azure VM SQL Server-Instanz in die sql managed Instanz migrieren, bevor Sie den Link verwenden. Detaillierte Schritte finden Sie unter „Migrieren des Zertifikats einer durch TDE geschützten Datenbank zu einer Azure SQL Managed Instance“

SQL Managed Instance Datenbanken, die mit dienstseitig verwalteten TDE-Schlüsseln verschlüsselt sind, können nicht in SQL Server wiederhergestellt werden. Sie können eine verschlüsselte Datenbank nur mit SQL Server verknüpfen, wenn Sie sie mit einem vom Kunden verwalteten Schlüssel verschlüsselt haben und der Zielserver Zugriff auf denselben Schlüssel hat, der zum Verschlüsseln der Datenbank verwendet wird. Weitere Informationen finden Sie unter Einrichten SQL Server-TDE mit Azure Key Vault.

Hinweis

Azure Key Vault wird von SQL Server unter Linux ab kumulativem Update 14 für SQL Server 2022 unterstützt.

Netzwerkkonnektivität testen

Bevor Sie die Migration starten, testen Sie die Netzwerkkonnektivität zwischen Ihrer SQL Server-Instanz und der verwalteten SQL-Instanz. Sie können die Konnektivität direkt über das Azure-Portal im Rahmen des Migrationsprozesses testen. Sie können die Konnektivität jedoch auch manuell testen, indem Sie Transact-SQL und den SQL Server-Agent verwenden. Weitere Informationen finden Sie unter Testen der Netzwerkkonnektivität.

Führen Sie die folgenden Schritte aus, um die Konnektivität über das Azure-Portal zu testen:

  1. Wählen Sie "Daten migrieren" im Datenbankmigrationsbereich für Ihre SQL Server-Instanzressource aus.

  2. Wählen Sie die MI-Linkoption aus.

  3. Wählen Sie die Zieldatenbanken aus, die Sie migrieren möchten, und verwenden Sie dann "Weiter": "Einstellungen ", um zur nächsten Registerkarte zu wechseln.

  4. Geben Sie auf der Registerkarte "Einstellungen " den Namen des Links und die Quellverfügbarkeitsgruppe an. Verwenden Sie dann die Testverbindung , um die Netzwerkkonnektivität zwischen SQL Server und SQL Managed Instance zu überprüfen:

    Screenshot der Schaltfläche zum Testen der Verbindungsverbindung für verwaltete Instanzen.

Berücksichtigen Sie die folgenden Punkte:

  • Um falsch negative Ergebnisse zu vermeiden, müssen alle Firewalls entlang des Netzwerkpfads Internet Control Message Protocol (ICMP)-Datenverkehr zulassen.
  • Um falsch positive Ergebnisse zu vermeiden, müssen alle Firewalls entlang des Netzwerkpfads Datenverkehr im proprietären SQL Server UCS-Protokoll zulassen. Das Blockieren des Protokolls kann zu einem erfolgreichen Verbindungstest führen, aber der Link kann nicht erstellt werden.
  • Erweiterte Firewallsetups mit Schutzläufen auf Paketebene müssen ordnungsgemäß konfiguriert werden, um Datenverkehr zwischen SQL Server und SQL Managed Instance zuzulassen.

Einschränkungen

Beachten Sie die folgenden Einschränkungen:

  • Die Einschränkungen des Links für verwaltete Instanzen gelten für Migrationen über das Azure-Portal.
  • Das Abbrechen einer Migration erfordert sysadmin-Berechtigungen für die SQL Server-Quellinstanz. Wenn Ihre SQL Server-Instanz nicht die geringsten Berechtigungen verwendet, weisen Sie dem Konto NT AUTHORITY\SYSTEM manuell zu.
  • Das Konfigurieren eines Links über das Azure-Portal für den Zweck der Migration ist nicht mit manuell erstellten Links kompatibel, entweder über SQL Server Management Studio (SSMS) oder Transact-SQL (T-SQL). Überprüfen Sie das bekannte Problem , um mehr zu erfahren.
  • Die Überwachung der Migration über das Azure-Portal ist nur für SQL Server-Instanzen verfügbar, die den Überwachungslizenzanforderungen entsprechen.

Häufige Probleme beheben

Informationen zur Problembehandlung häufig auftretender Probleme bei der Migration zu azure SQL Managed Instance finden Sie unter "Behandeln von Migrationsproblemen".

Verwandte Inhalte

  • Last updated on