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.

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. Löscht standardmäßig 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.

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. Um sicherzustellen, dass Ihre Instanz über genügend Ressourcen für die Aufgaben verfügt, die Sie darauf ausführen, überprüfen Sie die Nutzung von ArbeitsspeicherCPU, Auslagerungsdateien und durch Ihre ReplikationsinstanzIOPS. So ist beispielsweise die Ausführung mehrerer Aufgaben mit Amazon Redshift als Endpunkt recht E/A-intensiv. Sie können die Kapazität Ihrer Replikationsinstanz erhöhen IOPS oder Ihre Aufgaben für eine effizientere Migration auf mehrere Replikationsinstanzen aufteilen.

Weitere Informationen zur Bestimmung der Größe Ihrer Replikations-Instance finden Sie unter Auswahl der besten Größe für eine Replikations-Instance.

Sie können die Geschwindigkeit eines ersten Ladevorgangs bei einer Migration wie folgt erhöhen:

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.

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:

Bei der Verbindung mit Amazon treten Probleme auf RDS

Es kann mehrere Gründe geben, warum Sie keine Verbindung zu einer RDS Amazon-DB-Instance herstellen können, die Sie als Quelle oder Ziel festgelegt haben. Folgende Punkte sollten Sie überprüfen:

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

Informationen zur Verwendung Ihres eigenen On-Premises-Nameservers finden Sie unter Verwenden Ihres eigenen Vor-Ort-Nameservers.

CDCbleibt nach Volllast hängen

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.

Um sicherzustellen, dass Ihre Replikationsinstanz über genügend Ressourcen für die Durchführung der Migration verfügt, überprüfen Sie die Nutzung von ArbeitsspeicherCPU, Auslagerungsdateien und durch Ihre InstanceIOPS. Weitere Informationen zur Überwachung finden Sie unter AWS Database Migration Service Metriken.

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 für eine Spalte erstellt wird LOB

Unterstützt im LIMITED LOB Modus FULL LOB oder AWS DMS nicht die Replikation von Primärschlüsseln, bei denen es sich um LOB Datentypen handelt.

DMSmigriert zunächst eine Zeile mit einer LOB Spalte als Null und aktualisiert die LOB Spalte später. Wenn also der Primärschlüssel für eine LOB Spalte erstellt wird, schlägt das erste Einfügen fehl, da der Primärschlüssel nicht Null sein kann. Um das Problem zu umgehen, fügen Sie 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

Beim Ausführen eines vollständigen Ladevorgangs und einer CDC Aufgabe können doppelte Datensätze in Zieltabellen erstellt werden, die keinen Primärschlüssel oder eindeutigen Index haben. Um zu vermeiden, dass Datensätze in Zieltabellen während der Volllast und bei CDC Aufgaben dupliziert werden, stellen Sie sicher, dass 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:

Verwenden Sie die EC2 Amazon-Instance-IP-Adresse und den zuvor angegebenen Datenbank-Port für den AWS DMS Endpunkt. Stellen Sie sicher, dass der Endpunkt über die Sicherheitsgruppe verfügt, die den AWS DMS Zugriff auf den Datenbankport ermöglicht. Beachten Sie, dass der Proxy für die Dauer der Ausführung Ihrer DMS Aufgabe laufen 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 ModifyEndpointAktion AWS Management Console oder, um den parquetTimestampInMillisecond Wert für Ihren Amazon S3 S3-Endpunkt auf festzulegen. true Weitere Informationen finden Sie unter S3Settings.

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.

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. Verwenden Sie Binary Reader, um Änderungen an LOB Spalten auf Oracle 12c zu erfassen.

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:

Fehler: Oracle CDC hat 122301 der CDC maximale Oracle-Wiederholungszähler ü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 RDS Amazon-Datenbank das folgende Verfahren aus, um die Protokollspeicherung zu erhöhen. Der folgende Code erhöht beispielsweise die Protokollspeicherung in einer Amazon RDS DB-Instance auf 24 Stunden.

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:

LOBÄnderungen werden nicht erfasst

Derzeit muss eine Tabelle einen Primärschlüssel haben AWS DMS , um 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:

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 eine Reihe von Problemen verursacht.

Eins besteht darin, dass die von der Quell- und Zieldatenbank verwendeten Zeichensätze nicht übereinstimmen.

Bei einem anderen dieser Probleme unterscheiden sich die Einstellungen für die nationale Sprachunterstützung (NLS) zwischen den beiden Datenbanken. Eine häufige Ursache für diesen Fehler ist, wenn der SEMANTICS Parameter NLS _ LENGTH _ für die Quelldatenbank auf CHAR und der SEMANTICS Parameter NLS _ LENGTH _ für die Zieldatenbank auf gesetzt istBYTE.

NUMBERder Datentyp wird falsch interpretiert

Der NUMBER Oracle-Datentyp wird je nach Genauigkeit und Umfang von NUMBER in verschiedene AWS DMS Datentypen konvertiert. Diese Konvertierungen sind hier dokumentiert: Quelldatentypen für Oracle. Die Art und Weise, wie der NUMBER Typ konvertiert wird, kann auch durch die Verwendung der Endpunkteinstellungen für den Oracle-Quellendpunkt beeinflusst werden. Diese Endpunkteinstellungen sind unter Endpunkteinstellungen bei Verwendung von Oracle als Quelle für AWS DMS 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 AufgabeneinstellungTransactionConsistencyTimeout=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.

Fehler: Cannot retrieve Oracle archived Redo log destination ids

Dieser Fehler tritt auf, wenn für Ihre Oracle-Quelle keine Archivprotokolle generiert wurden oder V$ ARCHIVED _ leer LOG ist. Sie können den Fehler beheben, indem Sie manuell zwischen den Protokollen wechseln.

Führen Sie für eine RDS Amazon-Datenbank das folgende Verfahren aus, um zwischen 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 AWS DMS Diagnose-Amazon-Maschinen-Image (AMI), um die Leseleistung des Redo- oder Archivierungsprotokolls zu testen.

Sie können die AWS DMS Diagnose verwendenAMI, um Folgendes zu tun:

Anschließend können Sie auf der Grundlage der Ergebnisse Korrekturmaßnahmen ergreifen.

Behebung von Problemen mit My SQL

Im Folgenden erfahren Sie mehr über die Behebung von Problemen, die speziell bei der Verwendung AWS DMS mit Meine SQL Datenbanken auftreten.

CDCAufgabe schlägt für den RDS Amazon-DB-Instance-Endpunkt fehl, weil die Binärprotokollierung deaktiviert ist

Dieses Problem tritt bei Amazon RDS DB-Instances auf, weil automatische Backups deaktiviert sind. Aktivieren Sie automatische Sicherungen, indem Sie den Aufbewahrungszeitraum für Backups auf einen Wert größer als null festlegen.

Verbindungen zu einem Ziel: Meine SQL Instance wird während einer Aufgabe unterbrochen

Wenn Sie eine Aufgabe habenLOBs, bei der die Verbindung zu „Mein SQL Ziel“ unterbrochen wird, werden im Aufgabenprotokoll möglicherweise die folgenden Fehler 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.

Gehen Sie wie folgt vor, um das Problem zu lösen, bei dem eine Aufgabe von „Mein SQL Ziel“ getrennt wird:

Informationen zum Einstellen von Meine SQL Systemvariablen finden Sie unter Serversystemvariablen in der SQLDokumentation Meine.

Autocommit zu einem My SQL -kompatiblen Endpunkt hinzufügen

Deaktivieren Sie Fremdschlüssel auf einem My -kompatiblen Zielendpunkt SQL

Sie können Fremdschlüsselprüfungen auf My deaktivieren, SQL indem Sie Folgendes zu den zusätzlichen Verbindungsattributen im Abschnitt Erweitert des Zielendpunkts MySQL, Amazon Aurora My SQL -Compatible Edition oder MariaDB hinzufügen.

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

Einträge mit dem Status „Fehlerhaftes Ereignis“ in den Migrationsprotokollen weisen normalerweise darauf hin, dass auf dem Endpunkt der Quelldatenbank versucht wurde, einen Vorgang in der Datendefinitionssprache (DDL) nicht unterstützt zu haben. Nicht unterstützte DDL Operationen verursachen ein Ereignis, das die Replikationsinstanz nicht überspringen kann. Daher wird ein fehlerhaftes Ereignis protokolliert.

Starten Sie die Aufgabe von Anfang an neu, um dieses Problem zu beheben. Dadurch werden die Tabellen neu geladen und die Änderungen werden zu einem Zeitpunkt erfasst, zu dem der nicht unterstützte DDL Vorgang ausgeführt wurde.

Datenerfassung mit My 5.5 ändern SQL

AWS DMS Change Data Capture (CDC) für Amazon RDS My SQL -kompatible Datenbanken erfordert eine zeilenbasierte vollständige binäre Protokollierung, die in My SQL Version 5.5 oder niedriger nicht unterstützt wird. Um sie verwenden zu können AWS DMS CDC, müssen Sie ein Upgrade Ihrer Amazon RDS DB-Instance auf Meine SQL Version 5.6 durchführen.

Erhöhung der Aufbewahrung von Binärprotokollen für Amazon RDS DB-Instances

AWS DMS erfordert die Aufbewahrung von binären Protokolldateien für die Erfassung von Änderungsdaten. Gehen Sie wie folgt vor, um die Protokollaufbewahrung auf einer Amazon RDS DB-Instance zu erhöhen. 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 Spalte „Meine SQL Datenbank“ auf den vorhandenen Wert AWS DMS aktualisiert wird, zero rows affected wird von My die Meldung von zurückgegebenSQL. 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 diesen Fällen verwendet DMS derzeit nicht dieselben Namen für die Primärschlüssel, die in der Quelldatenbank verwendet wurden. DMSErstellt stattdessen den Primärschlüsselnamen auf der Grundlage des Tabellennamens. Wenn der Tabellenname lang ist, kann der automatisch generierte Bezeichner länger sein als die zulässigen Grenzwerte für MySQL.

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

Der folgende Fehler kann während einer Migration auftreten, wenn Sie in der Quelldatenbank Meine Datenbank keine Codepage-1252-Zeichen haben. SQL

  
[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)
                

Um das Problem zu umgehen, können Sie das CharsetMapping zusätzliche Verbindungsattribut mit Ihrem SQL Quellendpunkt My verwenden, um die Zeichensatzzuweisung anzugeben. 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 den Endpunkt Meine SQL Quelle verwendet werden, bei dem der Quellzeichensatz Utf8 oder istlatin1. 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 undCDC, wie im Folgenden beschrieben:

Erstellen Sie eine einzelne Aufgabe, die Volllast unterstützt, und CDC

Dieses Verfahren beschreibt, wie Fremdschlüssel und Indizes mithilfe einer einzigen Aufgabe für Volllast und CDC migriert werden.

Volllast und CDC Aufgaben separat erstellen

Diese Verfahren beschreiben, wie Fremdschlüssel und Indizes mithilfe separater Aufgaben für Volllast und CDC migriert werden.

Behebung von Problemen mit Postgre SQL

Im Folgenden erfahren Sie mehr über die Behebung von Problemen, die bei der Verwendung AWS DMS mit Postgre-Datenbanken spezifisch sind. SQL

JSONDatentypen werden gekürzt

AWS DMS behandelt den JSON Datentyp in Postgre SQL als LOB Datentypspalte. Das bedeutet, dass die LOB Größenbeschränkung, wenn Sie den eingeschränkten LOB Modus verwenden, für JSON Daten gilt.

Nehmen wir beispielsweise an, dass der eingeschrä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 Obergrenze von 4.096 KB gekürzt und bestehen den Validierungstest in Postgre nicht. SQL

Die folgenden Protokollinformationen zeigenJSON, dass diese Daten aufgrund der Einstellung für den eingeschränkten Modus gekürzt wurden und die Überprüfung fehlgeschlagen ist. LOB

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 SQL Postgre-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_ ERROR SqlState: 3F000:7 Meldung: NativeError: Es wurde kein Schema ausgewählt, in dem erstellt werden soll“ angezeigt. ERROR

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öschungen und Aktualisierungen einer Tabelle werden nicht repliziert mit CDC

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 SQL Postgre-Tabellen mit Primärschlüsseln.

Wenn eine Tabelle keinen Primärschlüssel hat, enthalten die Write-Ahead (WAL) -Protokolle kein Vorher-Bild 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.

Postgre-Erfassung SQL verhindern DDL

Sie können verhindern, dass ein SQL Postgre-Zielendpunkt DDL Anweisungen erfasst, indem Sie die folgende Endpunkt-Einstellungsanweisung hinzufügen.

"CaptureDDLs": "N"
            

Auswahl des Schemas, in dem Datenbankobjekte für die Erfassung erstellt DDL werden

Sie können steuern, in welchem Schema die Datenbankobjekte, die sich auf die Erfassung beziehen, erstellt DDL 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 der Migration zu Postgre SQL

In diesem Fall sind Ihre Tabellen und Daten im Allgemeinen weiterhin verfügbar.

Oracle verwendet standardmäßig Tabellennamen in Großbuchstaben und Postgre verwendet SQL standardmäßig Tabellennamen in Kleinbuchstaben. Wenn Sie eine Migration von Oracle zu Postgre durchführen, empfehlen wir IhnenSQL, 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 erhöht sich und restart_lsn bewegt sich bei langen Transaktionen, wie z. B. Workloads, nicht mehr ETL

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. Daher nimmt der Wert für ReplicationSlotDiskUsage zu und restart_lsn schreitet erst voran, wenn die Transaktion abgeschlossen/abgebrochen und das Rollback beendet ist. 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.

Zu den Quellen, die Ansichten unterstützen, gehören folgende.

Behebung von Problemen mit 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.

Die laufende Replikation schlägt fehl, nachdem RDS der SQL Server auf den sekundären Server umgestellt wurde

Wenn ein Failover einer SQL Quellserverinstanz auf die sekundäre Serverinstanz erfolgt, versucht die AWS DMS laufende Replikation weiterhin, eine Verbindung herzustellen, und setzt die Replikation fort, sobald die Quelle wieder online ist. RDSBei SQL MAZ Serverinstanzen kann der Besitzer der sekundären Datenbank jedoch unter bestimmten Umständen auf NT AUTHORITY\SYSTEM eingestellt werden. Nach einem Failover schlägt die DMS Aufgabe dadurch fehl und es wird der folgende Fehler angezeigt:

[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_owner in das rdsa-Konto für Ihre Datenbank, und setzen Sie dann Ihre Aufgabe fort. DMS

Fehler beim Erfassen von Änderungen für die Serverdatenbank SQL

Fehler bei der Erfassung von Änderungsdaten (CDC) können oft darauf hinweisen, dass eine der Voraussetzungen nicht erfüllt wurde. 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)                
            

Lesen Sie die aufgeführten Voraussetzungen für die Verwendung von SQL Server als Quelle unterVerwenden einer Microsoft SQL Server-Datenbank als Quelle für AWS DMS.

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: Der SQL Server unterstützt keine Veröffentlichungen

Der folgende Fehler wird generiert, 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 SQL Server Express derzeit nicht als Quelle oder Ziel.

Änderungen werden im Ziel nicht angezeigt

AWS DMS erfordert, dass sich eine SQL Quell-Serverdatenbank entweder im Datenwiederherstellungsmodell 'BULKLOGGED' oder 'befindet, um Änderungen konsistent zu erfassen. FULL Das Modell SIMPLE '' wird nicht unterstützt.

Das SIMPLE Wiederherstellungsmodell protokolliert die minimalen Informationen, 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. Dieses Problem ist der Grund AWS DMS , warum das SIMPLE Datenwiederherstellungsmodell nicht unterstützt wird. Informationen zu anderen erforderlichen Voraussetzungen für die Verwendung von SQL Server als Quelle finden Sie unterVerwenden einer Microsoft SQL Server-Datenbank als Quelle für AWS DMS.

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 die Tabelle nicht ordnungsgemäß CDC bearbeitet 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)
            

AWS DMS Analysiert bei CDC der Ausführung auf SQL Servertabellen die SQL Server-Tlogs. 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 Serversystemtabellen, um den Hexadezimaldatensatz zu analysieren. SQL 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 der Zugriff CDC auf diese Tabelle unterbrochen werden, um zu verhindern, dass Änderungen falsch analysiert werden und das Ziel nicht mit falschen Daten versorgt wird. Es gibt u. a. folgende Möglichkeiten zur Umgehung des Problems:

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.

Laden in einen Amazon-Redshift-Cluster in einer anderen AWS -Region

Sie können nicht in einen Amazon Redshift Redshift-Cluster laden, der sich in einer anderen AWS Region als Ihrer AWS DMS Replikationsinstanz befindet. DMSerfordert, dass sich Ihre Replikationsinstanz und Ihr Amazon Redshift Redshift-Cluster in derselben Region befinden.

Fehler: Beziehung "attrep_apply_exceptions" bereits vorhanden

Der Fehler „Relation 'awsdms_apply_exceptions' already exists“ tritt häufig auf, wenn ein Redshift-Endpunkt als Postgre-Endpunkt angegeben wird. SQL Um dieses Problem zu beheben, ändern Sie den Endpunkt und ändern Sie die Target engine in "redshift".

Fehler mit Tabellen, deren Name mit „awsdms_changes“ beginnt

Fehlermeldungen zu Tabellen mit Namen, die mit „awsdms_changes“ 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.

Tabellen in Clustern mit Namen wie dms.awsdms_changes000000000 werden angezeigt XXXX

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:

Sie finden die Voraussetzungen für die Verwendung von Amazon Redshift als Ziel unter Verwenden einer Amazon-Redshift-Datenbank als Ziel für AWS Database Migration Service.

Behebung von Problemen mit Amazon Aurora My SQL

Im Folgenden erfahren Sie mehr über die Behebung von Problemen, die speziell bei der Verwendung AWS DMS mit Amazon Aurora SQL My-Datenbanken auftreten.

Fehler: CHARACTER SET UTF8 Felder, die mit '"' abgeschlossen sind, von '"' umschlossen von Zeilen, die mit '\n' enden

Wenn Sie Amazon Aurora My SQL als Ziel verwenden, wird in den Protokollen möglicherweise ein Fehler wie der folgende angezeigt. Diese Art von Fehler weist normalerweise darauf hin, dass Sie ANSI _ QUOTES als Teil des MODE Parameters SQL _ angegeben haben. Wenn ANSI _ QUOTES Teil des MODE Parameters SQL _ ist, werden doppelte Anführungszeichen wie Anführungszeichen behandelt, was zu Problemen führen kann, wenn Sie eine Aufgabe ausführen.

Um diesen Fehler zu beheben, entfernen Sie ANSI _ QUOTES aus dem MODE Parameter SQL _.

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) 
            

Behebung von Problemen mit 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

Bei Verwendung SAP ASE als Quelle mit Tabellen, 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 normalerweise darauf zurückzuführen, dass ANSI _ auf dem Client der DMS Replikationsinstanz standardmäßig auf 1 NULL gesetzt ist.

Um sicherzustellen, dass LOB Felder korrekt migriert werden, fügen Sie die Einstellung Endpunkt 'AnsiNull=0' dem AWS DMS Quellendpunkt der Aufgabe hinzu.

Behebung von Problemen mit IBM Db2

Im Folgenden erfahren Sie mehr über die Behebung von Problemen, die speziell bei der Verwendung AWS DMS mit IBM Db2-Datenbanken auftreten.

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 Verbindungsattribut StartFromContext auf den erforderlichen Zeitstempel. Weitere Informationen finden Sie unter Endpunkteinstellungen bei Verwendung 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.