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.

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 SQL Server auf Azure-VM und Azure SQL Managed Instance-Ziele verwendet der Azure Database Migration Service (DMS) einen physischen Migrationsvorgang, der durch Sicherungs- und Wiederherstellungsvorgänge durchgeführt wird. 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 beginnen die Ausfallzeiten, sobald Sie den Migration Cutover initiieren und die Anwendung stoppen. 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 Namens der letzten Sicherungsdatei aus der Quelle, mit der auf der DMS-Überwachungsseite für die Migration angezeigten Sicherungsdatei verifizieren und ihre jeweilige Prüfsumme validieren.

Für Azure SQL Database-Ziele führt DMS eine logische Migration durch, wenn es sich um Azure SQL Database handelt. 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 auf der Migrationsüberwachungsseite die Anzahl der gelesenen Zeilen aus der Quelldatenbanktabelle und der in die Azure SQL-Zieldatenbanktabelle kopierten Zeilen überwachen und validieren. 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>;

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 können möglicherweise in Serviceprotokollen im Klartext erscheinen, Passwörter jedoch nie. 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, um das anfängliche Seeding für CDC auszuführen. 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 einem BSON- oder JSON-Dump 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-Dumps liest DMS die Dateien in den Blob-Container-Ordnern, die nach den Datenbanken benannt sind, die sie enthalten. 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-Datenbank für 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 Kundendaten im Ruhezustand 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 die notwendigen TLS-Einstellungen zur Unterstützung von Legacy-Clients zugelassen werden. 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 die Verwendung älterer TLS-Versionen für Legacy-Clients. 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 ältere Clients 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 von Kunden verwalteten Schlüsseln nicht zugänglich. 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).

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, die von der Quelle migriert werden sollen, einzusehen.

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. . . Durch Auswahl dieser Netzwerkschnittstelle können Sie die IP-Adresse sehen, die auf der Ressourcenübersichtsseite des Azure-Portals in die Zulassungsliste aufgenommen werden muss.

Möglicherweise müssen Sie auch die Port-Quelle, die SQL Server überwacht, in die Zulassungsliste aufnehmen. 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 zur Erlaubenliste 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

Obwohl mehrere Microsoft-Tutorials Sie durch den Prozess der Einrichtung eines virtuellen Netzwerks führen können, finden Sie die offizielle Dokumentation im Artikel Azure Virtual Network.

Eine typische einfache Datenbankmigration umfasst Folgendes:

1. Erstellen Sie Zieldatenbanken.
2. Bewerten Sie Ihre Quelldatenbanken mit SSMA. SSMA kann auch Datenbankobjekte konvertieren und das Schema auf Ihre Zielplattform 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. Vollständigen Ladevorgang starten.
6. Wählen Sie die nächste Überprüfung aus
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 Database-Zielinstanz während der Datenoperation vorübergehend hoch auf die Premium Tier SKU, um die Drosselung von Azure SQL Database zu minimieren, die bei der Verwendung von SKUs auf niedrigerer Ebene die Datenübertragungsaktivitäten beeinträchtigen kann.

Für DMS:

• Wenn Sie Sicherungen von einer lokalen Dateifreigabe auf Azure Blob Storage kopieren oder eine Migration zu Azure SQL Database durchführen, verwendet DMS den SHIR-Knoten als Compute. Achten Sie daher darauf, die Ressourcennutzung dieses SHIR-Knotens zu überwachen.
• Skalieren Sie Ihre Azure SQL Database-Zielinstanz während der Datenoperation vorübergehend auf die Premium Tier SKU, um die Drosselung der Datenträger von Azure SQL Database zu minimieren, die bei der Verwendung von SKUs auf niedrigerer Ebene die Datenübertragungsaktivitäten beeinträchtigen kann.
• Ausführlichere Informationen finden Sie unter Verbessern der SQL DB-Migrationsleistung – Azure-Datenbankmigrationsdienst.

Verwandte Inhalte

• Was ist der Azure Database Migration Service.