Häufig gestellte Fragen zur Verwendung von 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

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.

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 Azure SQL VM- und Azure SQL MI-Ziele verwendet DMS eine physische Migration mit Sicherung und Wiederherstellung. Wie weiter unten beschrieben, bestimmt der ausgewählte Migrationsmodus, wie die Daten zwischen Quelle und Ziel konsistent gehalten werden.

• Offlinemigration: Bei der Offlinemigration zu Azure SQL-VM- und Azure SQL MI-Zielen beginnt die Downtime der Anwendung, wenn die Migration beginnt. DMS stellt alle Sicherungsdateien am Ziel wieder her – vorausgesetzt, die neuesten Sicherungsdateien aus der Quelle wurden in den SMB-Netzwerkspeicher oder in den Azure-Blobcontainer übertragen (gemäß der Migrationskonfiguration). Wenn die Sicherung mit der CHECKSUM-Option erstellt wird, wird die Validierung automatisch im Rahmen des DMS-Wiederherstellungsvorgangs durchgeführt. 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: Bei der Onlinemigration zu Azure SQL-VM- und Azure SQL MI-Zielen beginnt die Downtime, sobald Sie den Cutover der Migration initiieren und die Anwendung beendet wird. DMS stellt alle Sicherungsdateien am Ziel wieder her – vorausgesetzt, die neuesten Sicherungsdateien aus der Quelle wurden in den SMB-Netzwerkspeicher oder in den Azure-Blobcontainer übertragen (gemäß der Migrationskonfiguration). 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 CHECKSUM-Option erstellt wird, wird die Validierung automatisch im Rahmen des DMS-Wiederherstellungsvorgangs durchgeführt. 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.

Bei Zielen vom Typ „Azure SQL-Datenbank“ führt DMS im Falle von Azure SQL-Datenbank eine logische Migration durch. Dabei werden die Daten aus den Tabellen der SQL-Quelldatenbank kopiert und in die Tabellen der als Ziel verwendeten Azure SQL-Datenbank-Instanz geschrieben. Da DMS nur Offlinemigrationen zu Azure SQL-Datenbank unterstützt, beginnt die Downtime der Anwendung, wenn die Migration beginnt. Sie können die Anzahl der aus der Quelldatenbanktabelle gelesenen Zeilen und die Anzahl der in die Azure SQL-Datenbank-Tabelle geschriebenen (kopierten) Zeilen über die Migrationsüberwachungsseite überwachen und überprüfen. Zusätzlich können Sie zur Bestätigung den folgenden TSQL-Code ausführen, um sowohl in Quell- als auch in Zieldatenbanken Prüfsummen zu erhalten und sich zu vergewissern, dass die Quell- und Wiederherstellungsdaten identisch sind.

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

Hinweis: Voraussetzung ist, dass gerade keine Anwendungen Daten in die Quell- oder Zieldatenbank schreiben. Sie können auch Tools wie das Datenbankvergleichstool für den Datenvergleich verwenden.

Die folgende Liste enthält die Azure-Ressourcen, die im Hintergrund 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 Service Bus
• 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 möglicherweise in Telemetrie enthalten sind, 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 (Classic) 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, die Windows-Leistungsdaten enthält, kann verwendet werden, um optionale (aber dringend empfohlene) Empfehlungen für die Dimensionierung von Workloads bereitzustellen.

Azure SQL-Datenbank

Migrationen zu Azure SQL-Datenbank werden in zwei Schritten ausgeführt. Der erste Schritt ist eine Schemamigration. DMS (Classic) verwendet 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 Dimensionierung der Workloads bereitzustellen.

Azure Database for 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, die Windows-Leistungsdaten enthält, kann verwendet werden, um optionale (aber dringend empfohlene) Empfehlungen für die Dimensionierung von Workloads bereitzustellen.

Azure Database for MySQL

In diesem Szenario erfolgt die Schemaextraktion und -migration durch DMS (Classic) 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 SQL-Datenbank

In diesem Szenario wird der AWR-Bericht oder eine Windows-Datei perfmon verwendet, um optionale (aber dringend empfohlene) Empfehlungen für die Dimensionierung von Arbeitsauslastungen bereitzustellen. Der Benutzer, der die Migration durchführt, verwendet das Database Schema Conversion Toolkit, um eine Schemamigration durchzuführen, um die Zieldatenbank vorzubereiten.

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 (Classic) 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. Legacy-Clients, die ältere Versionen von TLS erfordern, benötigen die erforderlichen Versionen, die auf der Portalseite DMS (Classic) aktiviert werden können. 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 KB3135244 - 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. Auf der Portalseite DMS (Classic) können ältere Versionen von TLS für Legacy-Clients verwendet werden. 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 KB3135244 - 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 30 Tage 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.

Always Encrypted

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. zum Verschieben zu Azure SQL VM oder Azure SQL Managed Instance aus 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 zum Anzeigen aller Daten hat, die von der Quelle migriert werden sollen.

VNET-Einfügung ist die Aktion, eine Azure-Ressource, die sich im Microsoft-Mandanten befindet, zu einem Subnetz in einem VNet unter dem Kundenmandanten hinzuzufügen. 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 die NSG-Regeln (Netzwerksicherheitsgruppen) des virtuellen Netzwerks nicht Port 443 für die ServiceTags „ServiceBus“, „Storage“ und „AzureMonitor“ blockieren. Ausführlichere Informationen zur NSG-Datenverkehrsfilterung in einem virtuellen Netzwerk finden Sie im Artikel Filtern des Netzwerkdatenverkehrs mit Netzwerksicherheitsgruppen.
• Wenn Sie eine Firewallappliance vor Ihren Quelldatenbanken verwenden, müssen Sie möglicherweise Firewallregeln hinzufügen, um Azure Database Migration Service den Zugriff auf die Quelldatenbanken für die Migration zu ermöglichen.

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 Firewallregeln hinzugefügt werden, damit Azure Database Migration Service auf Ihre Quelldatenbank für die Migration zugreifen kann. 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. Der Name der Netzwerkschnittstellenressource beginnt üblicherweise mit dem NIC-Präfix, gefolgt von einer eindeutigen Zeichen- und Ziffernfolge (z.B. NIC-jj6tnztnmarpsskr82rbndyp). 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.

Gegebenenfalls müssen Sie der Positivliste auch die Portquelle hinzufügen, an der SQL Server lauscht. Dies ist standardmäßig Port 1433. Es ist jedoch möglich, dass die SQL Server-Quellinstanz für das Lauschen an anderen Ports konfiguriert wurde. 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 von Zieldatenbanken
2. Bewerten der Quelldatenbank(en).
   • Bewerten der vorhandenen Datenbank(en) mithilfe von DMA für homogene Migrationen.
   • Bewerten der vorhandenen Datenbank(en) mithilfe von SSMA für heterogene Migrationen (aus verschiedenen Quellen). 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 eines Migrationsprojekts unter Angabe der Quelldatenbanken, der Zieldatenbanken und der zu migrierenden Tabellen.
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-Datenbank-Zielinstanz während der Datenmigration vorübergehend auf die Premium-Tarifebene hoch, um die Drosselung durch Azure SQL-Datenbank zu minimieren, die bei SKUs einer niedrigeren Ebene unter Umständen zu einer Beeinträchtigung der Datenübertragungsaktivitäten führt.

Für DMS:

• Wenn Sie Sicherungen von der lokalen Dateifreigabe in Azure Blob Storage ODER während der Migration zur Azure SQL-Datenbank-Zielinstanz kopieren, verwendet DMS den SHIR-Knoten als Computeressource. Achten Sie daher darauf, die Ressourcennutzung dieses SHIR-Knotens zu überwachen.
• Skalieren Sie Ihre Azure SQL-Datenbank-Zielinstanz während der Datenmigration vorübergehend auf die Premium-SKU hoch, um die Drosselung durch Azure SQL-Datenbank zu minimieren, die bei niedrigeren SKUs unter Umständen zu einer Beeinträchtigung der Datenübertragungsaktivitäten führt.
• Ausführlichere Informationen finden Sie im Blog.

Nächste Schritte

• Was ist der Azure Database Migration Service.