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.
