私はTeradata &に新しく、DDL-DMLの両方のステートメントで作業することができました。テーブルのデータを更新するための最善のアプローチ - Teradata
私が観察したことの1つは、多くのレコードを持つテーブルのデータがUPDATEになるまでに非常に遅いということです。
私は、このアップデートを実行するにはGoogleで見つかった最も簡単な方法は、新しい値で更新する列の保持値にCASEとINSERT-SELECT文を書くことです。
しかし、この状況がData Warehouse環境に到着したとき、何百万行ものテーブルを保持するテーブルから複数の列を更新する必要がある場合はどうなりますか？ どのようなアプローチがベストになるのでしょうか？
INSERT-SELECTのみOR MERGE-UPDATE OR MLOAD？
上記の方法のいずれかがこのUPDATE操作に使用されていないかどうかはわかりません。
ありがとうございます！
エンタープライズレベルでは、ボリュームは膨大であり、更新はスケジュールされたジョブ/スクリプトの一部であることが予想されます。
大量のデータを扱うアップデートでは、更新が失敗した場合（フォールバックジャーナルのため）しばらくの間テーブルをブロックするリスクが伴います。スクリプトはうまくテストされ、本番環境ではほとんど失敗しませんが、SCD-1を維持するために一致するレコードを削除した後、必要な形式の一時表に更新する必要のあるデータを挿入し、我々は歴史を維持していない）。
この目的のためにMLOADユーティリティを使用できますか？はいの場合は、パフォーマンスが向上しますか？ – Aditya
テーブルの更新については、他の読み込みおよび書き出しユーティリティが画面外に移動しています（高速読み込み、fastexport＆BTEQ：バルクには適していません）。残るのは、MLoadまたはTPumpです。 Mloadは、非常に少量のレコードで更新が発生しない限り、パフォーマンスを向上させます。これが発生すると、TPumpのパフォーマンスはMloadのパフォーマンスに近づく可能性があります。 Mloadはブロックレベルで動作し、TPumpは行レベルで動作します。 – appleboy
インデックスを使用できない場合は、フル・テーブル・スキャンが必要ですが、通常は非常に高速です（プライマリ・インデックスまたはパーティション・カラムの更新は遅いですが、さらに、巨大な更新によって、巨大なTransient Jornalが生成される可能性があります。あなたのテーブルの行の数と更新された行の割合は何ですか？あなたのアップデートはどのようにコード化されていますか？ – dnoeth
@Dnoeth現在のところ、実際には382,851,001行の行があります。しかし、これは週ごとの増分です。だから今私たちはINSERT-SELECTアプローチで大丈夫です。しかし、間もなくこれはスペースの制約のせいで私たちのケースでは失敗に終わります。 FYI、私たちは複数の列ユーザーを持っています.PI＆テーブルはマルチリーゼです。通常、私たちはPIではない列についての更新が必要です。 – Aditya
任意のセカンダリ/結合インデックス？ MERGEは通常UPDATEより優れています（スプーリングを避けるかもしれません）。あなたのアップデートはどのようにコード化されています巨大なSelectテーブルまたはソーステーブル？ – dnoeth