Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

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:

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:

Verbessern der Leistung einer AWS DMS-Migration

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

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:

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.

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:

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:

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:

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

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

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.

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.

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:

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:

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:

Ä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: