Häufig gestellte Fragen zur Verwendung von Azure Database Migration Service

Dieser Artikel enthält häufig gestellte Fragen zur Verwendung von Azure Database Migration Service sowie entsprechende Antworten.

Übersicht

Was ist Azure Database Migration Service?

Azure Database Migration Service ist ein vollständig verwalteter Dienst, der die nahtlose Migration von mehreren Datenbankquellen zu Azure-Datenplattformen mit minimaler Ausfallzeit ermöglicht. Der Dienst weist zurzeit den Status „Allgemeine Verfügbarkeit“ auf, wobei laufende Entwicklungsarbeiten sich auf Folgendes konzentrieren:

• Zuverlässigkeit und Leistung
• Iteratives Hinzufügen von Quelle-Ziel-Paaren
• Kontinuierliche Investition in reibungslose Migrationen

Welche Quelle-Ziel-Paare werden derzeit von Azure Database Migration Service unterstützt?

Der Dienst unterstützt derzeit eine Vielzahl von Quelle-Ziel-Paaren oder Migrationsszenarien. Eine vollständige Liste der Status der einzelnen verfügbaren Migrationsszenarios finden Sie im Artikel Status von Migrationsszenarios, die von Azure Database Migration Service unterstützt werden.

Welche Versionen von SQL Server werden von Azure Database Migration Service als Datenquelle unterstützt?

Bei der Migration von SQL Server werden für den Azure Database Migration Service SQL Server 2008 und höhere Versionen als Quellen unterstützt. Wenn Sie Azure Data Studio mit SQL-Migrationserweiterung verwenden, werden SQL Server 2008 bis SQL Server 2022 als Quellen unterstützt.

Was ist der Unterschied zwischen einer Offline- und einer Onlinemigration, wenn Azure Database Migration Service verwendet wird?

Sie können Azure Database Migration Service verwenden, um Offline- und Onlinemigrationen durchzuführen. Bei einer Offlinemigration beginnt der Ausfall der Anwendung, wenn die Migration gestartet wird. Bei einer Onlinemigration ist der Ausfall auf die Dauer der Umstellung am Ende der Migration beschränkt. Wir raten Ihnen, eine Offlinemigration zu testen, um zu ermitteln, ob die Ausfallzeit akzeptabel ist. Wenn nicht, sollten Sie eine Onlinemigration durchführen.

Hinweis

Die Verwendung von Azure Database Migration Service zum Ausführen einer Onlinemigration erfordert das Erstellen einer Instanz auf der Grundlage des Premium-Tarifs. Weitere Informationen finden Sie auf der Seite Azure Database Migration Service – Preise.

Wie vergleicht der Azure-Datenbankmigrationsdienst mit anderen Microsoft-Datenbankmigrationstools wie sql Server Migration Assistant (SSMA)?

Azure Database Migration Service ist die bevorzugte Methode für bedarfsorientierte Datenbankmigrationen zu Microsoft Azure. Ausführlichere Informationen zu den Unterschieden zwischen Azure Database Migration Service und anderen Microsoft-Datenbankmigrationstools sowie Empfehlungen für die Verwendung des Diensts in verschiedenen Szenarien finden Sie unter Differentiating Microsoft’s Database Migration Tools and Services (Abgrenzung der Datenbankmigrationstools und -dienste von Microsoft).

Inwiefern unterscheidet sich Azure Database Migration Service vom Azure Migrate-Angebot?

Azure Migrate unterstützt Benutzer bei der Migration lokaler virtueller Computer zu Azure IaaS. Der Dienst bewertet die Eignung für die Migration und die leistungsbasierte Größenauslegung und stellt Kostenschätzungen für die Ausführung Ihrer lokalen virtuellen Computer in Azure bereit. Azure Migrate ist hilfreich bei Lift & Shift-Migrationen lokaler, VM-basierter Workloads zu virtuellen Azure IaaS-Computern. Im Gegensatz zu Azure Database Migration Service handelt es sich bei Azure Migrate allerdings nicht um einen speziellen Datenbankmigrationsdienst für relationale Azure PaaS-Datenbankplattformen wie Azure SQL-Datenbank oder eine Azure SQL Managed Instance.

Speichert Database Migration Service Kundendaten?

Nein Database Migration Service speichert keine Kundendaten.

Wie kann ich sicherstellen, dass DMS alle Daten aus der Quelldatenbank zu Azure SQL Targets migriert hat?

Für SQL Server auf azure-VM und azure SQL Managed Instance-Ziele verwendet DMS physische Migration, die die Sicherung und Wiederherstellung verwendet. Wie im folgenden Abschnitt beschrieben, bestimmt der ausgewählte Migrationsmodus, wie die Daten zwischen Quelle und Ziel konsistent gehalten werden.

• Offlinemigration: Während der Offlinemigration zu SQL Server auf Azure VM- und Azure SQL Managed Instance-Zielen beginnt die Ausfallzeit der Anwendung beim Start der Migration. DMS stellt alle Sicherungsdateien auf dem Ziel wieder her, solange die neuesten Sicherungsdateien aus der Quelle in den SMB-Netzwerkspeicher oder in den Azure Blob-Container (gemäß der Migrationskonfiguration) übertragen wurden. Wenn die Sicherung mit der CHECKUM-Option erstellt wird, führt der DMS-Wiederherstellungsvorgang automatisch die Überprüfung aus. Ist keine Prüfsumme vorhanden, wird die Integrität der Sicherung explizit vor der Wiederherstellung überprüft. Dadurch wird sichergestellt, dass die Wiederherstellungsdatei mit der Sicherungsdatei identisch ist und somit beide die gleichen Daten enthalten. Sie können alle Sicherungsdateien einschließlich des letzten Sicherungsdateinamens aus der Quelle anhand der angewendeten bzw. am Ziel wiederhergestellten Sicherungsdatei überprüfen, die auf der DMS-Migrationsüberwachungsseite angezeigt wird, und ihre jeweilige Prüfsumme validieren.

• Onlinemigration: Während der Onlinemigration zu SQL Server auf Azure VM und azure SQL Managed Instance zielen Ausfallzeiten auf, sobald Sie den Migrations-Übernahmevorgang initiieren, und die Anwendung wird beendet. DMS stellt alle Sicherungsdateien auf dem Ziel wieder her, solange die neuesten Sicherungsdateien aus der Quelle in den SMB-Netzwerkspeicher oder in den Azure Blob-Container (gemäß der Migrationskonfiguration) übertragen wurden. Nachdem Sie auf die Schaltfläche „Cutover“ geklickt haben, zeigt DMS ggf. die Anzahl ausstehender Sicherungsdateien an, die im SMB-Netzwerkspeicher oder im Azure-Blobcontainer vorhanden sind und noch angewendet bzw. am Ziel wiederhergestellt werden müssen. Wenn die Sicherung mit der CHECKUM-Option erstellt wird, führt der DMS-Wiederherstellungsvorgang automatisch die Überprüfung aus. Ist keine Prüfsumme vorhanden, wird die Integrität der Sicherung explizit vor der Wiederherstellung überprüft. Dadurch wird sichergestellt, dass die Wiederherstellungsdatei mit der Sicherungsdatei identisch ist und somit beide die gleichen Daten enthalten. Sie können alle Sicherungsdateien, einschließlich des letzten Sicherungsdateinamens aus der Quelle, überprüfen, wobei die Sicherungsdatei auf die Zielseite der DMS-Migrationsüberwachung angewendet/wiederhergestellt und ihre jeweilige Prüfsumme überprüft wird.

Für Azure SQL-Datenbankziele führt DMS die logische Migration im Fall von Azure SQL-Datenbank durch. Das heißt, sie kopiert die Daten aus den Tabellen der SQL-Quelldatenbank und schreibt sie in die Tabellen der Azure SQL-Zieldatenbank. Da DMS nur die Offlinemigration zu Azure SQL-Datenbank unterstützt, beginnt die Ausfallzeit der Anwendung beim Starten der Migration. Sie können die Anzahl der gelesenen Zeilen (aus der Quelldatenbanktabelle) überwachen und überprüfen und auf der Migrationsüberwachungsseite kopiert (in die Azure SQL-Zieldatenbanktabelle geschrieben). Als zusätzliche Bestätigung können Sie die folgenden Transact-SQL ausführen, um die Prüfsumme sowohl bei Quell- als auch Zieldatenbanken abzurufen und die Quell- und Wiederherstellungsdaten zu überprüfen, die identisch sind.

SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>;

Hinweis

Solange keine Anwendung in die Quell- oder Zieldatenbank schreibt, können Sie auch Tools wie das Datenbankvergleichstool für den Datenvergleich verwenden.

Sicherheit

Welche Dienste werden erstellt und genutzt, wenn eine Instanz von DMS (klassisch) erstellt und ausgeführt wird?

Die folgende Liste enthält die Azure-Ressourcen, die hinter den Kulissen erstellt werden können, um eine Datenmigration durchzuführen. Die verwendeten Dienste können je nach Migrationsszenario variieren.

• Azure Monitor
• Azure-VM
• Azure Storage
• Azure-Servicebus
• Azure Data Factory

Wie werden Metadaten und Clientdaten aus der Quelle extrahiert und in das Ziel geschrieben?

Intern verwaltet DMS einen Metadatenspeicher, der Informationen zu Netzwerkspeicherorten, Anmeldeinformationen, Sicherungsdateien und abgeschlossenen Aufgaben enthält. Anmeldeinformationen und ausgewählte Felder, z. B. Kontoschlüssel, werden verschlüsselt. Daten, z. B. Tabellennamen, die in Telemetrie enthalten sein könnten, werden mit Hash versehen. Benutzernamen werden möglicherweise in Nur-Text-Protokollen angezeigt, kennwörter werden jedoch nie verwendet. Telemetrie wird nach Region isoliert, unterliegt Aufbewahrungsrichtlinien und ist nur für autorisierte Mitarbeiter innerhalb von Microsoft für zugelassene Problembehandlungszwecke verfügbar. Azure-Ressourcennamen wie Server- und Datenbanknamen folgen den Regeln für Azure-Ressourcen.

DMS (klassisch) nutzt Azure Service Bus-Themen, um die Kommunikation zwischen Computeebenen zu erleichtern. Die Azure Service Bus-Themen sind für jede DMS-Instanz einzigartig und alle personenbezogenen Daten werden verschlüsselt.

Azure SQL Managed Instance und SQL Server auf Azure-VMs

Schema und Daten werden mithilfe von Sicherung und Wiederherstellung migriert. Kunden haben die Wahl, aus einer Netzwerkfreigabe oder direkt aus einem Speichercontainer wiederherzustellen. Eine Datei mit Windows-Leistungsdaten kann verwendet werden, um optionale (aber dringend empfohlene) Empfehlungen für die Größenanpassung von Arbeitsauslastungen bereitzustellen.

Azure SQL-Datenbank

Migrationen zu Azure SQL-Datenbank werden in zwei Schritten ausgeführt. Der erste Schritt ist eine Schemamigration. DMS (klassisch) verwendet die SQL Management Objects (SMO) für die Schemamigration. Der zweite Schritt ist die tatsächliche Datenmigration. SqlBulkCopy wird zum Durchführen der Datenmigration verwendet. DMS unterstützt keine Schemamigration. Daten werden mithilfe von Azure Data Factory migriert. Optional, aber dringend empfohlen, kann eine Datei mit Windows-Leistungsdaten verwendet werden, um Empfehlungen für die Workloadanpassung bereitzustellen.

Azure-Datenbank für PostgreSQL

In diesem Szenario extrahiert der Endbenutzer die Metadaten, in diesem Fall das Schema unter Verwendung der Befehlszeilenprogramme pg_dump und pg_restore. Bei der Konfiguration der Änderungsdatenerfassung für PostgreSQL verwendet DMS intern pg_dump und pg_restore führt das anfängliche Seeding für CDC aus. Die Daten werden in einem verschlüsselten temporären Speicher gespeichert, auf den nur Ihre DMS-Instanz zugreifen kann. Eine Datei mit Windows-Leistungsdaten kann verwendet werden, um optionale (aber dringend empfohlene) Empfehlungen für die Größenanpassung von Arbeitsauslastungen bereitzustellen.

Azure-Datenbank für MySQL

In diesem Szenario erfolgt die Schemaextraktion und -migration durch DMS (klassisch) mithilfe des mysql-net/MySqlConnector. Wenn möglich, wird die MySQL-Binlogreplikation verwendet, um sowohl Daten- als auch Schemaänderungen zu replizieren. Benutzerdefinierter Code wird verwendet, um Änderungen zu synchronisieren, bei denen die Binlogreplikation nicht verwendet werden kann.

MongoDB zu Azure Cosmos DB

DMS extrahiert und fügt Daten aus einem MongoDB in Cosmos DB ein. Es bietet auch die Möglichkeit, die Daten aus einer BSON- oder JSON-Sicherungskopie zu extrahieren.

Bei BSON-Sicherungskopien verwendet DMS die Daten im bsondump-Format innerhalb desselben Ordners innerhalb eines BLOB-Containers. DMS sucht nur mit dem Format collection.metadata.json nach Metadatendateien.

Bei JSON-Sicherungskopien liest DMS die Dateien in den Blobcontainerordnern, die nach den enthaltenden Datenbanken benannt sind. In jedem Datenbankordner verwendet DMS nur Datendateien, die im data-Unterordner platziert sind. DMS untersucht nur Dateien, die im metadata-Unterordner platziert und mit dem Format collection.json für Metadaten benannt werden.

Oracle zu Azure Database for PostgreSQL

Ähnlich wie bei Oracle zu Azure SQL-Datenbank wird in diesem Szenario der AWR-Bericht oder eine Windows-Datei perfmon verwendet, um optionale (aber dringend empfohlene) Empfehlungen für die Dimensionierung von Arbeitsauslastungen bereitzustellen. Die ora2pg-Bibliothek wird verwendet, um das Schema zu extrahieren und die Daten manuell zu migrieren, indem der Benutzer die Migration durchführt.

Werden öffentliche Endpunkte verwendet?

DMS (klassisch) basiert auf der Kundennetzwerkkonfiguration. Wenn die Migrationsquelle private Endpunkte verwendet, verwenden wir private Endpunkte, was die bevorzugte Konfiguration ist. Wir verwenden öffentliche Endpunkte, wenn sie die einzige Option sind.

DMS verwendet ADF stark hinter den Kulissen für die Planung und Koordination von Datenbewegungen. Darüber hinaus unterscheidet sich die Self-Hosted Integration Runtime nicht von der, die Sie wahrscheinlich bereits für Ihre eigenen ADF-Pipelines verwenden. Weitere Informationen zu Firewall- und Proxyserverproblemen finden Sie unter Erstellen und Konfigurieren einer selbstgehostete Integration Runtime.

Werden alle Daten während der Übertragung und die ruhenden Daten verschlüsselt?

Alle ruhenden Kundendaten werden verschlüsselt. Einige Metadaten, einschließlich, aber nicht beschränkt auf logische Servernamen und Datenbanknamen, sowie Migrationsstatus und Migrationsfortschritt werden in Dienstprotokollen angezeigt, die nicht verschlüsselt sind.

Alle übertragenen Daten sind standardmäßig mit TLS 1.2-Verschlüsselung geschützt. Ältere Clients, die ältere Versionen von TLS erfordern, benötigen die erforderlichen Versionen, die auf der DMS-Portalseite (klassisch) aktiviert sind. Für DMS kann der Computer, auf dem die Self-Hosted Integration Runtime installiert ist, so konfiguriert werden, dass erforderliche TLS-Einstellungen für Legacyclients zulässig sind. Weitere Informationen zur TLS-Konfiguration für SQL Server finden Sie unter TLS 1.2-Unterstützung für Microsoft SQL Server.

Verwenden alle Azure-Dienste, die DMS und DMS (klassisch) zugrunde legen, private Endpunkte?

Wo immer möglich, werden private Endpunkte verwendet. Wenn private Endpunkte keine Option sind, werden öffentliche Endpunkte für die Kommunikation zwischen Dienstebenen verwendet. Unabhängig vom Endpunkttyp sind alle Ressourcen auf die bestimmte Instanz von DMS dediziert und mit eindeutigen Anmeldeinformationen gesichert.

Verwenden alle Azure-Dienste, die DMS und DMS (klassisch) zugrunde legen, CMK für ruhende Daten?

Wir unterstützen Customer Managed Keys nicht für die Verschlüsselung von Daten innerhalb unserer Datenebene oder Kontrollebene. Alle ruhenden Kundendaten werden jedoch mit vom Dienst verwalteten Schlüsseln verschlüsselt. Einige Metadaten, einschließlich, aber nicht beschränkt auf logische Servernamen und Datenbanknamen, sowie Migrationsstatus und Fortschritt werden in Dienstprotokollen in unverschlüsselter Form angezeigt.

Welche Art von Verschlüsselung wird für Daten bei der Übertragung verwendet?

Alle übertragenen Daten werden standardmäßig mit TLS 1.2-Verschlüsselung verschlüsselt. Die DMS(klassische) Portalseite ermöglicht es älteren Versionen von TLS, für Ältere Clients zu verwenden. Für DMS kann der Computer, auf dem die Self-Hosted Integration Runtime installiert ist, so konfiguriert werden, dass die Verwaltung von TLS-Einstellungen für Legacyclients möglich ist. Weitere Informationen zur TLS-Konfiguration für SQL Server finden Sie unter TLS 1.2-Unterstützung für Microsoft SQL Server.

Gibt es Daten, die nicht durch CMK geschützt sind, und wenn ja, welche Art von Daten? Beispielsweise Metadaten, Protokolle usw.

Wir machen die Möglichkeit zum Verschlüsseln von Daten auf unserer Steuerungs- oder Datenebene mit vom Customer Managed Keys nicht öffentlich. Alle Kundendaten außer Dienstprotokolle werden gelöscht, wenn die DMS-Instanz gelöscht wird. DMS-Dienstprotokolle werden nur 6 Monate lang aufbewahrt.

Wie unterstützt DMS Customer Managed Keys (CMK)?

TDE

DMS unterstützt die Migration von Customer Managed Keys (CMK) zu Azure SQL für Transparent Database Encryption (TDE). Schrittweise Anleitungen zum Migrieren Ihrer TDE-Schlüssel finden Sie im Tutorial: Migrieren von TDE-fähigen Datenbanken (Vorschau) zu Azure SQL in Azure Data Studio.

Zellverschlüsselung

Die Verschlüsselung auf Zellenebene wird auf Schemaebene behandelt. Die Schemamigrationstools migrieren alle Schemaobjekte, einschließlich der Funktionen und gespeicherten Prozeduren, die zum Implementieren der Verschlüsselung auf Zellenebene erforderlich sind.

Immer Verschlüsselt

DMS unterstützt derzeit keine Migration von Always Encrypted über Szenarien, in denen einzelne Datenzeilen zwischen Quelle und Ziel migriert werden. Spalten, die über Always Encrypted verschlüsselt werden, werden wie erwartet in Szenarien migriert, in denen Sicherung/Wiederherstellung verwendet wird, z. B. das Verschieben zu SQL Server auf azure VM oder azure SQL Managed Instance, von einer vorhandenen SQL Server-Instanz.

Stellt DMS sicher, dass der Zugriff auf Daten mit der Zugriffssteuerung für Standortinformationen gesteuert wird?

Wir implementieren keine Standortsteuerung, die über die bereits in Azure verfügbaren Zugriffskontrolle hinausgeht. Alle Daten, die einer DMS-Instanz zugeordnet sind, befinden sich in derselben Region wie die DMS-Ressource.

Wie stellt DMS sicher, dass Daten in einer Umgebung nicht mithilfe von DMS in eine andere verschoben werden können?

Unsere Dienstleistungen werden in verschiedenen Umgebungen mit unterschiedlichen internen Kontrollen und Geschäftsprozessen verwendet. DMS verschiebt Daten von und an eine beliebige Stelle, auf die das verwendete Konto Zugriff hat. Es liegt in der Verantwortung des Benutzers, die Berechtigungen und internen Kontrollen der Umgebung zu verstehen, in der sie arbeiten. Es ist besonders wichtig sicherzustellen, dass das Konto, das DMS zum Herstellen einer Verbindung mit der Quelle verwendet, Zugriff hat, um alle Daten anzuzeigen, die von der Quelle migriert werden sollen.

Wie wird die Einfügung virtueller Netzwerke in DMS (klassisch) verwendet? Gibt es Microsoft Zugriff auf mein Netzwerk?

Das Einfügen eines virtuellen Netzwerks ist die Aktion zum Hinzufügen einer Azure-Ressource, die sich innerhalb des Microsoft-Mandanten befindet, zu einem Subnetz in einem virtuellen Netzwerk unter dem Kundenmandanten. Dieser Ansatz wurde mit DMS gewählt, um es uns zu ermöglichen, die Computes im Auftrag des Kunden zu verwalten und gleichzeitig den Zugriff auf Kundenressourcen aufrechtzuerhalten. Da sich das Netzwerk im Kundenabonnement befindet, kann Microsoft den virtuellen Computer nicht über die Ausgabe von den Befehlen „Start“, „Beenden“, „Löschen“ oder „Bereitstellen“ hinaus verwalten. Alle anderen Verwaltungsaktionen, die Zugriff auf den virtuellen Computer benötigen, erfordern eine vom Kunden initiierte Supportanfrage und -genehmigung.

Konfiguration

Welche Voraussetzungen müssen für die Verwendung von Azure Database Migration Service erfüllt sein?

Zur Gewährleistung reibungsloser Datenbankmigrationen mit Azure Database Migration Service müssen mehrere Voraussetzungen erfüllt werden. Einige der Voraussetzungen gelten für alle unterstützten Szenarien (Quelle-Ziel-Paare) des Diensts, andere nur für ein bestimmtes Szenario.

Folgende Voraussetzungen von Azure Database Migration Service gelten für alle unterstützten Migrationsszenarien:

• Erstellen Sie ein virtuelles Microsoft Azure-Netzwerk für Azure Database Migration Service mithilfe des Azure Resource Manager-Bereitstellungsmodells, das Site-to-Site-Konnektivität für Ihre lokalen Quellserver über ExpressRoute oder über VPN bereitstellt.
• Stellen Sie sicher, dass ihre Regeln für die Netzwerksicherheitsgruppe ihres virtuellen Netzwerks den Port 443 für ServiceTags of ServiceBus, Storage und AzureMonitor nicht blockieren. Ausführlichere Informationen zur NSG-Datenverkehrsfilterung in einem virtuellen Netzwerk finden Sie im Artikel Filtern des Netzwerkdatenverkehrs mit Netzwerksicherheitsgruppen.
• Wenn Sie eine Firewall-Appliance vor Ihren Quelldatenbanken verwenden, müssen Sie möglicherweise Firewall-Regeln hinzufügen, um Azure Database Migration Service für die Migration den Zugriff auf die Quelldatenbanken zu erlauben.

Eine Liste mit allen Voraussetzungen für spezifische Migrationsszenarien mit Azure Database Migration Service finden Sie in den entsprechenden Tutorials der Azure Database Migration Service-Dokumentation.

Wie finde ich die IP-Adresse für Azure Database Migration Service, damit ich eine Positivliste von IP-Adressen für die Firewallregeln erstellen kann, die für den Zugriff auf meine Quelldatenbank für die Migration verwendet werden?

Möglicherweise müssen Sie Firewallregeln hinzufügen, die azure Database Migration Service den Zugriff auf Ihre Quelldatenbank für die Migration ermöglichen. Die IP-Adresse für den Dienst ist zwar dynamisch, bei Verwendung von ExpressRoute wird sie allerdings privat durch Ihr Unternehmensnetzwerk zugewiesen. Die einfachste Möglichkeit zur Ermittlung der entsprechenden IP-Adresse besteht darin, in der Ressourcengruppe, in der sich auch Ihre bereitgestellte Azure Database Migration Service-Ressource befindet, nach der zugeordneten Netzwerkschnittstelle zu suchen. Normalerweise beginnt der Name der Netzwerkschnittstellenressource mit dem Präfix NIC und gefolgt von einem eindeutigen Zeichen und einer Nummernfolge, NIC-jj6tnztnmarpsskr82rbndypz. B. . . Wenn Sie auf diese Netzwerkschnittstellenressource klicken, wird die IP-Adresse angezeigt, die auf der Ressourcenübersichtsseite im Azure-Portal in die Positivliste von IP-Adressen aufgenommen werden muss.

Möglicherweise müssen Sie auch die Portquelle einschließen, die SQL Server auf der Zulassungsliste überwacht. Standardmäßig ist es Port 1433, aber die SQL Server-Quelle kann so konfiguriert werden, dass auch andere Ports überwacht werden. In diesem Fall müssen Sie diese Ports ebenfalls der Positivliste hinzufügen. Den Port, an dem SQL Server lauscht, können Sie mithilfe einer Abfrage vom Typ „Dynamische Verwaltungssicht“ ermittelt:

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

Zum Ermitteln des Ports, an dem SQL Server lauscht, können Sie auch das SQL Server-Fehlerprotokoll abfragen:

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

Wie richte ich eine Microsoft Azure Virtual Network-Instanz ein?

Die Einrichtung eines virtuellen Azure-Netzwerks wird in mehreren Microsoft-Tutorials ausführlich beschrieben. Die offizielle Dokumentation finden Sie jedoch im Artikel Azure Virtual Network.

Verbrauch

Welche Schritte sind allgemein für eine Datenbankmigration mit Azure Database Migration Service erforderlich?

Eine typische einfache Datenbankmigration umfasst Folgendes:

1. Erstellen Sie Zieldatenbanken.
2. Bewerten Sie Ihre Quelldatenbanken.
   • Bewerten Sie bei homogenen Migrationen Ihre vorhandenen Datenbanken mithilfe der Azure SQL-Migrationserweiterung für Azure Data Studio.
   • Bewerten Sie bei heterogenen Migrationen (aus Konkurrierenquellen) Ihre vorhandenen Datenbanken mit SSMA. Sie verwenden SSMA auch, um Datenbankobjekte zu konvertieren und das Schema zu Ihrer Zielplattform zu migrieren.
3. Erstellen einer Instanz von Azure Database Migration Service
4. Erstellen Sie ein Migrationsprojekt, das die Quelldatenbanken, Zieldatenbanken und die zu migrierenden Tabellen angibt.
5. Starten des vollständigen Ladenvorgangs.
6. Auswählen der anschließenden Überprüfung
7. Durchführen eines manuellen Wechsels zur neuen cloudbasierten Datenbank für Ihre Produktionsumgebung

Problembehandlung und Optimierung

Ich richte ein Migrationsprojekt in DMS ein und habe Schwierigkeiten beim Herstellen einer Verbindung mit meiner Quelldatenbank. Wie sollte ich vorgehen?

Wenn Sie während der Migration keine Verbindung mit Ihrem Quelldatenbanksystem herstellen können, erstellen Sie eine VM im selben Subnetz des virtuellen Netzwerks, in dem Sie Ihre DMS-Instanz einrichten. Im virtuellen Computer sollten Sie in der Lage sein, einen Verbindungstest durchzuführen, z.B. mit einer UDL-Datei, um eine Verbindung mit SQL Server zu testen, oder Robo 3T herunterzuladen, um MongoDB-Verbindungen zu testen. Wenn der Verbindungstest erfolgreich ist, sollten Sie kein Problem mit dem Herstellen einer Verbindung mit Ihrer Quelldatenbank haben. Wenn der Verbindungstest nicht erfolgreich ist, wenden Sie sich an Ihren Netzwerkadministrator.

Warum ist mein Azure Database Migration Service nicht verfügbar oder wurde beendet?

Wenn der Benutzer Azure Database Migration Service (DMS) explizit beendet oder der Dienst für 24 Stunden inaktiv ist, wird der Dienst beendet oder automatisch angehalten. In jedem Fall ist der Dienst nicht verfügbar und beendet. Um aktive Migrationen wieder aufzunehmen, starten Sie den Dienst neu.

Gibt es Leistungsoptimierungsempfehlungen für Azure Database Migration Service?

Die Datenmigration mit diesem Dienst lässt sich durch folgende Maßnahmen beschleunigen:

Für DMS (klassisch):

• Verwenden Sie beim Erstellen Ihrer Dienstinstanz den universellen Tarif mit mehreren CPUs, damit dem Dienst mehrere vCPUs für Parallelisierung und schnellere Datenübertragungen zur Verfügung stehen.
• Skalieren Sie Ihre Azure SQL-Datenbankzielinstanz während des Datenmigrationsvorgangs vorübergehend auf die Premium-SKU, um die Azure SQL-Datenbankeinschränkung zu minimieren, die sich auf Datenübertragungsaktivitäten auswirken kann, wenn Sie SKUs auf niedrigerer Ebene verwenden.

Für DMS:

• Wenn Sie Sicherungen aus der lokalen Dateifreigabe in Azure Blob Storage kopieren oder während der Migration zu einer Azure SQL-Zieldatenbank migrieren, verwendet DMS den SHIR-Knoten als Berechnung. Achten Sie daher darauf, die Ressourcennutzung dieses SHIR-Knotens zu überwachen.
• Skalieren Sie Ihre Azure SQL-Datenbankzielinstanz während des Datenmigrationsvorgangs vorübergehend auf die Premium-SKU, um die Drosselung von Azure SQL-Datenbankdatenträgern zu minimieren, die sich auf Datenübertragungsaktivitäten auswirken können, wenn Sie SKUs auf niedrigerer Ebene verwenden.
• Ausführlichere Informationen finden Sie unter Verbessern der SQL DB-Migrationsleistung – Azure-Datenbankmigrationsdienst.

Verwandte Inhalte

• Was ist der Azure Database Migration Service.

Dieser Artikel enthält häufig gestellte Fragen zur Verwendung von Azure Database Migration Service sowie entsprechende Antworten.

Azure Database Migration Service ist ein vollständig verwalteter Dienst, der die nahtlose Migration von mehreren Datenbankquellen zu Azure-Datenplattformen mit minimaler Ausfallzeit ermöglicht. Der Dienst weist zurzeit den Status „Allgemeine Verfügbarkeit“ auf, wobei laufende Entwicklungsarbeiten sich auf Folgendes konzentrieren:

• Zuverlässigkeit und Leistung
• Iteratives Hinzufügen von Quelle-Ziel-Paaren
• Kontinuierliche Investition in reibungslose Migrationen

Der Dienst unterstützt derzeit eine Vielzahl von Quelle-Ziel-Paaren oder Migrationsszenarien. Eine vollständige Liste der Status der einzelnen verfügbaren Migrationsszenarios finden Sie im Artikel Status von Migrationsszenarios, die von Azure Database Migration Service unterstützt werden.

Bei der Migration von SQL Server werden für den Azure Database Migration Service SQL Server 2008 und höhere Versionen als Quellen unterstützt. Wenn Sie Azure Data Studio mit SQL-Migrationserweiterung verwenden, werden SQL Server 2008 bis SQL Server 2022 als Quellen unterstützt.

Sie können Azure Database Migration Service verwenden, um Offline- und Onlinemigrationen durchzuführen. Bei einer Offlinemigration beginnt der Ausfall der Anwendung, wenn die Migration gestartet wird. Bei einer Onlinemigration ist der Ausfall auf die Dauer der Umstellung am Ende der Migration beschränkt. Wir raten Ihnen, eine Offlinemigration zu testen, um zu ermitteln, ob die Ausfallzeit akzeptabel ist. Wenn nicht, sollten Sie eine Onlinemigration durchführen.

Hinweis

Die Verwendung von Azure Database Migration Service zum Ausführen einer Onlinemigration erfordert das Erstellen einer Instanz auf der Grundlage des Premium-Tarifs. Weitere Informationen finden Sie auf der Seite Azure Database Migration Service – Preise.

Azure Database Migration Service ist die bevorzugte Methode für bedarfsorientierte Datenbankmigrationen zu Microsoft Azure. Ausführlichere Informationen zu den Unterschieden zwischen Azure Database Migration Service und anderen Microsoft-Datenbankmigrationstools sowie Empfehlungen für die Verwendung des Diensts in verschiedenen Szenarien finden Sie unter Differentiating Microsoft’s Database Migration Tools and Services (Abgrenzung der Datenbankmigrationstools und -dienste von Microsoft).

Azure Migrate unterstützt Benutzer bei der Migration lokaler virtueller Computer zu Azure IaaS. Der Dienst bewertet die Eignung für die Migration und die leistungsbasierte Größenauslegung und stellt Kostenschätzungen für die Ausführung Ihrer lokalen virtuellen Computer in Azure bereit. Azure Migrate ist hilfreich bei Lift & Shift-Migrationen lokaler, VM-basierter Workloads zu virtuellen Azure IaaS-Computern. Im Gegensatz zu Azure Database Migration Service handelt es sich bei Azure Migrate allerdings nicht um einen speziellen Datenbankmigrationsdienst für relationale Azure PaaS-Datenbankplattformen wie Azure SQL-Datenbank oder eine Azure SQL Managed Instance.

Nein Database Migration Service speichert keine Kundendaten.

Für SQL Server auf azure-VM und azure SQL Managed Instance-Ziele verwendet DMS physische Migration, die die Sicherung und Wiederherstellung verwendet. Wie im folgenden Abschnitt beschrieben, bestimmt der ausgewählte Migrationsmodus, wie die Daten zwischen Quelle und Ziel konsistent gehalten werden.

• Offlinemigration: Während der Offlinemigration zu SQL Server auf Azure VM- und Azure SQL Managed Instance-Zielen beginnt die Ausfallzeit der Anwendung beim Start der Migration. DMS stellt alle Sicherungsdateien auf dem Ziel wieder her, solange die neuesten Sicherungsdateien aus der Quelle in den SMB-Netzwerkspeicher oder in den Azure Blob-Container (gemäß der Migrationskonfiguration) übertragen wurden. Wenn die Sicherung mit der CHECKUM-Option erstellt wird, führt der DMS-Wiederherstellungsvorgang automatisch die Überprüfung aus. Ist keine Prüfsumme vorhanden, wird die Integrität der Sicherung explizit vor der Wiederherstellung überprüft. Dadurch wird sichergestellt, dass die Wiederherstellungsdatei mit der Sicherungsdatei identisch ist und somit beide die gleichen Daten enthalten. Sie können alle Sicherungsdateien einschließlich des letzten Sicherungsdateinamens aus der Quelle anhand der angewendeten bzw. am Ziel wiederhergestellten Sicherungsdatei überprüfen, die auf der DMS-Migrationsüberwachungsseite angezeigt wird, und ihre jeweilige Prüfsumme validieren.

• Onlinemigration: Während der Onlinemigration zu SQL Server auf Azure VM und azure SQL Managed Instance zielen Ausfallzeiten auf, sobald Sie den Migrations-Übernahmevorgang initiieren, und die Anwendung wird beendet. DMS stellt alle Sicherungsdateien auf dem Ziel wieder her, solange die neuesten Sicherungsdateien aus der Quelle in den SMB-Netzwerkspeicher oder in den Azure Blob-Container (gemäß der Migrationskonfiguration) übertragen wurden. Nachdem Sie auf die Schaltfläche „Cutover“ geklickt haben, zeigt DMS ggf. die Anzahl ausstehender Sicherungsdateien an, die im SMB-Netzwerkspeicher oder im Azure-Blobcontainer vorhanden sind und noch angewendet bzw. am Ziel wiederhergestellt werden müssen. Wenn die Sicherung mit der CHECKUM-Option erstellt wird, führt der DMS-Wiederherstellungsvorgang automatisch die Überprüfung aus. Ist keine Prüfsumme vorhanden, wird die Integrität der Sicherung explizit vor der Wiederherstellung überprüft. Dadurch wird sichergestellt, dass die Wiederherstellungsdatei mit der Sicherungsdatei identisch ist und somit beide die gleichen Daten enthalten. Sie können alle Sicherungsdateien, einschließlich des letzten Sicherungsdateinamens aus der Quelle, überprüfen, wobei die Sicherungsdatei auf die Zielseite der DMS-Migrationsüberwachung angewendet/wiederhergestellt und ihre jeweilige Prüfsumme überprüft wird.

Für Azure SQL-Datenbankziele führt DMS die logische Migration im Fall von Azure SQL-Datenbank durch. Das heißt, sie kopiert die Daten aus den Tabellen der SQL-Quelldatenbank und schreibt sie in die Tabellen der Azure SQL-Zieldatenbank. Da DMS nur die Offlinemigration zu Azure SQL-Datenbank unterstützt, beginnt die Ausfallzeit der Anwendung beim Starten der Migration. Sie können die Anzahl der gelesenen Zeilen (aus der Quelldatenbanktabelle) überwachen und überprüfen und auf der Migrationsüberwachungsseite kopiert (in die Azure SQL-Zieldatenbanktabelle geschrieben). Als zusätzliche Bestätigung können Sie die folgenden Transact-SQL ausführen, um die Prüfsumme sowohl bei Quell- als auch Zieldatenbanken abzurufen und die Quell- und Wiederherstellungsdaten zu überprüfen, die identisch sind.

SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>;

Hinweis

Solange keine Anwendung in die Quell- oder Zieldatenbank schreibt, können Sie auch Tools wie das Datenbankvergleichstool für den Datenvergleich verwenden.

Die folgende Liste enthält die Azure-Ressourcen, die hinter den Kulissen erstellt werden können, um eine Datenmigration durchzuführen. Die verwendeten Dienste können je nach Migrationsszenario variieren.

• Azure Monitor
• Azure-VM
• Azure Storage
• Azure-Servicebus
• Azure Data Factory

Intern verwaltet DMS einen Metadatenspeicher, der Informationen zu Netzwerkspeicherorten, Anmeldeinformationen, Sicherungsdateien und abgeschlossenen Aufgaben enthält. Anmeldeinformationen und ausgewählte Felder, z. B. Kontoschlüssel, werden verschlüsselt. Daten, z. B. Tabellennamen, die in Telemetrie enthalten sein könnten, werden mit Hash versehen. Benutzernamen werden möglicherweise in Nur-Text-Protokollen angezeigt, kennwörter werden jedoch nie verwendet. Telemetrie wird nach Region isoliert, unterliegt Aufbewahrungsrichtlinien und ist nur für autorisierte Mitarbeiter innerhalb von Microsoft für zugelassene Problembehandlungszwecke verfügbar. Azure-Ressourcennamen wie Server- und Datenbanknamen folgen den Regeln für Azure-Ressourcen.

DMS (klassisch) nutzt Azure Service Bus-Themen, um die Kommunikation zwischen Computeebenen zu erleichtern. Die Azure Service Bus-Themen sind für jede DMS-Instanz einzigartig und alle personenbezogenen Daten werden verschlüsselt.

Azure SQL Managed Instance und SQL Server auf Azure-VMs

Schema und Daten werden mithilfe von Sicherung und Wiederherstellung migriert. Kunden haben die Wahl, aus einer Netzwerkfreigabe oder direkt aus einem Speichercontainer wiederherzustellen. Eine Datei mit Windows-Leistungsdaten kann verwendet werden, um optionale (aber dringend empfohlene) Empfehlungen für die Größenanpassung von Arbeitsauslastungen bereitzustellen.

Azure SQL-Datenbank

Migrationen zu Azure SQL-Datenbank werden in zwei Schritten ausgeführt. Der erste Schritt ist eine Schemamigration. DMS (klassisch) verwendet die SQL Management Objects (SMO) für die Schemamigration. Der zweite Schritt ist die tatsächliche Datenmigration. SqlBulkCopy wird zum Durchführen der Datenmigration verwendet. DMS unterstützt keine Schemamigration. Daten werden mithilfe von Azure Data Factory migriert. Optional, aber dringend empfohlen, kann eine Datei mit Windows-Leistungsdaten verwendet werden, um Empfehlungen für die Workloadanpassung bereitzustellen.

Azure-Datenbank für PostgreSQL

In diesem Szenario extrahiert der Endbenutzer die Metadaten, in diesem Fall das Schema unter Verwendung der Befehlszeilenprogramme pg_dump und pg_restore. Bei der Konfiguration der Änderungsdatenerfassung für PostgreSQL verwendet DMS intern pg_dump und pg_restore führt das anfängliche Seeding für CDC aus. Die Daten werden in einem verschlüsselten temporären Speicher gespeichert, auf den nur Ihre DMS-Instanz zugreifen kann. Eine Datei mit Windows-Leistungsdaten kann verwendet werden, um optionale (aber dringend empfohlene) Empfehlungen für die Größenanpassung von Arbeitsauslastungen bereitzustellen.

Azure-Datenbank für MySQL

In diesem Szenario erfolgt die Schemaextraktion und -migration durch DMS (klassisch) mithilfe des mysql-net/MySqlConnector. Wenn möglich, wird die MySQL-Binlogreplikation verwendet, um sowohl Daten- als auch Schemaänderungen zu replizieren. Benutzerdefinierter Code wird verwendet, um Änderungen zu synchronisieren, bei denen die Binlogreplikation nicht verwendet werden kann.

MongoDB zu Azure Cosmos DB

DMS extrahiert und fügt Daten aus einem MongoDB in Cosmos DB ein. Es bietet auch die Möglichkeit, die Daten aus einer BSON- oder JSON-Sicherungskopie zu extrahieren.

Bei BSON-Sicherungskopien verwendet DMS die Daten im bsondump-Format innerhalb desselben Ordners innerhalb eines BLOB-Containers. DMS sucht nur mit dem Format collection.metadata.json nach Metadatendateien.

Bei JSON-Sicherungskopien liest DMS die Dateien in den Blobcontainerordnern, die nach den enthaltenden Datenbanken benannt sind. In jedem Datenbankordner verwendet DMS nur Datendateien, die im data-Unterordner platziert sind. DMS untersucht nur Dateien, die im metadata-Unterordner platziert und mit dem Format collection.json für Metadaten benannt werden.

Oracle zu Azure Database for PostgreSQL

Ähnlich wie bei Oracle zu Azure SQL-Datenbank wird in diesem Szenario der AWR-Bericht oder eine Windows-Datei perfmon verwendet, um optionale (aber dringend empfohlene) Empfehlungen für die Dimensionierung von Arbeitsauslastungen bereitzustellen. Die ora2pg-Bibliothek wird verwendet, um das Schema zu extrahieren und die Daten manuell zu migrieren, indem der Benutzer die Migration durchführt.

DMS (klassisch) basiert auf der Kundennetzwerkkonfiguration. Wenn die Migrationsquelle private Endpunkte verwendet, verwenden wir private Endpunkte, was die bevorzugte Konfiguration ist. Wir verwenden öffentliche Endpunkte, wenn sie die einzige Option sind.

DMS verwendet ADF stark hinter den Kulissen für die Planung und Koordination von Datenbewegungen. Darüber hinaus unterscheidet sich die Self-Hosted Integration Runtime nicht von der, die Sie wahrscheinlich bereits für Ihre eigenen ADF-Pipelines verwenden. Weitere Informationen zu Firewall- und Proxyserverproblemen finden Sie unter Erstellen und Konfigurieren einer selbstgehostete Integration Runtime.

Alle ruhenden Kundendaten werden verschlüsselt. Einige Metadaten, einschließlich, aber nicht beschränkt auf logische Servernamen und Datenbanknamen, sowie Migrationsstatus und Migrationsfortschritt werden in Dienstprotokollen angezeigt, die nicht verschlüsselt sind.

Alle übertragenen Daten sind standardmäßig mit TLS 1.2-Verschlüsselung geschützt. Ältere Clients, die ältere Versionen von TLS erfordern, benötigen die erforderlichen Versionen, die auf der DMS-Portalseite (klassisch) aktiviert sind. Für DMS kann der Computer, auf dem die Self-Hosted Integration Runtime installiert ist, so konfiguriert werden, dass erforderliche TLS-Einstellungen für Legacyclients zulässig sind. Weitere Informationen zur TLS-Konfiguration für SQL Server finden Sie unter TLS 1.2-Unterstützung für Microsoft SQL Server.

Wo immer möglich, werden private Endpunkte verwendet. Wenn private Endpunkte keine Option sind, werden öffentliche Endpunkte für die Kommunikation zwischen Dienstebenen verwendet. Unabhängig vom Endpunkttyp sind alle Ressourcen auf die bestimmte Instanz von DMS dediziert und mit eindeutigen Anmeldeinformationen gesichert.

Wir unterstützen Customer Managed Keys nicht für die Verschlüsselung von Daten innerhalb unserer Datenebene oder Kontrollebene. Alle ruhenden Kundendaten werden jedoch mit vom Dienst verwalteten Schlüsseln verschlüsselt. Einige Metadaten, einschließlich, aber nicht beschränkt auf logische Servernamen und Datenbanknamen, sowie Migrationsstatus und Fortschritt werden in Dienstprotokollen in unverschlüsselter Form angezeigt.

Alle übertragenen Daten werden standardmäßig mit TLS 1.2-Verschlüsselung verschlüsselt. Die DMS(klassische) Portalseite ermöglicht es älteren Versionen von TLS, für Ältere Clients zu verwenden. Für DMS kann der Computer, auf dem die Self-Hosted Integration Runtime installiert ist, so konfiguriert werden, dass die Verwaltung von TLS-Einstellungen für Legacyclients möglich ist. Weitere Informationen zur TLS-Konfiguration für SQL Server finden Sie unter TLS 1.2-Unterstützung für Microsoft SQL Server.

Wir machen die Möglichkeit zum Verschlüsseln von Daten auf unserer Steuerungs- oder Datenebene mit vom Customer Managed Keys nicht öffentlich. Alle Kundendaten außer Dienstprotokolle werden gelöscht, wenn die DMS-Instanz gelöscht wird. DMS-Dienstprotokolle werden nur 6 Monate lang aufbewahrt.

TDE

DMS unterstützt die Migration von Customer Managed Keys (CMK) zu Azure SQL für Transparent Database Encryption (TDE). Schrittweise Anleitungen zum Migrieren Ihrer TDE-Schlüssel finden Sie im Tutorial: Migrieren von TDE-fähigen Datenbanken (Vorschau) zu Azure SQL in Azure Data Studio.

Zellverschlüsselung

Die Verschlüsselung auf Zellenebene wird auf Schemaebene behandelt. Die Schemamigrationstools migrieren alle Schemaobjekte, einschließlich der Funktionen und gespeicherten Prozeduren, die zum Implementieren der Verschlüsselung auf Zellenebene erforderlich sind.

Immer Verschlüsselt

DMS unterstützt derzeit keine Migration von Always Encrypted über Szenarien, in denen einzelne Datenzeilen zwischen Quelle und Ziel migriert werden. Spalten, die über Always Encrypted verschlüsselt werden, werden wie erwartet in Szenarien migriert, in denen Sicherung/Wiederherstellung verwendet wird, z. B. das Verschieben zu SQL Server auf azure VM oder azure SQL Managed Instance, von einer vorhandenen SQL Server-Instanz.

Wir implementieren keine Standortsteuerung, die über die bereits in Azure verfügbaren Zugriffskontrolle hinausgeht. Alle Daten, die einer DMS-Instanz zugeordnet sind, befinden sich in derselben Region wie die DMS-Ressource.

Unsere Dienstleistungen werden in verschiedenen Umgebungen mit unterschiedlichen internen Kontrollen und Geschäftsprozessen verwendet. DMS verschiebt Daten von und an eine beliebige Stelle, auf die das verwendete Konto Zugriff hat. Es liegt in der Verantwortung des Benutzers, die Berechtigungen und internen Kontrollen der Umgebung zu verstehen, in der sie arbeiten. Es ist besonders wichtig sicherzustellen, dass das Konto, das DMS zum Herstellen einer Verbindung mit der Quelle verwendet, Zugriff hat, um alle Daten anzuzeigen, die von der Quelle migriert werden sollen.

Das Einfügen eines virtuellen Netzwerks ist die Aktion zum Hinzufügen einer Azure-Ressource, die sich innerhalb des Microsoft-Mandanten befindet, zu einem Subnetz in einem virtuellen Netzwerk unter dem Kundenmandanten. Dieser Ansatz wurde mit DMS gewählt, um es uns zu ermöglichen, die Computes im Auftrag des Kunden zu verwalten und gleichzeitig den Zugriff auf Kundenressourcen aufrechtzuerhalten. Da sich das Netzwerk im Kundenabonnement befindet, kann Microsoft den virtuellen Computer nicht über die Ausgabe von den Befehlen „Start“, „Beenden“, „Löschen“ oder „Bereitstellen“ hinaus verwalten. Alle anderen Verwaltungsaktionen, die Zugriff auf den virtuellen Computer benötigen, erfordern eine vom Kunden initiierte Supportanfrage und -genehmigung.

Zur Gewährleistung reibungsloser Datenbankmigrationen mit Azure Database Migration Service müssen mehrere Voraussetzungen erfüllt werden. Einige der Voraussetzungen gelten für alle unterstützten Szenarien (Quelle-Ziel-Paare) des Diensts, andere nur für ein bestimmtes Szenario.

Folgende Voraussetzungen von Azure Database Migration Service gelten für alle unterstützten Migrationsszenarien:

• Erstellen Sie ein virtuelles Microsoft Azure-Netzwerk für Azure Database Migration Service mithilfe des Azure Resource Manager-Bereitstellungsmodells, das Site-to-Site-Konnektivität für Ihre lokalen Quellserver über ExpressRoute oder über VPN bereitstellt.
• Stellen Sie sicher, dass ihre Regeln für die Netzwerksicherheitsgruppe ihres virtuellen Netzwerks den Port 443 für ServiceTags of ServiceBus, Storage und AzureMonitor nicht blockieren. Ausführlichere Informationen zur NSG-Datenverkehrsfilterung in einem virtuellen Netzwerk finden Sie im Artikel Filtern des Netzwerkdatenverkehrs mit Netzwerksicherheitsgruppen.
• Wenn Sie eine Firewall-Appliance vor Ihren Quelldatenbanken verwenden, müssen Sie möglicherweise Firewall-Regeln hinzufügen, um Azure Database Migration Service für die Migration den Zugriff auf die Quelldatenbanken zu erlauben.

Eine Liste mit allen Voraussetzungen für spezifische Migrationsszenarien mit Azure Database Migration Service finden Sie in den entsprechenden Tutorials der Azure Database Migration Service-Dokumentation.

Möglicherweise müssen Sie Firewallregeln hinzufügen, die azure Database Migration Service den Zugriff auf Ihre Quelldatenbank für die Migration ermöglichen. Die IP-Adresse für den Dienst ist zwar dynamisch, bei Verwendung von ExpressRoute wird sie allerdings privat durch Ihr Unternehmensnetzwerk zugewiesen. Die einfachste Möglichkeit zur Ermittlung der entsprechenden IP-Adresse besteht darin, in der Ressourcengruppe, in der sich auch Ihre bereitgestellte Azure Database Migration Service-Ressource befindet, nach der zugeordneten Netzwerkschnittstelle zu suchen. Normalerweise beginnt der Name der Netzwerkschnittstellenressource mit dem Präfix NIC und gefolgt von einem eindeutigen Zeichen und einer Nummernfolge, NIC-jj6tnztnmarpsskr82rbndypz. B. . . Wenn Sie auf diese Netzwerkschnittstellenressource klicken, wird die IP-Adresse angezeigt, die auf der Ressourcenübersichtsseite im Azure-Portal in die Positivliste von IP-Adressen aufgenommen werden muss.

Möglicherweise müssen Sie auch die Portquelle einschließen, die SQL Server auf der Zulassungsliste überwacht. Standardmäßig ist es Port 1433, aber die SQL Server-Quelle kann so konfiguriert werden, dass auch andere Ports überwacht werden. In diesem Fall müssen Sie diese Ports ebenfalls der Positivliste hinzufügen. Den Port, an dem SQL Server lauscht, können Sie mithilfe einer Abfrage vom Typ „Dynamische Verwaltungssicht“ ermittelt:

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

Zum Ermitteln des Ports, an dem SQL Server lauscht, können Sie auch das SQL Server-Fehlerprotokoll abfragen:

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

Die Einrichtung eines virtuellen Azure-Netzwerks wird in mehreren Microsoft-Tutorials ausführlich beschrieben. Die offizielle Dokumentation finden Sie jedoch im Artikel Azure Virtual Network.

Eine typische einfache Datenbankmigration umfasst Folgendes:

1. Erstellen Sie Zieldatenbanken.
2. Bewerten Sie Ihre Quelldatenbanken.
   • Bewerten Sie bei homogenen Migrationen Ihre vorhandenen Datenbanken mithilfe der Azure SQL-Migrationserweiterung für Azure Data Studio.
   • Bewerten Sie bei heterogenen Migrationen (aus Konkurrierenquellen) Ihre vorhandenen Datenbanken mit SSMA. Sie verwenden SSMA auch, um Datenbankobjekte zu konvertieren und das Schema zu Ihrer Zielplattform zu migrieren.
3. Erstellen einer Instanz von Azure Database Migration Service
4. Erstellen Sie ein Migrationsprojekt, das die Quelldatenbanken, Zieldatenbanken und die zu migrierenden Tabellen angibt.
5. Starten des vollständigen Ladenvorgangs.
6. Auswählen der anschließenden Überprüfung
7. Durchführen eines manuellen Wechsels zur neuen cloudbasierten Datenbank für Ihre Produktionsumgebung

Wenn Sie während der Migration keine Verbindung mit Ihrem Quelldatenbanksystem herstellen können, erstellen Sie eine VM im selben Subnetz des virtuellen Netzwerks, in dem Sie Ihre DMS-Instanz einrichten. Im virtuellen Computer sollten Sie in der Lage sein, einen Verbindungstest durchzuführen, z.B. mit einer UDL-Datei, um eine Verbindung mit SQL Server zu testen, oder Robo 3T herunterzuladen, um MongoDB-Verbindungen zu testen. Wenn der Verbindungstest erfolgreich ist, sollten Sie kein Problem mit dem Herstellen einer Verbindung mit Ihrer Quelldatenbank haben. Wenn der Verbindungstest nicht erfolgreich ist, wenden Sie sich an Ihren Netzwerkadministrator.

Wenn der Benutzer Azure Database Migration Service (DMS) explizit beendet oder der Dienst für 24 Stunden inaktiv ist, wird der Dienst beendet oder automatisch angehalten. In jedem Fall ist der Dienst nicht verfügbar und beendet. Um aktive Migrationen wieder aufzunehmen, starten Sie den Dienst neu.

Die Datenmigration mit diesem Dienst lässt sich durch folgende Maßnahmen beschleunigen:

Für DMS (klassisch):

• Verwenden Sie beim Erstellen Ihrer Dienstinstanz den universellen Tarif mit mehreren CPUs, damit dem Dienst mehrere vCPUs für Parallelisierung und schnellere Datenübertragungen zur Verfügung stehen.
• Skalieren Sie Ihre Azure SQL-Datenbankzielinstanz während des Datenmigrationsvorgangs vorübergehend auf die Premium-SKU, um die Azure SQL-Datenbankeinschränkung zu minimieren, die sich auf Datenübertragungsaktivitäten auswirken kann, wenn Sie SKUs auf niedrigerer Ebene verwenden.

Für DMS:

• Wenn Sie Sicherungen aus der lokalen Dateifreigabe in Azure Blob Storage kopieren oder während der Migration zu einer Azure SQL-Zieldatenbank migrieren, verwendet DMS den SHIR-Knoten als Berechnung. Achten Sie daher darauf, die Ressourcennutzung dieses SHIR-Knotens zu überwachen.
• Skalieren Sie Ihre Azure SQL-Datenbankzielinstanz während des Datenmigrationsvorgangs vorübergehend auf die Premium-SKU, um die Drosselung von Azure SQL-Datenbankdatenträgern zu minimieren, die sich auf Datenübertragungsaktivitäten auswirken können, wenn Sie SKUs auf niedrigerer Ebene verwenden.
• Ausführlichere Informationen finden Sie unter Verbessern der SQL DB-Migrationsleistung – Azure-Datenbankmigrationsdienst.

Verwandte Inhalte

• Was ist der Azure Database Migration Service.