2017-12-07 22 views
0

前週からの再処理リクエストのデータがバックアップテーブルに移動され、そのために週末に発生したエラーを再処理できません。DB2でのデータローテーション

特定のテーブルについては、3つの異なるバージョンがあります。つまり、ドキュメントのステータスとIDを格納するtable1があります。したがって、Table1の3つの同一バージョンがあります。

Table1_A

Table1_B

Table1_C

Table1_A週間アクティブになり、(すべてのレコードを格納し、週末には、スクリプトが実行され、そのTable1_A後に非アクティブとtable1_Bされます空である)は、その週のアクティブなテーブルとしてその場所を取る。 Table1_Aは前週のデータを保持します。次の週末にスクリプトでTable1_Cがアクティブになり、Table1_Bは前週からのデータを保持し、Table1_Aはすべてのデータを削除します。同じプロセスが毎週繰り返されます。

前週に関するデータがもうアクティブではない表にあるため、前週の障害のトラブルシューティングはできません。

前の週のデータを以前のアクティブなテーブルから新しいアクティブなテーブルにコピーすることについては考えましたが、空ではなく新しいアクティブテーブルには、前週のデータがあります。

このデータをコピーするにはどうすればよいですか?

このデータをコピーするときに心配する必要があるものは何ですか?

さらに、これを解決するにはより良い方法がありますか?

ありがとうございました。

答えて

0

非常に柔軟性がありません。 この理由を説明していませんが、パーティション化の範囲を調べることを強くお勧めします。パーティション化では、SQLのパフォーマンスが向上し、データが不安定になるとすぐにロールアウトされます。

Table1_bがアクティブな状態で、Table1_aにデータが存在する場合、table1_aはまだ存在し、クエリ可能です。アプリケーションの観点からはオフラインになっていても、データベースの視点からはオフラインになっている可能性があります。

私はちょうどテーブルのパーティションをチェックアウトすることをお勧めできますビジネスの背景情報なし。

+0

失敗したリクエストは、元の失敗したリクエストのtransactionIDを使用してのみ再処理できます。再処理はアプリケーションを通じて行われます。前週のtransactionIDを含むデータは非アクティブなテーブルに格納されているため、前週の失敗に対しては再処理できません。 – SamAndTheMan