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 SQL-Server-Endpunkten
Dieser Abschnitt enthält spezifische Replikationsszenarien für SQL Server. Um zu ermitteln, welche Änderungen von SQL Server repliziert werden sollen, liest AWS DMS die Transaktionsprotokolle und führt regelmäßige Scans der Quelldatenbank aus. 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.
Themen
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 mithilfe der
CDCLatencySourceCloudWatch MetrikenCDCLatencySourceund oder durch Überprüfen der Durchsatzüberwachungsmeldungen in den Aufgabenprotokollen. Weitere Informationen zu CloudWatch Metriken für finden Sie AWS DMSunter Metriken für die Replikationsaufgabe.Ü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
in der technischen Dokumentation zu SQL Server . 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
in der technischen Dokumentation zu SQL Server .
Versuchen Sie Folgendes, um Latenzprobleme während Index-Neuerstellungen zu beheben:
Verwenden Sie das Wiederherstellungsmodell
BULK_LOGGEDfü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 und zu beheben, die DMS-Lesevorgänge verlangsamen, z. B. Festplattenlatenz oder E/A-Durchsatz.
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 die Zeit, zu der die Latenz entweder mithilfe der
WriteThroughputCloudWatch MetrikenReadThroughputund oder durch Überprüfen der Durchsatzüberwachungsmeldungen in den Aufgabenprotokollen stark ansteigte.Ü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
in der technischen Dokumentation zu SQL Server . Überprüfen Sie, ob die Größe der aktiven Transaktionsprotokolle oder Protokoll-Backups zugenommen hat. Weitere Informationen finden Sie unter Monitor log space use
in der technischen Dokumentation zu SQL Server .
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
in der technischen Dokumentation zu SQL Server . Überprüfen Sie, ob die Protokollkürzung mit dem
log_reuse_wait_desc value-WertREPLICATIONverzögert wird. Weitere Informationen finden Sie unter The Transaction Log (SQL Server)in der technischen Dokumentation zu SQL Server .
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 Verwendung von Amazon RDS für SQL Server als Quelle für AWS DMS.
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.
