Bewährte Methoden für AWS Database Migration Service

Um AWS Database Migration Service (AWS DMS) möglichst effektiv zu nutzen, schauen Sie sich die Empfehlungen in diesem Abschnitt zu den effizientesten Datenmigrationsmethoden an.

Planen der Migration für AWS Database Migration Service

Beim Planen einer Datenbankmigration mit AWS Database Migration Service sollten Sie Folgendes beachten:

• Sie müssen ein Netzwerk konfigurieren, um Ihre Quell- und Zieldatenbanken mit einer AWS DMS-Replikations-Instance zu verbinden. Dies kann so einfach sein wie die Verbindung zweier AWS-Ressourcen in derselben Virtual Private Cloud (VPC), in der sich Ihre Replikations-Instance befindet. Dies kann bis hin zu komplexeren Konfigurationen reichen, z. B. der Verbindung einer On-Premises-Datenbank mit einer Amazon RDS-DB-Instance über ein Virtual Private Network (VPN). Weitere Informationen finden Sie unter Netzwerkkonfigurationen für die Datenbankmigration.

• Quell- und Ziel-Endpunkte – Sie müssen wissen, welche Informationen und Tabellen in der Quelldatenbank zur Zieldatenbank migriert werden müssen. AWS DMS unterstützt eine grundlegende Schemamigration, einschließlich der Erstellung von Tabellen und primären Schlüsseln. Allerdings erstellt AWS DMS nicht automatisch sekundäre Indizes, Fremdschlüssel, Benutzerkonten und dergleichen in der Zieldatenbank. Je nach Quell- und Ziel-Datenbank-Engine müssen Sie zusätzliche Protokollierung einrichten oder andere Einstellungen für eine Quell- oder Zieldatenbank ändern müssen. Weitere Informationen finden Sie unter Quellen für die Datenmigration und Ziele für die Datenmigration.

• Schema/Code-Migration – AWS DMS führt keine Schema- oder Code-Konvertierung durch. Sie können Ihr Schema mithilfe von Tools wie Oracle SQL Developer, MySQL Workbench oder pgAdmin III konvertieren. Wenn Sie ein vorhandenes Schema in eine andere Datenbank-Engine konvertieren möchten, können Sie AWS Schema Conversion Tool (AWS SCT) verwenden. Dieses Tool kann ein Zielschema erstellen, aber auch ein ganzes Schema generieren und erstellen, wie Tabellen, Indizes, Ansichten und so weiter. Sie können das Tool auch verwenden, um PL/SQL oder TSQL in PgSQL und andere Formate umzuwandeln. Weitere Informationen zu AWS SCT finden Sie im AWS SCT-Benutzerhandbuch.

• Nicht unterstützte Datentypen – Einige Quelldatentypen müssen in die äquivalenten Datentypen für die Zieldatenbank konvertiert werden. Weitere Informationen über unterstützte Datentypen finden Sie im Quell- oder Zielabschnitt für Ihren Datenspeicher.

• Ergebnisse des Diagnoseunterstützungsskripts – Wenn Sie Ihre Migration planen, empfehlen wir Ihnen, Diagnoseunterstützungsskripts auszuführen. Anhand der Ergebnisse dieser Skripts finden Sie erweiterte Informationen zu potenziellen Migrationsfehlern.

  Wenn ein Unterstützungsskript für Ihre Datenbank verfügbar ist, laden Sie es über den Link im entsprechenden Skriptthema im folgenden Abschnitt herunter. Nachdem Sie das Skript überprüft haben, können Sie es gemäß dem im Skriptthema beschriebenen Verfahren in Ihrer lokalen Umgebung ausführen. Wenn die Skriptausführung abgeschlossen ist, können Sie die Ergebnisse überprüfen. Wir empfehlen, diese Skripts als ersten Schritt bei der Problembehandlung auszuführen. Die Ergebnisse können bei der Arbeit mit einem AWS Support-Team nützlich sein. Weitere Informationen finden Sie unter Arbeiten mit Diagnoseunterstützungsskripts in AWS DMS.

• Bewertungen vor der Migration – Bei einer Bewertung vor der Migration werden bestimmte Komponenten einer Datenbankmigrationsaufgabe bewertet, um Probleme zu identifizieren, die verhindern könnten, dass eine Migrationsaufgabe wie erwartet ausgeführt wird. Mithilfe dieser Bewertung können Sie potenzielle Probleme identifizieren, bevor Sie eine neue oder geänderte Aufgabe ausführen. Weitere Informationen zur Arbeit mit Bewertungen vor der Migration finden Sie unter Aktivieren und Verwenden von Vormigrationsbewertungen für eine Aufgabe.

Konvertieren des Schemas

AWS DMS führt keine Schema- oder Codekonvertierung durch. Wenn Sie ein vorhandenes Schema zu einer anderen Datenbank-Engine konvertieren möchten, können Sie AWS SCT verwenden. AWS SCT konvertiert Ihre Quellobjekte, Tabellen, Indizes, Ansichten, Auslöser und andere Systemobjekte in das Zielformat der Datendefinitionssprache (DDL). Sie können mithilfe von AWS SCT auch eine Großteil des Anwendungscodes, wie PL/SQL oder TSQL, in die äquivalente Zielsprache umwandeln.

Sie erhalten AWS SCT als kostenlosen Download von AWS. Weitere Informationen zu AWS SCT finden Sie im AWS SCT-Benutzerhandbuch.

Wenn sich Ihre Quell- und Zielendpunkte in derselben Datenbank-Engine befinden, können Sie Tools wie Oracle SQL Developer, MySQL Workbench oder PgAdmin4 verwenden, um Ihr Schema zu verschieben.

Überprüfung der öffentlichen Dokumentation von AWS DMS

Wir empfehlen Ihnen dringend, vor der ersten Migration die öffentlichen AWS DMS-Dokumentationsseiten für Ihre Quell- und Zielendpunkte durchzugehen. Diese Dokumentation kann Ihnen helfen, die Voraussetzungen für die Migration zu ermitteln und die aktuellen Einschränkungen zu verstehen, bevor Sie beginnen. Weitere Informationen finden Sie unter Arbeiten mit AWS-DMS-Endpunkten.

Während der Migration kann Ihnen die öffentliche Dokumentation bei der Behebung von Problemen mit AWS DMS helfen. Die Seiten zur Fehlerbehebung in der Dokumentation können Ihnen helfen, häufig auftretende Probleme bei der Verwendung von AWS DMS und ausgewählten Endpunktdatenbanken zu beheben. Weitere Informationen finden Sie unter Fehlerbehebung für Migrationsaufgaben in AWS Database Migration Service.

Ausführen eines Machbarkeitsnachweises

Um Probleme mit Ihrer Umgebung in den frühen Phasen Ihrer Datenbankmigration besser erkennen zu können, empfehlen wir Ihnen, eine kleine Testmigration durchzuführen. Auf diese Weise können Sie auch einen realistischeren Zeitplan für die Migration festlegen. Darüber hinaus müssen Sie möglicherweise eine umfassende Testmigration durchführen, um zu messen, ob AWS DMS den Durchsatz Ihrer Datenbank über Ihr Netzwerk bewältigen kann. Während dieser Zeit empfehlen wir, Ihre anfängliche Volllast und die laufende Replikation zu vergleichen und zu optimieren. Auf diese Weise können Sie Ihre Netzwerklatenz besser verstehen und die Gesamtleistung einschätzen.

An dieser Stelle haben Sie auch die Möglichkeit, Ihr Datenprofil und die Größe Ihrer Datenbank zu verstehen, einschließlich der folgenden Informationen:

• Wie viele Tabellen groß, mittel und klein sind.

• Wie AWS DMS mit Datentyp- und Zeichensatzkonvertierungen umgeht.

• Wie viele Tabellen Large Object (LOB)-Spalten haben.

• Wie lange es dauert, eine Testmigration durchzuführen.

Verbessern der Leistung einer AWS DMS-Migration

Die Leistung Ihrer AWS DMS-Migration wird von verschiedenen Faktoren beeinflusst:

• Ressourcenverfügbarkeit an der Quelle.

• Verfügbarer Netzwerkdurchsatz.

• Ressourcenkapazität des Replikationsservers.

• Fähigkeit des Ziels, Änderungen aufzunehmen.

• Art und Verteilung der Quelldaten.

• Anzahl der zu migrierenden Objekte.

Es ist möglich, durch Beachtung einiger oder aller der nachstehend erwähnten bewährten Methoden die Leistung zu verbessern. Ob Sie eine dieser Methoden anwenden können, hängt von Ihrem speziellen Anwendungsfall ab. Im Folgenden finden Sie einige Einschränkungen:

Bereitstellung eines geeigneten Replikationsservers

AWS DMS ist ein verwalteter Service, der auf einer Amazon-EC2-Instance ausgeführt wird. Dieser Service stellt eine Verbindung zur Quelldatenbank her, liest die Quelldaten, formatiert die Daten für die Verwendung durch die Zieldatenbank und lädt die Daten dann in die Zieldatenbank.

Der Großteil dieser Verarbeitung erfolgt im Arbeitsspeicher. Allerdings werden umfangreiche Transaktionen ggf. auf Festplatte gepuffert. Zwischengespeicherte Transaktionen und Protokolldateien werden ebenfalls auf Festplatte geschrieben. In den folgenden Abschnitten finden Sie Informationen dazu, was Sie bei der Auswahl Ihres Replikationsservers beachten sollten.

CPU

AWS DMS ist für heterogene Migrationen konzipiert, unterstützt aber auch homogene Migrationen. Um eine homogene Migration durchzuführen, konvertieren Sie zunächst jeden Quelldatentyp in den entsprechenden AWS DMS-Datentyp. Konvertieren Sie dann jeden AWS DMS-Datentyp in den Zieldatentyp. Verweise auf diese Konvertierungen für jede Datenbank-Engine finden Sie im AWS DMS-Benutzerhandbuch.

Damit AWS DMS diese Konvertierungen optimal durchführen kann, muss die CPU zum Zeitpunkt der Konvertierungen verfügbar sein. Eine Überlastung der CPU und ein Mangel an CPU-Ressourcen können zu langsamen Migrationen führen, was auch weitere Nebenwirkungen haben kann.

Replikations-Instance-Klasse

Einige der kleineren Instance-Klassen reichen für das Testen des Service oder für kleine Migrationen aus. Wenn Ihre Migration eine große Anzahl von Tabellen beinhaltet, oder Sie mehrere gleichzeitige Replikationsaufgaben ausführen möchten, sollten Sie in Betracht ziehen, eine der größeren Instances zu verwenden. Eine größere Instance kann sinnvoll sein, da der Service eine beträchtliche Menge an Arbeitsspeicher und CPU verbraucht.

T2-Instances wurden entwickelt, um eine moderate Basisleistung und eine signifikant höhere Leistung bereitzustellen, je nach den Anforderungen Ihres Workloads. Sie eignen sich für Workloads, die die volle CPU-Leistung selten oder uneinheitlich verwenden, jedoch gelegentlich Spitzenlasten verarbeiten müssen. T2-Instances eignen sich gut für Allzweck-Workloads, z. B. Webserver, Entwicklungsumgebungen und kleine Datenbanken. Wenn Sie Probleme mit einer langsamen Migration beheben und einen T2-Instance-Typ verwenden, überprüfen Sie die Host-Metrik „CPU-Auslastung“. Diese kann Ihnen zeigen, ob Sie die Baseline für diesen Instance-Typ übersteigen.

Die C4-Instance-Klassen wurden für höchste Prozessorleistung für rechenintensive Workloads konzipiert. Sie erreichen eine erheblich höhere Pakete-pro-Sekunde (PPS)-Leistung, weniger Netzwerkverstopfung und eine geringere Netzwerklatenz. AWS DMS kann CPU-intensiv sein, insbesondere bei heterogenen Migrationen und Replikationen wie etwa der Migration von Oracle zu PostgreSQL. C4-Instances können eine gute Wahl für diese Situationen sein.

Die R4-Instance-Klassen sind speicheroptimiert für speicherintensive Workloads Laufende Migrationen oder Replikationen von Transaktionssystemen mit hohem Durchsatz unter Verwendung von AWS DMS können zeitweise große Mengen an CPU und Speicher verbrauchen. R4-Instances verfügen über mehr Arbeitsspeicher pro vCPU.

AWS DMS-Unterstützung für die Instance-Klassen R5 und C5

Die R5-Instance-Klassen sind speicheroptimierte Instances, die darauf ausgelegt sind, eine schnelle Leistung bei Workloads zu erreichen, die große Datensätze im Arbeitsspeicher verarbeiten. Laufende Migrationen oder Replikationen von Transaktionssystemen mit hohem Durchsatz unter Verwendung von AWS DMS können zeitweise große Mengen an CPU und Speicher verbrauchen. R5-Instances bieten 5 Prozent mehr Speicher pro vCPU als R4 und die größte Größe bietet 768 GiB Arbeitsspeicher. Darüber hinaus bieten R5-Instances eine Verbesserung des Preises pro GiB um 10 Prozent und eine um ~ 20 % höhere CPU-Leistung als R4.

Die C5-Instance-Klassen sind für rechenintensive Workloads optimiert und bieten eine kostengünstige hohe Leistung bei einem niedrigen Preis-Leistungs-Verhältnis. Sie erreichen eine deutlich höhere Netzwerkleistung. Elastic Network Adapter (ENA) bietet C5-Instances mit bis zu 25 Gbit/s Netzwerkbandbreite und bis zu 14 Gbit/s dedizierter Bandbreite für Amazon EBS. AWS DMSkann CPU-intensiv sein, insbesondere bei heterogenen Migrationen und Replikationen wie der Migration von Oracle zu PostgreSQL. C5-Instances können für solche Situationen eine gute Wahl sein.

Speicher

Abhängig von der Instance-Klasse umfasst Ihre Replikations-Instance entweder 50 GB oder 100 GB Datenspeicher. Dieser Speicher wird für Protokolldateien und alle zwischengespeicherten Änderungen verwendet, die während des Ladevorgangs erfasst werden. Wenn Ihr Quellsystem ausgelastet ist oder umfangreiche Transaktionen verarbeitet, müssen Sie möglicherweise Ihren Speicherplatz erweitern. Wenn Sie mehrere Aufgaben auf dem Replikationsserver ausführen, benötigen Sie möglicherweise auch eine Speichererweiterung. Normalerweise reicht die Standardmenge aber aus.

Alle Speicher-Volumes in AWS DMS sind GP2- oder Allzweck-Solid-State-Laufwerke (SSDs). GP2-Volumes verfügen über eine Basisleistung von drei E/A-Vorgängen pro Sekunde (IOPS) und können auf Kreditbasis bis zu 3 000 IOPS gesteigert werden. Als Faustregel gilt: Überprüfen Sie die ReadIOPS- und WriteIOPS -Metriken für die Replikations-Instance. Stellen Sie sicher, dass die Summe dieser Werte die Basisleistung für dieses Volume nicht überschreitet.

Multi-AZ

Wenn Sie sich für eine Multi-AZ-Instance entscheiden, können Sie damit Ihre Migration vor Speicherausfällen schützen. Die meisten Migrationen sind vorübergehend und nicht für einen langen Zeitraum vorgesehen. Wenn Sie AWS DMS für fortlaufende Replikationszwecke verwenden, kann die Wahl einer Multi-AZ-Instance Ihre Verfügbarkeit verbessern, falls ein Speicherproblem auftreten sollte.

Wenn Sie eine einzelne AZ- oder Multi-AZ-Replikations-Instance während eines FULL LOAD-Vorgangs verwenden und ein Failover oder ein Host-Austausch stattfindet, ist zu erwarten, dass die Volllast-Aufgabe fehlschlägt. Für die verbleibenden Tabellen, die nicht abgeschlossen wurden oder sich in einem Fehlerstatus befinden, können Sie die Aufgabe ab dem Zeitpunkt des Fehlers neu starten.

Paralleles Laden mehrerer Tabellen

Standardmäßig lädt AWS DMS immer acht Tabellen gleichzeitig. Möglicherweise lässt sich eine Leistungsverbesserung erzielen, wenn Sie diese Menge etwas erhöhen, sofern Sie einen sehr großen Replikationsserver verwenden wie einen dms.c4.xlarge oder eine größere Instance. Es kann jedoch auch vorkommen, dass die Leistung durch Erhöhen der parallelen Ausführung an einem bestimmten Punkt abfällt. Wenn Ihr Replikationsserver relativ klein ist, z. B. ein dms.t2.medium, sollten Sie die Anzahl der parallel geladenen Tabellen reduzieren.

Um diese Zahl in der AWS Management Console zu ändern, öffnen Sie die Konsole, wählen Sie Aufgaben, wählen Sie aus, ob Sie eine Aufgabe erstellen oder ändern möchten, und wählen Sie dann Erweiterte Einstellungen. Ändern Sie unter Tuning Settings (Optimierung der Einstellungen) die Option Maximum number of tables to load in parallel (Maximale Anzahl parallel zu ladender Tabellen).

Um diese Zahl mit der AWS CLI zu ändern, ändern Sie den MaxFullLoadSubTasks-Parameter unter TaskSettings.

Verwendung paralleler Volllast

Sie können eine parallele Ladung aus Oracle-, Microsoft SQL Server-, MySQL-, Sybase- und IBM-Db2-LUW-Quellen verwenden, die auf Partitionen und Unterpartitionen basieren. Dadurch kann die Gesamtdauer des Vollladevorgangs verbessert werden. Darüber hinaus können Sie bei der Ausführung einer AWS DMS-Migrationsaufgabe die Migration großer oder partitionierter Tabellen beschleunigen. Teilen Sie dazu die Tabelle in Segmente auf und laden Sie die Segmente parallel in dieselbe Migrationsaufgabe.

Wenn Sie paralleles Laden verwenden möchten, können Sie mit der parallel-load-Option eine Tabellenzuweisungsregel des Typs table-settings angeben. In der table-settings-Regel geben Sie die Auswahlkriterien für die Tabelle bzw. Tabellen an, die Sie parallel laden möchten. Um die Auswahlkriterien anzugeben, legen Sie das Element type für parallel-load auf eine der folgenden Optionen fest:

• partitions-auto

• subpartitions-auto

• partitions-list

• ranges

• none

Weitere Informationen zu diesen Einstellungen finden Sie unter Regeln und Operationen für Tabellen- und Sammlungseinstellungen.

Arbeiten mit Indizes, Auslösern und Einschränkungen bezüglich der referenziellen Integrität

Indizes, Auslöser und Einschränkungen bezüglich der referenziellen Integrität können sich auf Ihre Migrationsleistung auswirken kann dazu führen, dass Ihre Migration fehlschlägt. Wie sich diese auf die Migration auswirken, hängt davon ab, ob Ihre Replikationsaufgabe eine Volllastaufgabe oder eine laufende Replikationsaufgabe (Change Data Capture, CDC) ist.

Für eine Volllastaufgabe empfehlen wir, Primärschlüsselindizes, Sekundärindizes, referentielle Integritätsbeschränkungen und DML-Trigger (Data Manipulation Language) zu löschen. Sie können auch ihre Erstellung bis zum Abschluss der Volllastaufgaben verzögern. Während einer Volllast-Aufgabe sind keine Indizes erforderlich und es entstehen Fixkosten für die Wartung, wenn sie vorhanden sind. Da die Aufgabe zum vollständigen Laden Tabellen gruppenweise lädt, wird gegen Einschränkungen bezüglich der referenziellen Integrität verstoßen. Gleichermaßen kann das Einfügen, Aktualisieren und Löschen von Auslösern Fehler verursachen, wenn z. B. für eine zuvor im Bulk-Verfahren geladene Tabelle das Einfügen einer Zeile ausgelöst wird. Andere Arten von Auslöser beeinträchtigen aufgrund der zusätzlichen Verarbeitung ebenfalls die Leistung.

Sie können Primärschlüssel und sekundäre Indizes vor einer Volllast-Aufgabe erstellen, wenn Ihre Daten-Volumes relativ klein sind und die zusätzliche Migrationszeit nicht von Bedeutung ist. Einschränkungen bezüglich der referenziellen Integrität und Auslöser sollten immer deaktiviert werden.

Für eine Volllast-plus-CDC-Aufgabe empfehlen wir, dass Sie vor der CDC-Aufgabe sekundäre Indizes hinzufügen. Da AWS DMS logische Replikation verwendet, sollten sekundäre Indizes, die DML-Operationen unterstützen, vorhanden sein, um vollständige Tabellen-Scans zu verhindern. Sie können die Replikationsaufgabe vor der CDC-Phase anhalten, um Indizes und referenzielle Integritätsbeschränkungen zu erstellen, bevor Sie die Aufgabe neu starten.

Sie sollten Auslöser unmittelbar vor dem Cutover aktivieren.

Schalten Sie Backups und Transaktionsprotokollierung aus

Bei der Migration zu einer Amazon-RDS-Datenbank wird empfohlen, Sicherungen und Multi-AZ für das Ziel zu deaktivieren, bis Sie zum Cutover bereit sind. Auch wenn die Migration zu Systemen erfolgt, die keine Amazon-RDS-Systeme sind, sollten Sie bis zum Cutover jegliche Protokollierung auf dem Ziel deaktivieren.

Verwenden mehrerer Aufgaben

Manchmal lässt sich durch die Verwendung mehrerer Aufgaben für eine einzelne Migration die Leistung verbessern. Wenn Sie über Tabellensätze verfügen, die nicht an gängigen Transaktionen teilnehmen, können Sie Ihre Migration möglicherweise in mehrere Aufgaben aufteilen. Die Transaktionskonsistenz innerhalb einer Aufgabe wird gewahrt, daher ist es wichtig, dass Tabellen in separaten Aufgaben nicht an gemeinsamen Transaktionen beteiligt sind. Außerdem lesen alle Aufgaben den Transaktionsstrom unabhängig voneinander. Achten Sie also darauf, die Quelldatenbank nicht zu sehr zu belasten.

Sie können mehrere Aufgaben verwenden, um separate Replikations-Streams zu erstellen. Auf diese Weise können Sie die Lesevorgänge auf der Quelle, die Prozesse auf der Replikations-Instance und die Schreibvorgänge in der Zieldatenbank parallelisieren.

Optimieren der Verarbeitung von Änderungen

Standardmäßig verarbeitet AWS DMS Änderungen in einem transaktionalen Modus, bei dem die Integrität der Transaktionen gewahrt wird. Wenn Sie sich temporäre Ausfälle bei der Transaktionsintegrität leisten können, können Sie stattdessen die Option batch optimized apply verwenden. Bei dieser Option werden Transaktionen auf effiziente Weise gruppiert und in Stapeln angewendet, um die Effizienz zu erhöhen. Die Verwendung der Option „Batch optimized Apply“ verstößt fast immer gegen Einschränkungen der referenziellen Integrität. Wir empfehlen daher, diese Einschränkungen während des Migrationsprozesses zu deaktivieren und sie im Rahmen des Übergangsprozesses wieder zu aktivieren.

Verwenden Ihres eigenen Vor-Ort-Nameservers

Normalerweise verwendet eine AWS DMS-Replikations-Instance den Domain Name System (DNS)-Resolver in einer Amazon-EC2-Instance, um Domain-Endpunkte aufzulösen. Sie können jedoch Ihren eigenen On-Premises-Namensserver verwenden, um bestimmte Endpunkte aufzulösen, wenn Sie den Amazon-Route-53-Resolver verwenden. Mit diesem Tool können Sie Abfragen zwischen On-Premises-Systemen und AWS durchführen und eingehende und ausgehende Endpunkte, Weiterleitungsregeln und eine private Verbindung verwenden. Zu den Vorteilen der Verwendung eines On-Premises-Namensservers gehören verbesserte Sicherheit und Benutzerfreundlichkeit hinter einer Firewall.

Wenn Sie über eingehende Endpunkte verfügen, können Sie DNS-Abfragen verwenden, die ihren Ursprung On-Premises haben, um von AWS gehostete Domains aufzulösen. Die Endpunkte werden durch Zuweisung der IP-Adresse in jedem Subnetz konfiguriert, für das Sie einen Resolver bereitstellen möchten. Verwenden Sie AWS Direct Connect oder ein Virtual Private Network (VPN), um die Konnektivität zwischen Ihrer On-Premises-DNS-Infrastruktur und AWS herzustellen.

Ausgehende Endpunkte stellen eine Verbindung zu Ihrem On-Premises-Namensserver her. Der Namensserver gewährt nur Zugriff auf IP-Adressen, die in einer Zulassungsliste und in einem ausgehenden Endpunkt enthalten sind. Die IP-Adresse Ihres Nameservers ist die Ziel-IP-Adresse. Wenn Sie eine Sicherheitsgruppe für einen ausgehenden Endpunkt auswählen, wählen Sie dieselbe Sicherheitsgruppe, die von der Replikations-Instance verwendet wird.

Verwenden Sie Weiterleitungsregeln, um Domains auszuwählen, die an den Namensserver weitergeleitet werden sollen. Für einen ausgehenden Endpunkt können mehrere Weiterleitungsregeln vorhanden sein. Der Geltungsbereich der Weiterleitungsregel ist Ihre Virtual Private Cloud (VPC). Mithilfe einer mit einer VPC verknüpften Weiterleitungsregel können Sie einen logisch isolierten Bereich der AWS-Cloud bereitstellen. Von diesem logisch isolierten Bereich aus können Sie AWS-Ressourcen in einem virtuellen Netzwerk starten.

Domains, die in Ihrer On-Premises-DNS-Infrastruktur gehostet werden, können als bedingte Weiterleitungsregeln konfiguriert werden, die ausgehende DNS-Abfragen ermöglichen. Wenn eine Abfrage an eine dieser Domains durchgeführt wird, lösen die Regeln den Versuch aus, DNS-Anforderungen an DNS-Server weiterzuleiten, die mit den Regeln konfiguriert wurden. Auch hier ist eine private Verbindung über AWS Direct Connect oder VPN erforderlich.

Das folgende Diagramm zeigt die Route-53-Resolver-Architektur.

Weitere Informationen zu Route 53 DNS Resolver finden Sie unter Erste Schritte mit Route 53 Resolver im Entwicklerhandbuch zu Amazon Route 53.

Verwenden von Amazon Route 53 Resolver mit AWS DMS

Sie können einen On-Premises-Namensserver für AWS DMS zur Auflösung von Endpunkten mit Amazon Route 53 Resolver einrichten.

So erstellen Sie einen On-Premises-Namensserver für AWS DMS basierend auf Route 53

1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Route 53-Konsole unter https://console.aws.amazon.com/route53/.

2. Wählen Sie in der Route-53-Konsole die AWS-Region aus, in der Sie Ihren Route 53 Resolver konfigurieren möchten. Der Route 53 Resolver ist spezifisch für eine Region.

3. Wählen Sie die Abfragerichtung – eingehend, ausgehend oder beides.

4. Geben Sie Ihre Konfiguration für eingehende Abfragen an:

   1. Geben Sie einen Endpunktnamen ein und wählen Sie eine VPC.

   2. Weisen Sie ein oder mehrere Subnetze innerhalb der VPC zu (wählen Sie beispielsweise zwei für höhere Verfügbarkeit).

   3. Weisen Sie bestimmte IP-Adressen zu, die als Endpunkte verwendet werden sollen, oder lassen Sie diese durch Route 53 Resolver automatisch zuweisen.

5. Erstellen Sie eine Regel für Ihre lokale Domäne, damit Workloads innerhalb der VPC DNS-Abfragen an Ihre DNS-Infrastruktur weitergeleitet werden können.

6. Geben Sie eine oder mehrere IP-Adressen für Ihre On-Premises-DNS-Server ein.

7. Übermitteln Sie Ihre Regel.

Wenn alles erstellt wurdet, ist Ihre VPC mit Ihren eingehenden und ausgehenden Regeln verknüpft und kann mit dem Routing des Datenverkehrs beginnen.

Weitere Informationen zu Route 53 Resolver finden Sie unter Erste Schritte mit Route 53 Resolver im Entwicklerhandbuch zu Amazon Route 53.

Migrieren von Binary Large Objects (LOBs)

Im Allgemeinen migriert AWS DMS LOB-Daten in zwei Phasen:

1. AWS DMS erstellt eine neue Zeile in der Zieltabelle und füllt die Zeile mit allen Daten mit Ausnahme des zugehörigen LOB-Werts.

2. AWS DMS aktualisiert die Zeile in der Zieltabelle mit den LOB-Daten.

Dieser Migrationsvorgang für LOBs erfordert, dass alle LOB-Spalten in der Zieltabelle während der Migration nullwertfähig sein müssen. Dies gilt auch dann, wenn die LOB-Spalten in der Quelltabelle nicht nullwertfähig sind. Wenn AWS DMS die Zieltabellen erstellt, werden LOB-Spalten standardmäßig als löschbar festgelegt. In manchen Fällen können Sie die Zieltabellen mithilfe eines anderen Mechanismus wie Import oder Export erstellen. Stellen Sie in solchen Fällen sicher, dass die LOB-Spalten Null-Werte zulassen, bevor Sie die Migrationsaufgabe starten.

Für diese Anforderung gibt es eine Ausnahme. Angenommen, Sie führen eine homogene Migration von einer Oracle-Quelle zu einem Oracle-Ziel durch und wählen Limited Lob-Modus. In diesem Fall wird die gesamte Zeile auf einmal gefüllt, einschließlich aller LOB-Werte. In einem solchen Fall kann AWS DMS die LOB-Spalten der Zieltabelle bei Bedarf mit nicht löschbaren Einschränkungen erstellen.

Verwenden des begrenzten LOB-Modus

AWS DMS nutzt zwei Methoden, um Leistung und Benutzerfreundlichkeit gegeneinander abzuwägen, wenn Ihre Migration LOB-Werte enthält:

1. Mit Limited LOB-Modus (Begrenzter LOB-Modus) werden alle LOB-Werte bis zu einer vom Benutzer angegebenen Größe (Standard: 32 KB) migriert. LOB-Werte, die größer als das Größenlimit sind, müssen manuell migriert werden. Limited LOB mode (Begrenzter LOB-Modus), der Standard für alle Migrationsaufgaben, bietet in der Regel die beste Leistung. Sie müssen jedoch sicherstellen, dass die Einstellung des Parameters Max. LOB-Größe korrekt ist. Stellen Sie diesen Parameter sollte auf die maximale LOB-Größe für alle Ihre Tabellen ein.

2. Full LOB mode (Vollständiger LOB-Modus) migriert alle LOB-Daten in Ihren Tabellen unabhängig von der Größe. Full LOB mode (Vollständiger LOB-Modus) bietet die Möglichkeit, alle LOB-Daten in Ihren Tabellen zu verschieben, aber der Prozess kann die Leistung signifikant beeinträchtigen.

Bei einigen Datenbank-Engines, z. B. PostgreSQL, behandelt AWS DMS JSON-Datentypen wie LOBs. Stellen Sie sicher, dass bei Auswahl von Begrenzter LOB-Modus die Option Max. LOB-Größe auf einen Wert festgelegt ist, der nicht dazu führt, dass die JSON-Daten gekürzt werden.

AWS DMS bietet vollen Support für die Verwendung großer Objektdatentypen (BLOBs, CLOBs und NCLOBs). Für die folgenden Quellendpunkte werden LOBs uneingeschränkt unterstützt:

• Oracle

• Microsoft SQL Server

• ODBC

Für die folgenden Zielendpunkte werden LOBs uneingeschränkt unterstützt:

• Oracle

• Microsoft SQL Server

Der folgende Zielendpunkt verwendet eine eingeschränkte LOB-Unterstützung. Sie können keine unbegrenzte LOB-Größe für diesen Zielendpunkt verwenden.

• Amazon Redshift

• Amazon S3

Für Endpunkte mit uneingeschränkter LOB-Unterstützung können Sie auch eine Obergrenze für LOB-Datentypen festlegen.

Verbesserte LOB-Leistung

Bei der Migration von LOB-Daten können Sie die folgenden verschiedenen LOB-Optimierungseinstellungen angeben.

LOB-Einstellungen pro Tabelle

Mithilfe der LOB-Einstellungen pro Tabelle können Sie LOB-Einstellungen auf Aufgabenebene für einige oder alle Tabellen überschreiben. Definieren Sie dazu die lob-settings in Ihrer table-settings-Regel. Im Folgenden finden Sie eine Beispieltabelle, die einige große LOB-Werte enthält.

SET SERVEROUTPUT ON
CREATE TABLE TEST_CLOB
(
ID NUMBER,
C1 CLOB,
C2 VARCHAR2(4000)
);
DECLARE
bigtextstring CLOB := '123';
iINT;
BEGIN
WHILE Length(bigtextstring) <= 60000 LOOP
bigtextstring := bigtextstring || '000000000000000000000000000000000';
END LOOP;
INSERT INTO TEST_CLOB (ID, C1, C2) VALUES (0, bigtextstring,'AnyValue');
END;
/
SELECT * FROM TEST_CLOB;
COMMIT

Erstellen Sie dann eine Migrationsaufgabe und ändern Sie die LOB-Behandlung für Ihre Tabelle mithilfe der neuen lob-settings-Regel. Der bulk-max-siz-Wert bestimmt die maximale LOB-Größe (KB). Es wird gekürzt, wenn diese größer als die angegebene Größe ist.

{
	"rules": [{
			"rule-type": "selection",
			"rule-id": "1",
			"rule-name": "1",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"rule-action": "include"
		},
		{
			"rule-type": "table-settings",
			"rule-id": "2",
			"rule-name": "2",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"lob-settings": {
				"mode": "limited",
				"bulk-max-size": "16"
			}
		}
	]
}

Selbst wenn diese AWS DMS-Aufgabe mit FullLobMode : true erstellt wurde, weisen die LOB-Einstellungen pro Tabelle AWS DMS an, dass die LOB-Daten in dieser bestimmten Tabelle auf 16 000 gekürzt werden. Sie können dies anhand der Aufgabenprotokolle überprüfen.

721331968: 2018-09-11T19:48:46:979532 [SOURCE_UNLOAD] W: The value of column 'C' in table
'HR.TEST_CLOB' was truncated to length 16384

Inline-LOB-Einstellungen

Wenn Sie eine AWS DMS-Aufgabe erstellen, bestimmt der LOB-Modus, wie LOBs behandelt werden.

Der vollständige LOB-Modus und der eingeschränkte LOB-Modus haben jeweils ihre eigenen Vor- und Nachteile. Der Inline-LOB-Modus kombiniert die Vorteile des vollständigen LOB-Modus und des eingeschränkten LOB-Modus.

Sie können den Inline-LOB-Modus verwenden, wenn Sie sowohl kleine als auch große LOBs replizieren müssen und die meisten LOBs klein sind. Wenn Sie diese Option wählen, überträgt die AWS DMS-Aufgabe bei Volllast die kleinen LOBs inline, was effizienter ist. Die AWS DMS-Aufgabe überträgt die großen LOBs, indem sie eine Suche in der Quelltabelle durchführt.

Während der Änderungsverarbeitung werden sowohl kleine als auch große LOBs repliziert, indem eine Suche in der Quelltabelle durchgeführt wird.

Wenn Sie den Inline-LOB-Modus verwenden, überprüft die AWS DMS-Aufgabe alle LOB-Größen, um zu bestimmen, welche LOB-Größen inline übertragen werden sollen. LOBs, die größer als die angegebene Größe sind, werden im vollständigen LOB-Modus repliziert. Wenn Sie also wissen, dass die meisten LOBs größer als die angegebene Einstellung sind, ist es besser, diese Option nicht zu verwenden. Lassen Sie stattdessen eine unbegrenzte LOB-Größe zu.

Sie konfigurieren diese Option mithilfe eines Attributs in den Aufgabeneinstellungen, InlineLobMaxSize, das nur verfügbar ist, wenn FullLobMode auf true gesetzt ist. Der Standardwert für InlineLobMaxSize ist 0 und der Bereich liegt zwischen 1 und 102 400 Kilobyte (100 MB).

Sie könnten beispielsweise die folgenden AWS DMS-Aufgabeneinstellungen verwenden. Hier führt die Einstellung von InlineLobMaxSize auf einen Wert von 5 dazu, dass alle LOBs, die kleiner als oder gleich 5 KiB (5 120 Byte) sind, inline übertragen werden.

{
  "TargetMetadata": {
  "TargetSchema": "",
  "SupportLobs": true,
  "FullLobMode": true,
  "LobChunkSize": 64,
  "LimitedSizeLobMode": false,
  "LobMaxSize": 32,
  "InlineLobMaxSize": 5,
  "LoadMaxFileSize": 0,
  "ParallelLoadThreads": 0,
  "ParallelLoadBufferSize":0,
  "BatchApplyEnabled": false,
  "TaskRecoveryTableEnabled": false},
  . . .
}

Verbessern der Leistung beim Migrieren umfangreicher Tabellen mit Zeilenfilterung

Wenn Sie die Leistung beim Migrieren großer Tabellen verbessern möchten, können Sie die Migration in mehr als eine Aufgabe unterteilen. Sie können einen Schlüssel oder einen Partitionsschlüssel verwenden, um die Migration mittels Zeilenfilterung in mehrere Aufgaben aufzuteilen. Mit einer Ganzzahl-Primärschlüssel-ID von 1 bis 8.000.000 können Sie mittels Zeilenfilterung acht Aufgaben erstellen, um jeweils eine Million Datensätze zu migrieren.

So wenden Sie die Zeilenfilterung in der Konsole an:

1. Öffnen Sie die AWS Management Console.

2. Wählen Sie Aufgaben und erstellen Sie eine neue Aufgabe.

3. Wählen Sie die Registerkarte Tabellenzuordnungen aus und erweitern Sie Auswahlregeln.

4. Wählen Sie Neue Auswahlregel hinzufügen. Sie können dann einen Spaltenfilter mit der Bedingung „kleiner oder gleich“, „größer oder gleich“, „gleich“ oder einer Bereichsbedingung (zwischen zwei Werten) hinzufügen. Weitere Informationen zur Spaltenfilterung finden Sie unter Festlegen der Tabellenauswahl und der Transformationsregeln über die Konsole.

Alternativ können Sie bei einer großen Tabelle, die nach Datum partitioniert ist, Daten basierend auf dem Datum migrieren. Angenommen, Sie haben eine Tabelle nach Monat partitioniert und nur die Daten des aktuellen Monats werden aktualisiert. In diesem Fall können Sie für jede statische Monatspartition eine Volllastaufgabe und für die aktuell aktualisierte Partition eine Volllast-plus-CDC-Aufgabe erstellen.

Wenn Ihre Tabelle über einen einspaltigen Primärschlüssel oder einen eindeutigen Index verfügt, können Sie von Ihrer AWS DMS-Aufgabe die Tabelle segmentieren lassen, indem sie ein paralleles Laden des Typs „Bereiche“ verwendet, um die Daten parallel zu laden. Weitere Informationen finden Sie unter Regeln und Operationen für Tabellen- und Sammlungseinstellungen.

Fortlaufende Replikation

AWS DMS bietet eine fortlaufende Replikation von Daten, um die Synchronität der Quell- und Zieldatenbank aufrechtzuhalten. Es wird allerdings nur eine begrenzte Menge an DDL-Anweisungen (Data Definition Language) repliziert. AWS DMS verbreitet keine Elemente wie Indizes, Benutzer, Berechtigungen, gespeicherte Prozeduren und andere Datenbankänderungen, die sich nicht direkt auf die Tabellendaten beziehen.

Wenn Sie die fortlaufende Replikation verwenden möchten, sollten Sie die Option Multi-AZ bei der Erstellung Ihrer Replikations-Instance aktivieren. Die Option Multi-AZ bietet für die Replikations-Instance hohe Verfügbarkeit und Failover-Unterstützung. Diese Option kann sich jedoch auf die Leistung auswirken und die Replikation verlangsamen, während Änderungen auf das Zielsystem angewendet werden.

Bevor Sie Ihre Quell- oder Zieldatenbanken aktualisieren, empfehlen wir, dass Sie alle AWS DMS-Aufgaben beenden, die auf diesen Datenbanken ausgeführt werden. Setzen Sie die Aufgaben fort, nachdem Ihre Upgrades abgeschlossen sind.

Während der fortlaufenden Replikation ist es wichtig, die Netzwerkbandbreite zwischen Ihrem Quelldatenbanksystem und Ihrer AWS DMS-Replikations-Instance zu ermitteln. Stellen Sie sicher, dass das Netzwerk während der laufenden Replikation keine Engpässe verursacht.

Es ist auch wichtig, die Änderungsrate und die Generierung von Archivprotokollen pro Stunde auf Ihrem Quelldatenbanksystem zu ermitteln. Auf diese Weise können Sie sich einen Überblick über den Durchsatz verschaffen, den Sie bei fortlaufender Replikation erzielen können.

Reduzieren der Last Ihrer Quelldatenbank

AWS DMS nutzt einige Ressourcen in Ihrer Quelldatenbank. Während einer Aufgabe zum vollständigen Laden führt AWS DMS eine vollständige Tabellenprüfung der Quelltabelle parallel für jede verarbeitete Tabelle aus. Zudem fragt jede Aufgabe, die Sie als Teil einer Migration erstellen, die Quelldatenbank im Rahmen des CDC-Prozesses nach Änderungen ab. Bei einigen Quelldatenbanken, wie Oracle, müssen Sie möglicherweise die in das Änderungsprotokoll Ihrer Datenbanken geschriebene Datenmenge erhöhen, damit AWS DMS den CDC-Vorgang durchführen kann.

Wenn Sie feststellen, dass Ihre Quelldatenbank überlastet ist, können Sie die Anzahl der Aufgaben und/oder Tabellen pro Aufgabe für die Migration reduzieren. Da die einzelnen Aufgaben unabhängig voneinander Änderungen erhalten, kann die Änderungserfassungslast durch die Konsolidierung der Aufgaben verringert werden.

Reduzierung von Engpässen in Ihrer Zieldatenbank

Versuchen Sie während der Migration, alle Prozesse zu entfernen, die ggf. um die Schreibressourcen in Ihrer Zieldatenbank konkurrieren.

• Schalten Sie unnötige Auslöser aus.

• Schalten Sie sekundäre Indizes beim ersten Laden aus und aktivieren Sie sie später während der fortlaufenden Replikation wieder.

• Bei Amazon-RDS-Datenbanken empfiehlt es sich, Backups und Multi-AZ bis zum Cutover auszuschalten.

• Bei der Migration zu Nicht-RDS-Systemen sollten Sie jegliche Protokollierung auf dem Ziel bis zum Cutover deaktivieren.

Verwendung der Datenvalidierung während der Migration

Um sicherzustellen, dass Ihre Daten korrekt von der Quelle zum Ziel migriert werden, empfehlen wir nachdrücklich, Datenvalidierung zu verwenden. Wenn Sie die Datenvalidierung für eine Aufgabe aktivieren, vergleicht AWS DMS die Quell- und Zieldaten sofort, nachdem eine Tabelle vollständig geladen wurde.

Die Datenvalidierung funktioniert mit den folgenden Datenbanken dort, wo AWS DMS sie als Quell- und Ziel-Endpunkte unterstützt:

• Oracle

• PostgreSQL

• MySQL

• MariaDB

• Microsoft SQL Server

• Amazon Aurora MySQL-Compatible Edition

• Amazon Aurora PostgreSQL-Compatible Edition

• IBM Db2 (LUW)

• Amazon Redshift

Weitere Informationen finden Sie unter Datenvalidierung mit AWS DMS.

Überwachen Ihrer AWS DMS-Aufgaben mithilfe von Metriken

Sie haben mehrere Möglichkeiten, die Metriken für Ihre Aufgaben mithilfe der AWS DMS-Konsole zu überwachen:

Host-Metriken

Host-Metriken finden Sie auf der Registerkarte CloudWatch Metriken für jede bestimmte Replikations-Instance. Hier können Sie überwachen, ob Ihre Replikations-Instance die richtige Größe hat.

Metriken für die Replikationsaufgabe

Metriken für Replikationsaufgaben, einschließlich eingehender und festgeschriebener Änderungen, sowie die Latenz zwischen dem Replikationshost und Quell-/Zieldatenbanken finden Sie auf der Registerkarte CloudWatch Metriken für jede bestimmte Aufgabe.

Tabellenmetriken

Sie finden einzelne Tabellenmetriken auf der Registerkarte Tabellenstatistiken für jede einzelne Aufgabe. Zu diesen Metriken gehören die folgenden Zahlen:

• Zeilen, die während des Vollladevorgangs geladen wurden.

• Einfüge-, Aktualisierungs- und Löschvorgänge seit dem Start der Aufgabe.

• DDL-Operationen seit dem Start der Aufgabe.

Weitere Informationen zum Überwachen von Metriken finden Sie unter Überwachen von AWS-DMS-Aufgaben.

Ereignisse und Benachrichtigungen

AWS DMS verwendet Amazon SNS zum Bereitstellen von Benachrichtigungen, wenn ein AWS DMS-Ereignis auftritt, z. B. beim Erstellen oder Löschen einer Replikations-Instance. Sie können mit diesen Benachrichtigungen in jeder Form arbeiten, die von Amazon SNS für eine AWS-Region unterstützt wird. Dazu können E-Mail-Nachrichten, Textnachrichten oder Aufrufe an einen HTTP-Endpunkt gehören.

Weitere Informationen finden Sie unter Arbeiten mit Amazon-SNS-Ereignissen und Benachrichtigungen in AWS Database Migration Service.

Verwenden des Aufgabenprotokolls für die Behebung von Migrationsproblemen

In einigen Fällen kann AWS DMS auf Probleme stoßen, bei denen Warnungen oder Fehlermeldungen nur im Aufgabenprotokoll erscheinen. Insbesondere Probleme mit der Kürzung von Daten oder Ablehnung von Zeilen aufgrund von Fremdschlüsselverstößen werden nur in das Aufgabenprotokoll geschrieben. Daher ist es wichtig, das Aufgabenprotokoll bei einer Datenbankmigration zu überprüfen. Um das Aufgabenprotokoll anzuzeigen, konfigurieren Sie Amazon CloudWatch als Teil der Aufgabenerstellung.

Weitere Informationen finden Sie unter Überwachen von Replikationsaufgaben mit Amazon CloudWatch.

Problembehandlung bei Replikationsaufgaben mit Time Travel

Um AWS DMS-Migrationsprobleme zu beheben, können Sie mit Time Travel arbeiten. Weitere Informationen zu Time Travel finden Sie unter Time-Travel-Aufgabeneinstellungen.

Seien Sie sich der folgenden Überlegungen bewusst, wenn Sie mit Time Travel arbeiten:

• Um zu hohe Belastung für eine DMS-Replikations-Instance zu vermeiden, aktivieren Sie Time Travel nur für Aufgaben, die Debugging benötigen.

• Wenn Sie Time Travel zur Fehlerbehebung bei Replikationsaufgaben verwenden, die möglicherweise mehrere Tage dauern, sollten Sie die Metriken der Replikations-Instance im Hinblick auf den Ressourcenaufwand überwachen. Dieses Konzept eignet sich insbesondere für Fälle, in denen Quelldatenbanken über einen längeren Zeitraum mit hohen Transaktionslasten belastet werden. Weitere Details finden Sie unter Überwachen von AWS-DMS-Aufgaben.

• Ist die Einstellung EnableRawData der Time-Travel-Aufgabe auf true gesetzt, ist die Auslastung des Aufgabenspeichers während der DMS-Replikation möglicherweise höher als wenn Time Travel nicht aktiviert ist. Wenn Sie Time Travel für längere Zeiträume aktivieren, überwachen Sie Ihre Aufgabe.

• Derzeit können Sie Time Travel nur auf Aufgabenebene aktivieren. Änderungen an allen Tabellen werden in Time-Travel-Protokollen protokolliert. Wenn Sie Probleme mit bestimmten Tabellen in einer Datenbank mit hohem Transaktionsvolumen beheben möchten, erstellen Sie eine separate Aufgabe.

Ändern des Benutzers und des Schemas für ein Oracle-Ziel

Wenn Sie Oracle als Ziel verwenden, migriert AWS DMS die Daten zu dem Schema, das im Besitz des Zielendpunkt-Benutzers ist.

Nehmen Sie zum Beispiel an, dass Sie ein Schema mit dem Namen PERFDATA zu einem Oracle-Zielendpunkt migrieren und der Benutzername des Zielendpunktes MASTER ist. AWS DMS stellt eine Verbindung mit dem Oracle-Ziel als MASTER her und füllt das MASTER-Schema mit Datenbankobjekten von PERFDATA.

Um dieses Verhalten zu übergehen, müssen Sie eine Schematransformation bereitstellen. Wenn Sie beispielsweise die PERFDATA-Schemaobjekte zu einem PERFDATA-Schema am Zielendpunkt migrieren möchten, können Sie die folgende Transformation verwenden.

{
    "rule-type": "transformation",
    "rule-id": "2",
    "rule-name": "2",
    "object-locator": {
        "schema-name": "PERFDATA"
    },
    "rule-target": "schema",
    "rule-action": "rename",
    "value": "PERFDATA"
}

Weitere Informationen zu Umwandlungen finden Sie unter Festlegen der Tabellenauswahl- und Transformationsregeln mit JSON.

Ändern von Tabellen- und Index-Tabellenräumen für ein Oracle-Ziel

Wenn Oracle als Ziel verwendet wird, migriert AWS DMS alle Tabellen und Indizes zum Standardtabellenraum auf dem Ziel. Nehmen Sie beispielsweise an, dass Ihre Quelle eine andere Datenbank-Engine als Oracle ist. Alle Zieltabellen und Indizes werden zum selben Standard-Tabellenräumen migriert.

Um dieses Verhalten zu übergehen, müssen Sie entsprechende Transformationen von Tabellenräumen bereitstellen. Nehmen Sie beispielsweise an, dass Sie Tabellen und Indizes zu Tabellen- und Index-Tabellenräumen im Oracle-Ziel migrieren möchten, die nach dem Schema in der Quelle benannt sind. In diesem Fall können Sie Transformationen verwenden, die den folgenden ähnlich sind. Hier hat das Schema an der Quelle den Namen INVENTORY und die entsprechenden Tabellen- und Index-Tabellenräume im Ziel haben die Namen INVENTORYTBL und INVENTORYIDX.

{
   "rule-type": "transformation",
   "rule-id": "3",
   "rule-name": "3",
   "rule-action": "rename",
   "rule-target": "table-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "table-tablespace-name": "%"
   },
   "value": "INVENTORYTBL"
},
{
   "rule-type": "transformation",
   "rule-id": "4
   "rule-name": "4",
   "rule-action": "rename",
   "rule-target": "index-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "index-tablespace-name": "%"
   },
   "value": "INVENTORYIDX"
}

Weitere Informationen zu Umwandlungen finden Sie unter Festlegen der Tabellenauswahl- und Transformationsregeln mit JSON.

Wenn Oracle sowohl Quelle als auch Ziel ist, können Sie vorhandene Tabellen- oder Index-Tabellenraum-Zuweisungen beibehalten, indem Sie das zusätzliche Verbindungsattribut für Oracle Source, enableHomogenousTablespace=true, festlegen. Weitere Informationen finden Sie unter Endpunkteinstellungen bei Verwendung von Oracle als Quelle für AWS DMS.

Aktualisieren der Engine-Version einer Replikations-Instance

AWS veröffentlicht regelmäßig neue Versionen der AWS DMS-Replikations-Engine-Software mit neuen Funktionen und Leistungsverbesserungen. Jede Version der Replikations-Engine-Software verfügt über eine eigene Versionsnummer. Es ist wichtig, die vorhandene Version Ihrer AWS DMS-Replikations-Instance zu testen, auf der eine Produktionslast ausgeführt wird, bevor Sie Ihre Replikations-Instance auf eine neuere Version aktualisieren. Weitere Informationen zu automatischen Versions-Upgrades finden Sie unter AWS DMS-Versionshinweise.

Grundlegendes zu Ihren Migrationskosten

AWS Database Migration Service unterstützt Sie bei der einfachen und sicheren Migration zu AWS zu niedrigen Kosten. Sie zahlen nur für Ihre Replikations-Instances und zusätzlichen Protokollspeicher. Jede Datenbank-Migrations-Instance beinhaltet ausreichend Speicherplatz für Auslagerungsspeicher, Replikationsprotokolle und Daten-Cache für die meisten Replikationen. Die eingehende Datenübertragung ist kostenlos.

Möglicherweise benötigen Sie beim ersten Laden oder während der Spitzenlastzeit mehr Ressourcen. Mithilfe von CloudWatch-Metriken können Sie die Ressourcenauslastung der Replikations-Instance genau überwachen. Anschließend können Sie die Größe der Replikations-Instance je nach Nutzung hoch- und herunterskalieren.

Weitere Informationen zur Schätzung Ihrer Migrationskosten finden Sie unter:

• AWS Database Migration Service-Preise

• AWS Pricing Calculator