- パック係数が高いと、TPumpスループットが向上する可能性があります。 高いパック係数を使用できない場合、セッション数を増やすことは、クライアントがそれらをサポートできる場合にTPumpスループットを向上させるもう1つの方法です。
- データの読み込み遅延を減らし、単一行のリアルタイム可用性を向上するには、パック係数を減らすか、BEGIN LOADでLATENCYオプションを使用します。
- 入力データにエラーが含まれている場合、パック係数が低いと、エラーが含まれているリクエストをロールバックするオーバーヘッドが減少し、エラーのないすべての行が再処理されます。
- 永続マクロを使用し、以前の/同様の実行からのTPumpの推奨パック係数を指定することにより、TPumpの起動を高速化します。 事前定義されたマクロの使用の詳細については、TPump EXECUTEコマンドを参照してください。
- セッション数を選択するときは、TPumpジョブの実行時の合計システム負荷を考慮してください。 複数のTPumpジョブが実行されている場合は、システム内のAMPの数以下のセッション数を検討してください。
- 複数のTPumpジョブが同じ基本索引値を持つ同じテーブルの行を更新する可能性がある場合は、テーブルの基本索引のデータを手動で分割して、同じPI値を持つすべての行が同じTPumpジョブに送信されるようにします。 次に、SERIALIZE ONを指定して、同じNUPI値を持つ行をそのTPumpジョブ内の単一セッションに強制し、競合の可能性をさらに減らします。
- データベース内の挿入のターゲット テーブルが結合インデックスに含まれる場合は、インデックスのないステージング テーブルに挿入するようにTPumpを指定することを検討してください。このステージング テーブルから一定の間隔でベース テーブルへの挿入/選択は、結合インデックスが関係する場合にテーブルを更新する方がパフォーマンスが良い方法である可能性があります。insert/selectの前に、UNIONを使用して、ステージング テーブルに最近挿入されたデータがクエリ回答セットに含まれていることを確認できます。
- TPump完了時間がシステムでアクティブな他の作業よりも重要である場合、TPumpジョブが意思決定支援クエリと同時に実行されるときに、Teradataワークロード管理でTPumpユーザーをより優先度の高いパフォーマンスグループまたはワークロードに割り当てます。
- TPumpが各入力レコードに対して単一AMP操作を実行できるようにするには、データベースに渡される列の中に、更新される行のプライマリインデックス値全体を含めます。 TPumpでSERIALIZE ONを使用する場合、ユーザーは、FIELDコマンドのKEYオプションを使用して、TPumpへの基本索引の列を適切に識別する必要があります。
- TPump/Teradata DataConnector/Teradata CLIv2クライアントの最新バージョンとVantageの最新バージョンを使用します。
- 同時実行は、ジョブのスループットをTPumpする鍵です。目標は、システム上で実行されている他の作業を同時に考慮しながら、(SESSIONS * PACK) として表現される同時DML操作を最大化することです。
- ARRAYSUPPORTオフの場合、TPumpジョブの最大同時AWT使用量は、通常、20 * SESSIONSの数になります。すべてのアクティブなTPumpジョブの合計 (20 * SESSIONS) がシステム上のAMP数を超える状況を避けます。1 つのTPumpパック(1 つの複数ステートメント要求)で使用されるAWTの最大数 は、ターゲットテーブルにフォールバックまたはUSIがあるかどうかによって異なる場合があります。4 つの異なるケースと最大AWTの使用法があります。
- 非USI、非フォールバック 20
- 非USI、フォールバック 20~40
- USI、非フォールバック 1~2~21 最大
- USI、フォールバック 1~4~23 最大
ターゲットテーブルにUSIがある場合、1対2のAWTまたは1対4のAWTが並行して使用されるように、より低い範囲の値が最も可能性が高く、おそらく想定されるべきです。 USIがテーブル上にある場合、AWTの使用に関して並列処理が大幅に少なくなることを期待してください。 USIのメンテナンスはシリアル化されて一意性違反を再現できるため、USIの場合、挿入ステップの並列処理は大幅に減少します。
- ARRAYSUPPORTオンにした場合、すべてのアクティブなTPumpジョブの（SESSIONS * PACK）の合計がシステム上のAMPの数を超える状況を回避します。
- テーブルの行サイズとブロックサイズは、TPumpのスループットに影響します。 行が大きいと、ブロックあたりの行数が減り、特定の行数を処理するために追加のI/Oが必要になります。 テーブル ブロック サイズを小さくすると、パフォーマンスが向上します。 テーブル ブロックが小さいほど、FSGキャッシュに簡単にキャッシュされ、全体的な物理I/Oが少なくて済みます。
- ステップ時間の変化や構文解析などの条件について、DBQLを使用してTPumpジョブ ステートメントを監視します。 これらの負のスループット。