Données manquantes lors du chargement de données via le datastage ETL

Je tente de charger des données de la table DB2 vers Netezza via ETL Datastage. C'est une charge delta par rapport à une colonne d'horodatage. donc la source SQL est commeDonnées manquantes lors du chargement de données via le datastage ETL

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

Après le chargement des données dans le tableau Netezza, quand je courais en dessous de la requête et obtenu le résultat suivant.

select max(timestamp_column) from netezza_table;

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

Ce qui me semble bon.

Mais j'ai remarqué que nous avons un enregistrement dans la table DB2 dont la colonne timestamp_column est '2017-02-10 11:17:54', bien que ces données soient manquantes dans la table Netezza de destination.

Ce n'est pas un problème courant, mais lorsque le problème est survenu, j'ai remarqué que la valeur timestamp_column de l'enregistrement manquant est inférieure à 1 ou 2 secondes.

Ma question est, si la valeur max(timestamp_column) est '2017-02-10 11:17:56' dans Netezza alors le travail ETL aurait dû aller chercher l'enregistrement '2017-02-10 11:17:54'.

Comment est-il possible de rater cet enregistrement?

Source

2017-02-10 Amlan

Avez-vous supprimé la mise en forme que j'ai ajoutée? Votre question est assez difficile à lire sans elle. – mustaccio

Hé, je m'excuse. c'est arrivé par erreur. – Amlan

Il est tout à fait possible que la transaction qui a mis à jour l'enregistrement '2017-02-10 11:17:54' validée après la lecture de la ligne par le travail ETL. Le niveau d'isolation par défaut dans la base de données DB2 (je suppose que DB2 pour LUW) est CS, qui verrouille uniquement la ligne courante lors du traitement d'un curseur, et les autres transactions sont libres de mettre à jour les lignes déjà lues.

Vous pouvez essayer d'augmenter le niveau d'isolation du travail ETL à RR pour vous assurer que le jeu de résultats ne change pas jusqu'à ce que vous ayez fini de le lire, mais gardez à l'esprit que cela affectera la simultanéité des mises à jour DB2.

Source

2017-02-10 20:08:07 mustaccio

Merci pour votre commentaire. Le niveau d'isolement dans mon travail ETL est RU. Comme table source est une table de transaction et plusieurs enregistrements insèrent par seconde. Alors, quelle est la meilleure façon de résoudre ce problème. – Amlan

Eh bien, cela dépend de ce qui est le plus important pour vous: la cohérence ou la simultanéité. Si vous avez absolument besoin d'un cliché cohérent de la table source, vous devez empêcher les mises à jour, ce qui détruit la concurrence. Si vous ne pouvez pas sacrifier la concurrence, vous devrez vivre avec des données légèrement incohérentes jusqu'à la prochaine exécution d'ETL. – mustaccio

Oui, mais le problème est la prochaine fois qu'ETL va chercher les données de la table source où timestamp_column> '2017-02-10 11:17:56' (car nous chargeons des enregistrements delta à travers ce travail). donc ces données manquantes ne seront pas disponibles dans ma table de destination. – Amlan

Une façon de résoudre votre problème pourrait être un horodatage de changement de ligne. Cet horodatage est généré automatiquement par DB2 au moment de l'insertion ou de la mise à jour et constitue donc une solution parfaite pour déterminer les deltas. Ajouter une colonne supplémentaire à votre table source comme celui-ci

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

Pour éviter les conflits en raison du changement DDL vous pouvez également définir cette colonne comme « cachée ». Cela signifie qu'il peut être explicitement sélectionné mais n'est pas retourné lors de l'exécution d'un

SELECT * FROM tab

Source

2017-02-12 17:07:39 MichaelTiefenbacher

Données manquantes lors du chargement de données via le datastage ETL

Répondre

Questions connexes