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.
# Fehlerbehebung bei Migrationsaufgaben in AWS Database Migration Service
Im Folgenden finden Sie Themen zur Behebung von Problemen mit dem AWS Database Migration Service (AWS DMS). Diese Themen können Ihnen helfen, häufig auftretende Probleme bei der Verwendung von Endpunktdatenbanken AWS DMS und ausgewählten Endpunktdatenbanken zu lösen.
Wenn Sie einen AWS Support-Fall eröffnet haben, identifiziert Ihr Support-Techniker möglicherweise ein potenzielles Problem mit einer Ihrer Endpunktdatenbankkonfigurationen. Der Techniker bittet Sie möglicherweise außerdem, ein Support-Skript auszuführen, um Diagnoseinformationen zu Ihrer Datenbank zu erhalten. Einzelheiten zum Herunterladen, Ausführen und Hochladen der Diagnoseinformationen aus dieser Art von Support-Skript finden Sie unter [Arbeiten mit Skripten zur Diagnoseunterstützung in AWS DMS](CHAP_SupportScripts.md).
AWS DMS Sammelt zur Fehlerbehebung Trace- und Dumpdateien in der Replikationsinstanz. Sie können diese Dateien dem AWS Support zur Verfügung stellen, falls ein Problem auftritt, das eine Fehlerbehebung erfordert. Standardmäßig löscht DMS Trace- und Dumpdateien, die älter als dreißig Tage sind. Wenn Sie die Erfassung von Trace- und Dump-Dateien deaktivieren möchten, wenden Sie sich an den AWS Support.
**Topics**
+ [Migrationsaufgaben werden langsam ausgeführt](#CHAP_Troubleshooting.General.SlowTask)
+ [Die Statusleiste der Aufgabe bewegt sich nicht](#CHAP_Troubleshooting.General.StatusBar)
+ [Die Aufgabe ist abgeschlossen, aber es wurde nichts migriert](#CHAP_Troubleshooting.General.NothingMigrated)
+ [Fremdschlüssel und sekundäre Indizes fehlen](#CHAP_Troubleshooting.General.MissingSecondaryObjs)
+ [AWS DMS erstellt keine Protokolle CloudWatch](#CHAP_Troubleshooting.General.CWL)
+ [Bei der Verbindung mit Amazon RDS treten Probleme auf](#CHAP_Troubleshooting.General.RDSConnection)
+ [Es treten Netzwerkprobleme auf](#CHAP_Troubleshooting.General.Network)
+ [CDC ist nach Volllast hängen geblieben](#CHAP_Troubleshooting.General.CDCStuck)
+ [Fehler durch Primärschlüsselverletzung beim Neustart einer Aufgabe](#CHAP_Troubleshooting.General.PKErrors)
+ [Erstes Laden des Schemas fehlgeschlagen](#CHAP_Troubleshooting.General.SchemaLoadFail)
+ [Aufgaben mit unbekanntem Fehler fehlgeschlagen](#CHAP_Troubleshooting.General.TasksFail)
+ [Bei erneutem Laden der Aufgabe werden Tabellen von Beginn an geladen](#CHAP_Troubleshooting.General.RestartLoad)
+ [Die Anzahl der Tabellen pro Aufgabe verursacht Probleme](#CHAP_Troubleshooting.General.TableLimit)
+ [Aufgaben schlagen fehl, wenn ein Primärschlüssel in der LOB-Spalte erstellt wird](#CHAP_Troubleshooting.General.PKLOBColumn)
+ [Doppelte Datensätze in einer Zieltabelle ohne Primärschlüssel](#CHAP_Troubleshooting.General.DuplicateRecords)
+ [Quellendpunkte fallen in den reservierten IP-Bereich](#CHAP_Troubleshooting.General.ReservedIP)
+ [Zeitstempel sind in Amazon-Athena-Abfragen unleserlich](#CHAP_Troubleshooting.General.GarbledTimestamps)
+ [Fehlersuche bei Verwendung von Oracle](#CHAP_Troubleshooting.Oracle)
+ [Fehlersuche bei Verwendung von MySQL](#CHAP_Troubleshooting.MySQL)
+ [Fehlersuche bei Verwendung von PostgreSQL](#CHAP_Troubleshooting.PostgreSQL)
+ [Fehlersuche bei Verwendung von Microsoft SQL Server](#CHAP_Troubleshooting.SQLServer)
+ [Fehlersuche bei Verwendung von Amazon Redshift](#CHAP_Troubleshooting.Redshift)
+ [Fehlersuche bei Verwendung von Amazon Aurora MySQL](#CHAP_Troubleshooting.Aurora)
+ [Fehlersuche bei Verwendung von SAP ASE](#CHAP_Troubleshooting.SAP)
+ [Fehlersuche bei Verwendung von IBM Db2](#CHAP_Troubleshooting.Db2)
+ [Die Tabelle hat eine Tabelle mit dem Fehler „Die Anweisung 'where' konnte nicht erstellt werden“ gesperrt](#CHAP_Troubleshooting.table.suspended)
+ [Behebung von Latenzproblemen in AWS Database Migration Service](CHAP_Troubleshooting_Latency.md)
+ [Arbeiten mit Skripten zur Diagnoseunterstützung in AWS DMS](CHAP_SupportScripts.md)
+ [Arbeiten mit dem AWS DMS Diagnosesupport AMI](CHAP_SupportAmi.md)
## Migrationsaufgaben werden langsam ausgeführt
Verschiedene Probleme können dazu führen, dass eine Migrationsaufgabe langsam ausgeführt wird oder dass nachfolgende Aufgaben langsamer ausgeführt werden als die erste Aufgabe.
Der häufigste Grund dafür, dass eine Migrationsaufgabe langsam ausgeführt wird, ist, dass der AWS DMS Replikationsinstanz nicht genügend Ressourcen zugewiesen sind. Überprüfen Sie die Nutzung von CPU, Arbeitsspeicher, Swap-Dateien und IOPS durch Ihre Replikations-Instance, um sicherzustellen, dass die Instance über ausreichend Ressourcen für die ausgeführte Aufgabe verfügt. Beispielsweise sind mehrere Aufgaben mit Amazon Redshift als Endpunkt I/O intensiv. Sie können die IOPS für Ihre Replikations-Instance erhöhen oder Ihre Aufgaben über mehrere Replikations-Instances verteilen, um die Migration effizienter zu gestalten.
Weitere Informationen zur Bestimmung der Größe Ihrer Replikations-Instance finden Sie unter [Auswahl der besten Größe für eine Replikations-Instance](CHAP_BestPractices.SizingReplicationInstance.md).
Sie können die Geschwindigkeit eines ersten Ladevorgangs bei einer Migration wie folgt erhöhen:
+ Wenn Ihr Ziel eine DB-Instance von Amazon RDS ist, stellen Sie sicher, dass Multi-AZ nicht für die DB-Ziel-Instance aktiviert ist.
+ Deaktivieren Sie alle automatischen Backups oder Protokollierungen für die Zieldatenbank während des Ladevorgangs und aktivieren Sie sie wieder, wenn die Migration abgeschlossen ist.
+ Verwenden Sie bereitgestellte IOPS, sofern dieses Feature für Ihr Ziel verfügbar ist.
+ Wenn Ihre Migrationsdaten Folgendes enthalten LOBs, stellen Sie sicher, dass die Aufgabe für die LOB-Migration optimiert ist. Weitere Informationen zur Optimierung für finden Sie LOBs unter[Ziel-Metadaten-Aufgabeneinstellungen](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md).
## Die Statusleiste der Aufgabe bewegt sich nicht
Die Aufgabenstatusleiste bietet eine Schätzung des Fortschritts der Aufgabe. Die Qualität dieser Schätzung hängt von der Qualität der Tabellenstatistik der Quelldatenbank ab. Je besser die Tabellenstatistik, desto genauer die Schätzung.
Für eine Aufgabe mit nur einer Tabelle, die keine geschätzte Zeilenstatistik hat, AWS DMS kann keine vollständige Schätzung in Prozent angegeben werden. Überprüfen Sie in diesem Fall anhand des Aufgabenstatus und der Angabe der geladenen Zeilen, ob die Aufgabe tatsächlich ausgeführt wird und Fortschritte macht.
## Die Aufgabe ist abgeschlossen, aber es wurde nichts migriert
Gehen Sie wie folgt vor, wenn nach Abschluss Ihrer Aufgabe nichts migriert wurde.
+ Überprüfen Sie, ob der Benutzer, der den Endpunkt erstellt hat, Lesezugriff auf die Tabelle hat, die Sie migrieren möchten.
+ Überprüfen Sie, ob es sich bei dem Objekt, das Sie migrieren möchten, um eine Tabelle handelt. Wenn es sich um eine Ansicht handelt, aktualisieren Sie die Tabellenzuordnungen und geben Sie den Objekt-Locator als „Ansicht“ oder „Alle“ an. Weitere Informationen finden Sie unter [Festlegen der Tabellenauswahl und der Transformationsregeln über die Konsole](CHAP_Tasks.CustomizingTasks.TableMapping.Console.md).
## Fremdschlüssel und sekundäre Indizes fehlen
AWS DMS erstellt Tabellen, Primärschlüssel und in einigen Fällen eindeutige Indizes, aber es werden keine anderen Objekte erstellt, die für eine effiziente Migration der Daten aus der Quelle nicht erforderlich sind. So erstellt DMS z. B. keine sekundären Indizes, Nicht-Primärschlüssel-Beschränkungen oder Datenstandardwerte.
Um sekundäre Objekte von der Datenbank zu migrieren, verwenden Sie die nativen Tools der Datenbank, wenn Sie die Migration auf derselben Datenbank-Engine wie Ihre Quelldatenbank durchführen. Verwenden Sie das AWS Schema Conversion Tool (AWS SCT), wenn Sie die Migration auf eine andere Datenbank-Engine durchführen als die, die von Ihrer Quelldatenbank für die Migration sekundärer Objekte verwendet wird.
## AWS DMS erstellt keine Protokolle CloudWatch
Wenn Ihre Replikationsaufgabe keine CloudWatch Protokolle erstellt, stellen Sie sicher, dass Ihr Konto die `dms-cloudwatch-logs-role` Rolle hat. Wenn diese Rolle nicht vorhanden ist, erstellen Sie sie wie folgt:
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Wählen Sie die Registerkarte **Rollen** aus. Wählen Sie **Rolle erstellen** aus.
1. Wählen Sie im Abschnitt **Typ der vertrauenswürdigen Entität auswählen** die Option **AWS-Service** aus.
1. Wählen Sie im Abschnitt **Wählen Sie einen Anwendungsfall aus** **DMS** aus.
1. Wählen Sie **Weiter: Berechtigungen** aus.
1. Geben Sie es **AmazonDMSCloudWatchLogsRole** in das Suchfeld ein und aktivieren Sie das Kästchen neben **Amazon DMSCloud WatchLogsRole**. Dadurch werden AWS DMS Zugriffsberechtigungen erteilt CloudWatch.
1. Wählen Sie **Next: Tags** (Weiter: Tags) aus.
1. Klicken Sie auf **Weiter: Prüfen**.
1. Geben Sie für **Rollenname** **dms-cloudwatch-logs-role** ein. Bei diesem Namen wird zwischen Groß- und Kleinschreibung unterschieden.
1. Wählen Sie **Rolle erstellen** aus.
**Anmerkung**
Wenn Ihr Konto Teil von AWS Organizations ist, stellen Sie sicher, dass die Service Control-Richtlinien (SCPs) Ihre IAM-Rollenberechtigungen nicht einschränken. SCPs kann IAM-Rollenberechtigungen überschreiben und einschränken, selbst wenn sie ordnungsgemäß konfiguriert sind.
## Bei der Verbindung mit Amazon RDS treten Probleme auf
Es kann verschiedene Gründe dafür geben, dass Sie keine Verbindung mit einer DB-Instance von Amazon RDS herstellen können, die Sie als Quelle oder Ziel festgelegt haben. Folgende Punkte sollten Sie überprüfen:
+ Stellen Sie sicher, dass die Kombination aus Benutzername und Passwort korrekt ist.
+ Stellen Sie sicher, dass der Endpunktwert, der in der Amazon-RDS-Konsole für die Instance angezeigt wird, mit der Endpunktkennung übereinstimmt, die Sie zum Erstellen des AWS DMS -Endpunkts verwendet haben.
+ Stellen Sie sicher, dass der in der Amazon-RDS-Konsole für die Instance angezeigte Port-Wert mit dem Port übereinstimmt, der dem AWS DMS -Endpunkt zugewiesen ist.
+ Stellen Sie sicher, dass die der Amazon RDS-DB-Instance zugewiesene Sicherheitsgruppe Verbindungen von der AWS DMS -Replikations-Instance zulässt.
+ Wenn sich die AWS DMS Replikationsinstanz und die Amazon RDS-DB-Instance nicht in derselben Virtual Private Cloud (VPC) befinden, überprüfen Sie, ob die DB-Instance öffentlich zugänglich ist.
### Fehlermeldung: Falsche Thread-Verbindungszeichenfolge: Falscher Thread-Wert 0
Dieser Fehler kann häufig auftreten, wenn Sie die Verbindung zu einem Endpunkt testen. Diese Fehlermeldung weist auf einen Fehler in der Verbindungszeichenfolge hin. Ein Beispiel ist ein Leerzeichen nach der Host-IP-Adresse. Ein anderes Beispiel ist ein fehlerhaftes Zeichen, das in die Verbindungszeichenfolge kopiert wurde.
## Es treten Netzwerkprobleme auf
Das häufigste Netzwerkproblem betrifft die VPC-Sicherheitsgruppe, die von der AWS DMS -Replikations-Instance verwendet wird. Standardmäßig verfügt diese Sicherheitsgruppe über Regeln, die ausgehenden Datenverkehr zu 0.0.0.0/0 auf allen Ports zulassen. In vielen Fällen ändern Sie diese Sicherheitsgruppe oder verwenden Ihre eigene Sicherheitsgruppe. Wenn dies der Fall ist, stellen Sie zumindest sicher, dass die Quell- und Zielendpunkte über ihre jeweiligen Datenbankports ausgehenden Datenverkehr erhalten.
Weitere Probleme im Zusammenhang mit der Konfiguration können Folgendes umfassen:
+ **Replikations-Instance sowie Quell- und Zielendpunkt in derselben VPC** – Die von den Endpunkten verwendete Sicherheitsgruppe muss eingehenden Datenverkehr am Datenbankport von der Replikations-Instance zulassen. Stellen Sie sicher, dass die von der Replikations-Instance verwendete Sicherheitsgruppe Zugang zu den Endpunkten hat. Sie können auch eine Regel in der von den Endpunkten verwendeten Sicherheitsgruppe erstellen, die der privaten IP-Adresse der Replikations-Instance den Zugriff erlaubt.
+ **Der Quellendpunkt befindet sich außerhalb der von der Replikations-Instance verwendeten VPC (über Internet-Gateway).** – Die VPC-Sicherheitsgruppe muss über Routing-Regeln verfügen, die Datenverkehr, der nicht für die VPC bestimmt ist, an das Internet-Gateway senden. In dieser Konfiguration scheint es, dass die Verbindung zum Endpunkt von der öffentlichen IP-Adresse auf der Replikations-Instance kommt.
+ **Der Quellendpunkt befindet sich außerhalb der von der Replikations-Instance verwendeten VPC (über NAT-Gateway).** – Sie können ein Network Address Translation (NAT)-Gateway mit einer einzelnen Elastic-IP-Adresse konfigurieren, die an eine einzelne Elastic-Network-Schnittstelle gebunden ist. Dieses NAT-Gateway empfängt eine NAT-Kennung (nat-\$1\$1\$1\$1\$1).
Unter Umständen enthält die VPC eine Standardroute zu diesem NAT-Gateway anstelle des Internet-Gateways. In solchen Fällen scheint die Replikations-Instance stattdessen den Datenbankendpunkt über die öffentliche IP-Adresse des NAT-Gateways zu kontaktieren. Dann muss der Eingang zum Datenbankendpunkt außerhalb der VPC den Eingang von der NAT-Adresse anstatt von der öffentlichen IP-Adresse der Replikations-Instance erlauben.
Informationen zur Verwendung Ihres eigenen On-Premises-Nameservers finden Sie unter [Verwenden Ihres eigenen Vor-Ort-Nameservers](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver).
## CDC ist nach Volllast hängen geblieben
Langsame oder hängen gebliebene Replikationsänderungen können nach einem vollständigen Migrationsladevorgang auftreten, wenn mehrere AWS DMS -Einstellungen miteinander in Konflikt stehen.
Nehmen wir beispielsweise an, dass der Parameter **Zieltabellen-Vorbereitungsmodus** auf **Nichts unternehmen** oder **Kürzen** gesetzt ist. In diesem Fall haben Sie angewiesen, keine Einrichtung AWS DMS für die Zieltabellen vorzunehmen, einschließlich der Erstellung primärer und eindeutiger Indizes. Wenn Sie keine primären oder eindeutigen Schlüssel für die Zieltabellen erstellt haben, wird bei jedem AWS DMS Update ein vollständiger Tabellenscan durchgeführt. Dadurch kann die Leistung erheblich beeinträchtigt werden.
## Fehler durch Primärschlüsselverletzung beim Neustart einer Aufgabe
Dieser Fehler kann auftreten, wenn Daten von einer vorherigen Migrationsaufgabe in der Zieldatenbank verbleiben. Wenn die Option **Zieltabellenvorbereitungsmodus** auf „**Nichts tun**“ gesetzt ist, werden AWS DMS keine Vorbereitungen an der Zieltabelle vorgenommen, einschließlich der Bereinigung von Daten, die aus einer vorherigen Aufgabe eingefügt wurden.
Um Ihre Aufgabe erneut zu starten und diese Fehler zu vermeiden, müssen Sie die in die Zieltabellen eingefügten Zeilen aus der vorherigen Aufgabenausführung entfernen.
## Erstes Laden des Schemas fehlgeschlagen
Unter Umständen schlägt das erste Laden Ihrer Schemas möglicherweise mit dem Fehler `Operation:getSchemaListDetails:errType=, status=0, errMessage=, errDetails=` fehl.
In solchen Fällen verfügt das Benutzerkonto, das für die AWS DMS Verbindung mit dem Quellendpunkt verwendet wird, nicht über die erforderlichen Berechtigungen.
## Aufgaben mit unbekanntem Fehler fehlgeschlagen
Unbekannte Fehler können verschiedene Ursachen haben. Oft stellen wir jedoch fest, dass das Problem darin besteht, dass der AWS DMS Replikationsinstanz nicht genügend Ressourcen zugewiesen sind.
Überprüfen Sie die Nutzung von CPU, Arbeitsspeicher, Swap-Dateien und IOPS durch Ihre Replikations-Instance, um sicherzustellen, dass Ihre Instance über ausreichend Ressourcen für die Migration verfügt. Weitere Informationen zur Überwachung finden Sie unter [AWS Database Migration Service Metriken](CHAP_Monitoring.md#CHAP_Monitoring.Metrics).
## Bei erneutem Laden der Aufgabe werden Tabellen von Beginn an geladen
AWS DMS startet das Laden der Tabelle von Anfang an neu, wenn das anfängliche Laden einer Tabelle noch nicht abgeschlossen ist. Wenn eine Aufgabe neu gestartet wird, werden die Tabellen von Anfang an AWS DMS neu geladen, wenn der erste Ladevorgang nicht abgeschlossen wurde.
## Die Anzahl der Tabellen pro Aufgabe verursacht Probleme
Es gibt keine festgelegte Begrenzung für die Anzahl der Tabellen pro Replikationsaufgabe. Als Faustregel empfehlen wir jedoch, die Anzahl der Tabellen in einer Aufgabe auf weniger als 60 000 zu begrenzen. Die Ressourcennutzung wird oft zum Engpass, wenn eine einzige Aufgabe mehr als 60.000 Tabellen verwendet.
## Aufgaben schlagen fehl, wenn ein Primärschlüssel in der LOB-Spalte erstellt wird
Unterstützt im Modus FULL LOB oder LIMITED LOB AWS DMS keine Replikation von Primärschlüsseln, bei denen es sich um LOB-Datentypen handelt.
DMS migriert zunächst eine Zeile mit einer LOB-Spalte als Null und aktualisiert später die LOB-Spalte. Wenn der Primärschlüssel in einer LOB-Spalte erstellt wird, schlägt daher die anfängliche Einfügung fehl, da der Primärschlüssel nicht null sein darf. Fügen Sie zur Umgehung des Problems eine weitere Spalte als Primärschlüssel hinzu und entfernen Sie den Primärschlüssel aus der LOB-Spalte.
## Doppelte Datensätze in einer Zieltabelle ohne Primärschlüssel
Das Ausführen einer Volllast- und CDC-Aufgabe kann zu doppelten Datensätzen in Zieltabellen führen, die keinen Primärschlüssel oder eindeutigen Index haben. Um das Duplizieren von Datensätzen in Zieltabellen bei Volllast- und-CDC-Aufgaben zu vermeiden, stellen Sie sicher, dass die Zieltabellen über einen Primärschlüssel oder einen eindeutigen Index verfügen.
## Quellendpunkte fallen in den reservierten IP-Bereich
Wenn eine AWS DMS Quelldatenbank eine IP-Adresse innerhalb des reservierten IP-Bereichs 192.168.0.0/24 verwendet, schlägt der Verbindungstest für den Quellendpunkt fehl. Die folgenden Schritte stellen eine mögliche Umgehung des Problems dar:
1. Suchen Sie eine Amazon-EC2-Instance, die sich nicht im reservierten Bereich befindet und unter 192.168.0.0/24 mit der Quelldatenbank kommunizieren kann.
1. Installieren Sie einen Socat-Proxy und führen Sie ihn aus. Es folgt ein Beispiel.
```
yum install socat
socat -d -d -lmlocal2 tcp4-listen:database port,bind=0.0.0.0,reuseaddr,fork tcp4:source_database_ip_address:database_port
&
```
Verwenden Sie die IP-Adresse der Amazon-EC2-Instance und den oben angegebenen Datenbank-Port für den AWS DMS -Endpunkt. Stellen Sie sicher, dass der Endpunkt über die Sicherheitsgruppe verfügt, die den Zugriff auf AWS DMS den Datenbankport ermöglicht. Beachten Sie, dass der Proxy für die Dauer der Ausführung Ihrer DMS-Aufgabe aktiv sein muss. Je nach Anwendungsfall müssen Sie möglicherweise das Proxy-Setup automatisieren.
## Zeitstempel sind in Amazon-Athena-Abfragen unleserlich
Wenn Zeitstempel in Athena-Abfragen unleserlich sind, verwenden Sie die [ModifyEndpoint](https://docs.aws.amazon.com/dms/latest/APIReference/API_ModifyEndpoint.html)Aktion AWS-Managementkonsole oder, um den `parquetTimestampInMillisecond` Wert für Ihren Amazon S3 S3-Endpunkt auf festzulegen. `true` Weitere Informationen finden Sie unter [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html).
## Fehlersuche bei Verwendung von Oracle
Im Folgenden erfahren Sie mehr über die Behebung von Problemen, die speziell bei der Verwendung AWS DMS mit Oracle-Datenbanken auftreten.
**Topics**
+ [Abrufen von Daten aus Ansichten](#CHAP_Troubleshooting.Oracle.Views)
+ [Migration LOBs von Oracle 12c](#CHAP_Troubleshooting.Oracle.12cLOBs)
+ [Zwischen Oracle LogMiner und Binary Reader wechseln](#CHAP_Troubleshooting.Oracle.LogMinerBinaryReader)
+ [Fehler: Oracle CDC angehalten 122301 Oracle CDC maximale Wiederholversuche überschritten.](#CHAP_Troubleshooting.Oracle.CDCStopped)
+ [Automatisches Hinzufügen der zusätzlichen Protokollierung zu einem Oracle-Quellendpunkt](#CHAP_Troubleshooting.Oracle.AutoSupplLogging)
+ [LOB-Änderungen werden nicht erfasst](#CHAP_Troubleshooting.Oracle.LOBChanges)
+ [Fehler: ORA-12899: Wert zu groß für Spalte *column-name*](#CHAP_Troubleshooting.Oracle.ORA12899)
+ [Datentyp NUMBER wird nicht richtig interpretiert](#CHAP_Troubleshooting.Oracle.Numbers)
+ [Datensätze fehlen bei Volllast](#CHAP_Troubleshooting.Oracle.RecordsMissing)
+ [Table Error](#CHAP_Troubleshooting.Oracle.TableError)
+ [Fehler: Cannot retrieve Oracle archived Redo log destination ids](#CHAP_Troubleshooting.Oracle.RedoLogError)
+ [Bewertung der Leseleistung von Oracle-Redo- oder -Archivprotokollen](#CHAP_Troubleshooting.Oracle.ReadPerformUtil)
+ [LOB-Daten konnten nicht abgerufen werden](#CHAP_Troubleshooting.Oracle.LOBdata)
### Abrufen von Daten aus Ansichten
Sie können Daten aus einer Ansicht einmal abrufen; Sie können sie nicht für die laufende Replikation verwenden. Um Daten aus Ansichten extrahieren zu können, müssen Sie den folgenden Code im Abschnitt **Endpunkteinstellungen** auf der Seite zum Oracle-Quellendpunkt hinzufügen. Wenn Sie Daten aus einer Ansicht extrahieren, wird die Ansicht im Zielschema als Tabelle angezeigt.
```
"ExposeViews": true
```
### Migration LOBs von Oracle 12c
AWS DMS kann zwei Methoden verwenden, um Änderungen an einer Oracle-Datenbank zu erfassen: Binary Reader und Oracle. LogMiner AWS DMS Verwendet standardmäßig Oracle, LogMiner um Änderungen zu erfassen. In Oracle 12c unterstützt Oracle jedoch LogMiner keine LOB-Spalten. Um Änderungen an LOB-Spalten unter Oracle 12c zu erfassen, verwenden Sie Binary Reader.
### Zwischen Oracle LogMiner und Binary Reader wechseln
AWS DMS kann zwei Methoden verwenden, um Änderungen an einer Oracle-Quelldatenbank zu erfassen: Binary Reader und Oracle LogMiner. Oracle LogMiner ist die Standardeinstellung. Um Binary Reader zur Erfassung von Änderungen verwenden, führen Sie die folgenden Schritte aus:
**So verwenden Sie Binary Reader für die Erfassung von Änderungen**
1. Melden Sie sich bei [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) an AWS-Managementkonsole und öffnen Sie die AWS DMS Konsole.
1. Wählen Sie **Endpunkte** aus.
1. Wählen Sie den Oracle-Quellendpunkt, für den Sie Binary Reader verwenden möchten.
1. Wählen Sie **Ändern** aus.
1. Wählen Sie **Erweitert** aus und fügen Sie dann den folgenden Code unter **Extra Verbindungsattribute** hinzu:
```
useLogminerReader=N
```
1. Verwenden Sie ein Oracle-Entwicklertool wie SQL-Plus, um dem AWS DMS Benutzerkonto, das für die Verbindung mit dem Oracle-Endpunkt verwendet wird, die folgenden zusätzlichen Rechte zu gewähren.
```
SELECT ON V_$TRANSPORTABLE_PLATFORM
```
### Fehler: Oracle CDC angehalten 122301 Oracle CDC maximale Wiederholversuche überschritten.
Dieser Fehler tritt auf, wenn die benötigten Oracle-Archivprotokolle von Ihrem Server entfernt wurden, bevor AWS DMS Sie sie zum Erfassen von Änderungen verwenden konnten. Erhöhen Sie die Richtlinien für die Aufbewahrung von Protokollen auf Ihrem Datenbankserver. Führen Sie für eine Amazon RDS-Datenbank die folgenden Schritte aus, um die Aufbewahrungsfrist für Protokolle zu erhöhen. Im folgenden Beispiel wird durch den Code die Aufbewahrung für Protokolle für eine Amazon RDS-DB-Instance auf 24 Stunden erhöht.
```
exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);
```
### Automatisches Hinzufügen der zusätzlichen Protokollierung zu einem Oracle-Quellendpunkt
Standardmäßig AWS DMS ist die zusätzliche Protokollierung deaktiviert. Um die zusätzliche Protokollierung für einen Oracle-Quellendpunkt automatisch zu aktivieren, führen Sie die folgenden Schritte aus:
**So fügen Sie einem Oracle-Quellendpunkt die zusätzliche Protokollierung hinzu**
1. Melden Sie sich bei [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) an AWS-Managementkonsole und öffnen Sie die AWS DMS Konsole.
1. Wählen Sie **Endpunkte** aus.
1. Wählen Sie den Oracle-Quellendpunkt, dem Sie die zusätzliche Protokollierung hinzufügen möchten.
1. Wählen Sie **Ändern** aus.
1. Wählen Sie **Erweitert** aus und fügen Sie dann den folgenden Code im Textfeld **Extra Verbindungsattribute** hinzu:
```
addSupplementalLogging=Y
```
1. Wählen Sie **Ändern** aus.
### LOB-Änderungen werden nicht erfasst
Derzeit muss eine Tabelle über einen Primärschlüssel verfügen, um AWS DMS LOB-Änderungen zu erfassen. Wenn eine Tabelle, die enthält, LOBs keinen Primärschlüssel hat, können Sie verschiedene Maßnahmen ergreifen, um LOB-Änderungen zu erfassen:
+ Fügen Sie der Tabelle einen Primärschlüssel hinzu. Dazu fügen Sie einfach eine ID-Spalte hinzu und füllen diese mit einer Sequenz unter Verwendung eines Auslösers.
+ Erstellen Sie eine materialisierte Ansicht der Tabelle, die eine vom System generierte ID als Primärschlüssel enthält, und migrieren Sie dann die materialisierte Ansicht anstatt der Tabelle.
+ Erstellen Sie einen logische Standby, fügen Sie der Tabelle einen Primärschlüssel hinzu, und migrieren Sie vom logischen Standby.
### Fehler: ORA-12899: Wert zu groß für Spalte *column-name*
Der Fehler „ORA-12899: Wert zu groß für Spalte*column-name*“ wird häufig durch mehrere Probleme verursacht.
Eins besteht darin, dass die von der Quell- und Zieldatenbank verwendeten Zeichensätze nicht übereinstimmen.
Ein anderes besteht darin, dass sich die National Language Support (NLS)-Einstellungen zwischen den beiden Datenbanken unterscheiden. Ein häufiger Grund für diesen Fehler ist, wenn der NLS\$1LENGTH\$1SEMANTICS-Parameter der Quelldatenbank auf CHAR und der NLS\$1LENGTH\$1SEMANTICS-Parameter der Zieldatenbank auf BYTE festgelegt sind.
### Datentyp NUMBER wird nicht richtig interpretiert
Der Oracle NUMBER-Datentyp wird je nach Genauigkeit und Skalierung von NUMBER in verschiedene AWS DMS Datentypen konvertiert. Diese Konvertierungen sind hier dokumentiert: [Quelldatentypen für Oracle](CHAP_Source.Oracle.md#CHAP_Source.Oracle.DataTypes). Die Art und Weise, wie der Datentyp NUMBER konvertiert wird, kann auch von der Verwendung von Endpunkteinstellungen für den Oracle-Quellendpunkt abhängen. Diese Endpunkteinstellungen sind unter [Endpunkteinstellungen bei Verwendung von Oracle als Quelle für AWS DMS](CHAP_Source.Oracle.md#CHAP_Source.Oracle.ConnectionAttrib) dokumentiert.
### Datensätze fehlen bei Volllast
Sucht beim Vollladen nach offenen Transaktionen auf Datenbankebene und wartet, bis die Transaktion festgeschrieben ist. AWS DMS AWS DMS Wartet beispielsweise, basierend auf der Aufgabeneinstellung`TransactionConsistencyTimeout=600`, 10 Minuten, auch wenn sich die offene Transaktion auf einer Tabelle befindet, die nicht in der Tabellenzuordnung enthalten ist. Wenn sich die offene Transaktion jedoch auf eine Tabelle bezieht, die in der Tabellenzuordnung enthalten ist, und die Transaktion nicht rechtzeitig bestätigt wird, führt dies zu fehlenden Datensätzen in der Zieltabelle.
Sie können die Aufgabeneinstellung `TransactionConsistencyTimeout` ändern und die Wartezeit erhöhen, wenn Sie wissen, dass das Bestätigen offener Transaktionen länger dauert.
Beachten Sie außerdem, dass der Standardwert für die Aufgabeneinstellung `FailOnTransactionConsistencyBreached` `false` lautet. Das bedeutet, dass AWS DMS weiterhin andere Transaktionen angewendet werden, offene Transaktionen jedoch übersehen werden. Falls Sie möchten, dass die Aufgabe fehlschlägt, wenn offene Transaktionen nicht rechtzeitig abgeschlossen werden, können Sie `FailOnTransactionConsistencyBreached` auf `true` setzen.
### Table Error
`Table Error` wird während der Replikation in Tabellenstatistiken angezeigt, wenn eine `WHERE`-Klausel nicht auf eine Primärschlüsselspalte verweist und die zusätzliche Protokollierung nicht für alle Spalten verwendet wird.
Um dieses Problem zu beheben, aktivieren Sie die zusätzliche Protokollierung für alle Spalten der Tabelle, auf die verwiesen wird. Weitere Informationen finden Sie unter [Einrichten der zusätzlichen Protokollierung](CHAP_Source.Oracle.md#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging).
### Fehler: Cannot retrieve Oracle archived Redo log destination ids
Dieser Fehler tritt auf, wenn für Ihre Oracle-Quelle keine Archivprotokolle generiert wurden oder wenn V\$1ARCHIVED\$1LOG leer ist. Sie können den Fehler beheben, indem Sie manuell zwischen den Protokollen wechseln.
Führen Sie für eine Amazon-RDS-Datenbank die folgenden Schritte aus, um die Protokolldateien zu wechseln. Die Prozedur `switch_logfile` hat keine Parameter.
```
exec rdsadmin.rdsadmin_util.switch_logfile;
```
Verwenden Sie für eine selbstverwaltete Oracle-Quelldatenbank den folgenden Befehl, um einen Protokollwechsel zu erzwingen.
```
ALTER SYSTEM SWITCH LOGFILE ;
```
### Bewertung der Leseleistung von Oracle-Redo- oder -Archivprotokollen
Wenn Sie Leistungsprobleme bei Ihrer Oracle-Quelle feststellen, können Sie die Leseleistung Ihrer Oracle-Redo- oder -Archivprotokolle bewerten, um Möglichkeiten zur Leistungssteigerung zu finden. Verwenden Sie das [Diagnose-Amazon-Machine-Image (AMI) von AWS DMS](CHAP_SupportAmi.md), um die Leseleistung des Redo- oder -Archivprotokolls zu testen.
Sie können das AWS DMS Diagnose-AMI verwenden, um Folgendes zu tun:
+ Verwenden Sie die bFile-Methode, um die Leistung von Redo-Protokolldateien zu bewerten.
+ Verwenden Sie LogMiner diese Methode, um die Leistung von Redo-Log-Dateien zu bewerten.
+ Verwenden Sie die Methode PL/SQL (`dbms_lob.read`), um die Leistung von Redo-Log-Dateien zu bewerten.
+ Verwenden Sie Single-Thread, um die Leseleistung von zu bewerten. ASMFile
+ Verwenden Sie Multi-Threads, um die Leseleistung von zu bewerten. ASMFile
+ Verwenden Sie die Direct-OS-Windows-Funktion Readfile() oder die Linux-Funktion Pread64, um die Redo-Protokolldatei zu bewerten.
Anschließend können Sie auf der Grundlage der Ergebnisse Korrekturmaßnahmen ergreifen.
**So testen Sie die Leseleistung von Oracle-Redo- oder -Archivprotokolldateien**
1. Erstellen Sie eine AWS DMS diagnostische AMI-Amazon EC2-Instance und stellen Sie eine Verbindung zu ihr her.
Weitere Informationen finden Sie unter [Arbeiten mit dem AWS DMS Diagnose-AMI](CHAP_SupportAmi.md).
1. Führen Sie den Befehl **awsreplperf** aus.
```
$ awsreplperf
```
Der Befehl zeigt die Optionen des AWS DMS Oracle Read Performance Utility an.
```
0. Quit
1. Read using Bfile
2. Read using LogMiner
3. Read file PL/SQL (dms_lob.read)
4. Read ASMFile Single Thread
5. Read ASMFile Multi Thread
6. Readfile() function
```
1. Wählen Sie eine Option in der Liste aus.
1. Geben Sie die folgenden Informationen zu Datenbankverbindung und Archivprotokoll ein.
```
Oracle user name [system]:
Oracle password:
Oracle connection name [orcllx]:
Connection format hostname:port/instance
Oracle event trace? [N]:
Default N = No or Y = Yes
Path to redo or archive log file []:
```
1. Untersuchen Sie die angezeigte Ausgabe auf relevante Informationen zur Leseleistung. Im Folgenden werden beispielsweise Ausgaben gezeigt, die sich aus der Auswahl von Option Nummer 2, **Lesen mit**, ergeben können LogMiner.
![\[Ausgabe des Dienstprogramms zur Leseleistung\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/images/datarep-oracle-read-perf-util.png)
1. Geben Sie **0** (Null) ein, um das Dienstprogramm zu beenden.
**Nächste Schritte**
+ Wenn die Ergebnisse zeigen, dass die Lesegeschwindigkeit unter einem akzeptablen Schwellenwert liegt, führen Sie das [Oracle Diagnostic Support Script](CHAP_SupportScripts.Oracle.md) auf dem Endpunkt aus und überprüfen Sie die Abschnitte zu Wartezeit, Lastprofil und E/A-Profil. Passen Sie dann alle ungewöhnlichen Konfigurationen an, die die Leseleistung verbessern könnten. Wenn Ihre Redo-Protokolldateien beispielsweise bis zu 2 GB groß sind, versuchen Sie, LOG\$1BUFFER auf 200 MB zu erhöhen, um die Leistung zu verbessern.
+ Sehen Sie sich [AWS DMS Best Practices](CHAP_BestPractices.md) an, um sicherzustellen, dass Ihre Replikations-Instance, Aufgabe und Endpunkte in DMS optimal konfiguriert sind.
### LOB-Daten konnten nicht abgerufen werden
LOB-Suchfehler (Large Object) AWS DMS treten unter bestimmten Umständen bei Datenmigrationsprozessen auf. AWS DMS Verwendet während der Vollladephase die Suchmethode für die LOB-Datenmigration, wenn die Aufgabe für den FULL LOB-Modus konfiguriert ist. Insbesondere während der CDC-Phase (Change Data Capture) wird unabhängig von den AWS DMS LOB-Einstellungen durchgängig die Lookup-Methode verwendet.
AWS DMS repliziert zuerst Zeilen ohne die LOB-Spalte, ruft LOB-Daten mithilfe eines **SELECT** Befehls ab und führt einen **UPDATE** Befehl aus, um das LOB-Feld auf dem Ziel zu replizieren. Diese sequentielle INSERT- und UPDATE-Operation kennzeichnet das LOOKUP-Verhalten. Die LOB-Suche während der CDC-Phase ist nicht universell für alle Datenbank-Engines anwendbar, und je nach Datengröße können die Aufgaben Inline-Zeilen zusammen mit Spaltendaten replizieren.
Ein Fehler beim LOB-Suchvorgang ist ein häufiges Problem, das während der Migration auftreten kann und die Fehlermeldung „LOB-Daten konnten nicht abgerufen werden, wird auf Null gesetzt“ angezeigt wird. Während dieses Fehlers werden die partiellen Tabellendaten auf dem Ziel, insbesondere die LOB-Spalten, als NULL-Werte angezeigt. Diese Fehler können durch verschiedene Faktoren ausgelöst werden:
+ Das Löschen der Quellzeile erfolgt, bevor DMS den Suchvorgang abschließt
+ Zeitweise auftretende Verbindungsprobleme, die Lookup-Threads unterbrechen
+ DMS-Lookup-Abfragen geraten aufgrund von Szenarien mit dem Sperren von Quelltabellen in einen Wartestatus
Um diese LOB-Suchfehler zu beheben, können Sie wie folgt vorgehen:
+ Implementieren Sie eingeschränkte LOB-Einstellungen während der Vollladephase, um das Suchverhalten zu vermeiden und die Leistung zu verbessern.
+ Laden Sie die betroffenen Tabellen neu, wenn auf dem Ziel Fehlermeldungen und unvollständige Daten bei der Suche angezeigt werden.
+ Bei Problemen, die auf zeitweise auftretende Probleme mit der Verfügbarkeit von Netzwerk- oder Quelldatenbanken zurückzuführen sind, starten Sie die Aufgabe erneut, um alle Inkonsistenzen der Tabellendaten zu beheben.
Diese Schritte zur Behandlung von LOB-Suchfehlern sorgen für eine zuverlässigere Datenmigration und tragen dazu bei, die Datenintegrität während des gesamten Prozesses aufrechtzuerhalten.
## Fehlersuche bei Verwendung von MySQL
Im Folgenden erfahren Sie mehr über die Behebung von Problemen, die bei der Verwendung AWS DMS mit MySQL-Datenbanken spezifisch sind.
**Topics**
+ [CDC-Aufgabe schlägt für Amazon RDS-DB-Instance-Endpunkt aufgrund deaktivierter binärer Protokollierung fehl](#CHAP_Troubleshooting.MySQL.CDCTaskFail)
+ [Verbindungen mit einer MySQL-Ziel-Instance werden während einer Aufgabe getrennt](#CHAP_Troubleshooting.MySQL.ConnectionDisconnect)
+ [Hinzufügen von Autocommit zu einem MySQL-kompatiblen Endpunkt](#CHAP_Troubleshooting.MySQL.Autocommit)
+ [Deaktivieren von Fremdschlüsseln auf einem MySQL-kompatiblen Zielendpunkt](#CHAP_Troubleshooting.MySQL.DisableForeignKeys)
+ [Durch Fragezeichen ersetzte Zeichen](#CHAP_Troubleshooting.MySQL.CharacterReplacement)
+ [„Bad event“-Protokolleinträge](#CHAP_Troubleshooting.MySQL.BadEvent)
+ [Change Data Capture (CDC) mit MySQL 5.5](#CHAP_Troubleshooting.MySQL.MySQL55CDC)
+ [Erhöhen der Aufbewahrungszeit für binäre Protokolle für Amazon RDS-DB-Instances](#CHAP_Troubleshooting.MySQL.BinLogRetention)
+ [Protokollmeldung: Einige Änderungen von der Quelldatenbank hatten bei Anwendung auf die Zieldatenbank keine Auswirkungen.](#CHAP_Troubleshooting.MySQL.NoImpact)
+ [Fehler: Bezeichner zu lang](#CHAP_Troubleshooting.MySQL.IDTooLong)
+ [Fehler: Felddatenumwandlung schlägt aufgrund nicht unterstützten Zeichensatzes fehl](#CHAP_Troubleshooting.MySQL.UnsupportedCharacterSet)
+ [Fehler: Die Konvertierung der Felddaten von Codepage 1252 nach UTF8 [120112] ist fehlgeschlagen](#CHAP_Troubleshooting.MySQL.DataConversionFailed)
+ [Indizes, Fremdschlüssel oder kaskadierende Aktualisierungen oder Löschungen wurden nicht migriert](#CHAP_Troubleshooting.MySQL.FKsAndIndexes)
### CDC-Aufgabe schlägt für Amazon RDS-DB-Instance-Endpunkt aufgrund deaktivierter binärer Protokollierung fehl
Dieses Problem tritt bei Amazon RDS-DB-Instances auf, wenn automatische Sicherungen deaktiviert sind. Aktivieren Sie automatische Sicherungen, indem Sie den Aufbewahrungszeitraum für Backups auf einen Wert größer als null festlegen.
### Verbindungen mit einer MySQL-Ziel-Instance werden während einer Aufgabe getrennt
Wenn Sie eine Aufgabe haben LOBs , bei der die Verbindung zu einem MySQL-Ziel getrennt wird, werden möglicherweise die folgenden Fehler im Aufgabenprotokoll angezeigt.
```
[TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: 08S01 NativeError:
2013 Message: [MySQL][ODBC 5.3(w) Driver][mysqld-5.7.16-log]Lost connection
to MySQL server during query [122502] ODBC general error.
```
```
[TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: HY000 NativeError:
2006 Message: [MySQL][ODBC 5.3(w) Driver]MySQL server has gone away
[122502] ODBC general error.
```
In diesem Fall müssen Sie möglicherweise einige Aufgabeneinstellungen anpassen.
Um das Problem einer Aufgabe zu lösen, die von einem MySQL-Ziel getrennt wird, führen Sie die folgenden Schritte aus:
+ Stellen Sie sicher, dass Ihre Datenbankvariable `max_allowed_packet` auf einen ausreichend großen Wert festgelegt ist, um Ihre größten LOBs zu speichern.
+ Stellen Sie sicher, dass die folgenden Variablen auf einen hohen Zeitüberschreitungswert festgelegt sind. Wir empfehlen, einen Wert von mindestens 5 Minuten für jede dieser Variablen zu verwenden.
+ `net_read_timeout`
+ `net_write_timeout`
+ `wait_timeout`
Informationen zum Festlegen von MySQL-Systemvariablen finden Sie unter [Server System Variables](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html) in der [MySQL-Dokumentation](https://dev.mysql.com/).
### Hinzufügen von Autocommit zu einem MySQL-kompatiblen Endpunkt
**So fügen Sie Autocommit zu einem MySQL-kompatiblen Zielendpunkt hinzu**
1. Melden Sie sich bei [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) an AWS-Managementkonsole und öffnen Sie die AWS DMS Konsole.
1. Wählen Sie **Endpunkte** aus.
1. Wählen Sie den MySQL-kompatiblen Zielendpunkt aus, dem Sie Autocommit hinzufügen möchten.
1. Wählen Sie **Ändern** aus.
1. Wählen Sie **Erweitert** aus und fügen Sie dann den folgenden Code im Textfeld **Extra Verbindungsattribute** hinzu:
```
Initstmt= SET AUTOCOMMIT=1
```
1. Wählen Sie **Ändern** aus.
### Deaktivieren von Fremdschlüsseln auf einem MySQL-kompatiblen Zielendpunkt
Sie können Fremdschlüsselprüfungen für MySQL deaktivieren, indem Sie **Extra Verbindungsattribute** im Abschnitt **Erweitert** des Zielendpunkts von MySQL, MariaDB oder der Amazon-Aurora-MySQL-kompatiblen Edition hinzufügen.
**So deaktivieren Sie Fremdschlüssel auf einem MySQL-kompatiblen Zielendpunkt**
1. [Melden Sie sich bei v2/ an AWS-Managementkonsole und öffnen Sie die AWS DMS Konsole. https://console.aws.amazon.com/dms/](https://console.aws.amazon.com/dms/v2/)
1. Wählen Sie **Endpunkte** aus.
1. Wählen Sie den MySQL-, Aurora-MySQL- oder MariaDB-Zielendpunkt aus, für den Sie Fremdschlüssel deaktivieren möchten.
1. Wählen Sie **Ändern** aus.
1. Wählen Sie **Erweitert** aus und fügen Sie dann den folgenden Code im Textfeld **Extra Verbindungsattribute** hinzu:
```
Initstmt=SET FOREIGN_KEY_CHECKS=0
```
1. Wählen Sie **Ändern** aus.
### Durch Fragezeichen ersetzte Zeichen
Die häufigste Situation, die dieses Problem verursacht, ist, wenn die Zeichen des Quellendpunkts mit einem Zeichensatz codiert wurden, der dies AWS DMS nicht unterstützt.
### „Bad event“-Protokolleinträge
„Bad event“-Einträge in den Migrationsprotokollen weisen in der Regel darauf hin, dass auf dem Endpunkt der Quelldatenbank ein nicht unterstützter Data Definition Language (DDL)-Vorgang versucht wurde. Nicht unterstützte DDL-Vorgänge führen zu einem Ereignis, das die Replikations-Instance nicht überspringen kann, sodass ein fehlerhaftes Ereignis protokolliert wird.
Starten Sie die Aufgabe von Anfang an neu, um dieses Problem zu beheben. Dadurch werden die Tabellen neu geladen und die Änderungen werden ab einem Zeitpunkt erfasst, nachdem der nicht unterstützte DDL-Vorgang ausgeführt wurde.
### Change Data Capture (CDC) mit MySQL 5.5
AWS DMS Change Data Capture (CDC) für Amazon RDS MySQL-kompatible Datenbanken erfordert eine vollständige zeilenbasierte Binärprotokollierung, die in MySQL Version 5.5 oder niedriger nicht unterstützt wird. Um AWS DMS CDC verwenden zu können, müssen Sie Ihre Amazon RDS-DB-Instance auf MySQL Version 5.6 aktualisieren.
### Erhöhen der Aufbewahrungszeit für binäre Protokolle für Amazon RDS-DB-Instances
AWS DMS erfordert die Aufbewahrung von binären Protokolldateien für die Erfassung von Änderungsdaten. Um die Aufbewahrungsfrist für Protokolle für eine Amazon RDS-DB-Instance zu erhöhen, gehen Sie wie folgt vor. Beim folgenden Beispiel wird die Aufbewahrungszeit für binäre Protokolle auf 24 Stunden erhöht.
```
call mysql.rds_set_configuration('binlog retention hours', 24);
```
### Protokollmeldung: Einige Änderungen von der Quelldatenbank hatten bei Anwendung auf die Zieldatenbank keine Auswirkungen.
Wenn der Wert einer MySQL-Datenbankspalte auf den vorhandenen Wert AWS DMS aktualisiert wird, `zero rows affected` wird von MySQL eine Meldung von zurückgegeben. Dieses Verhalten unterscheidet sich von anderen Datenbank-Engines wie Oracle und SQL Server. Diese Engines aktualisieren eine Zeile, auch wenn der ersetzende Wert mit dem aktuellen identisch ist.
### Fehler: Bezeichner zu lang
Der folgende Fehler tritt auf, wenn ein Bezeichner zu lang ist:
```
TARGET_LOAD E: RetCode: SQL_ERROR SqlState: HY000 NativeError:
1059 Message: MySQLhttp://ODBC 5.3(w) Driverhttp://mysqld-5.6.10Identifier
name 'name' is too long 122502 ODBC general error. (ar_odbc_stmt.c:4054)
```
In einigen Fällen legen Sie fest, AWS DMS dass die Tabellen und Primärschlüssel in der Zieldatenbank erstellt werden. In solchen Fällen verwendet DMS derzeit nicht die gleichen Namen für die Primärschlüssel, die in der Quelldatenbank verwendet wurden. Stattdessen erstellt DMS die Primärschlüsselnamen basierend auf den Tabellennamen. Bei langen Tabellennamen kann es vorkommen, dass der automatisch generierte Bezeichner die zulässigen Grenzwerte für MySQL überschreitet.
Der aktuelle Ansatz zum Beheben dieses Problems besteht darin, zunächst die Tabellen und Primärschlüssel in der Zieldatenbank vorab zu erstellen. Verwenden Sie dann eine Aufgabe, bei der die Aufgabeneinstellung **Zieltabellen-Vorbereitungsmodus** auf **Nichts unternehmen** oder **Kürzen** gesetzt ist, um die Zieltabellen zu befüllen.
### Fehler: Felddatenumwandlung schlägt aufgrund nicht unterstützten Zeichensatzes fehl
Der folgende Fehler tritt auf, wenn ein nicht unterstützter Zeichensatz dazu führt, dass eine Felddatenumwandlung fehlschlägt:
```
"[SOURCE_CAPTURE ]E: Column 'column-name' uses an unsupported character set [120112]
A field data conversion failed. (mysql_endpoint_capture.c:2154)
```
Überprüfen Sie die Parameter Ihrer Datenbank bezüglich Verbindungen. Mit dem folgenden Befehl können Sie diese Parameter festlegen:
```
SHOW VARIABLES LIKE '%char%';
```
### Fehler: Die Konvertierung der Felddaten von Codepage 1252 nach UTF8 [120112] ist fehlgeschlagen
Die folgenden Fehler kann während einer Migration auftreten, wenn Sie andere als Codepage-1252-Zeichen in der MySQL-Quelldatenbank haben.
```
[SOURCE_CAPTURE ]E: Error converting column 'column_xyz' in table
'table_xyz with codepage 1252 to UTF8 [120112] A field data conversion failed.
(mysql_endpoint_capture.c:2248)
```
Als Abhilfe können Sie das zusätzliche Verbindungsattribut `CharsetMapping` mit Ihrem MySQL-Quellendpunkt verwenden, um die Zeichensatzzuordnung festzulegen. Möglicherweise müssen Sie die AWS DMS Migrationsaufgabe von Anfang an neu starten, wenn Sie diese Endpunkteinstellung hinzufügen.
Die folgende Endpunkteinstellung könnte beispielsweise für einen MySQL-Quellendpunkt verwendet werden, bei dem der Quellzeichensatz `Utf8` oder ist`latin1`. 65001 ist die UTF8 Codepage-ID.
```
CharsetMapping=utf8,65001
CharsetMapping=latin1,65001
```
### Indizes, Fremdschlüssel oder kaskadierende Aktualisierungen oder Löschungen wurden nicht migriert
AWS DMS unterstützt nicht die Migration sekundärer Objekte wie Indizes und Fremdschlüssel. Zum Replizieren von Änderungen, die durch eine kaskadierende Aktualisierung oder Löschung an untergeordneten Tabellen vorgenommen wurden, muss die auslösende Fremdschlüsseleinschränkung für die Zieltabelle aktiv sein. Erstellen Sie den Fremdschlüssel manuell in der Zieltabelle, um diese Einschränkung zu umgehen. Erstellen Sie dann entweder eine einzelne Aufgabe für Volllast und CDC oder zwei separate Aufgaben für Volllast und CDC, wie im Folgenden beschrieben:
#### Eine einzelne Aufgabe erstellen, die Volllast und CDC unterstützt
In diesem Verfahren wird beschrieben, wie Fremdschlüssel und Indizes mithilfe einer einzelnen Aufgabe für Volllast und CDC migriert werden.
**Eine Aufgabe für Volllast und CDC erstellen**
1. Erstellen Sie manuell die Tabellen mit Fremdschlüsseln und Indizes auf dem Ziel, die mit den Quelltabellen übereinstimmen.
1. Fügen Sie dem AWS DMS Zielendpunkt die folgende ECA hinzu:
```
Initstmt=SET FOREIGN_KEY_CHECKS=0;
```
1. Erstellen Sie die AWS DMS Aufgabe mit der `TargetTablePrepMode` Einstellung auf`DO_NOTHING`.
1. Setzen Sie die Einstellung `Stop task after full load completes` auf `StopTaskCachedChangesApplied`.
1. Starten Sie die Aufgabe. AWS DMS stoppt die Aufgabe automatisch, nachdem sie den vollen Ladevorgang abgeschlossen hat, und wendet alle zwischengespeicherten Änderungen an.
1. Entfernen Sie das zuvor hinzugefügte ECA `SET FOREIGN_KEY_CHECKS`.
1. Setzen Sie die Aufgabe fort. Die Aufgabe geht in die CDC-Phase über und wendet die laufenden Änderungen aus der Quelldatenbank auf das Ziel an.
#### Aufgaben für Volllast und CDC separat erstellen
In diesen Verfahren wird beschrieben, wie Fremdschlüssel und Indizes mithilfe separater Aufgaben für Volllast und CDC migriert werden.
**Eine Aufgabe für Volllast erstellen**
1. Erstellen Sie manuell die Tabellen mit Fremdschlüsseln und Indizes auf dem Ziel, die mit den Quelltabellen übereinstimmen.
1. Fügen Sie dem AWS DMS Zielendpunkt die folgende ECA hinzu:
```
Initstmt=SET FOREIGN_KEY_CHECKS=0;
```
1. Erstellen Sie die AWS DMS Aufgabe, wobei der `TargetTablePrepMode` Parameter auf gesetzt `DO_NOTHING` und auf `EnableValidation` gesetzt ist`FALSE`.
1. Starten Sie die Aufgabe. AWS DMS stoppt die Aufgabe automatisch, nachdem sie den vollen Ladevorgang abgeschlossen hat, und wendet alle zwischengespeicherten Änderungen an.
1. Notieren Sie sich nach Aufgabenabschluss die Startzeit der Aufgabe für Volllast in UTC oder den Namen und die Position der Binärprotokolldatei, um die Nur-CDC-Aufgabe zu starten. In den Protokollen finden Sie den Zeitstempel in UTC ab der ersten Startzeit der Volllast.
**Eine Nur-CDC-Aufgabe erstellen**
1. Entfernen Sie das zuvor festgelegte ECA `SET FOREIGN_KEY_CHECKS`.
1. Erstellen Sie die Nur-CDC-Aufgabe und legen Sie die Startposition auf die im vorherigen Schritt notierte Startzeit der Aufgabe für Volllast fest. Alternativ können Sie auch die im vorigen Schritt notierte Position der Binärprotokolldatei verwenden. Setzen Sie die Einstellung `TargetTablePrepMode` auf `DO_NOTHING`. Aktivieren Sie die Datenvalidierung, indem Sie die Einstellung `EnableValidation` auf `TRUE` setzen, wenn erforderlich.
1. Starten Sie die Nur-CDC-Aufgabe und überwachen Sie die Protokolle auf Fehler.
**Anmerkung**
Diese Problemumgehung gilt nur für Migrationen von MySQL zu MySQL. Sie können diese Methode nicht mit dem Feature für Stapelanwendungen verwenden, da dieses voraussetzt, dass Zieltabellen keine aktiven Fremdschlüssel haben.
## Fehlersuche bei Verwendung von PostgreSQL
Im Folgenden erfahren Sie mehr über die Behebung von Problemen, die bei der Verwendung AWS DMS mit PostgreSQL-Datenbanken spezifisch sind.
**Topics**
+ [Verkürzte JSON-Datentypen](#CHAP_Troubleshooting.PostgreSQL.JSONTruncation)
+ [Spalten eines benutzerdefinierten Datentyps werden nicht korrekt migriert](#CHAP_Troubleshooting.PostgreSQL.UserDefinedDataType)
+ [Fehler: Kein Schema zum Erstellen ausgewählt](#CHAP_Troubleshooting.PostgreSQL.NoSchema)
+ [Lösch- und Aktualisierungsvorgänge für eine Tabelle werden bei Verwendung von CDC nicht repliziert](#CHAP_Troubleshooting.PostgreSQL.DeletesNotReplicated)
+ [Truncate-Anweisungen werden nicht ordnungsgemäß propagiert](#CHAP_Troubleshooting.PostgreSQL.Truncate)
+ [Verhindern, dass PostgreSQL DDL erfasst](#CHAP_Troubleshooting.PostgreSQL.NoCaptureDDL)
+ [Auswahl des Schemas, in dem Datenbankobjekte für die DDL-Erfassung erstellt werden](#CHAP_Troubleshooting.PostgreSQL.SchemaDDL)
+ [Oracle-Tabellen fehlen nach Migration zu PostgreSQL](#CHAP_Troubleshooting.PostgreSQL.OracleTablesMissing)
+ [ReplicationSlotDiskUsage nimmt bei langen Transaktionen, wie z. B. ETL-Workloads, zu und restart\$1lsn läuft nicht mehr weiter](#CHAP_Troubleshooting.PostgreSQL.AvoidLongTransactions)
+ [Für Aufgabe, die Ansicht als Quelle verwendet, wurden keine Zeilen kopiert](#CHAP_Troubleshooting.PostgreSQL.ViewTask)
+ [Ungültige Bytefolge für die Kodierung von "“ UTF8](#CHAP_Troubleshooting.PostgreSQL.invalidbyte)
### Verkürzte JSON-Datentypen
AWS DMS behandelt den JSON-Datentyp in PostgreSQL als LOB-Datentypspalte. Das bedeutet, dass die LOB-Größenbeschränkung für JSON-Daten gilt, wenn Sie den beschränkten LOB-Modus verwenden.
Nehmen wir beispielsweise an, dass der beschränkte LOB-Modus auf 4 096 KB eingestellt ist. In diesem Fall werden alle JSON-Daten, die größer als 4 096 KB sind, bei der Begrenzung von 4 096 KB gekürzt und der Validierungstest in PostgreSQL schlägt fehl.
Die folgenden Protokollinformationen zeigen einen JSON-Code, der aufgrund der Einstellungen des beschränkten LOB-Modus und fehlgeschlagener Validierung gekürzt wurde.
```
03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement:
'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? ,
"new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? ,
"start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? ,
"updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement:
'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? ,
"new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? ,
"start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? ,
"updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt.c:2415)
03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState:
22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;,
Error while executing the query [1022502] (ar_odbc_stmt.c:2421)
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState:
22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;,
Error while executing the query [1022502] (ar_odbc_stmt.c:2421)
```
### Spalten eines benutzerdefinierten Datentyps werden nicht korrekt migriert
AWS DMS Erstellt bei der Replikation aus einer PostgreSQL-Quelle die Zieltabelle mit den gleichen Datentypen für alle Spalten, mit Ausnahme von Spalten mit benutzerdefinierten Datentypen. In solchen Fällen wird der Datentyp als "character varying" im Ziel erstellt.
### Fehler: Kein Schema zum Erstellen ausgewählt
In einigen Fällen wird möglicherweise der Fehler „SQL\$1ERROR SqlState: 3F000:7 Message: ERROR NativeError: no schema has been selected to create in“ angezeigt.
Dieser Fehler kann auftreten, wenn Ihre JSON-Tabellenzuordnung einen Platzhalterwert für das Schema enthält, die Quelldatenbank diesen Wert jedoch nicht unterstützt.
### Lösch- und Aktualisierungsvorgänge für eine Tabelle werden bei Verwendung von CDC nicht repliziert
Lösch- und Aktualisierungsvorgänge während der Change Data Capture (CDC) werden ignoriert, wenn die Quelltabelle keinen Primärschlüssel hat. AWS DMS unterstützt Change Data Capture (CDC) für PostgreSQL-Tabellen mit Primärschlüsseln.
Wenn eine Tabelle keinen Primärschlüssel aufweist, enthalten die Write-Ahead (WAL)-Protokolle kein Vorher-Image der Datenbankzeile. In diesem Fall AWS DMS kann die Tabelle nicht aktualisiert werden. Erstellen Sie einen Primärschlüssel für die Quelltabelle, damit Löschvorgänge repliziert werden.
### Truncate-Anweisungen werden nicht ordnungsgemäß propagiert
Bei Verwendung von Change Data Capture (CDC) werden TRUNCATE-Operationen von nicht unterstützt. AWS DMS
### Verhindern, dass PostgreSQL DDL erfasst
Sie können verhindern, dass ein PostgreSQL-Zielendpunkt DDL-Anweisungen erfasst, indem Sie die folgende **Endpunkteinstellung**-Anweisung hinzufügen.
```
"CaptureDDLs": "N"
```
### Auswahl des Schemas, in dem Datenbankobjekte für die DDL-Erfassung erstellt werden
Sie können steuern, in welchem Schema die Datenbankobjekte im Zusammenhang mit der Erfassung von DDL erstellt werden. Fügen Sie die folgende **Endpunkteinstellung**-Anweisung hinzu. Der Parameter **Endpunkteinstellung** ist auf der Registerkarte des Quellendpunkts verfügbar.
```
"DdlArtifactsSchema: "xyzddlschema"
```
### Oracle-Tabellen fehlen nach Migration zu PostgreSQL
In diesem Fall sind Ihre Tabellen und Daten im Allgemeinen weiterhin verfügbar.
Bei Oracle werden Tabellennamen standardmäßig in Großbuchstaben, bei PostgreSQL in Kleinbuchstaben geschrieben. Für Migrationen von Oracle zu PostgreSQL empfehlen wir, bestimmte Transformationsregeln im Abschnitt zur Tabellenzuordnung Ihrer Aufgabe anzugeben. Mit diesen Transformationsregeln wird die Groß- und Kleinschreibung Ihrer Tabellennamen umgewandelt.
Falls Sie Ihre Tabellen ohne Transformationsregeln für die Umwandlung der Groß-/Kleinschreibung der Tabellennamen migriert haben, setzen Sie die Tabellennamen in Anführungszeichen, wenn Sie darauf verweisen.
### ReplicationSlotDiskUsage nimmt bei langen Transaktionen, wie z. B. ETL-Workloads, zu und restart\$1lsn läuft nicht mehr weiter
Wenn die logische Replikation aktiviert ist, beträgt die maximale Anzahl von Änderungen, die pro Transaktion im Arbeitsspeicher gespeichert werden, 4 MB. Danach werden die Änderungen auf den Datenträger übertragen. Das hat zur Folge, dass der `ReplicationSlotDiskUsage` Wert steigt und erst dann `restart_lsn` voranschreitet, wenn die Transaktion abgeschlossen ist und der Rollback abgeschlossen ist completed/aborted . Da es sich um eine lange Transaktion handelt, kann das Rollback lange dauern.
Vermeiden Sie daher lang andauernde Transaktionen, wenn die logische Replikation aktiviert ist. Versuchen Sie stattdessen, die Transaktion in mehrere kleinere Transaktionen aufzuteilen.
### Für Aufgabe, die Ansicht als Quelle verwendet, wurden keine Zeilen kopiert
Setzen Sie zum Migrieren einer Ansicht `table-type` auf `all` oder `view`. Weitere Informationen finden Sie unter [Festlegen der Tabellenauswahl und der Transformationsregeln über die Konsole](CHAP_Tasks.CustomizingTasks.TableMapping.Console.md).
Zu den Quellen, die Ansichten unterstützen, gehören folgende.
+ Oracle
+ Microsoft SQL Server
+ MySQL
+ PostgreSQL
+ IBM Db2 (LUW)
+ SAP Adaptive Server Enterprise (ASE)
### Ungültige Bytefolge für die Kodierung von "“ UTF8
Die Datenmigration von Oracle zu PostgreSQL mithilfe von unterschiedlichen Zeichensatzkodierungen zwischen den beiden Datenbanken AWS DMS stellt besondere Herausforderungen dar. Ein erhebliches Problem ergibt sich aus dem AL32 UTF8 Zeichensatz von Oracle, der 4-Byte-Zeichen vollständig unterstützt, während der UTF8 Zeichensatz-Implementierung von PostgreSQL diese Fähigkeit fehlt. Diese Ungleichheit führt häufig zu Migrationsfehlern, insbesondere wenn es sich um Tabellen oder Spalten in der Oracle-Quelle handelt, die 4-Byte-Zeichen enthalten.
Bei Migrationsversuchen können sowohl in den DMS-Aufgabenprotokollen als auch in den PostgreSQL-Zieldatenbankprotokollen Fehlermeldungen auftreten, die auf Probleme mit ungültigen UTF8 Bytesequenzen hinweisen. Eine typische Fehlermeldung „FEHLER: ungültige Bytefolge für die Kodierung" UTF8 „: 0xed 0xb0 0x86" wird angezeigt. Um dieses Problem zu beheben, AWS DMS bietet die "" -Einstellungen eine Lösung. `ReplaceChars` Während des Migrationsvorgangs werden ungültige Zeichen automatisch ersetzt oder entfernt. Dieser Ansatz verhindert effektiv codierungsbedingte Fehler, ohne dass Änderungen an den Quelldaten erforderlich sind.
Weitere Informationen finden Sie unter Aufzählungszeichen für *Zeichensatzvalidierung und -ersetzung* [im Thema Aufgabeneinstellungen zur Zeichenersetzung](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.CharacterSubstitution.html).
## Fehlersuche bei Verwendung von Microsoft SQL Server
Im Folgenden erfahren Sie mehr über die Behebung von Problemen, die bei der Verwendung AWS DMS mit Microsoft SQL Server-Datenbanken spezifisch sind.
**Topics**
+ [Die laufende Replikation schlägt fehl, nachdem für RDS für SQL Server ein Failover zur sekundären Version durchgeführt wurde](#CHAP_Troubleshooting.SQLServer.RepFailover)
+ [Fehler bei Erfassung von Änderungen für SQL Server-Datenbank](#CHAP_Troubleshooting.SQLServer.CDCErrors)
+ [Fehlende Identitätsspalten](#CHAP_Troubleshooting.SQLServer.IdentityColumns)
+ [Fehler: SQL Server unterstützt keine Publikationen](#CHAP_Troubleshooting.SQLServer.Publications)
+ [Änderungen werden in Ihrem Ziel nicht angezeigt](#CHAP_Troubleshooting.SQLServer.NoChanges)
+ [Uneinheitliche Tabelle, die über Partitionen hinweg zugeordnet ist](#CHAP_Troubleshooting.SQLServer.Nonuniform)
+ [Fehler: Die CDC-Aufgabe ist mit einem fehlerhaften Umschlag und einem ungültigen context/LCX Datencode bei der Verarbeitung einer Transaktion fehlgeschlagen](#CHAP_Troubleshooting.SQLServer.badenvelope.cdc)
### Die laufende Replikation schlägt fehl, nachdem für RDS für SQL Server ein Failover zur sekundären Version durchgeführt wurde
Wenn ein Failover einer SQL Server-Quellinstanz auf die sekundäre Instanz erfolgt, versucht die AWS DMS laufende Replikation weiterhin, eine Verbindung herzustellen, und setzt die Replikation fort, sobald die Quelle wieder online ist. Bei MAZ-Instanzen von RDS für SQL Server kann der sekundäre Datenbankbesitzer jedoch unter bestimmten Umständen auf eingestellt werden. `NT AUTHORITY\SYSTEM` Nach einem Failover führt dies dazu, dass die DMS-Aufgabe mit dem folgenden Fehler fehlschlägt:
```
[SOURCE_CAPTURE ]E: RetCode: SQL_ERROR SqlState: 42000 NativeError: 33009 Message:
[Microsoft][ODBC Driver 17 for SQL Server][SQL Server]The database owner SID recorded in the master
database differs from the database owner SID recorded in database 'rdsadmin'. You should correct
this situation by resetting the owner of database 'rdsadmin' using the ALTER AUTHORIZATION statement.
Line: 1 Column: -1 [1022502] (ar_odbc_stmt.c:5035)
```
Um dieses Problem zu beheben, folgen Sie den Schritten unter [Ändern des db\$1owner in das rdsa-Konto für Ihre Datenbank, und setzen Sie dann Ihre](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.SQLServer.CommonDBATasks.ChangeDBowner.html) DMS-Aufgabe fort.
### Fehler bei Erfassung von Änderungen für SQL Server-Datenbank
Fehler während CDC weisen häufig darauf hin, dass eine der Voraussetzungen nicht erfüllt war. Zum Beispiel ist eine der am häufigsten übersehenen Voraussetzungen eine vollständige Datenbanksicherung. Das Aufgabenprotokoll gibt dieses Versäumnis mit dem folgenden Fehler an:
```
SOURCE_CAPTURE E: No FULL database backup found (under the 'FULL' recovery model).
To enable all changes to be captured, you must perform a full database backup.
120438 Changes may be missed. (sqlserver_log_queries.c:2623)
```
Überprüfen Sie die Voraussetzungen für die Verwendung von SQL Server als Quelle unter [Verwenden einer Microsoft SQL Server-Datenbank als Quelle für AWS DMS](CHAP_Source.SQLServer.md).
### Fehlende Identitätsspalten
AWS DMS unterstützt keine Identitätsspalten, wenn Sie ein Zielschema erstellen. Sie müssen sie hinzufügen, nachdem der erste Ladevorgang abgeschlossen ist.
### Fehler: SQL Server unterstützt keine Publikationen
Die folgende Fehlermeldung wird angezeigt, wenn Sie SQL Server Express als Quellendpunkt verwenden:
```
RetCode: SQL_ERROR SqlState: HY000 NativeError: 21106
Message: This edition of SQL Server does not support publications.
```
AWS DMS unterstützt derzeit SQL Server Express nicht als Quelle oder Ziel.
### Änderungen werden in Ihrem Ziel nicht angezeigt
AWS DMS erfordert, dass eine SQL Server-Quelldatenbank entweder das Datenwiederherstellungsmodell „FULL“ oder „BULK LOGGED“ verwendet, um Änderungen konsistent zu erfassen. Das Modell „SIMPLE“ wird nicht unterstützt.
Beim Wiederherstellungsmodell SIMPLE werden minimale Informationen protokolliert, die erforderlich sind, damit Benutzer ihre Datenbank wiederherstellen können. Alle inaktiven Protokolleinträge werden automatisch abgeschnitten, wenn ein Prüfpunkt eintritt.
Alle Operationen werden weiterhin protokolliert. Sobald jedoch ein Prüfpunkt eintritt, wird das Protokoll automatisch gekürzt. Diese Kürzung bedeutet, dass das Protokoll wiederverwendet werden und ältere Protokolleinträge überschrieben werden können. Wenn Protokolleinträge überschrieben werden, können Änderungen nicht erfasst werden. Aus diesem Grund wird das SIMPLE-Datenwiederherstellungsmodell AWS DMS nicht unterstützt. Informationen zu weiteren erforderlichen Voraussetzungen für die Verwendung von SQL Server als Quelle finden Sie unter [Verwenden einer Microsoft SQL Server-Datenbank als Quelle für AWS DMS](CHAP_Source.SQLServer.md).
### Uneinheitliche Tabelle, die über Partitionen hinweg zugeordnet ist
Während der Change Data Capture (CDC) wird die Migration einer Tabelle mit einer speziellen Struktur unterbrochen, wenn CDC für die Tabelle nicht ordnungsgemäß ausgeführt werden AWS DMS kann. Nachrichten wie diese werden ausgegeben:
```
[SOURCE_CAPTURE ]W: Table is not uniformly mapped across partitions. Therefore - it is excluded from CDC (sqlserver_log_metadata.c:1415)
[SOURCE_CAPTURE ]I: Table has been mapped and registered for CDC. (sqlserver_log_metadata.c:835)
```
Wenn CDC auf SQL Server-Tabellen ausgeführt wird, werden die SQL AWS DMS Server-Tlogs analysiert. AWS DMS Analysiert in jedem Tlog-Datensatz Hexadezimalwerte, die Daten für Spalten enthalten, die während einer Änderung eingefügt, aktualisiert oder gelöscht wurden.
AWS DMS Liest die Tabellenmetadaten aus den SQL Server-Systemtabellen, um den Hexadezimaldatensatz zu analysieren. Diese Systemtabellen identifizieren, was die speziell strukturierten Tabellenspalten sind und zeigen einige ihrer internen Eigenschaften, wie „xoffset“ und „null bit position“.
AWS DMS erwartet, dass die Metadaten für alle Rohpartitionen der Tabelle identisch sind. In Einzelfällen haben speziell strukturierte Tabellen jedoch nicht auf allen Partitionen die gleichen Metadaten. In diesen Fällen AWS DMS kann CDC für diese Tabelle ausgesetzt werden, um zu verhindern, dass Änderungen falsch analysiert und das Ziel mit falschen Daten versorgt wird. Es gibt u. a. folgende Möglichkeiten zur Umgehung des Problems:
+ Wenn die Tabelle über einen gruppierten Index verfügt, führen Sie einen Indexneuaufbau durch.
+ Wenn die Tabelle keinen gruppierten Index hat, fügen Sie der Tabelle einen gruppierten Index hinzu (Sie können ihn später löschen, wenn Sie möchten).
### Fehler: Die CDC-Aufgabe ist mit einem fehlerhaften Umschlag und einem ungültigen context/LCX Datencode bei der Verarbeitung einer Transaktion fehlgeschlagen
Der Fehler „Bad Envelope“ tritt auf, wenn AWS DMS bestimmte Ereignistypen in der CDC-Phasenreplikation während des Validierungsprozesses nicht validiert werden können. Dieser Fehler kann häufig auftreten, wenn Aufgaben ab einem bestimmten Zeitstempel, der in die Mitte einer Transaktion fällt, wieder aufgenommen werden. In solchen Fällen liest die Aufgabe möglicherweise ein Commit-Ereignis, ohne das entsprechende Ereignis „Transaktion starten“ zu finden, was zu einem ungültigen Transaktionskontext führt und den Fehler „Bad Envelope“ auslöst.
Um dieses Problem zu beheben, müssen Sie die Konfiguration des SQL Server-Quellendpunkts ändern, indem Sie den `ignoreTxnCtxValidityCheck` Parameter `true` im Abschnitt Zusätzliche Verbindungsattribute auf festlegen, bevor Sie die Aufgabe fortsetzen. Wenn der Fehler nach der Implementierung dieser Lösung weiterhin besteht, reichen Sie ein AWS [Supportticket](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) ein.
## Fehlersuche bei Verwendung von Amazon Redshift
Im Folgenden erfahren Sie mehr über die Behebung von Problemen, die speziell bei der Verwendung AWS DMS mit Amazon Redshift Redshift-Datenbanken auftreten.
**Topics**
+ [In einen Amazon Redshift Redshift-Cluster in einer anderen AWS Region laden](#CHAP_Troubleshooting.Redshift.Regions)
+ [Fehler: Beziehung "attrep\$1apply\$1exceptions" bereits vorhanden](#CHAP_Troubleshooting.Redshift.AlreadyExists)
+ [Fehler mit Tabellen, deren Name mit „awsdms\$1changes“ beginnt](#CHAP_Troubleshooting.Redshift.Changes)
+ [Anzeige von Tabellen in Clustern mit Namen wie dms.awsdms\$1changes000000000XXXX](#CHAP_Troubleshooting.Redshift.TempTables)
+ [Berechtigungen für die Verwendung mit Amazon Redshift erforderlich](#CHAP_Troubleshooting.Redshift.Permissions)
### In einen Amazon Redshift Redshift-Cluster in einer anderen AWS Region laden
Sie können nicht in einen Amazon Redshift Redshift-Cluster laden, der sich in einer anderen AWS Region als Ihrer AWS DMS Replikationsinstanz befindet. DMS setzt voraus, dass sich die Replikations-Instance und der Amazon-Redshift-Cluster in derselben Region befinden.
### Fehler: Beziehung "attrep\$1apply\$1exceptions" bereits vorhanden
Der Fehler „Relation 'awsdms\$1apply\$1exceptions' already exists“ tritt häufig auf, wenn ein Redshift-Endpunkt als PostgreSQL-Endpunkt angegeben wird. Um dieses Problem zu beheben, ändern Sie den Endpunkt und ändern Sie die **Target engine** in "redshift".
### Fehler mit Tabellen, deren Name mit „awsdms\$1changes“ beginnt
Fehlermeldungen zu Tabellen mit Namen, die mit „awsdms\$1changes“ beginnen, können auftreten, wenn zwei Aufgaben gleichzeitig ausgeführt werden, die versuchen, Daten in den gleichen Amazon Redshift-Cluster zu laden. Aufgrund der Art und Weise, wie temporäre Tabellen benannt sind, können gleichzeitige Aufgaben in Konflikt geraten, wenn die gleiche Tabelle aktualisiert wird.
### Anzeige von Tabellen in Clustern mit Namen wie dms.awsdms\$1changes000000000XXXX
AWS DMS erstellt temporäre Tabellen, wenn Daten aus in Amazon S3 gespeicherten Dateien geladen werden. Die Namen dieser temporären Tabellen weisen das Präfix `dms.awsdms_changes` auf. Diese Tabellen sind erforderlich, damit sie Daten speichern AWS DMS können, wenn sie zum ersten Mal geladen werden und bevor sie in die endgültige Zieltabelle eingefügt werden.
### Berechtigungen für die Verwendung mit Amazon Redshift erforderlich
Für die Verwendung AWS DMS mit Amazon Redshift muss das Benutzerkonto, das Sie für den Zugriff auf Amazon Redshift verwenden, über die folgenden Berechtigungen verfügen:
+ CRUD (Auswählen, Einfügen, Aktualisieren, Löschen)
+ Massenladevorgang
+ Erstellen, Ändern, Löschen (falls gemäß Aufgabendefinition erforderlich)
Sie finden die Voraussetzungen für die Verwendung von Amazon Redshift als Ziel unter [Verwenden einer Amazon Redshift Redshift-Datenbank als Ziel für AWS Database Migration Service](CHAP_Target.Redshift.md).
## Fehlersuche bei Verwendung von Amazon Aurora MySQL
Im Folgenden erfahren Sie mehr über die Behebung von Problemen, die speziell bei der Verwendung AWS DMS mit Amazon Aurora MySQL-Datenbanken auftreten.
**Topics**
+ [Fehler: CHARACTER UTF8 SET-Felder, die mit '"' abgeschlossen sind, umschlossen von '"' Zeilen, die mit '\$1n' enden](#CHAP_Troubleshooting.Aurora.ANSIQuotes)
### Fehler: CHARACTER UTF8 SET-Felder, die mit '"' abgeschlossen sind, umschlossen von '"' Zeilen, die mit '\$1n' enden
Wenn Sie Amazon Aurora MySQL als Ziel verwenden, wird in den Protokollen möglicherweise ein Fehler wie der folgende angezeigt. Dieser Fehlertyp weist in der Regel darauf hin, dass ANSI\$1QUOTES Teil des SQL\$1MODE-Parameters ist. Die Verwendung von ANSI\$1QUOTES im SQL\$1MODE-Parameter sorgt dafür, dass doppelte Anführungszeichen wie einfache Anführungszeichen verwendet werden, was bei Ausführung einer Aufgabe zu Problemen führen kann.
Um diesen Fehler zu beheben, entfernen Sie ANSI\$1QUOTES aus dem SQL\$1MODE-Parameter.
```
2016-11-02T14:23:48 [TARGET_LOAD ]E: Load data sql statement. load data local infile
"/rdsdbdata/data/tasks/7XO4FJHCVON7TYTLQ6RX3CQHDU/data_files/4/LOAD000001DF.csv" into table
`VOSPUSER`.`SANDBOX_SRC_FILE` CHARACTER SET UTF8 fields terminated by ','
enclosed by '"' lines terminated by '\n'( `SANDBOX_SRC_FILE_ID`,`SANDBOX_ID`,
`FILENAME`,`LOCAL_PATH`,`LINES_OF_CODE`,`INSERT_TS`,`MODIFIED_TS`,`MODIFIED_BY`,
`RECORD_VER`,`REF_GUID`,`PLATFORM_GENERATED`,`ANALYSIS_TYPE`,`SANITIZED`,`DYN_TYPE`,
`CRAWL_STATUS`,`ORIG_EXEC_UNIT_VER_ID` ) ; (provider_syntax_manager.c:2561)
```
## Fehlersuche bei Verwendung von SAP ASE
Im Folgenden erfahren Sie mehr über die Behebung von Problemen, die speziell bei der Verwendung AWS DMS mit SAP ASE-Datenbanken auftreten.
### Fehler: LOB-Spalten haben NULL-Werte, wenn die Quelle einen zusammengesetzten eindeutigen Index mit NULL-Werten hat
Wenn Sie SAP ASE als Quelle mit Tabellen verwenden, die mit einem zusammengesetzten eindeutigen Index konfiguriert sind, der NULL-Werte zulässt, werden LOB-Werte während der laufenden Replikation möglicherweise nicht migriert. Dieses Verhalten ist in der Regel darauf zurückzuführen, dass ANSI\$1NULL auf dem Client der DMS-Replikations-Instance standardmäßig auf 1 gesetzt ist.
Um sicherzustellen, dass LOB-Felder korrekt migriert werden, fügen Sie die Einstellung Endpoint `'AnsiNull=0'` dem AWS DMS Quellendpunkt der Aufgabe hinzu.
## Fehlersuche bei Verwendung von IBM Db2
Im Folgenden erfahren Sie mehr über die Behebung von Problemen, die bei der Verwendung AWS DMS mit IBM Db2-Datenbanken spezifisch sind.
### Fehler: Fortsetzen ab Zeitstempel wird nicht unterstützt
Wenn Sie bei laufender Replikation (CDC) die Replikation ab einem bestimmten Zeitstempel starten möchten, setzen Sie das zusätzliche Verbindungsattribut `StartFromContext` auf den erforderlichen Zeitstempel. Weitere Informationen finden Sie unter [Zusätzliche Verbindungsattribute (ECAs) bei Verwendung](CHAP_Source.DB2.md#CHAP_Source.DB2.ConnectionAttrib) von Db2 LUW. Indem Sie `StartFromContext` auf den erforderlichen Zeitstempel setzen, wird folgender Fehler verhindert:
```
Last Error Resume from timestamp is not supported Task error notification received from
subtask 0, thread 0 [reptask/replicationtask.c:2822] [1020455] 'Start from timestamp' was blocked to prevent Replicate from
scanning the log (to find the timestamp). When using IBM DB2 for LUW, 'Start from timestamp' is only supported if an actual
change was captured by this Replicate task earlier to the specified timestamp.
```
## Die Tabelle hat eine Tabelle mit dem Fehler „Die Anweisung 'where' konnte nicht erstellt werden“ gesperrt
Wenn Sie in DMS versuchen, einen Datensatz in einer Tabelle zu aktualisieren, die keinen Primärschlüssel hat, kann das System keine WHERE-Bedingung erstellen und zeigt den folgenden Fehler an:
```
[TARGET_APPLY ]E: Failed to build 'where' statement
```
Dies kann auf mehrere bekannte Probleme oder Einschränkungen zurückzuführen sein:
+ Die Primärschlüsselspalte wird mithilfe der `remove-column` Transformationsregel entfernt.
+ Bei der Tabellenstruktur stimmt Ihre Quell- und Zieldatenbank nicht überein, d. h. die Primärschlüsselspalte existiert in der Quelle, aber nicht in der Zieldatenbank oder wurde möglicherweise entfernt.
+ Bekannte Einschränkungen oder fehlende Voraussetzungen:
+ Die zusätzliche Protokollierung wurde für Oracle-Tabellen nicht ordnungsgemäß aktiviert.
+ Die Oracle-Tabelle wurde mit langen Objektnamen (über 30 Byte) erstellt. Daher können Objektnamen Tabellen- oder Spaltennamen sein.
+ Replikation aus Oracle-Anwendungscontainern PDB.
# Behebung von Latenzproblemen in AWS Database Migration Service
Dieser Abschnitt bietet einen Überblick über die häufigsten Ursachen für die Latenz von AWS DMS Aufgaben während der laufenden Replikationsphase (CDC). AWS DMS repliziert Daten asynchron. Latenz ist die Verzögerung zwischen dem Zeitpunkt, an dem eine Änderung an der Quelle freigeschaltet wurde, und dem Zeitpunkt, an dem die Änderung auf das Ziel repliziert wurde. Latenz kann durch Fehlkonfigurationen von Replikationskomponenten wie beispielsweise den folgenden verursacht werden:
+ Quellendpunkt oder Datenquelle
+ Zielendpunkt oder Datenquelle
+ Replikations-Instances
+ Das Netzwerk zwischen diesen Komponenten
Es wird empfohlen, eine Testmigration als Machbarkeitsnachweis zu verwenden, um Informationen über Ihre Replikation zu erfassen. Sie können diese Informationen dann verwenden, um Ihre Replikationskonfiguration zu optimieren und die Latenz zu minimieren. Informationen zur Ausführung einer Migration als Machbarkeitsnachweis finden Sie unter [Ausführen eines Machbarkeitsnachweises](CHAP_BestPractices.md#CHAP_BestPractices.RunPOC).
**Topics**
+ [CDC-Latenztypen](#CHAP_Troubleshooting_Latency_Types)
+ [Häufige Ursachen für CDC-Latenz](#CHAP_Troubleshooting_Latency_Causes)
+ [Fehlersuche bei Latenzproblemen](CHAP_Troubleshooting_Latency_Troubleshooting.md)
## CDC-Latenztypen
In diesem Abschnitt werden die Typen von Replikationslatenz beschrieben, die während CDC auftreten können.
### Quelllatenz
Die Verzögerung zwischen dem Commit des letzten vom Quellendpunkt erfassten Ereignisses und dem aktuellen Systemzeitstempel der Replikations-Instance in Sekunden. Mithilfe der Metrik können Sie die Latenz zwischen der Datenquelle und Ihrer Replikationsinstanz überwachen. `CDCLatencySource` CloudWatch Eine hohe `CDCLatencySource`-Metrik weist darauf hin, dass der Prozess der Erfassung von Änderungen aus der Quelle verzögert wird. Wenn Ihre Anwendung beispielsweise um 10:00 Uhr eine Einfügung an die Quelle festschreibt und die Änderung um 10:02 Uhr AWS DMS verarbeitet, beträgt die Metrik 120 Sekunden. `CDCLatencySource`
Informationen zu Metriken für finden Sie unter. CloudWatch AWS DMS[Metriken für die Replikationsaufgabe](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task)
### Ziellatenz
Die Verzögerung zwischen dem Commit des ersten Ereignisses in der Quelle, das für das Ziel freigeschaltet werden soll, und dem aktuellen Zeitstempel der DMS-Replikations-Instance in Sekunden. Mithilfe der `CDCLatencyTarget` CloudWatch Metrik können Sie die Latenz zwischen Commits in der Datenquelle und Ihrem Datenziel überwachen. Dies bedeutet, dass `CDCLatencyTarget` auch Verzögerungen beim Lesen aus der Quelle berücksichtigt. Daher ist `CDCLatencyTarget` immer größer als oder gleich `CDCLatencySource`.
Wenn Ihre Anwendung beispielsweise um 10:00 Uhr eine Einfügung an die Quelle festschreibt und sie um 10:02 Uhr AWS DMS verarbeitet und um 10:05 Uhr in das Ziel schreibt, beträgt die Metrik 300 Sekunden. `CDCLatencyTarget`
## Häufige Ursachen für CDC-Latenz
In diesem Abschnitt werden die Ursachen von Latenz beschrieben, die während CDC bei Ihrer Replikation auftreten können.
**Topics**
+ [Endpunktressourcen](#CHAP_Troubleshooting_Latency_Causes_Endpoint)
+ [Ressourcen für Replikations-Instances](#CHAP_Troubleshooting_Latency_Causes_Replication_Instance)
+ [Netzwerkgeschwindigkeit und -bandbreite](#CHAP_Troubleshooting_Latency_Causes_Replication_Network)
+ [DMS-Konfiguration](#CHAP_Troubleshooting_Latency_Causes_Replication_DMS_Config)
+ [Replikationsszenarien](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios)
### Endpunktressourcen
Die folgenden Faktoren haben erhebliche Auswirkungen auf die Replikationsleistung und -latenz:
+ Konfigurationen der Quell- und Zieldatenbank
+ Instance-Größe
+ Zu wenig bereitgestellter oder falsch konfigurierter Quell- oder Zieldatenspeicher
Um die Ursachen für die Latenz zu ermitteln, die durch Endpunktprobleme AWS bei -gehosteten Quellen und Zielen verursacht werden, sollten Sie die folgenden Messwerte überwachen: CloudWatch
+ `FreeMemory`
+ `CPUUtilization`
+ Durchsatz und I/O Metriken wie, `WriteIOPS``WriteThroughput`, oder `ReadLatency`
+ Metriken zum Transaktionsvolumen wie beispielsweise `CDCIncomingChanges`
Informationen zur Überwachung von CloudWatch Metriken finden Sie unter[AWS Database Migration Service Metriken](CHAP_Monitoring.md#CHAP_Monitoring.Metrics).
### Ressourcen für Replikations-Instances
Die Ressourcen für Replikations-Instances sind für die Replikation entscheidend. Sie sollten sicherstellen, dass es keine Ressourcenengpässe gibt, da diese sowohl Quell- als auch Ziellatenz verursachen können.
Überprüfen Sie Folgendes, um Ressourcenengpässe für Ihre Replikations-Instance zu identifizieren:
+ Bei kritischen CloudWatch Messwerten wie CPU, Arbeitsspeicher I/O pro Sekunde und Speicher treten keine Spitzenwerte oder konstant hohe Werte auf.
+ Ihre Replikations-Instance ist für Ihren Workload angemessen dimensioniert. Informationen zur Ermittlung der richtigen Größe einer Replikations-Instance finden Sie unter [Auswahl der besten Größe für eine Replikations-Instance](CHAP_BestPractices.SizingReplicationInstance.md).
### Netzwerkgeschwindigkeit und -bandbreite
Die Netzwerkbandbreite ist ein Faktor, der sich auf die Datenübertragung auswirkt. Führen Sie einen der folgenden Schritte aus, um die Netzwerkleistung Ihrer Replikation zu analysieren:
+ Überprüfen Sie die Metriken `ReadThroughput` und `WriteThroughput` auf Instance-Ebene. Informationen zur Überwachung von CloudWatch Metriken finden Sie unter. [AWS Database Migration Service Metriken](CHAP_Monitoring.md#CHAP_Monitoring.Metrics)
+ Verwenden Sie das AWS DMS Diagnostic Support AMI. Wenn das Diagnosesupport-AMI in Ihrer Region nicht verfügbar ist, können Sie es aus jeder unterstützten Region herunterladen und in Ihre Region kopieren, um eine Netzwerkanalyse vorzunehmen. Informationen zum Diagnosesupport-AMI finden Sie unter [Arbeiten mit dem AWS DMS Diagnosesupport AMI](CHAP_SupportAmi.md).
Der CDC-Eingang AWS DMS ist Single-Thread-fähig, um die Datenkonsistenz zu gewährleisten. Daher können Sie das Datenvolumen bestimmen, das Ihr Netzwerk unterstützen kann, indem Sie Ihre Single-Thread-Datenübertragungsrate berechnen. Wenn Ihre Aufgabe beispielsweise über ein Netzwerk mit 100 Mbit/s (Megabit pro Sekunde) eine Verbindung zu ihrer Quelle herstellt, hat Ihre Replikation theoretisch eine maximale Bandbreitenzuweisung von 12,5 MBps (Megabyte pro Sekunde). Das entspricht 45 Gigabit pro Stunde. Wenn die Rate der Generierung von Transaktionsprotokollen auf der Quelle mehr als 45 Gigabit pro Stunde beträgt, bedeutet dies, dass bei der Aufgabe CDC-Latenz besteht. Bei einem MBps 100-Netzwerk handelt es sich bei diesen Raten um theoretische Höchstwerte. Andere Faktoren wie Netzwerkverkehr und Ressourcenaufwand für Quelle und Ziel reduzieren die tatsächlich verfügbare Bandbreite.
### DMS-Konfiguration
Dieser Abschnitt enthält empfohlene Replikationskonfigurationen, die zur Verringerung der Latenz beitragen können.
+ **Endpunkteinstellungen**: Ihre Einstellungen für den Quell- und Zielendpunkt können Leistungseinbußen bei Ihrer Replikations-Instance verursachen. Endpunkteinstellungen, die ressourcenintensive Features aktivieren, wirken sich auf die Leistung aus. Bei einem Oracle-Endpunkt verbessert die Deaktivierung LogMiner und Verwendung von Binary Reader beispielsweise die Leistung, da dies ressourcenintensiv LogMiner ist. Die folgende Endpunkteinstellung verbessert die Leistung eines Oracle-Endpunkts:
```
useLogminerReader=N;useBfile=Y
```
Weitere Informationen zu Endpunkteinstellungen finden Sie in der Dokumentation zu Ihrer Quell- und Ziel-Endpunkt-Engine im Thema [Arbeiten mit AWS DMS-Endpunkten](CHAP_Endpoints.md).
+ **Aufgabeneinstellungen**: Einige Aufgabeneinstellungen für Ihr spezielles Replikationsszenario können Leistungseinbußen bei Ihrer Replikations-Instance verursachen. Beispielsweise verwendet AWS DMS standardmäßig den transaktionalen Anwendungsmodus (`BatchApplyEnabled=false`) für CDC für alle Endpunkte außer Amazon Redshift. Bei Quellen mit einer großen Anzahl von Änderungen lässt sich die Leistung jedoch möglicherweise verbessern, wenn `BatchApplyEnabled` auf `true` gesetzt wird.
Weitere Informationen zu den Aufgabeneinstellungen finden Sie unter [Angeben von Aufgabeneinstellungen für Aufgaben des AWS Database Migration Service](CHAP_Tasks.CustomizingTasks.TaskSettings.md).
+ **Startposition einer reinen CDC-Aufgabe**: Wird eine reine CDC-Aufgabe von einer Position oder einem Zeitstempel in der Vergangenheit aus gestartet, wird die Aufgabe mit einer erhöhten CDC-Quelllatenz gestartet. Je nach Umfang der Änderungen an der Quelle dauert es einige Zeit, bis die Aufgabenlatenz nachlässt.
+ **LOB-Einstellungen**: Datentypen mit großen Objekten können die Replikationsleistung aufgrund der Art und Weise AWS DMS beeinträchtigen, wie große Binärdaten repliziert werden. Weitere Informationen finden Sie unter den folgenden Themen:
+ [Einstellung der LOB-Unterstützung für Quelldatenbanken in einer Aufgabe AWS DMS](CHAP_Tasks.LOBSupport.md)
+ [Migrieren großer binärer Objekte () LOBs](CHAP_BestPractices.md#CHAP_BestPractices.LOBS).
### Replikationsszenarien
In diesem Abschnitt werden spezifische Replikationsszenarien und deren mögliche Auswirkungen auf die Latenz beschrieben.
**Topics**
+ [Anhalten einer Aufgabe für einen längeren Zeitraum](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Stoptask)
+ [Zwischengespeicherte Änderungen](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Cachedchanges)
+ [Regionsübergreifende Replikation](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Crossregion)
#### Anhalten einer Aufgabe für einen längeren Zeitraum
Wenn Sie eine Aufgabe beenden, wird die Position des letzten Transaktionslogs AWS DMS gespeichert, das aus der Quelle gelesen wurde. Wenn Sie die Aufgabe fortsetzen, versucht DMS, von derselben Position des Transaktionsprotokolls aus mit dem Lesevorgang fortzufahren. Wird eine Aufgabe nach mehreren Stunden oder Tagen fortgesetzt, erhöht sich die CDC-Quelllatenz, bis DMS den Transaktionsrückstand abgearbeitet hat.
#### Zwischengespeicherte Änderungen
**Zwischengespeicherte Änderungen sind Änderungen**, die Ihre Anwendung in die Datenquelle schreibt, während die Replikationsphase unter Volllast AWS DMS ausgeführt wird. DMS wendet diese Änderungen erst an, wenn die Volllastphase abgeschlossen ist und die CDC-Phase beginnt. Bei einer Quelle mit einer großen Anzahl von Transaktionen dauert das Übernehmen zwischengespeicherter Änderungen länger. Daher nimmt die Quelllatenz zu, wenn die CDC-Phase beginnt. Wir empfehlen, die Volllastphase auszuführen, wenn das Transaktionsvolumen gering ist, um die Anzahl der zwischengespeicherten Änderungen zu minimieren.
#### Regionsübergreifende Replikation
Wenn Sie Ihre DMS-Endpunkte oder Ihre Replikationsinstanz in verschiedenen AWS Regionen lokalisieren, erhöht sich die Netzwerklatenz. Dadurch erhöht sich auch die Replikationslatenz. Um eine optimale Leistung zu erzielen, sollten Sie Ihren Quellendpunkt, Ihren Zielendpunkt und Ihre Replikationsinstanz in derselben AWS Region lokalisieren.
# Fehlersuche bei Latenzproblemen
Dieser Abschnitt enthält Schritte zur Fehlerbehebung bei der Replikationslatenz.
Gehen Sie wie folgt vor, um Latenzprobleme zu beheben:
+ Ermitteln Sie zunächst die Art und den Umfang der Latenz für die Aufgabe. Überprüfen Sie in der DMS-Konsole oder der CLI den Abschnitt Tabellenstatistik der Aufgabe. Wenn sich die Zähler ändern, wird gerade eine Datenübertragung ausgeführt. Überprüfen Sie die Metriken `CDCLatencySource` und `CDCLatencyTarget` zusammen, um zu ermitteln, ob es während CDC einen Engpass gibt.
+ Wenn hohe `CDCLatencySource`- oder `CDCLatencyTarget`-Metriken auf einen Engpass in Ihrer Replikation hinweisen, überprüfen Sie Folgendes:
+ Wenn `CDCLatencySource` hoch und gleich `CDCLatencyTarget` 0 ist`CDCLatencySource`, deutet dies darauf hin, dass Ihr Quellendpunkt einen Engpass aufweist und AWS DMS dass Daten problemlos auf das Ziel geschrieben werden. Weitere Informationen finden Sie im Nachfolgenden unter [Fehlersuche bei Problemen mit der Quelllatenz](CHAP_Troubleshooting_Latency_Source.md).
+ Wenn `CDCLatencySource` der Wert niedrig und der Wert hoch `CDCLatencyTarget` ist, deutet dies darauf hin, dass Ihr Zielendpunkt einen Engpass aufweist und AWS DMS dass die Daten problemlos von der Quelle gelesen werden. Weitere Informationen finden Sie im Nachfolgenden unter [Fehlersuche bei Problemen mit der Ziellatenz](CHAP_Troubleshooting_Latency_Target.md).
+ Wenn `CDCLatencySource` hoch und `CDCLatencyTarget` deutlich höher als `CDCLatencySource` ist, deutet dies auf Engpässe sowohl beim Lesen aus der Quelle als auch beim Schreiben in das Ziel hin. Untersuchen Sie zuerst die Quell- und dann die Ziellatenz.
Informationen zur Überwachung von Aufgabenmetriken in DMS finden Sie unter [AWS DMS-Aufgaben überwachen](CHAP_Monitoring.md).
# Fehlersuche bei Problemen mit der Quelllatenz
In den folgenden Themen werden spezifische Replikationsszenarien für Quellendpunkttypen beschrieben.
**Topics**
+ [Fehlersuche bei Oracle-Endpunkten](CHAP_Troubleshooting_Latency_Source_Oracle.md)
+ [Fehlersuche bei MySQL-Endpunkten](CHAP_Troubleshooting_Latency_Source_MySQL.md)
+ [Fehlersuche bei PostgreSQL-Endpunkten](CHAP_Troubleshooting_Latency_Source_PostgreSQL.md)
+ [Fehlersuche bei SQL-Server-Endpunkten](CHAP_Troubleshooting_Latency_Source_SQLServer.md)
# Fehlersuche bei Oracle-Endpunkten
Dieser Abschnitt enthält spezifische Replikationsszenarien für Oracle.
## Das Lesen aus der Quelle wurde angehalten
AWS DMS unterbricht in den folgenden Szenarien das Lesen aus einer Oracle-Quelle. Dieses Verhalten ist beabsichtigt. Sie können die Ursachen dafür mithilfe des Aufgabenprotokolls untersuchen. Suchen Sie im Aufgabenprotokoll nach Meldungen, die den folgenden ähneln. Weitere Informationen zur Arbeit mit dem Aufgabenprotokoll finden Sie unter [AWS DMS-Aufgabenprotokolle anzeigen und verwalten](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs).
+ **SORTER-Meldung**: Dies weist darauf hin, dass DMS Transaktionen auf der Replikations-Instance zwischenspeichert. Weitere Informationen finden Sie unter [SORTER-Meldung im Aufgabenprotokoll](CHAP_Troubleshooting_Latency_Target.md#CHAP_Troubleshooting_Latency_Target_Sorter).
+ **Aufgabenprotokolle debuggen**: Wenn DMS den Lesevorgang unterbricht, schreibt Ihre Aufgabe wiederholt die folgende Meldung in die Debug-Aufgabenprotokolle, ohne Änderungen am Kontextfeld oder Zeitstempel:
+ **Binary Reader**:
```
[SOURCE_CAPTURE ]T: Produce CTI event:
context '00000020.f23ec6e5.00000002.000a.00.0000:190805.3477731.16'
xid [00000000001e0018] timestamp '2021-07-19 06:57:55'
thread 2 (oradcdc_oralog.c:817)
```
+ **Logminer**:
```
[SOURCE_CAPTURE ]T: Produce INSERT event:
object id 1309826 context '000000000F2CECAA010000010005A8F500000275016C0000000000000F2CEC58'
xid [000014e06411d996] timestamp '2021-08-12 09:20:32' thread 1 (oracdc_reader.c:2269)
```
+ AWS DMS protokolliert die folgende Meldung für jeden neuen Redo- oder archivierten Log-Vorgang.
```
00007298: 2021-08-13T22:00:34 [SOURCE_CAPTURE ]I: Start processing archived Redo log sequence 14850 thread 2 name XXXXX/XXXXX/ARCHIVELOG/2021_08_14/thread_2_seq_14850.22977.1080547209 (oradcdc_redo.c:754)
```
Wenn die Quelle neue Redo- oder Archivierungsvorgänge durchführt und AWS DMS diese Meldungen nicht in das Protokoll schreibt, bedeutet dies, dass die Aufgabe keine Ereignisse verarbeitet.
## Hohe Redo-Generierung
Wenn Ihre Aufgabe Redo- oder archivierte Protokolle verarbeitet, die Quelllatenz jedoch hoch bleibt, versuchen Sie, die Redo-Protokollgenerierungsrate und -generierungsmuster zu ermitteln. Eine hohe Redo-Protokollgenerierungsrate führt zu einer höheren Quelllatenz, da Ihre Aufgabe alle Redo- und Archivierungsprotokolle liest, um Änderungen im Zusammenhang mit den replizierten Tabellen abzurufen.
Verwenden Sie die folgenden Abfragen, um die Redo-Generierungsrate zu ermitteln.
+ Redo-Generierungsrate pro Tag:
```
select trunc(COMPLETION_TIME,'DD') Day, thread#,
round(sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024) GB,
count(*) Archives_Generated from v$archived_log
where completion_time > sysdate- 1
group by trunc(COMPLETION_TIME,'DD'),thread# order by 1;
```
+ Redo-Generierungsrate pro Stunde:
```
Alter session set nls_date_format = 'DD-MON-YYYY HH24:MI:SS';
select trunc(COMPLETION_TIME,'HH') Hour,thread# ,
round(sum(BLOCKS*BLOCK_SIZE)/1024/1024) "REDO PER HOUR (MB)",
count(*) Archives from v$archived_log
where completion_time > sysdate- 1
group by trunc(COMPLETION_TIME,'HH'),thread# order by 1 ;
```
Überprüfen Sie Folgendes, um Latenzprobleme in diesem Szenario zu beheben:
+ Überprüfen Sie die Netzwerkbandbreite und die Single-Thread-Leistung Ihrer Replikation, um sicherzustellen, dass Ihr zugrunde liegendes Netzwerk die Redo-Generierungsrate der Quelle unterstützen kann. Informationen zu den möglichen Auswirkungen der Netzwerkbandbreite auf die Replikationsleistung finden Sie unter [Netzwerkgeschwindigkeit und -bandbreite](CHAP_Troubleshooting_Latency.md#CHAP_Troubleshooting_Latency_Causes_Replication_Network).
+ Überprüfen Sie, ob Sie die zusätzliche Protokollierung korrekt eingerichtet haben. Vermeiden Sie zusätzliche Protokollierung an der Quelle, wie beispielsweise die Aktivierung der Protokollierung für alle Spalten einer Tabelle. Weitere Informationen zum Einrichten der zusätzlichen Protokollierung finden Sie unter [Einrichten der zusätzlichen Protokollierung](CHAP_Source.Oracle.md#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging).
+ Stellen Sie sicher, dass Sie die richtige API verwenden, um die Redo- oder archivierten Protokolle zu lesen. Sie können entweder Oracle LogMiner oder AWS DMS Binary Reader verwenden. Binary Reader LogMiner liest zwar die Online-Redo-Logs und archivierten Redo-Log-Dateien, liest und analysiert die rohen Redo-Log-Dateien jedoch direkt. Daher ist Binary Reader leistungsfähiger. Wir empfehlen, Binary Reader zu verwenden, wenn die Redo-Protokollgenerierung mehr als 10 GB/Stunde umfasst. Weitere Informationen finden Sie unter [Verwenden von Oracle LogMiner oder AWS DMS Binary Reader für CDC](CHAP_Source.Oracle.md#CHAP_Source.Oracle.CDC).
+ Überprüfen Sie, ob Sie `ArchivedLogsOnly` auf `Y` gesetzt haben. Wenn diese Endpunkteinstellung festgelegt ist, liest AWS DMS aus den archivierten Redo-Protokollen. Dies erhöht die Latenz der Quelle, da vor dem AWS DMS Lesen auf die Archivierung des Online-Redo-Logs gewartet wird. Weitere Informationen finden Sie unter [ArchivedLogsOnly](https://docs.aws.amazon.com/dms/latest/APIReference/API_OracleSettings.html#DMS-Type-OracleSettings-ArchivedLogsOnly).
+ Wenn Ihre Oracle-Quelle Automatic Storage Management (ASM) verwendet, erhalten Sie unter [REDO wird auf Oracle ASM gespeichert, wenn Oracle als Quelle für verwendet wird AWS DMS](CHAP_Source.Oracle.md#CHAP_Source.Oracle.REDOonASM) Informationen zur ordnungsgemäßen Konfiguration Ihres Datenspeichers. Möglicherweise können Sie die Leseleistung auch weiter optimieren, wenn Sie das zusätzliche Verbindungsattribut (Extra Connection Attrribute, ECA) `asmUsePLSQLArray` verwenden. Für weitere Informationen zur Nutzung von `asmUsePLSQLArray` siehe [Endpunkteinstellungen bei Verwendung von Oracle als Quelle für AWS DMS](CHAP_Source.Oracle.md#CHAP_Source.Oracle.ConnectionAttrib).
# Fehlersuche bei MySQL-Endpunkten
Dieser Abschnitt enthält spezifische Replikationsszenarien für MySQL. AWS DMS scannt das MySQL-Binärlog regelmäßig, um Änderungen zu replizieren. Dieser Prozess kann die Latenz in den folgenden Szenarien erhöhen:
**Topics**
+ [Lang laufende Transaktion in der Quelle](#CHAP_Troubleshooting_Latency_Source_MySQL_Longrunning)
+ [Hoher Workload in der Quelle](#CHAP_Troubleshooting_Latency_Source_MySQL_Highworkload)
+ [Binärprotokoll-Konflikt](#CHAP_Troubleshooting_Latency_Source_MySQL_Binarylog)
## Lang laufende Transaktion in der Quelle
Da MySQL nur freigeschaltete Transaktionen in das Binärprotokoll schreibt, verursachen lang laufende Transaktionen Latenzspitzen, die proportional zur Abfrageausführungszeit sind.
Verwenden Sie die folgende Abfrage oder das Slow-Query-Protokoll, um lang laufende Transaktionen zu identifizieren:
```
SHOW FULL PROCESSLIST;
```
Informationen zur Verwendung des Slow-Query-Protokolls finden Sie unter [The Slow Query Log](https://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html) in der [MySQL-Dokumentation](https://dev.mysql.com/doc/).
Strukturieren Sie Ihre Quelltransaktionen neu, um entweder die Abfrageausführungszeit zu verringern oder die Häufigkeit der Commits zu erhöhen und dadurch Latenzspitzen aufgrund lang laufender Transaktionen zu vermeiden.
## Hoher Workload in der Quelle
Da es sich bei CDC in DMS um einen Single-Thread-Prozess handelt, kann eine große Anzahl von Transaktionen zu einer höheren Quelllatenz führen. Vergleichen Sie die Anzahl und Größe der während der Latenzzeit generierten Binärprotokolle mit den vor der Latenzzeit generierten Protokollen, um zu ermitteln, ob die Quelllatenz auf einen hohen Workload zurückzuführen ist. Verwenden Sie die folgenden Abfragen, um die Binärprotokolle und den Status des DMS-CDC-Threads zu überprüfen:
```
SHOW BINARY LOGS;
SHOW PROCESSLIST;
```
Weitere Informationen zu den Status von CDC-Binärprotokoll-Dump-Threads finden Sie unter [Replication Source Thread States](https://dev.mysql.com/doc/refman/8.0/en/source-thread-states.html).
Sie können die Latenz ermitteln, indem Sie die letzte Binärprotokoll-Position, die in der Quelle generiert wurde, mit dem Ereignis vergleichen, das DMS gerade verarbeitet. Gehen Sie wie folgt vor, um das neueste Binärprotokoll der Quelle zu identifizieren:
+ Aktivieren Sie Debug-Protokolle für die Komponente SOURCE\$1CAPTURE.
+ Rufen Sie das Binärprotokoll zur DMS-Verarbeitung und die Positionsdetails aus den Debug-Protokollen der Aufgabe ab.
+ Verwenden Sie die folgende Abfrage, um das neueste Binärprotokoll der Quelle zu identifizieren:
```
SHOW MASTER STATUS;
```
Optimieren Sie den Wert für `EventsPollInterval`, um die Leistung weiter zu verbessern. Standardmäßig fragt DMS das Binärprotokoll alle 5 Sekunden ab. Sie können die Leistung jedoch verbessern, indem Sie diesen Wert reduzieren. Weitere Informationen zur `EventsPollInterval`-Einstellung finden Sie unter [Endpunkteinstellungen bei Verwendung von MySQL als Quelle für AWS DMS](CHAP_Source.MySQL.md#CHAP_Source.MySQL.ConnectionAttrib).
## Binärprotokoll-Konflikt
Für die Migration mehrerer Tabellen mit einer großen Datenmenge empfehlen wir, die Tabellen in separate Aufgaben für MySQL 5.7.2 oder höher aufzuteilen. In den MySQL-Versionen 5.7.2 und höher erzeugt der Master-Dump-Thread weniger Sperrkonflikte und verbessert den Durchsatz. Daher sperrt der Dump-Thread das Binärprotokoll nicht mehr, wenn er ein Ereignis liest. Dies bedeutet, dass mehrere Dump-Threads die Binärprotokolldatei gleichzeitig lesen können. Außerdem bedeutet dies, dass Dump-Threads das Binärprotokoll lesen können, während Clients darin schreiben. Weitere Informationen zu Dump-Threads finden Sie unter [Replication Threads](https://dev.mysql.com/doc/refman/8.0/en/replication-threads.html) und in den [Versionshinweisen zu MySQL 5.7.2](https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-2.html).
Zum Verbessern der Replikationsleistung für MySQL-Quellversionen vor 5.7.2 sollten Sie versuchen, Aufgaben mit CDC-Komponenten zusammenzufassen.
# Fehlersuche bei PostgreSQL-Endpunkten
Dieser Abschnitt enthält spezifische Replikationsszenarien für PostgreSQL.
**Topics**
+ [Lang laufende Transaktion in der Quelle](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Longrunning)
+ [Hoher Workload in der Quelle](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highworkload)
+ [Hohen Netzwerkdurchsatz](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highnetwork)
+ [Dateien in Aurora PostgreSQL ausgeben](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill)
## Lang laufende Transaktion in der Quelle
Wenn in der Quelldatenbank lang laufende Transaktionen vorhanden sind, z. B. einige Tausend Einfügungen in einer einzelnen Transaktion, steigen die DMS-CDC-Ereignis- und Transaktionszähler erst an, wenn die Transaktion abgeschlossen ist. Diese Verzögerung kann Latenzprobleme verursachen, die Sie anhand der Metrik `CDCLatencyTarget` messen können.
Führen Sie einen der folgenden Schritte aus, um lang laufende Transaktionen zu überprüfen:
+ Verwenden Sie die Ansicht `pg_replication_slots`. Wenn der `restart_lsn` Wert nicht aktualisiert wird, ist es wahrscheinlich, dass PostgreSQL aufgrund von lang andauernden aktiven Transaktionen nicht in der Lage ist, Write Ahead Logs (WALs) zu veröffentlichen. Informationen zur Ansicht `pg_replication_slots` finden Sie unter [pg\$1replication\$1slots](https://www.postgresql.org/docs/15/view-pg-replication-slots.html) in der [Dokumentation zu PostgreSQL 15.4](https://www.postgresql.org/docs/15/).
+ Verwenden Sie die folgende Abfrage, um eine Liste aller aktiven Abfragen in der Datenbank zusammen mit den zugehörigen Informationen zurückzugeben:
```
SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity WHERE query != ''
AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
```
Das Feld `age` in den Abfrageergebnissen zeigt die aktive Dauer der einzelnen Abfragen an, anhand derer Sie lang laufende Abfragen identifizieren können.
## Hoher Workload in der Quelle
Wenn Ihre PostgreSQL-Quelle einen hohen Workload aufweist, überprüfen Sie Folgendes, um die Latenz zu reduzieren:
+ Wenn Sie das Plug-in `test_decoding` während der Migration einer Teilmenge von Tabellen aus der Quelldatenbank mit einem hohen TPS-Wert (Transaktionen pro Sekunde) verwenden, kann es zu einer hohen Latenz kommen. Dies liegt daran, dass das Plug-in `test_decoding` alle Datenbankänderungen an die Replikations-Instance sendet, die DMS dann basierend auf der Tabellenzuordnung der Aufgabe filtert. Ereignisse für Tabellen, die nicht Teil der Tabellenzuordnung der Aufgabe sind, können die Quelllatenz erhöhen.
+ Überprüfen Sie den TPS-Durchsatz anhand einer der folgenden Methoden:
+ Verwenden Sie für Aurora PostgreSQL-Quellen die `CommitThroughput` CloudWatch Metrik.
+ Verwenden Sie für PostgreSQL, das in Amazon RDS oder On-Premises ausgeführt wird, die folgende Abfrage mit einem PSQL-Client der Version 11 oder höher (drücken Sie während der Abfrage **enter**, um die Ergebnisse weiterzuleiten):
```
SELECT SUM(xact_commit)::numeric as temp_num_tx_ini FROM pg_stat_database; \gset
select pg_sleep(60);
SELECT SUM(xact_commit)::numeric as temp_num_tx_final FROM pg_stat_database; \gset
select (:temp_num_tx_final - :temp_num_tx_ini)/ 60.0 as "Transactions Per Second";
```
+ Um die Latenz bei der Verwendung des Plug-ins `test_decoding` zu reduzieren, sollten Sie stattdessen das Plug-in `pglogical` verwenden. Im Gegensatz zum Plug-in `test_decoding` filtert das Plug-in `pglogical` Änderungen an Write-Ahead-Protokollen (WALs) an der Quelle und sendet nur relevante Änderungen an die Replikations-Instance. Hinweise zur Verwendung des `pglogical` Plug-ins mit finden Sie AWS DMS unter. [Konfigurieren des Plug-ins pglogical](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security.Pglogical)
## Hohen Netzwerkdurchsatz
Bei Ihrer Replikation wird möglicherweise eine hohe Netzwerkbandbreite beansprucht, wenn Sie das Plug-in `test_decoding` verwenden, insbesondere bei Transaktionen mit hohem Volumen. Dies liegt daran, dass das Plug-in `test_decoding` Änderungen verarbeitet und in ein für Menschen lesbares Format umwandelt, das größer als das ursprüngliche Binärformat ist.
Zum Verbessern der Leistung sollten Sie stattdessen das Plug-in `pglogical` verwenden, bei dem es sich um ein binäres Plug-in handelt. Im Gegensatz zum Plug-in `test_decoding` generiert das Plug-in `pglogical` eine Ausgabe im Binärformat, was zu komprimierten Änderungen des Write-Ahead-Protokoll (WAL)-Streams führt.
## Dateien in Aurora PostgreSQL ausgeben
In PostgreSQL Version 13 und höher bestimmt der `logical_decoding_work_mem` Parameter die Speicherzuweisung für Decodierung und Streaming. Weitere Informationen zu dem `logical_decoding_work_mem` Parameter finden Sie unter [Resource Consumption in PostgreSQL in der [PostgreSQL](https://www.postgresql.org/docs/13/)](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM) 13.13-Dokumentation.
Bei der logischen Replikation werden Änderungen für alle Transaktionen im Speicher gesammelt, bis diese Transaktionen festgeschrieben werden. Wenn die in allen Transaktionen gespeicherte Datenmenge die durch den Datenbankparameter angegebene Menge überschreitet`logical_decoding_work_mem`, gibt DMS die Transaktionsdaten auf die Festplatte aus, um Speicherplatz für neue Dekodierungsdaten freizugeben.
Transaktionen mit langer Laufzeit oder viele Untertransaktionen können dazu führen, dass DMS mehr Speicher für die logische Dekodierung verbraucht. Diese erhöhte Speicherauslastung führt dazu, dass DMS Spill-Dateien auf der Festplatte erstellt, was zu einer hohen Quelllatenz während der Replikation führt.
Gehen Sie wie folgt vor, um die Auswirkungen einer Erhöhung der Quell-Workload zu verringern:
+ Reduzieren Sie lang andauernde Transaktionen.
+ Reduzieren Sie die Anzahl der Untertransaktionen.
+ Vermeiden Sie es, Operationen auszuführen, die eine große Anzahl von Protokolldatensätzen generieren, wie z. B. das Löschen oder Aktualisieren einer ganzen Tabelle in einer einzigen Transaktion. Führen Sie Operationen stattdessen in kleineren Batches durch.
Sie können die folgenden CloudWatch Metriken verwenden, um die Arbeitslast an der Quelle zu überwachen:
+ `TransactionLogsDiskUsage`: Die Anzahl der Byte, die derzeit von der logischen WAL belegt sind. Dieser Wert steigt monoton an, wenn die logischen Replikationssteckplätze nicht in der Lage sind, mit der Geschwindigkeit neuer Schreibvorgänge Schritt zu halten, oder wenn langwierige Transaktionen die Garbage-Collection älterer Dateien verhindern.
+ `ReplicationSlotDiskUsage`: Die Menge an Festplattenspeicher, die die logischen Replikationsslots derzeit belegen.
Sie können die Latenz der Quelle reduzieren, indem Sie den `logical_decoding_work_mem` Parameter optimieren. Der Standardwert für diesen Parameter ist 64 MB. Dieser Parameter begrenzt die Speichermenge, die von jeder logischen Streaming-Replikationsverbindung verwendet wird. Es wird empfohlen, den `logical_decoding_work_mem` Wert deutlich höher als den `work_mem` Wert festzulegen, um die Anzahl der dekodierten Änderungen zu reduzieren, die DMS auf die Festplatte schreibt.
Es wird empfohlen, Dateien regelmäßig auf überladene Dateien zu überprüfen, insbesondere in Zeiten starker Migrationsaktivitäten oder Latenz. Wenn DMS eine beträchtliche Anzahl von Spill-Dateien erstellt, bedeutet dies, dass die logische Dekodierung nicht effizient funktioniert, was die Latenz erhöhen kann. Um dies zu verringern, erhöhen Sie den Parameterwert. `logical_decoding_work_mem`
Sie können den aktuellen Transaktionsüberlauf mit der `aurora_stat_file` Funktion überprüfen. Weitere Informationen finden Sie unter [Anpassen des Arbeitsspeichers für die logische Dekodierung](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.html#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem) im *Amazon Relational Database Service Developer Guide*.
# Fehlersuche bei SQL-Server-Endpunkten
Dieser Abschnitt enthält spezifische Replikationsszenarien für SQL Server. Um zu ermitteln, welche Änderungen vom SQL-Server repliziert werden sollen, werden die Transaktionsprotokolle AWS DMS gelesen und die Quelldatenbank regelmäßig gescannt. Die Replikationslatenz ist in der Regel darauf zurückzuführen, dass SQL Server diese Scans aufgrund von Ressourcenbeschränkungen drosselt. Sie kann auch auf einen deutlichen Anstieg der Anzahl von Ereignissen zurückzuführen sein, die innerhalb kurzer Zeit in das Transaktionsprotokoll geschrieben werden.
**Topics**
+ [Index-Neuerstellungen](#CHAP_Troubleshooting_Latency_Source_SQLServer_Indexrebuilds)
+ [Große Transaktionen](#CHAP_Troubleshooting_Latency_Source_SQLServer_Largetransactions)
+ [Falsch konfiguriertes MS-CDC-Abfrageintervall für Amazon RDS SQL Server](#CHAP_Troubleshooting_Latency_Source_SQLServer_MisconfiguredCDC)
+ [Replikation mehrerer CDC-Aufgaben aus derselben Quelldatenbank](#CHAP_Troubleshooting_Latency_Source_SQLServer_MultipleCDC)
+ [Verarbeitung von Transaktionsprotokoll-Backups für RDS für SQL Server](#CHAP_Troubleshooting_Latency_Source_SQLServer_backup)
## Index-Neuerstellungen
Wenn SQL Server einen großen Index neu erstellt, wird eine einzige Transaktion verwendet. Dadurch werden viele Ereignisse generiert und möglicherweise viel Protokollspeicher beansprucht, wenn SQL Server mehrere Indizes gleichzeitig neu erstellt. In diesem Fall können Sie mit kurzen Replikationsspitzen rechnen. Wenn Ihre SQL-Server-Quelle anhaltende Protokollspitzen aufweist, überprüfen Sie Folgendes:
+ Überprüfen Sie zunächst den Zeitraum der Latenzspitzen anhand der `CDCLatencySource` CloudWatch Metriken `CDCLatencySource` und oder anhand der Meldungen zur Durchsatzüberwachung in den Taskprotokollen. Informationen zu CloudWatch Metriken für finden Sie AWS DMS unter[Metriken für die Replikationsaufgabe](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task).
+ Überprüfen Sie, ob die Größe der aktiven Transaktionsprotokolle oder Protokoll-Backups während der Latenzspitze zugenommen hat. Überprüfen Sie außerdem, ob während dieser Zeit ein Wartungsauftrag oder eine Neuerstellung ausgeführt wurde. Informationen zur Überprüfung der Größe des Transaktionsprotokolls finden Sie unter [Monitor log space use](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse) in der [technischen Dokumentation zu SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16).
+ Stellen Sie sicher, dass Ihr Wartungsplan den bewährten Methoden für SQL Server entspricht. Informationen zu den bewährten Methoden für die Wartung von SQL Server finden Sie unter [Index maintenance strategy](https://learn.microsoft.com/en-us/sql/relational-databases/indexes/reorganize-and-rebuild-indexes?view=sql-server-ver16#index-maintenance-strategy) in der [technischen Dokumentation zu SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16).
Versuchen Sie Folgendes, um Latenzprobleme während Index-Neuerstellungen zu beheben:
+ Verwenden Sie das Wiederherstellungsmodell `BULK_LOGGED` für Offline-Neuerstellungen, um die Anzahl der Ereignisse zu reduzieren, die eine Aufgabe verarbeiten muss.
+ Beenden Sie die Aufgabe während der Index-Neuerstellung, wenn möglich. Versuchen Sie alternativ, Index-Neuerstellungen außerhalb der Spitzenzeiten zu planen, um die Auswirkungen einer Latenzspitze zu mildern.
+ Versuchen Sie, Ressourcenengpässe zu identifizieren, die DMS-Lesevorgänge verlangsamen, z. B. Festplattenlatenz oder I/O Durchsatz, und beheben Sie diese.
## Große Transaktionen
Transaktionen mit vielen Ereignissen oder lang laufende Transaktionen lassen das Transaktionsprotokoll anwachsen. Dadurch dauern DMS-Lesevorgänge länger, was zu Latenz führt. Dies ist vergleichbar mit den Auswirkungen von Index-Neuerstellungen auf die Replikationsleistung.
Möglicherweise haben Sie Schwierigkeiten, dieses Problem zu identifizieren, wenn Sie mit dem typischen Workload in der Quelldatenbank nicht vertraut sind. Gehen Sie wie folgt vor, um dieses Problem zu beheben:
+ Identifizieren Sie zunächst anhand der `WriteThroughput` CloudWatch Metriken `ReadThroughput` und oder anhand der Meldungen zur Durchsatzüberwachung in den Taskprotokollen den Zeitpunkt, zu dem die Latenz am höchsten war.
+ Überprüfen Sie, ob es in der Quelldatenbank lang laufende Abfragen während der Latenzspitze gibt. Informationen zu lang laufenden Abfragen finden Sie unter [Troubleshoot slow-running queries in SQL Server](https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/performance/troubleshoot-slow-running-queries) in der [technischen Dokumentation zu SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16).
+ Überprüfen Sie, ob die Größe der aktiven Transaktionsprotokolle oder Protokoll-Backups zugenommen hat. Weitere Informationen finden Sie unter [Monitor log space use](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse) in der [technischen Dokumentation zu SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16).
Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben:
+ Die beste Lösung besteht darin, Ihre Transaktionen auf der Anwendungsseite so umzustrukturieren, dass sie schnell abgeschlossen werden.
+ Wenn Sie Ihre Transaktionen nicht umstrukturieren können, besteht eine kurzfristige Lösung darin, nach Ressourcenengpässen wie Festplattenwartezeiten oder CPU-Konflikten zu suchen. Wenn Sie Engpässe in Ihrer Quelldatenbank feststellen, können Sie die Latenz reduzieren, indem Sie die Festplatten-, CPU- und Speicherressourcen für die Quelldatenbank erhöhen. Dadurch werden Konflikte um Systemressourcen reduziert, sodass DMS-Abfragen schneller abgeschlossen werden können.
## Falsch konfiguriertes MS-CDC-Abfrageintervall für Amazon RDS SQL Server
Eine falsch konfigurierte Einstellung für das Abfrageintervall auf Amazon-RDS-Instances kann das Transaktionsprotokoll anwachsen lassen. Das liegt daran, dass die Replikation die Protokollkürzung verhindert. Während laufende Aufgaben möglicherweise weiterhin mit minimaler Latenz repliziert werden, kann das Anhalten und Fortsetzen von Aufgaben oder das Starten von reinen CDC-Aufgaben Aufgabenfehler verursachen. Diese sind auf Zeitüberschreitungen während des Scannens des großen Transaktionsprotokolls zurückzuführen.
Gehen Sie wie folgt vor, um Probleme mit falsch konfigurierten Abfrageintervallen zu beheben:
+ Überprüfen Sie, ob die Größe des aktiven Transaktionsprotokolls zunimmt und ob die Protokollnutzung nahezu 100 Prozent beträgt. Weitere Informationen finden Sie unter [Monitor log space use](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse) in der [technischen Dokumentation zu SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16).
+ Überprüfen Sie, ob die Protokollkürzung mit dem `log_reuse_wait_desc value`-Wert `REPLICATION` verzögert wird. Weitere Informationen finden Sie unter [The Transaction Log (SQL Server)](https://learn.microsoft.com/en-us/sql/relational-databases/logs/the-transaction-log-sql-server?view=sql-server-ver16#FactorsThatDelayTruncation) in der [technischen Dokumentation zu SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16).
Wenn Sie Probleme mit einem der Elemente in der vorherigen Liste feststellen, passen Sie das MS-CDC-Abfrageintervall an. Informationen zur Optimierung des Abfrageintervalls finden Sie unter [Empfohlene Einstellungen bei der Verwendung von RDS für SQL Server als Quelle für AWS DMS](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.Configuration.Settings).
## Replikation mehrerer CDC-Aufgaben aus derselben Quelldatenbank
Während der Volllastphase empfehlen wir, Tabellen auf mehrere Aufgaben aufzuteilen, um die Leistung zu verbessern, abhängige Tabellen logisch voneinander zu trennen und die Auswirkungen eines Aufgabenfehlers zu minimieren. Während der CDC-Phase empfehlen wir jedoch, die Aufgaben zusammenzufassen, um die Anzahl der DMS-Scans zu minimieren. Während der CDC-Phase scannt jede DMS-Aufgabe die Transaktionsprotokolle mehrmals pro Minute auf neue Ereignisse. Da jede Aufgabe unabhängig ausgeführt wird, scannt jede Aufgabe jedes Transaktionsprotokoll einzeln. Dies erhöht die Festplatten- und CPU-Auslastung in der SQL-Server-Quelldatenbank. Infolgedessen kann eine große Anzahl von parallel ausgeführten Aufgaben dazu führen, dass SQL Server DMS-Lesevorgänge drosselt, was eine erhöhte Latenz verursacht.
Möglicherweise haben Sie Schwierigkeiten, dieses Problem zu identifizieren, wenn mehrere Aufgaben schrittweise gestartet werden. Das häufigste Symptom dieses Problems besteht darin, dass die meisten Aufgaben-Scans länger dauern. Dies verursacht eine höhere Latenz bei diesen Scans. SQL Server priorisiert einige Aufgaben-Scans, sodass einige Aufgaben eine normale Latenz aufweisen. Überprüfen Sie die Metrik `CDCLatencySource` für alle Ihre Aufgaben, um dieses Problem zu beheben. Wenn einige der Aufgaben einen zunehmenden Wert für `CDCLatencySource` und andere einen niedrigen Wert für `CDCLatencySource` aufweisen, ist es wahrscheinlich, dass SQL Server Ihre DMS-Lesevorgänge für einige Ihrer Aufgaben drosselt.
Wenn SQL Server Ihre Aufgabenlesevorgänge während CDC drosselt, fassen Sie Ihre Aufgaben zusammen, um die Anzahl der DMS-Scans zu minimieren. Die maximale Anzahl von Aufgaben, die eine Verbindung mit Ihrer Quelldatenbank herstellen können, ohne dass Konflikte entstehen, hängt von Faktoren wie der Kapazität der Quelldatenbank, der Wachstumsrate des Transaktionsprotokolls oder der Anzahl der Tabellen ab. Testen Sie die Replikation in einer Testumgebung, die Ihrer Produktionsumgebung ähnelt, um die ideale Anzahl von Aufgaben für Ihr Replikationsszenario zu ermitteln.
## Verarbeitung von Transaktionsprotokoll-Backups für RDS für SQL Server
AWS DMS 3.5.3 und höher unterstützen die Replikation von RDS für SQL Server-Protokollsicherungen. Das Replizieren von Ereignissen aus den Backup-Logs auf RDS-Instanzen ist langsamer als das Replizieren von Ereignissen aus dem aktiven Transaktionslog. Dies liegt daran, dass DMS seriell Zugriff auf Backups anfordert, um sicherzustellen, dass die Transaktionssequenz beibehalten wird, und um das Risiko zu minimieren, dass der Amazon RDS-Instance-Speicher voll wird. Darüber hinaus variiert die Zeit, die benötigt wird, um die Backups auf der Seite von Amazon RDS für DMS verfügbar zu machen, je nach Größe der Protokollsicherung und der Auslastung der RDS for SQL Server-Instance.
Aufgrund dieser Einschränkungen empfehlen wir, ECA `ActivateSafeguard` auf `true` einzustellen. Dadurch wird sichergestellt, dass Transaktionen nicht gesichert werden, während die DMS-Aufgabe aus dem aktiven Transaktionslog liest. Diese Einstellung verhindert auch, dass Amazon RDS Transaktionen im aktiven Protokoll archiviert, wenn DMS Transaktionen aus dem Backup liest, wodurch die Möglichkeit ausgeschlossen wird, dass DMS das aktive Protokoll nicht aufholen kann. Beachten Sie, dass dies dazu führen kann, dass die Größe des aktiven Protokolls zunimmt, während die Aufgabe aufgeholt wird. Stellen Sie sicher, dass Ihre Instance über genügend Speicherplatz verfügt, damit der Instance nicht der Speicherplatz ausgeht.
Verwenden Sie für eine reine CDC-Aufgabe, die aus RDS für SQL Server-Quellen repliziert wird, wenn möglich die systemeigene CDC-Startposition über der systemeigenen CDC-Startzeit. Das liegt daran, dass sich DMS auf Systemtabellen stützt, um den Startpunkt für die systemeigene Startposition zu ermitteln, anstatt einzelne Protokollsicherungen zu scannen, wenn Sie eine native Startzeit angeben.
# Fehlersuche bei Problemen mit der Ziellatenz
Dieser Abschnitt enthält Szenarien, die zur Ziellatenz beitragen können.
**Topics**
+ [Probleme bei der Indizierung](#CHAP_Troubleshooting_Latency_Target_Indexing)
+ [SORTER-Meldung im Aufgabenprotokoll](#CHAP_Troubleshooting_Latency_Target_Sorter)
+ [Sperren von Datenbanken](#CHAP_Troubleshooting_Latency_Target_Locking)
+ [Langsame LOB-Lookups](#CHAP_Troubleshooting_Latency_Target_LOB)
+ [Multi-AZ, Prüfungsprotokollierung und Backups](#CHAP_Troubleshooting_Latency_Target_MultiAZ)
## Probleme bei der Indizierung
AWS DMS Repliziert während der CDC-Phase Änderungen an der Quelle, indem DML-Anweisungen (insert, update und delete) auf dem Ziel ausgeführt werden. Bei heterogenen Migrationen mit DMS können Unterschiede bei den Indexoptimierungen für die Quelle und das Ziel dazu führen, dass das Schreiben in das Ziel länger dauert. Dies führt zu Problemen mit der Ziellatenz und -leistung.
Gehen Sie wie folgt vor, um Probleme bei der Indizierung zu beheben: Die Verfahren unterscheiden sich je nach Datenbank-Engine.
+ Überwachen Sie die Abfragezeit für Ihre Zieldatenbank. Ein Vergleich der Abfrageausführungszeit für Ziel und Quelle kann Aufschluss darüber geben, welche Indizes optimiert werden müssen.
+ Aktivieren Sie die Protokollierung für langsam laufende Abfragen.
Gehen Sie wie folgt vor, um Probleme bei der Indizierung für lange laufende Replikationen zu beheben:
+ Passen Sie die Indizes Ihrer Quell- und Zieldatenbanken so an, dass die Abfrageausführungszeit für die Quelle und das Ziel ähnlich ist.
+ Vergleichen Sie die in DML-Abfragen verwendeten sekundären Indizes für die Quelle und das Ziel. Stellen Sie sicher, dass die DML-Leistung auf dem Ziel mit der DML-Leistung auf der Quelle vergleichbar oder besser als diese ist.
Beachten Sie, dass das Verfahren zur Optimierung von Indizes spezifisch für Ihre Datenbank-Engine ist. Es gibt kein DMS-Feature zur Optimierung von Quell- und Zielindizes.
## SORTER-Meldung im Aufgabenprotokoll
Wenn ein Zielendpunkt nicht mit der Menge der Änderungen Schritt halten kann, die auf ihn AWS DMS geschrieben werden, speichert die Aufgabe die Änderungen auf der Replikationsinstanz zwischen. Wenn der Cache einen internen Schwellenwert überschreitet, liest die Aufgabe keine weiteren Änderungen aus der Quelle. Auf diese Weise verhindert DMS, dass der Speicherplatz auf der Replikations-Instance knapp wird oder dass die Aufgabe beim Lesen einer großen Menge ausstehender Ereignisse hängen bleibt.
Um dieses Problem zu beheben, suchen Sie in den CloudWatch Protokollen nach einer Meldung, die einer der folgenden ähnelt:
```
[SORTER ]I: Reading from source is paused. Total disk usage exceeded the limit 90% (sorter_transaction.c:110)
[SORTER ]I: Reading from source is paused. Total storage used by swap files exceeded the limit 1048576000 bytes (sorter_transaction.c:110)
```
Wenn Ihre Protokolle eine Meldung enthalten, die der ersten Meldung ähnelt, deaktivieren Sie die Ablaufprotokollierung für die Aufgabe und erhöhen Sie den Speicher der Replikations-Instance. Informationen zum Erhöhen des Speichers der Replikations-Instance finden Sie unter [Ändern einer Replikations-Instance](CHAP_ReplicationInstance.Modifying.md).
Wenn Ihre Protokolle eine Meldung enthalten, die der zweiten Meldung ähnelt, gehen Sie wie folgt vor:
+ Verschieben Sie Tabellen mit zahlreichen Transaktionen oder lang laufenden DML-Operationen in eine separate Aufgabe, wenn sie keine Abhängigkeiten von anderen Tabellen in der Aufgabe aufweisen.
+ Erhöhen Sie die Einstellungen `MemoryLimitTotal` und `MemoryKeepTime`, um die Transaktion für einen längeren Zeitraum im Speicher zu halten. Dies hilft nicht, wenn die Latenz dauerhaft ist, aber es kann dazu beitragen, die Latenz bei kurzen Ausbrüchen des Transaktionsvolumens gering zu halten. Weitere Informationen zu diesen Aufgabeneinstellungen finden Sie unter [Einstellungen für die Optimierung der Verarbeitung von Änderungen](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
+ Prüfen Sie, ob Sie die Stapelanwendung für Ihre Transaktion verwenden können, indem Sie `BatchApplyEnabled` auf `true` setzen. Informationen zur Einstellung `BatchApplyEnabled` finden Sie unter [Ziel-Metadaten-Aufgabeneinstellungen](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md).
## Sperren von Datenbanken
Wenn eine Anwendung auf eine Datenbank zugreift, die als Replikationsziel verwendet AWS DMS wird, sperrt die Anwendung möglicherweise eine Tabelle, auf die DMS zuzugreifen versucht. Dadurch entsteht ein Sperrkonflikt. Da DMS Änderungen in der Reihenfolge in die Zieldatenbank schreibt, in der sie in der Quelle aufgetreten sind, führen Verzögerungen beim Schreiben in eine Tabelle aufgrund von Sperrkonflikten zu Verzögerungen beim Schreiben in alle Tabellen.
Fragen Sie zum Beheben dieses Problems die Zieldatenbank ab, um zu überprüfen, ob ein Sperrkonflikt DMS-Schreibtransaktionen blockiert. Wenn die Zieldatenbank DMS-Schreibtransaktionen blockiert, führen Sie einen oder mehrere der folgenden Schritte aus:
+ Strukturieren Sie Ihre Abfragen neu, sodass Änderungen häufiger freigeschaltet werden.
+ Ändern Sie Ihre Einstellungen für das Sperr-Timeout.
+ Partitionieren Sie Ihre Tabellen, um Sperrkonflikte zu minimieren.
Beachten Sie, dass das Verfahren zur Optimierung von Sperrkonflikten spezifisch für Ihre Datenbank-Engine ist. Es gibt kein DMS-Feature zur Optimierung von Sperrkonflikten.
## Langsame LOB-Lookups
Wenn eine LOB-Spalte (Large Object) AWS DMS repliziert wird, führt sie eine Suche in der Quelle durch, kurz bevor Änderungen in das Ziel geschrieben werden. Dieser Lookup verursacht in der Regel keine Latenz auf dem Ziel. Wenn die Quelldatenbank den Lookup jedoch aufgrund von Sperren verzögert, kann dies zu einem Anstieg der Ziellatenz führen.
Dieses Problem ist in der Regel schwer zu diagnostizieren. Aktivieren Sie das detaillierte Debugging in den Aufgabenprotokollen und vergleichen Sie die Zeitstempel der LOB-Lookup-Aufrufe in DMS, um dieses Problem zu beheben. Informationen zur Aktivierung des detaillierten Debuggings finden Sie unter [AWS DMS-Aufgabenprotokolle anzeigen und verwalten](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs).
Versuchen Sie Folgendes, um dieses Problem zu beheben:
+ Verbessern Sie die Leistung der SELECT-Abfrage in der Quelldatenbank.
+ Passen Sie die DMS-LOB-Einstellungen an. Informationen zum Anpassen der LOB-Einstellungen finden Sie unter [Migrieren großer binärer Objekte () LOBs](CHAP_BestPractices.md#CHAP_BestPractices.LOBS).
## Multi-AZ, Prüfungsprotokollierung und Backups
Bei Amazon-RDS-Zielen kann sich die Ziellatenz in den folgenden Fällen erhöhen:
+ Sicherungen
+ Nach der Aktivierung mehrerer Availability Zones (Multi-AZ)
+ Nach der Aktivierung der Datenbankprotokollierung, wie beispielsweise Prüfungs- oder Slow-Query-Protokolle.
Diese Probleme sind in der Regel schwer zu diagnostizieren. Überwachen Sie die Latenz auf periodische Spitzenwerte während der Wartungsfenster von Amazon RDS oder bei hoher Datenbanklast, um diese Probleme zu beheben.
Versuchen Sie Folgendes, um diese Probleme zu beheben:
+ Wenn möglich, deaktivieren Sie während einer kurzfristigen Migration Multi-AZ, Backups oder die Protokollierung.
+ Verschieben Sie Ihre Wartungsfenster auf Zeiträume mit geringer Aktivität.
# Arbeiten mit Skripten zur Diagnoseunterstützung in AWS DMS
Wenn Sie bei der Arbeit mit auf ein Problem stoßen AWS DMS, benötigt Ihr Support-Techniker möglicherweise weitere Informationen zu Ihrer Quell- oder Zieldatenbank. Wir möchten sicherstellen, dass der AWS Support so viele der erforderlichen Informationen wie möglich in kürzester Zeit erhält. Aus diesem Grund haben wir Skripts entwickelt, um diese Informationen für mehrere der wichtigsten relationalen Datenbank-Engines abzufragen.
Wenn ein Unterstützungsskript für Ihre Datenbank verfügbar ist, können Sie es über den Link im entsprechenden Skriptthema im folgenden Abschnitt herunterladen. Nachdem Sie das Skript überprüft haben (wie nachfolgend beschrieben), können Sie es gemäß dem im Skriptthema beschriebenen Verfahren ausführen. Wenn die Ausführung des Skripts abgeschlossen ist, können Sie seine Ausgabe in Ihren AWS Support-Fall hochladen (ebenfalls unten beschrieben).
Bevor Sie das Skript ausführen, können Sie alle Fehler erkennen, die möglicherweise beim Herunterladen oder Speichern des Unterstützungsskripts aufgetreten sind. Vergleichen Sie dazu die Prüfsumme für die Skriptdatei mit einem Wert von AWS. AWS verwendet den SHA256 Algorithmus für die Prüfsumme.
**So prüfen Sie die Unterstützungsskriptdatei anhand einer Prüfsumme**
1. Öffnen Sie die neueste Prüfsummendatei, die zur Prüfung dieser Unterstützungsskripts zur Verfügung gestellt wurde, unter [https://d2pwp9zz55emqw.cloudfront.net/sha256Check.txt](https://d2pwp9zz55emqw.cloudfront.net/sha256Check.txt). Beispielsweise könnte die Datei einen Inhalt wie den folgenden haben.
```
MYSQL dfafd0d511477c699f96c64693ad0b1547d47e74d5c5f2f2025b790b1422e3c8
ORACLE 6c41ebcfc99518cfa8a10cb2ce8943b153b2cc7049117183d0b5de3d551bc312
POSTGRES 6ccd274863d14f6f3146fbdbbba43f2d8d4c6a4c25380d7b41c71883aa4f9790
SQL_SERVER 971a6f2c46aec8d083d2b3b6549b1e9990af3a15fe4b922e319f4fdd358debe7
```
1. Führen Sie den SHA256 Validierungsbefehl für Ihr Betriebssystem in dem Verzeichnis aus, das die Support-Datei enthält. Auf dem macOS-Betriebssystem können Sie beispielsweise den folgenden Befehl in einem Oracle-Unterstützungsskript ausführen, das später in diesem Thema beschrieben wird.
```
shasum -a 256 awsdms_support_collector_oracle.sql
```
1. Vergleichen Sie die Ergebnisse des Befehls mit dem Wert, der in der zuletzt geöffneten `sha256Check.txt`-Datei angezeigt wird. Die beiden Werte sollten übereinstimmen. Wenn dies nicht der Fall ist, informieren Sie Ihren Support-Techniker darüber, um zu erfahren, wie Sie eine saubere Unterstützungsskriptdatei erhalten können.
Wenn Sie über eine saubere Unterstützungsskriptdatei verfügen, stellen Sie vor der Ausführung des Skripts sicher, dass Sie die SQL sowohl aus Leistungs- als auch aus Sicherheitsperspektive gelesen und verstanden haben. Wenn Sie mit der Ausführung von SQL in diesem Skript nicht vertraut sind, können Sie das problematische SQL auskommentieren oder entfernen. Sie können sich auch an Ihren Support-Techniker wenden, um mögliche Behelfslösungen zu besprechen.
Nach erfolgreichem Abschluss und sofern nicht anders angegeben, gibt das Skript die Ausgabe in einem lesbaren HTML-Format zurück. Das Skript ist so konzipiert, dass alle Daten oder Sicherheitsdetails, die Ihr Unternehmen gefährden könnten, aus diesem HTML-Code ausgeschlossen werden. Es nimmt auch keine Änderungen an Ihrer Datenbank oder ihrer Umgebung vor. Wenn Sie jedoch Informationen im HTML-Code finden, die Sie nicht weitergeben möchten, können Sie die Probleminformationen entfernen, bevor Sie den HTML-Code hochladen. Wenn der HTML-Code akzeptabel ist, laden Sie ihn mithilfe der **Anlagen** in den **Falldetails** Ihres Support-Falls hoch.
Jedes der folgenden Themen beschreibt die Skripts, die für eine unterstützte AWS DMS Datenbank verfügbar sind, und wie sie ausgeführt werden. Ihr Support-Techniker wird Sie zu einem bestimmten Skript weiterleiten, das im Folgenden dokumentiert ist.
**Topics**
+ [Oracle-Diagnoseunterstützungsskripts](CHAP_SupportScripts.Oracle.md)
+ [SQL-Server-Diagnoseunterstützungsskripts](CHAP_SupportScripts.SQLServer.md)
+ [Diagnoseunterstützungsskripts für MySQL-kompatible Datenbanken](CHAP_SupportScripts.MySQL.md)
+ [PostgreSQL-Diagnoseunterstützungsskripts](CHAP_SupportScripts.PostgreSQL.md)
# Oracle-Diagnoseunterstützungsskripts
Im Folgenden finden Sie die Diagnosesupport-Skripte, die für die Analyse einer lokalen Datenbank oder einer Amazon RDS for Oracle Oracle-Datenbank in Ihrer AWS DMS Migrationskonfiguration verfügbar sind. Diese Skripts funktionieren entweder mit einem Quell- oder Zielendpunkt. Die Skripts wurden alle so geschrieben, dass sie im Befehlszeilen-Dienstprogramm SQL\$1Plus ausgeführt werden können. Weitere Informationen zur Verwendung dieses Dienstprogramms finden Sie unter [Verwendung von SQL Command Line](https://docs.oracle.com/cd/B25329_01/doc/appdev.102/b25108/xedev_sqlplus.htm) in der Oracle-Dokumentation.
Bevor Sie das Skript ausführen, stellen Sie sicher, dass das von Ihnen verwendete Benutzerkonto über die erforderlichen Berechtigungen für den Zugriff auf Ihre Oracle-Datenbank verfügt. Bei den angezeigten Berechtigungseinstellungen wird davon ausgegangen, dass ein Benutzer wie folgt erstellt wurde.
```
CREATE USER script_user IDENTIFIED BY password;
```
Legen Sie für eine On-Premises-Datenbank die Mindestberechtigungen wie folgt für `script_user` fest.
```
GRANT CREATE SESSION TO script_user;
GRANT SELECT on V$DATABASE to script_user;
GRANT SELECT on V$VERSION to script_user;
GRANT SELECT on GV$SGA to script_user;
GRANT SELECT on GV$INSTANCE to script_user;
GRANT SELECT on GV$DATAGUARD_CONFIG to script_user;
GRANT SELECT on GV$LOG to script_user;
GRANT SELECT on DBA_TABLESPACES to script_user;
GRANT SELECT on DBA_DATA_FILES to script_user;
GRANT SELECT on DBA_SEGMENTS to script_user;
GRANT SELECT on DBA_LOBS to script_user;
GRANT SELECT on V$ARCHIVED_LOG to script_user;
GRANT SELECT on DBA_TAB_MODIFICATIONS to script_user;
GRANT SELECT on DBA_TABLES to script_user;
GRANT SELECT on DBA_TAB_PARTITIONS to script_user;
GRANT SELECT on DBA_MVIEWS to script_user;
GRANT SELECT on DBA_OBJECTS to script_user;
GRANT SELECT on DBA_TAB_COLUMNS to script_user;
GRANT SELECT on DBA_LOG_GROUPS to script_user;
GRANT SELECT on DBA_LOG_GROUP_COLUMNS to script_user;
GRANT SELECT on V$ARCHIVE_DEST to script_user;
GRANT SELECT on DBA_SYS_PRIVS to script_user;
GRANT SELECT on DBA_TAB_PRIVS to script_user;
GRANT SELECT on DBA_TYPES to script_user;
GRANT SELECT on DBA_CONSTRAINTS to script_user;
GRANT SELECT on V$TRANSACTION to script_user;
GRANT SELECT on GV$ASM_DISK_STAT to script_user;
GRANT SELECT on GV$SESSION to script_user;
GRANT SELECT on GV$SQL to script_user;
GRANT SELECT on DBA_ENCRYPTED_COLUMNS to script_user;
GRANT SELECT on DBA_PDBS to script_user;
GRANT EXECUTE on dbms_utility to script_user;
```
Legen Sie für eine Amazon-RDS-Datenbank die Mindestberechtigungen wie folgt fest.
```
GRANT CREATE SESSION TO script_user;
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATABASE','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$VERSION','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('GV_$SGA','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('GV_$INSTANCE','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('GV_$DATAGUARD_CONFIG','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('GV_$LOG','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TABLESPACES','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_DATA_FILES','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_SEGMENTS','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_LOBS','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ARCHIVED_LOG','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TAB_MODIFICATIONS','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TABLES','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TAB_PARTITIONS','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_MVIEWS','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_OBJECTS','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TAB_COLUMNS','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_LOG_GROUPS','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_LOG_GROUP_COLUMNS','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ARCHIVE_DEST','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_SYS_PRIVS','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TAB_PRIVS','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TYPES','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_CONSTRAINTS','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TRANSACTION','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('GV_$ASM_DISK_STAT','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('GV_$SESSION','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('GV_$SQL','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_ENCRYPTED_COLUMNS','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_PDBS','script_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_UTILITY','script_user','EXECUTE');
```
Im Folgenden finden Sie Beschreibungen, wie Sie jedes für Oracle verfügbare SQL\$1Plus-Unterstützungsskript herunterladen, überprüfen und ausführen können. Dort erfahren Sie auch, wie Sie die Ausgabe überprüfen und in Ihren AWS -Support-Fall hochladen können.
**Topics**
+ [Das Skript awsdms\$1support\$1collector\$1oracle.sql](#CHAP_SupportScripts.Oracle.Awsdms_Support_Collector_Oracle_Script)
## Das Skript awsdms\$1support\$1collector\$1oracle.sql
Laden Sie das [https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_oracle.sql](https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_oracle.sql)-Skript herunter.
Dieses Skript erfasst Informationen über Ihre Oracle-Datenbankkonfiguration. Denken Sie daran, die Prüfsumme des Skripts zu überprüfen. Wenn die Prüfsumme verifiziert wurde, überprüfen Sie den SQL-Code in dem Skript, um den Code auszukommentieren, dessen Ausführung Sie nicht wünschen. Wenn Sie mit der Integrität und dem Inhalt des Skripts zufrieden sind, können Sie es ausführen.
**So führen Sie das Skript aus und laden die Ergebnisse in Ihren Support-Fall hoch**
1. Führen Sie das Skript in Ihrer Datenbankumgebung mit der folgenden SQL\$1Plus-Befehlszeile aus.
```
SQL> @awsdms_support_collector_oracle.sql
```
Das Skript zeigt eine kurze Beschreibung und eine Aufforderung an, die Ausführung entweder fortzusetzen oder abzubrechen. Betätigen Sie zum Fortfahren die Eingabetaste.
1. Geben Sie bei der folgenden Eingabeaufforderung nur den Namen eines der Schemata ein, die Sie migrieren möchten.
1. Geben Sie bei der folgenden Eingabeaufforderung den Namen des Benutzers (*script\$1user*) ein, den Sie für die Verbindung mit der Datenbank definiert haben.
1. Geben Sie bei der folgenden Eingabeaufforderung die Anzahl der Tage an Daten ein, die Sie untersuchen möchten, oder akzeptieren Sie die Standardeinstellung. Das Skript erfasst dann die angegebenen Daten aus Ihrer Datenbank.
Nach Abschluss des Skripts wird der Name der HTML-Ausgabedatei angezeigt, beispielsweise `dms_support_oracle-2020-06-22-13-20-39-ORCL.html`. Das Skript speichert diese Datei in Ihrem Arbeitsverzeichnis.
1. Überprüfen Sie diese HTML-Datei und entfernen Sie alle Informationen, die Sie nicht weitergeben möchten. Wenn Sie den HTML-Code teilen können, laden Sie die Datei in Ihren AWS Support-Fall hoch. Weitere Informationen zum Hochladen dieser Datei finden Sie unter [Arbeiten mit Skripten zur Diagnoseunterstützung in AWS DMS](CHAP_SupportScripts.md).
# SQL-Server-Diagnoseunterstützungsskripts
Im Folgenden finden Sie eine Beschreibung der Diagnosesupportskripte, die für die Analyse einer lokalen Datenbank oder einer Amazon RDS for SQL Server Server-Datenbank in Ihrer AWS DMS Migrationskonfiguration verfügbar sind. Diese Skripts funktionieren entweder mit einem Quell- oder Zielendpunkt. Führen Sie diese Skript für eine On-Premises-Datenbank im Befehlszeilen-Dienstprogramm sqlcmd aus. Weitere Informationen zur Verwendung dieses Dienstprogramms finden Sie unter [sqlcmd – Verwendung des Hilfsprogramms](https://docs.microsoft.com/en-us/sql/ssms/scripting/sqlcmd-use-the-utility?view=sql-server-ver15) in der Microsoft-Dokumentation.
Bei einer Amazon-RDS-Datenbank können Sie mit dem Befehlszeilen-Dienstprogramm sqlcmd keine Verbindung herstellen. Führen Sie diese Skripts stattdessen mit einem beliebigen Client-Tool aus, das eine Verbindung zu Amazon RDS SQL Server herstellt.
Bevor Sie das Skript ausführen, stellen Sie sicher, dass das von Ihnen verwendete Benutzerkonto über die erforderlichen Berechtigungen für den Zugriff auf Ihre SQL-Server-Datenbank verfügt. Sowohl für eine On-Premises- als auch für eine Amazon-RDS-Datenbank können Sie dieselben Berechtigungen verwenden, die Sie für den Zugriff auf Ihre SQL-Server-Datenbank ohne die `SysAdmin`-Rolle verwenden.
**Topics**
+ [Einrichtung von Mindestberechtigungen für eine On-Premises-SQL-Server-Datenbank](#CHAP_SupportScripts.SQLServer.onprem)
+ [Einrichtung von Mindestberechtigungen für eine Amazon-RDS-SQL-Server-Datenbank](#CHAP_SupportScripts.SQLServer.rds)
+ [SQL-Server-Unterstützungsskripts](#CHAP_SupportScripts.SQLServer.Scripts)
## Einrichtung von Mindestberechtigungen für eine On-Premises-SQL-Server-Datenbank
**So richten Sie Mindestberechtigungen für eine On-Premises-SQL-Server-Datenbank ein**
1. Erstellen Sie unter Verwendung von SQL Server Management Studio (SSMS) ein neues SQL-Server-Konto mit Passwort-Authentifizierung, zum Beispiel `on-prem-user`.
1. Wählen Sie im Abschnitt **Benutzerzuweisungen** von SSMS die Datenbanken **MSDB** und **MASTER** aus (wodurch öffentliche Berechtigungen erteilt werden) und weisen Sie der Datenbank, die Sie für die fortlaufende Replikation verwenden möchten, die Rolle `DB_OWNER` zu.
1. Öffnen Sie das Kontextmenü (rechte Maustaste) für das neue Konto, wählen Sie **Sicherheit** aus, um ausdrücklich die `Connect SQL`-Berechtigung zu erteilen.
1. Führen Sie die folgenden Befehle zum Erteilen der Berechtigung aus.
```
GRANT VIEW SERVER STATE TO on-prem-user;
USE MSDB;
GRANT SELECT ON MSDB.DBO.BACKUPSET TO on-prem-user;
GRANT SELECT ON MSDB.DBO.BACKUPMEDIAFAMILY TO on-prem-user;
GRANT SELECT ON MSDB.DBO.BACKUPFILE TO on-prem-user;
```
## Einrichtung von Mindestberechtigungen für eine Amazon-RDS-SQL-Server-Datenbank
**So richten Sie Mindestberechtigungen für eine Amazon-RDS-SQL-Server-Datenbank ein**
1. Erstellen Sie unter Verwendung von SQL Server Management Studio (SSMS) ein neues SQL-Server-Konto mit Passwort-Authentifizierung, zum Beispiel `rds-user`.
1. Wählen Sie im Abschnitt **Benutzerzuweisungen** von SSMS die Datenbank **MSDB** aus (die öffentliche Zugriffsrechte gewährt) und weisen Sie die `DB_OWNER`-Rolle der Datenbank zu, in der Sie das Skript ausführen möchten.
1. Öffnen Sie das Kontextmenü (rechte Maustaste) für das neue Konto, wählen Sie **Sicherheit** aus, um ausdrücklich die `Connect SQL`-Berechtigung zu erteilen.
1. Führen Sie die folgenden Befehle zum Erteilen der Berechtigung aus.
```
GRANT VIEW SERVER STATE TO rds-user;
USE MSDB;
GRANT SELECT ON MSDB.DBO.BACKUPSET TO rds-user;
GRANT SELECT ON MSDB.DBO.BACKUPMEDIAFAMILY TO rds-user;
GRANT SELECT ON MSDB.DBO.BACKUPFILE TO rds-user;
```
## SQL-Server-Unterstützungsskripts
In den folgenden Themen wird beschrieben, wie jedes für SQL Server verfügbare Unterstützungsskript heruntergeladen, überprüft und ausgeführt wird. Dort erfahren Sie auch, wie Sie die Skriptausgabe überprüfen und in Ihren AWS -Support-Fall hochladen können.
**Topics**
+ [Das Skript awsdms\$1support\$1collector\$1sql\$1server.sql](#CHAP_SupportScripts.SQLServer.Awsdms_Support_Collector_SQLServer_Script)
### Das Skript awsdms\$1support\$1collector\$1sql\$1server.sql
Laden Sie das [https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_sql_server.sql](https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_sql_server.sql)-Skript herunter.
**Anmerkung**
Führen Sie dieses Skript zur Unterstützung der SQL-Server-Diagnose nur auf SQL Server 2014 und höheren Versionen aus.
Dieses Skript erfasst Informationen über Ihre SQL-Server-Datenbankkonfiguration. Denken Sie daran, die Prüfsumme des Skripts zu überprüfen. Wenn die Prüfsumme verifiziert wurde, überprüfen Sie den SQL-Code in dem Skript, um den Code auszukommentieren, dessen Ausführung Sie nicht wünschen. Wenn Sie mit der Integrität und dem Inhalt des Skripts zufrieden sind, können Sie es ausführen.
**So führen Sie das Skript für eine On-Premises-SQL-Server-Datenbank aus**
1. Führen Sie das Skript mit der folgenden sqlcmd-Befehlszeile aus.
```
sqlcmd -Uon-prem-user -Ppassword -SDMS-SQL17AG-N1 -y 0
-iC:\Users\admin\awsdms_support_collector_sql_server.sql -oC:\Users\admin\DMS_Support_Report_SQLServer.html -dsqlserverdb01
```
Zu den angegebenen sqlcmd-Befehlsparametern gehören unter anderem:
+ `-U` – Name des Datenbankbenutzers.
+ `-P` – Passwort des Datenbankbenutzers.
+ `-S` – Name des SQL-Server-Datenbankservers.
+ `-y` – Maximale Breite der vom Hilfsprogramm sqlcmd ausgegebenen Spalten. Ein Wert von 0 gibt Spalten mit unbegrenzter Breite an.
+ `-i` – Pfad des auszuführenden Unterstützungsskripts, in diesem Fall `awsdms_support_collector_sql_server.sql`.
+ `-o` – Pfad der HTML-Ausgabedatei mit einem von Ihnen angegebenen Dateinamen, der die erfassten Datenbankkonfigurationsinformationen enthält.
+ `-d` – Name der SQL-Server-Datenbank.
1. Überprüfen Sie nach Abschluss des Skripts die HTML-Ausgabedatei und entfernen Sie alle Informationen, die Sie nicht weitergeben möchten. Wenn Sie den HTML-Code teilen können, laden Sie die Datei in Ihren AWS Support-Fall hoch. Weitere Informationen zum Hochladen dieser Datei finden Sie unter [Arbeiten mit Skripten zur Diagnoseunterstützung in AWS DMS](CHAP_SupportScripts.md).
Mit Amazon RDS für SQL Server können Sie keine Verbindung mit dem Befehlszeilen-Dienstprogramm sqlcmd herstellen. Gehen Sie daher wie folgt vor.
**So führen Sie das Skript für eine RDS-SQL-Server-Datenbank aus**
1. Führen Sie das Skript mit einem beliebigen Client-Tool aus, mit dem Sie als `Master`-Benutzer eine Verbindung zu RDS SQL Server herstellen und die Ausgabe als HTML-Datei speichern können.
1. Überprüfen Sie die Ausgabe-HTML-Datei und entfernen Sie alle Informationen, die Sie nicht weitergeben möchten. Wenn Sie den HTML-Code teilen können, laden Sie die Datei in Ihren AWS Support-Fall hoch. Weitere Informationen zum Hochladen dieser Datei finden Sie unter [Arbeiten mit Skripten zur Diagnoseunterstützung in AWS DMS](CHAP_SupportScripts.md).
# Diagnoseunterstützungsskripts für MySQL-kompatible Datenbanken
Im Folgenden finden Sie die Diagnosesupportskripte, die für die Analyse einer lokalen oder Amazon RDS for MySQL-kompatiblen Datenbank in Ihrer Migrationskonfiguration verfügbar sind. AWS DMS Diese Skripts funktionieren entweder mit einem Quell- oder Zielendpunkt. Die Skripts wurden alle so geschrieben, dass sie im Befehlszeilen-Dienstprogramm MySQL SQL ausgeführt werden können.
Informationen zum Installieren des MySQL-Clients finden Sie in der MySQL-Dokumentation unter [Installation der MySQL-Shell](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-install.html). Informationen zur Verwendung des MySQL-Clients finden Sie in der MySQL-Dokumentation unter [Verwendung von MySQL-Shell-Befehlen](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-configuring.html).
Bevor Sie das Skript ausführen, stellen Sie sicher, dass das von Ihnen verwendete Benutzerkonto über die erforderlichen Berechtigungen für den Zugriff auf Ihre MySQL-kompatible Datenbank verfügt. Gehen Sie wie folgt vor, um ein Benutzerkonto zu erstellen und die Mindestberechtigungen bereitzustellen, die zur Ausführung dieses Skripts erforderlich sind.
**So richten Sie ein Benutzerkonto mit den Mindestberechtigungen für die Ausführung dieser Skripts ein**
1. Erstellen Sie den Benutzer zum Ausführen der Skripts.
```
create user 'username'@'hostname' identified by password;
```
1. Erteilen Sie den `select`-Befehl für Datenbanken, um sie zu analysieren.
```
grant select on database-name.* to username;
grant replication client on *.* to username;
```
1.
```
grant execute on procedure mysql.rds_show_configuration to username;
```
In den folgenden Themen wird beschrieben, wie jedes für eine MySQL-kompatible Datenbank verfügbare Unterstützungsskript heruntergeladen, überprüft und ausgeführt wird. Sie beschreiben auch, wie Sie die Skriptausgabe überprüfen und in Ihren AWS Support-Fall hochladen können.
**Topics**
+ [Das Skript awsdms\$1support\$1collector\$1MySQL.sql](#CHAP_SupportScripts.MySQL.Awsdms_Support_Collector_MySQL_Script)
## Das Skript awsdms\$1support\$1collector\$1MySQL.sql
Laden Sie das [https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_MySQL.sql](https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_MySQL.sql)-Skript herunter.
Dieses Skript erfasst Informationen über Ihre MySQL-kompatible Datenbankkonfiguration. Denken Sie daran, die Prüfsumme des Skripts zu überprüfen. Wenn die Prüfsumme verifiziert wurde, überprüfen Sie den SQL-Code in dem Skript, um den Code auszukommentieren, dessen Ausführung Sie nicht wünschen. Wenn Sie mit der Integrität und dem Inhalt des Skripts zufrieden sind, können Sie es ausführen.
Führen Sie das Skript aus, nachdem Sie über die Befehlszeile eine Verbindung zu Ihrer Datenbankumgebung hergestellt haben.
**So führen Sie dieses Skript aus und laden die Ergebnisse in Ihren Support-Fall hoch**
1. Verbinden Sie sich mit Ihrer Datenbank mithilfe des `mysql`-Befehls.
```
mysql -p -h hostname -P port -u username database-name
```
1. Führen Sie das Skript mit dem folgenden mysql-`source`-Befehl aus.
```
source awsdms_support_collector_MySQL.sql
```
Überprüfen Sie den generierten Bericht und entfernen Sie alle Informationen, die Sie nicht weitergeben möchten. Wenn Sie den Inhalt weitergeben können, laden Sie die Datei in Ihren AWS -Support-Fall hoch. Weitere Informationen zum Hochladen dieser Datei finden Sie unter [Arbeiten mit Skripten zur Diagnoseunterstützung in AWS DMS](CHAP_SupportScripts.md).
**Anmerkung**
Wenn Sie bereits über ein Benutzerkonto mit den unter [Diagnoseunterstützungsskripts für MySQL-kompatible Datenbanken](#CHAP_SupportScripts.MySQL) beschriebenen erforderlichen Berechtigungen verfügen, können Sie das vorhandene Benutzerkonto auch verwenden, um das Skript auszuführen.
Denken Sie daran, eine Verbindung zu Ihrer Datenbank herzustellen, bevor Sie das Skript ausführen.
Das Skript generiert seine Ausgabe im Textformat.
Unter Berücksichtigung der bewährten Sicherheitsmethoden empfehlen wir, dieses Benutzerkonto nach erfolgreicher Ausführung des Skripts zu löschen, wenn Sie ein neues Benutzerkonto nur zur Ausführung dieses MySQL-Diagnoseunterstützungsskripts erstellen.
# PostgreSQL-Diagnoseunterstützungsskripts
Im Folgenden finden Sie die Diagnosesupportskripte, die zur Analyse aller PostgreSQL-RDBMS (lokal, Amazon RDS oder Aurora PostgreSQL) in Ihrer Migrationskonfiguration verfügbar sind. AWS DMS Diese Skripts funktionieren entweder mit einem Quell- oder Zielendpunkt. Die Skripts wurden alle so geschrieben, dass sie im Befehlszeilen-Dienstprogramm psql ausgeführt werden können.
Bevor Sie diese Skripts ausführen, stellen Sie sicher, dass das von Ihnen verwendete Benutzerkonto über die erforderlichen Berechtigungen für den Zugriff auf eine PostgreSQL-RDBMS verfügt:
+ PostgreSQL 10.x oder höher – Ein Benutzerkonto mit Ausführungsberechtigung für die `pg_catalog.pg_ls_waldir`-Funktion.
+ PostgreSQL 9.x oder früher – Ein Benutzerkonto mit Standardberechtigungen.
Wir empfehlen, ein vorhandenes Konto mit den entsprechenden Berechtigungen zu verwenden, um diese Skripts auszuführen.
Wenn Sie ein neues Benutzerkonto erstellen oder einem vorhandenen Konto Berechtigungen zur Ausführung dieser Skripts gewähren müssen, können Sie die folgenden SQL-Befehle für jedes PostgreSQL-RDBMS ausführen, basierend auf der PostgreSQL-Version.
**So gewähren Sie Kontoberechtigungen zur Ausführung dieser Skripts für eine PostgreSQL-Datenbank der Version 10.x oder höher**
+ Führen Sie eine der folgenden Aktionen aus:
+ Führen Sie für ein neues Benutzerkonto Folgendes aus.
```
CREATE USER script_user WITH PASSWORD 'password';
GRANT EXECUTE ON FUNCTION pg_catalog.pg_ls_waldir TO script_user;
```
+ Führen Sie für ein vorhandenes Benutzerkonto Folgendes aus.
```
GRANT EXECUTE ON FUNCTION pg_catalog.pg_ls_waldir TO script_user;
```
**So gewähren Sie Kontoberechtigungen zur Ausführung dieser Skripts für eine PostgreSQL-Datenbank der Version 9.x oder früher**
+ Führen Sie eine der folgenden Aktionen aus:
+ Führen Sie für ein neues Benutzerkonto Folgendes mit Standardberechtigungen aus.
```
CREATE USER script_user WITH PASSWORD password;
```
+ Verwenden Sie für ein vorhandenes Benutzerkonto die vorhandenen Berechtigungen.
**Anmerkung**
Diese Skripts unterstützen bestimmte Funktionen im Zusammenhang mit der Ermittlung der WAL-Größe für PostgreSQL-9.x- und frühere Datenbanken nicht. Weitere Informationen erhalten Sie vom AWS Support.
In den folgenden Themen wird beschrieben, wie Sie jedes für PostgreSQL verfügbare Unterstützungsskript herunterladen, überprüfen und ausführen. Außerdem wird beschrieben, wie Sie die Skriptausgabe überprüfen und in Ihren AWS -Support-Fall hochladen.
**Topics**
+ [Das Skript awsdms\$1support\$1collector\$1postgres.sql](#CHAP_SupportScripts.PostgreSQL.Awsdms_Support_Collector_PostgreSQL_Script)
## Das Skript awsdms\$1support\$1collector\$1postgres.sql
Laden Sie das [https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_postgres.sql](https://d2pwp9zz55emqw.cloudfront.net/scripts/awsdms_support_collector_postgres.sql)-Skript herunter.
Dieses Skript erfasst Informationen über Ihre PostgreSQL-Datenbankkonfiguration. Denken Sie daran, die Prüfsumme im Skript zu überprüfen. Wenn die Prüfsumme verifiziert wurde, überprüfen Sie den SQL-Code in dem Skript, um den Code auszukommentieren, dessen Ausführung Sie nicht wünschen. Wenn Sie mit der Integrität und dem Inhalt des Skripts zufrieden sind, können Sie es ausführen.
**Anmerkung**
Sie können dieses Skript mit dem psql-Client Version 10 oder höher ausführen.
Sie können die folgenden Verfahren verwenden, um dieses Skript entweder von Ihrer Datenbankumgebung oder von der Befehlszeile aus auszuführen. In beiden Fällen können Sie Ihre Datei später zum AWS -Support hochladen.
**So führen Sie dieses Skript aus und laden die Ergebnisse in Ihren Support-Fall hoch**
1. Führen Sie eine der folgenden Aktionen aus:
+ Führen Sie das Skript mit der folgenden psql-Befehlszeile aus Ihrer Datenbankumgebung aus.
```
dbname=# \i awsdms_support_collector_postgres.sql
```
Geben Sie bei der folgenden Eingabeaufforderung nur den Namen eines der Schemata ein, die Sie migrieren möchten.
Geben Sie bei der folgenden Eingabeaufforderung den Namen des Benutzers (`script_user`) ein, den Sie für die Verbindung mit der Datenbank definiert haben.
+ Führen Sie das folgende Skript direkt über die Befehlszeile aus. Diese Option vermeidet jegliche Eingabeaufforderungen vor der Ausführung des Skripts.
```
psql -h database-hostname -p port -U script_user -d database-name -f awsdms_support_collector_postgres.sql
```
1. Überprüfen Sie die Ausgabe-HTML-Datei und entfernen Sie alle Informationen, die Sie nicht weitergeben möchten. Wenn Sie den HTML-Code weitergeben können, laden Sie die Datei in Ihren AWS -Support-Fall hoch. Weitere Informationen zum Hochladen dieser Datei finden Sie unter [Arbeiten mit Skripten zur Diagnoseunterstützung in AWS DMS](CHAP_SupportScripts.md).
# Arbeiten mit dem AWS DMS Diagnosesupport AMI
Wenn Sie bei der Arbeit mit auf ein Netzwerkproblem stoßen AWS DMS, benötigt Ihr Support-Techniker möglicherweise weitere Informationen zu Ihrer Netzwerkkonfiguration. Wir möchten sicherstellen, dass der AWS Support so viele der erforderlichen Informationen wie möglich in kürzester Zeit erhält. Aus diesem Grund haben wir ein vorgefertigtes Amazon EC2 EC2-AMI mit Diagnosetools zum Testen Ihrer AWS DMS Netzwerkumgebung entwickelt.
Die auf dem Amazon Machine Image (AMI) installierten Diagnosetests umfassen Folgendes:
+ Virtual Private Cloud (VPC)
+ Verlust von Netzwerkpaketen
+ Netzwerklatenz
+ Größe der Maximum Transmission Unit (MTU)
**Topics**
+ [Starten Sie eine neue Amazon EC2 AWS DMS EC2-Diagnoseinstanz](#CHAP_SupportAmi_Launch)
+ [Erstellen einer IAM-Rolle](#CHAP_SupportAmi_Iam)
+ [Ausführen von Diagnosetests](#CHAP_SupportAmi_Run)
+ [Nächste Schritte](#CHAP_SupportAmi_NextSteps)
+ [AMI IDs nach Regionen](#CHAP_SupportAmi_AmiIDs)
+ [AWS System-Patch-Manager](#CHAP_PatchManager)
**Anmerkung**
Wenn Sie Leistungsprobleme bei Ihrer Oracle-Quelle feststellen, können Sie die Leseleistung Ihrer Oracle-Redo- oder -Archivprotokolle bewerten, um Möglichkeiten zur Leistungssteigerung zu finden. Weitere Informationen finden Sie unter [Bewertung der Leseleistung von Oracle-Redo- oder -Archivprotokollen](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Oracle.ReadPerformUtil).
## Starten Sie eine neue Amazon EC2 AWS DMS EC2-Diagnoseinstanz
In diesem Abschnitt starten Sie eine neue Amazon-EC2-Instance. Informationen zum Starten einer Amazon-EC2-Instance finden Sie unter [Erste Schritte mit Amazon-EC2-Instances für Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) im [Amazon-EC2-Benutzerhandbuch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/).
Starten Sie eine Amazon-EC2-Instance mit den folgenden Einstellungen:
+ Suchen Sie für **Anwendungs- und BS-Images (Amazon Machine Image)** nach dem **DMS-DIAG-AMI**-AMI. Wenn Sie an der Konsole angemeldet sind, können Sie mit [dieser Abfrage](https://us-east-1.console.aws.amazon.com/ec2/home?region=us-east-1#Images:visibility=public-images;search=:dms-diag-ami;v=3;) nach dem AMI suchen. Die AMI-ID des AWS Diagnose-AMI in Ihrer Region finden Sie im [AMI IDs nach Regionen](#CHAP_SupportAmi_AmiIDs) Folgenden.
+ Als **Instance-Typ** empfehlen wir Ihnen, **t2.micro** zu wählen.
+ Wählen Sie für **Netzwerkeinstellungen** dieselbe VPC aus, die Ihre Replikations-Instance verwendet.
Sobald die Instance aktiv ist, stellen Sie eine Verbindung mit der Instance her. Informationen zum Verbinden mit einer Amazon-EC2-Linux-Instance finden Sie unter [Verbindung mit Ihrer Linux-Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html).
## Erstellen einer IAM-Rolle
Wenn Sie die Diagnosetests auf Ihrer Replikations-Instance mit den erforderlichen Mindestberechtigungen ausführen möchten, erstellen Sie eine IAM-Rolle, die die folgende Berechtigungsrichtlinie verwendet:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"dms:DescribeEndpoints",
"dms:DescribeTableStatistics",
"dms:DescribeReplicationInstances",
"dms:DescribeReplicationTasks",
"secretsmanager:GetSecretValue"
],
"Resource": "*"
}
]
}
```
------
Fügen Sie die Rolle einem neuen IAM-Benutzer an. Informationen zum Erstellen und Schützen von IAM-Rollen, -Richtlinien und -Benutzern finden Sie in den folgenden Themen im [IAM-Benutzerhandbuch](https://docs.aws.amazon.com/IAM/latest/UserGuide/):
+ [Erste Schritte mit IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started.html)
+ [Erstellen von IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html)
+ [Erstellen von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)
## Ausführen von Diagnosetests
Nachdem Sie eine Amazon-EC2-Instance erstellt und eine Verbindung zu ihr hergestellt haben, gehen Sie wie folgt vor, um Diagnosetests auf Ihrer Replikations-Instance durchzuführen.
1. Konfigurieren Sie die AWS CLI:
```
$ aws configure
```
Geben Sie die Zugangsdaten für das AWS Benutzerkonto ein, das Sie für die Ausführung der Diagnosetests verwenden möchten. Geben Sie die Region für Ihre VPC und Replikations-Instance an.
1. Zeigen Sie die verfügbaren AWS DMS Aufgaben in Ihrer Region an. Ersetzen Sie Beispielregion durch Ihre Region.
```
$ dms-report -r us-east-1 -l
```
Dieser Befehl zeigt den Status Ihrer Aufgaben an.
![\[Diagnose-Tool, das die Aufgabenliste anzeigt.\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/images/datarep-diagami1.png)
1. Zeigen Sie die Endpunkte und Einstellungen der Aufgaben an. **Ersetzen Sie es durch Ihre Aufgabe Amazon Resource Name (ARN).
```
$ dms-report -t
```
Dieser Befehl zeigt die Endpunkte und Einstellungen Ihrer Aufgabe an.
![\[Das Diagnose-Tool zeigt die Endpunktliste für die Aufgabe an.\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/images/datarep-diagami2.png)
1. Führen Sie Diagnosetests durch. Ersetze es ** durch deinen Task ARN.
```
$ dms-report -t -n y
```
Mit diesem Befehl werden Diagnosedaten zur VPC, zur Netzwerkpaketübertragung, zur Netzwerklatenz und zur MTU-Größe (Maximum Transmission Unit) Ihrer Replikations-Instance angezeigt.
![\[Diagnose-Tool, das Netzwerkdaten anzeigt.\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/images/datarep-diagami3.png)
## Nächste Schritte
In den folgenden Abschnitten werden Informationen zur Fehlerbehebung beschrieben, die auf den Ergebnissen der Netzwerkdiagnosetests basieren:
### VPC-Tests
Dieser Test stellt sicher, dass sich die diagnostische Amazon-EC2-Instance in derselben VPC wie die Replikations-Instance befindet. Wenn sich die diagnostische Amazon-EC2-Instance nicht in derselben VPC wie Ihre Replikations-Instance befindet, beenden und erstellen Sie sie erneut in der korrekten VPC. Sie können die VPC einer Amazon-EC2-Instance nicht mehr ändern, nachdem Sie sie erstellt haben.
### Tests auf Netzwerkpaketverlust
Dieser Test sendet 10 Pakete an die folgenden Endpunkte und prüft, ob Pakete verloren gehen:
+ Der AWS DMS Amazon EC2-Metadatenservice auf Port 80
+ Der Quellendpunkt
+ Der Zielendpunkt
Alle Pakete sollten erfolgreich ankommen. Wenn Pakete verloren gehen, wenden Sie sich an einen Netzwerktechniker, um das Problem zu ermitteln und eine Lösung zu finden.
### Netzwerklatenztests
Dieser Test sendet 10 Pakete an dieselben Endpunkte wie im vorherigen Test und prüft die Paketlatenz. Alle Pakete sollten eine Latenz von weniger als 100 Millisekunden haben. Wenn Pakete eine Latenz von mehr als 100 Millisekunden haben, wenden Sie sich an einen Netzwerktechniker, um das Problem zu ermitteln und eine Lösung zu finden.
### Tests der Größe der Maximum Transmission Unit (MTU)
Dieser Test ermittelt die MTU-Größe, indem das Traceroute-Tool auf denselben Endpunkten wie beim vorherigen Test verwendet wird. Alle Pakete in diesem Test sollten dieselbe MTU-Größe haben. Wenn Pakete eine andere MTU-Größe haben, wenden Sie sich an einen Systemspezialisten, um das Problem zu ermitteln und eine Lösung zu finden.
## AMI IDs nach Regionen
Führen Sie das folgende AWS CLI-Beispiel aus, um eine Liste der in Ihrer AWS Region AMIs verfügbaren DMS-Diagnosen anzuzeigen.
```
aws ec2 describe-images --owners 343299325021 --filters "Name=name, Values=DMS-DIAG*" --query "sort_by(Images, &CreationDate)[-1].[Name, ImageId, CreationDate]" --output text
```
Wenn die Ausgabe keine Ergebnisse anzeigt, bedeutet dies, dass das DMS-Diagnose-AMI in Ihrer AWS Region nicht verfügbar ist. Um das Problem zu umgehen, folgen Sie den folgenden Schritten, um das Diagnose-AMI aus einer anderen Region zu kopieren. Weitere Informationen finden Sie unter [Kopieren eines AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/CopyingAMIs.html).
+ Starten Sie eine Instance in der verfügbaren Region.
+ Erstellen Sie das Bild. Das Bild wird Ihnen gehören.
+ Kopieren Sie das AMI in Ihre Region, z. B. in die Region Naher Osten (VAE).
+ Starten Sie die Instance in Ihrer lokalen Region.
## AWS System-Patch-Manager
AWS Systems Patch Manager automatisiert das Patchen für Betriebssysteme und Anwendungen auf Ihren EC2-Instances.
**Gehen Sie wie folgt vor, um den Patch Manager zu konfigurieren:**
1. Systems Manager aktivieren:
1. Hängen Sie die `AmazonSSMManagedInstanceCore` IAM-Richtlinie an Ihre EC2-Instance-Rolle an.
1. Stellen Sie sicher, dass der SSM-Agent installiert ist (Standard für Amazon Linux 2, Ubuntu AMIs 20.04\$1).
1. Erstellen Sie eine Patch-Baseline, indem Sie Regeln für critical/security Updates definieren, einschließlich Zeitplänen für die Patch-Anwendung.
1. Planen Sie Updates für die Installation von Patches zu einem bestimmten Zeitpunkt mithilfe von Wartungsfenstern in SSM.
1. Überprüfen Sie die Konformität, indem Sie den Patchstatus und die Konformitätsberichte im Systems Manager überprüfen.