SQLFehlerbehebung bei Serverendpunkten - AWS Database Migration Service

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.

SQLFehlerbehebung bei Serverendpunkten

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

Index-Neuerstellungen

Wenn der SQL Server einen großen Index neu erstellt, verwendet er eine einzige Transaktion. Dadurch werden viele Ereignisse generiert und kann eine große Menge an Protokollspeicher beanspruchen, wenn der SQL Server mehrere Indizes gleichzeitig neu erstellt. In diesem Fall können Sie mit kurzen Replikationsspitzen rechnen. Wenn Ihre SQL Serverquelle ständig hohe Protokollspitzen aufweist, überprüfen Sie Folgendes:

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, die DMS Lesevorgänge verlangsamen, wie z. B. Festplattenlatenz oder I/O-Durchsatz, zu identifizieren und zu beheben.

Große Transaktionen

Transaktionen mit vielen Ereignissen oder lang laufende Transaktionen lassen das Transaktionsprotokoll anwachsen. Dies führt dazu, dass DMS Lesevorgänge länger dauern, 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:

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 Konflikten zu suchen. CPU Wenn Sie Engpässe in Ihrer Quelldatenbank feststellen, können Sie die Latenz reduzieren, indem Sie die Festplatten- und Speicherressourcen für die Quelldatenbank erhöhen. CPU Dadurch werden Konflikte um Systemressourcen reduziert, sodass DMS Abfragen schneller abgeschlossen werden können.

Falsch konfiguriertes CDC MS-Abfrageintervall für Amazon Server RDS SQL

Eine falsch konfigurierte Einstellung für das Abfrageintervall auf RDS Amazon-Instances kann dazu führen, dass das Transaktionsprotokoll wächst. Das liegt daran, dass die Replikation die Protokollkürzung verhindert. Während laufende Aufgaben möglicherweise weiterhin mit minimaler Latenz repliziert werden, kann das Stoppen und Wiederaufnehmen von Aufgaben oder Aufgaben, die CDC nur gestartet werden, zu Aufgabenfehlern führen. 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:

Wenn Sie Probleme mit einem der Elemente in der vorherigen Liste feststellen, passen Sie das CDC MS-Polling-Intervall an. Informationen zur Optimierung des Abfrageintervalls finden Sie unter Empfohlene Einstellungen bei der Verwendung von RDS for SQL Server als Quelle für AWS DMS.

Replizieren 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. Wir empfehlen jedoch, die Aufgaben während der CDC Phase zu konsolidieren, um die Anzahl der Scans zu minimierenDMS. Während dieser CDC Phase durchsucht 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 den Speicherplatz und die CPU Auslastung der SQL Quellserver-Datenbank. Infolgedessen kann eine große Anzahl von Aufgaben, die parallel ausgeführt werden, dazu führen, dass der SQL Server DMS Lesevorgänge drosselt, was zu einer erhöhten Latenz führt.

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. SQLDer Server priorisiert einige Aufgabenscans, sodass bei einigen Aufgaben eine normale Latenz auftritt. Überprüfen Sie die Metrik CDCLatencySource für alle Ihre Aufgaben, um dieses Problem zu beheben. Wenn einige Aufgaben eine zunehmende und einige Aufgaben eine niedrige aufweisenCDCLatencySource, ist es wahrscheinlichCDCLatencySource, dass der SQL Server Ihre DMS Lesevorgänge für einige Ihrer Aufgaben drosselt.

Wenn der SQL Server währenddessen die Lesevorgänge Ihrer Aufgaben einschränktCDC, konsolidieren Sie Ihre Aufgaben, um die Anzahl der Scans zu minimieren. DMS 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 der Sicherung des Transaktionsprotokolls für den Server RDS SQL

AWS DMS 3.5.3 und höher unterstützen die Replikation von RDS SQL Serverprotokollsicherungen aus. 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, DMS dass der Zugriff auf Backups seriell angefordert wird, um sicherzustellen, dass die Transaktionssequenz beibehalten wird, und um das Risiko zu minimieren, dass der RDS Amazon-Instance-Speicher voll wird. Darüber hinaus DMS variiert die Zeit, die benötigt wird, um die Backups auf RDS Amazon-Seite 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, den Wert ECA ActivateSafeguard auf zu setzentrue. Dadurch wird sichergestellt, dass Transaktionen nicht gesichert werden, während die DMS Aufgabe aus dem aktiven Transaktionslog liest. Diese Einstellung verhindert auch, dass Amazon Transaktionen im aktiven Protokoll RDS archiviert, wenn Transaktionen aus dem Backup gelesen werden, wodurch die Möglichkeit ausgeschlossen DMS wird, dass das aktive Protokoll DMS nicht abgerufen werden 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 bei einer Aufgabe, die CDC ausschließlich aus RDS SQL Serverquellen repliziert wird, möglichst die native CDC Startposition anstelle der systemeigenen CDC Startzeit. Das liegt daran, DMS dass Systemtabellen zur Identifizierung des Startpunkts für die systemeigene Startposition verwendet werden, anstatt einzelne Protokollsicherungen zu scannen, wenn Sie eine systemeigene Startzeit angeben.