Oracle TIMESTAMP vs. ETL-Realitaet: Wie ein Treiber Nanosekunden „gefressen“ hat

Ein kleines Metadatenproblem mit grosser Wirkung auf die Datenqualitaet.

In einem Projekt mit Informatica PowerCenter 10.5.6 fiel auf, dass die ETL-Strecke zwar stabil lief, die Zeitstempel im Zielsystem aber nicht mehr vollständig waren.
Auf den ersten Blick wirkte alles unauffällig, bis beim Vergleich von Source und Target klar wurde: Sekunden wurden korrekt übernommen, Subsekunden jedoch abgeschnitten.

Das Problem im Detail

Beim Einlesen der Source- und Target-Strukturen über bestimmte Oracle-ODBC-Treiber wurden die Metadaten für Oracle-TIMESTAMP nicht korrekt interpretiert.
Dadurch wurde effektiv nur eine Feldlänge von 19 Zeichen weiterverarbeitet.

Das führte zu:

• unvollständiger Übernahme von Precision und Scale
• stiller Truncation bei Fractional Seconds
• Verlust von Nanosekunden
• inkonsistenten Zeitstempeln in nachgelagerten Prozessen

Gerade bei CDC, Event-Sequenzen und technischen Audit-Logs ist das kein kosmetischer Fehler, sondern ein relevantes Risiko für Korrelation, Reihenfolge und Nachvollziehbarkeit.

Wo die Ursache wirklich lag

Die Analyse zeigte, dass die Fehlerquelle nicht in der Mapping-Logik lag, sondern bereits tiefer in der Treiber-Metadatenebene.
Entscheidend waren die vom Treiber gelieferten Parameter wie column size, precision und scale.

Wenn diese Informationen falsch importiert werden, startet die gesamte ETL-Kette mit einem semantisch verkürzten Datentyp.

Die stabile Lösung

Die Source- und Target-Definitionen wurden im PowerCenter Designer mit dem DataDirect Windows-Treiber neu eingelesen.

Danach war das Verhalten konsistent:

• Precision und Scale wurden korrekt erkannt
• die für PowerCenter notwendige Gesamtfeldlänge war korrekt
• keine abgeschnittenen Fractional Seconds mehr
• End-to-End konsistente TIMESTAMP-Werte inklusive Subsekunden

Praxisfazit

Wenn TIMESTAMP-Werte in Informatica plötzlich nur noch auf Sekundenebene sauber ankommen, sollte der Fokus nicht nur auf Mapping-Regeln liegen.
Die eigentliche Ursache sitzt häufig in der Metadaten-Interpretation des Treibers.

Kurz gesagt:
Nicht jeder Zeitstempel-Fehler ist ein Transformationsfehler.
Manchmal entscheidet der Treiber darüber, ob Nanosekunden überleben oder still verloren gehen.