2017-02-10 6 views
0

Ich versuche, Daten von DB2-Tabelle zu Netezza über ETL-Datastage zu laden. Dies ist eine Delta-Last für eine Timestamp-Spalte. So Quelle SQL ist wieFehlende Daten beim Laden von Daten über ETL-Daten

select * from db2_table where timestamp_column > '2017-02-10 08:24:00'; 

Nach dem Laden der Daten in Netezza Tabelle, wenn ich unter Abfrage lief und bekam folgendes Ergebnis.

select max(timestamp_column) from netezza_table; 

kehrt '2017-02-10 11:17:56'

Was mir gut aussieht.

Aber ich habe festgestellt, dass wir einen Datensatz in der DB2-Tabelle haben, deren timestamp_column '2017-02-10 11:17:54' ist, obwohl diese Daten in der Netezza-Zieltabelle fehlen.

Dies ist kein reguläres Problem, aber als das Problem auftrat, habe ich festgestellt, dass der Wert timestamp_column des fehlenden Datensatzes weniger als 1 oder 2 Sekunden beträgt.

Meine Frage ist, wenn max(timestamp_column) Wert ist '2017-02-10 11:17:56' in Netezza dann der ETL-Job sollte den '2017-02-10 11:17:54' Datensatz abgerufen haben.

Wie ist es möglich, diesen Rekord zu verpassen?

+0

ausgeführt wird. Ihre Frage ist ohne sie schwer zu lesen. – mustaccio

+0

Hey, ich entschuldige mich. es geschah aus Versehen. – Amlan

Antwort

0

Es ist durchaus möglich, dass die Transaktion, die den '2017-02-10 11:17:54' Datensatz aktualisiert, der nach dem Lesen der Zeile vom ETL-Job übernommen wurde. Die Standardisolationsstufe in der DB2-Datenbank (ich nehme an, DB2 für LUW) ist CS, die nur die aktuelle Zeile bei der Verarbeitung eines Cursors sperrt, während andere Transaktionen Zeilen, die bereits gelesen wurden, aktualisieren können.

Sie können versuchen, die Isolationsstufe des ETL-Jobs auf RR zu erhöhen, um sicherzustellen, dass sich die Ergebnismenge nicht ändert, bis Sie sie gelesen haben. Beachten Sie jedoch, dass dies Auswirkungen auf die gleichzeitige Ausführung von Aktualisierungen auf der DB2-Seite hat.

+0

Danke für Ihren Kommentar. Isolationsstufe in meinem ETL-Job ist RU. Als Quellentabelle dient eine Transaktionstabelle und mehrere Datensätze pro Sekunde. Also, was ist der beste Weg, um dieses Problem zu lösen. – Amlan

+0

Nun, das hängt davon ab, was Ihnen wichtiger ist: Konsistenz oder Nebenläufigkeit. Wenn Sie unbedingt einen konsistenten Snapshot der Quelltabelle benötigen, müssen Sie Updates verhindern und die Parallelität ausschalten. Wenn Sie die Parallelität nicht opfern können, müssen Sie bis zum nächsten ETL-Lauf mit etwas inkonsistenten Daten leben. – mustaccio

+0

Ja, aber das Problem ist das nächste Mal, wenn ETL Daten aus der Quelltabelle holt, wo timestamp_column> '2017-02-10 11:17:56' (da wir Delta-Datensätze über diesen Job laden). , so dass die fehlenden Daten in meiner Zieltabelle nicht verfügbar sind. – Amlan

0

Eine Möglichkeit zur Lösung Ihres Problems könnte ein Zeilenwechsel-Zeitstempel sein. Dieser Zeitstempel wird von DB2 automatisch bei der Einfüge- oder Aktualisierungszeit erzeugt und ist daher eine perfekte Lösung zur Bestimmung von Deltas. Fügen Sie eine zusätzliche Spalte zu Ihrer Quelltabelle wie diese

rct timestamp not null generated always for each row on update as row change timestamp 

Um Konflikte zu vermeiden, weil der DDL Änderung auch diese Spalte als „hidden“ definiert man konnte. Dies bedeutet, dass es explizit ausgewählt werden kann, aber nicht zurückgegeben wird, wenn