2017-02-10 9 views
0

ETLデータストアを介してDB2テーブルからNetezzaにデータをロードしようとしています。これはタイムスタンプ列に対するデルタロードです。 私は、クエリの下に走って次の結果を得たときにソースSQLは、Netezzaのテーブル内のデータをロードした後ETLデーターを介してデータをロード中にデータが欠落しています

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

のようなものです。私にはよさそうだ

select max(timestamp_column) from netezza_table; 

戻り'2017-02-10 11:17:56'

しかし、timestamp_columnが'2017-02-10 11:17:54'のDB2テーブルにレコードがありますが、そのデータは宛先Netezzaテーブルにはありません。

これは定期的な問題ではありませんが、問題が発生したときに、紛失したレコードのtimestamp_columnの値が1秒または2秒未満であることがわかりました。

私の質問は、max(timestamp_column)の値が'2017-02-10 11:17:56'でNetezzaの場合、ETLジョブが'2017-02-10 11:17:54'レコードをフェッチしたはずです。

このレコードを見逃す可能性はありますか?

+0

追加した書式を削除した理由は何ですか?あなたの質問は、それなしでは読むのが非常に難しいです。 – mustaccio

+0

ねえ、お詫び申し上げます。それは間違って起こった。 – Amlan

答えて

0

行の後にコミットされた'2017-02-10 11:17:54'レコードを更新したトランザクションがETLジョブによって読み取られた可能性があります。 DB2データベースのデフォルトの分離レベル(DB2 for LUWと仮定しています)はCSです。これはカーソルの処理時に現在の行のみをロックし、他のトランザクションはすでに読み込まれた行を自由に更新します。

ETLジョブの分離レベルをRRに引き上げて、読込みが完了するまで結果セットが変更されないようにすることができますが、DB2側の更新の並行性に影響します。

+0

ご意見ありがとうございます。 ETLジョブの分離レベルはRUです。ソース表はトランザクション表で、1秒あたり複数のレコードが挿入されるためです。だから、この問題を解決する最善の方法は何か。 – Amlan

+0

それは、あなたにとって重要なこと、すなわち一貫性や並行性に依存します。一貫性のあるソース表のスナップショットが必要な場合は、更新を防ぎ、並行性を失わなければなりません。並行性を犠牲にすることができない場合は、次のETLが実行されるまで少し矛盾したデータを使用して実行する必要があります。 – mustaccio

+0

はい、問題は次回です。ETLはtimestamp_column> '2017-02-10 11:17:56' (このジョブを通じてデルタレコードをロードしているため)のソーステーブルからデータをフェッチします。 これらの欠落したデータは私の目的地のテーブルでは利用できません。 – Amlan

0

問題を解決する方法は、行変更のタイムスタンプです。 このタイムスタンプは、挿入または更新時に自動的にDB2によって生成されるため、デルタを決定するための完璧なソリューションです。 ので、あなたも、「隠された」として、この列を定義した可能性がDDL変更の競合を避けるために、この

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

のようにソース表に追加の列を追加します。つまり、明示的に選択できますが、実行中に返されません。

SELECT * FROM tab 
関連する問題