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.
# 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.