Teradata TPumpは、MultiLoadユーティリティと同様の機能を備えたTeradataユーティリティです。MultiLoadは、挿入、更新、および削除を実行してTeradataテーブルを編集します。Teradata TPumpも同様です。このセクションでは、MultiLoadとTeradata TPumpの重要な相違点について説明します。このセクションのすべての情報は、このマニュアルの後半で、さらに具体的にあるいは包括的に説明します。
操作の方法
MultiLoadは、データベースの更新を段階的に実行します。操作の最初の段階では、大きな(64KB)データ メッセージをデータベースに効率的に送信するために、特殊なデータベースとCLIv2プロトコルを使用します。データは一時的なテーブルに格納されます。操作の2番目の段階では、一時的なテーブルが整列され、そこから変更内容が各種のターゲット テーブルに適用されます。この段階では、処理全体がデータベースで実行され、クライアント上のMultiLoadはジョブが正常に完了するのを待ちます。
Teradata TPumpはデータベースの更新を非同期に実行します。変更内容は、従来型のCLIv2パーセルで送信され、ターゲット テーブルにすぐに適用されます。その効率を上げるために、Teradata TPumpは複数文の要求を作成します。さらに、ロックのオーバーヘッドを減らすのに役立つ逐次化オプションを提供しています。
スケールの経済性とパフォーマンス
MultiLoadの第2段階では、変更が1回のパスによってターゲット テーブルに適用されるため、変更の量が多いほどMultiLoadのパフォーマンスは向上します。物理データ ブロックに対するすべての変更がブロックの1回の読み取りと1回の書き込みによって実現されます。さらに、MultiLoadによって使用される一時的なテーブルと整列プロセスは、変更の量によって「償却」する必要のある追加のオーバーヘッドとなります。
一方、Teradata TPumpの場合、一時的なテーブルのオーバーヘッドがないため、変更量が比較的少ない場合はより効率的に動作します。Teradata TPumpは、大量のデータを処理する場合にはコスト高になります。これは、物理データ ブロックへの複数の更新によって、ブロックの複数の読み取りと書き込みが発生する可能性が高くなるためです。
基本索引なし(NoPI)テーブルのロード
NoPIテーブルには、基本索引がありません。このテーブルは、テーブルに常にデータが追加される場合のステージングテーブルとして使用できます。通常、この方式でのデータ投入は、基本索引を含んだ従来のテーブルよりも高速に実行されます。
NoPIテーブルにより、Teradata TPump Array INSERTのパフォーマンスが向上します。
複数文リクエスト
パフォーマンスをMultiLoadよりも向上させるためにTeradata TPumpが採用している最も重要な技法は、複数文要求です。複数の文を1つの要求に入れることは、2つの理由で有益です。1つは、大きなメッセージは小さなメッセージより効率的であるため、ネットワークのオーバーヘッドが減少することです。2つ目の理由は、(ROBUSTモード時)各要求で書き込まれたデータベース行が1つ余分に増える、Teradata TPumpの回復のオーバーヘッドが減ることです。Teradata TPumpは、BEGIN LOADコマンドのPACK仕様に基づいて、複数の文を1つの要求に自動的にまとめます。
Teradata TPump PACK係数はクライアントに対して、同じ要求の複数のデータ レコードをサーバーに送信して処理するよう指示します。サーバーでエラーが検出されると、要求全体をアボートし、エラーはクライアントに送り返されます。その後、Teradata TPumpはエラーが生じたデータ レコードを要求から削除し、Teradata TPumpエラー テーブルに格納します。その後、この要求はサーバーに再送信されます。エラーの処理は1度に1つのみのため、1つの要求で複数のエラーが存在する場合、ロールバックと再発行が複数回生じ、パフォーマンスが低下する可能性があります。
Teradata TPump 14.00からは、このエラー処理におけるパフォーマンスの問題を新しいクライアント/サーバー プロトコルが解決しています。この機能では、同一の要求における複数のエラーを処理します。データに関するエラーがサーバーで検出された場合、関連する文のみがロールバックされます。同じ要求で正常に処理されたその他の文は、ロールバックされません。サーバーはその後、エラーが発生した文ごとにエラー パーセルを1つクライアントに返し、さらに正常に処理された文ごとに成功パーセルを1つ返します。
エラーが生じなかったデータ レコードはサーバーによって正常に処理されるため、エラーが発生したデータ レコードを削除した後、要求を再発行する必要はありません。Teradata TPumpは、次のデータ レコード セットの必要な処理を続行します。
使用法または機能上の制約に関する詳細は、Teradata Vantage™ - SQLデータ操作言語, B035-1146を参照してください。
マクロの作成
効率化のために、Teradata TPumpは、実際のDMLコマンドではなく、マクロを使用してテーブルを修正します。ジョブの開始前に文を同等のマクロに変更するという技法により、パフォーマンスが著しく向上します。
- Teradata TPumpによってデータベースに送信されるネットワーク(およびチャネル)メッセージのサイズが小さくなる。
- マクロの実行計画(またはステップ)がキャッシュに入れられ、再使用されるため、データベース パーシング エンジンのオーバーヘッドが減少する。これにより、Teradata TPumpから送信された各要求の計画と最適化という、通常のパーサー(構文解析)処理が不要になります。
マクロによって必要とされるスペースはごくわずかであるため、マクロに関して問題となるのは、マクロがデータベースのどこに置かれるかということだけです。マクロは、再始動ログテーブルを含むデータベース、またはBEGIN LOADコマンドのMACRODBキーワードを使用して指定されたデータベースに組み込まれます。
ロックおよびトランザクションのロジック
Teradata TPumpでは、MultiLoadとは対照的に、従来の行ハッシュ ロックが使用されます。そのため、ターゲットテーブルに対してある程度の同時読み取りおよび書き込みアクセスが可能になります。ターゲットテーブルへの完全なアクセスを維持するときは、いつでもTeradata TPumpを停止することができます。ただし、Teradata TPumpを停止すると、更新処理の特性によっては、データの相互関係上の整合性が損なわれることがあります。
この点は、いくつかのターゲット テーブルに対する1つの論理的な更新として機能するMultiLoadとは異なります。MultiLoadがそのロジックの第2段階に入ると、ジョブは基本的に取り消しができず、すべてのターゲット テーブルはジョブが完了するまで書き込みアクセスがロックされます。
トリガーが関連付けられている行がTeradata TPumpによって操作されると、必要に応じてトリガーが呼び出されます。
回復ロジックおよびオーバーヘッド
Teradata TPumpのROBUSTモードでは、要求が発行されるたびに、再起動ログ テーブルに1つのデータベース行が書き込まれます。再始動ログ テーブルにおけるこの行の集まりは、要求ログと呼ぶことができます。要求はデータベースによって、完全に終了するか、完全にロールバックされるかのどちらかに保証されているため、要求ログは常にTeradata TPumpインポートの完了状況を正確に反映しています。したがって、再始動ロジックに関する要求ログのオーバーヘッドは、要求ごとにパックされる文の数が多いほど減少します。
Teradata TPumpでは、さらに、チェックポイント間隔を指定することができます。チェックポイント プロセスで、Teradata TPumpは、インポート ファイルからの保留中の変更をすべてデータベースにフラッシュし、さらに要求ログを空にします。チェックポイント間隔が大きいほど、要求ログ(およびそのテーブル)のサイズが増大することが見込まれます。予期しない再始動時には、Teradata TPumpは、インポート データ ソースを要求ログと一緒にスキャンして、要求ログで検出されない文を再実行します。
Teradata TPumpのSIMPLE(非ROBUST)モードでは、基本的なチェックポイントが作成されます。チェックポイントとチェックポイントの間に再始動が発生すると、いくつかの要求はおそらく再処理されます。一部の状況のもとでは、これで十分な保護になります。
これに対し、MultiLoadでは、再始動によってジョブが常に最初から再始動されることがないように、第1段階でチェックポイントが使用されます。第2段階では、MultiLoadの一時的なテーブルが、適用すべきすべての変更のリポジトリとして使用され、変更を適用するデータベース プロセスにおいて、何かの変更が脱落したり2回以上適用されたりすることがないように保証されます。
変更の逐次化
Teradata TPumpまたはMultiLoadの使い方によっては、1つのジョブで1つの行に複数の変更が加えられることがあります。例えば、バッチ ジョブ中に挿入された行が後で更新されたり、更新された行が後で削除されたりすることがあります。どのケースでも、これらの操作を正しい順序で行なうことが非常に重要です。MultiLoadでは、操作の順序が正しく維持されることが自動的に保証されます。逐次化機能を使用することにより、Teradata TPumpでも同様の操作順序を達成できますが、そのためには、多少のスクリプト作成作業とユーティリティ オーバーヘッドが必要になります。
BEGIN LOADコマンドで逐次化オプションを使用すると、特定のキーを持つデータ レコードに対するそれぞれの変更をTeradata TPumpが正しい順序で送信することが保証されます。FIELDコマンドのKEY修飾子は、スクリプトにおいて特定のフィールドを逐次化キーの一部として指定する手段です。この機能の目的は、ターゲット テーブルの基本索引に対応するキーを指定することです。実際には、TABLEコマンドで生成されるフィールドがテーブルの基本索引の一部であるときに、そのフィールドはKEY修飾子によって自動的に修飾されます。Teradata TPumpスクリプトのDML文で複数のターゲット テーブルを指定する場合、逐次化機能の使用時にすべてのテーブルの基本索引が一致するように保証するのは、スクリプト作成者の責任です。
逐次化機能は、データ レコードをデータベースに送ったのがどのセッションかをそのレコードのキーに基づいて判別しながら各データ レコードをハッシュすることによって機能します。したがって、ハッシュの算術演算や、送信用に選択されたセッションですでに要求が保留されている場合にデータを保存するのに必要とされる余分なバッファリングから、アプリケーションの余分なオーバーヘッドが発生します。
最後に、逐次化機能によって、データベースのデッドロックが発生する可能性が著しく減少することに注目する必要があります。デッドロックが起こる可能性があるのは、データベース内で同じハッシュ コードを使う行に影響を与える要求がアプリケーションに対して発行されたときです。デッドロックはデータベースとTeradata TPumpによって正しく処理されますが、解決プロセスには時間がかかります。さらに、デッドロックによってロールバックされた要求をアプリケーションが再実行する必要があるため、アプリケーションに余分なオーバーヘッドが生じます。
BEGIN LOADコマンドのSERIALIZEONの使用に加えて、DMLコマンドのSERIALIZEONキーワードも使用できます。これは、指定したフィールドについて逐次化をオンにする目的で使用するキーワードです。DMLベースの逐次化機能の詳細については、DMLを参照してください。
デュアル データベース ストラテジー
逐次化機能の目的は、一般にデュアル データベースというカテゴリに分類されるその他の様々なアプリケーションをサポートすることです。その種のアプリケーションでは、別のデータベースから何らかの方法で挿入、更新、および削除についてライブフィードを受け、それらを前処理なしでデータベースに適用します。
Teradata TPumpとMultiLoadはどちらも、デュアル データベース ストラテジーのパーツになり得るものです。デュアル データベース アプリケーションは、そのアプリケーションに固有のparamod/inmodを介してTeradata TPumpまたはMultiLoadに送られるDMLストリームを生成します。Teradata TPumpとMultiLoadのどちらを選択するかは、データの量(大量の場合はMultiLoadが有利)や、同時アクセス要件(アクセス要件が多い場合はTeradata TPumpが有利)などによって決まります。
リソースの使用量と制限
Teradata TPumpに固有の機能として、文の速度を調整して実行時のリソース使用量を制限する機能があります。Teradata TPumpでは、文がデータベースに送信される1分当たりの速度を制御でき、文の送信速度は、クライアントとデータベースの両方のリソース使用量に直接に関連します。文の速度は、2つの方法で制御することができます。ジョブの実行中に動的に制御するか、あるいはBEGIN LOADコマンドのRATEキーワードを使ってジョブのスクリプト内で指定します。文の速度に対する動的な制御は、データベース上のテーブルを更新することによって実施されます。
Teradata TPumpとは対照的に、MultiLoadは常にCPUとメモリを非常に効率的に使用します。第1段階では、(データベースがボトルネックにならないものと仮定すれば)大量のネットワークまたはチャネル リソースを消費しているクライアントが、多くの場合MultiLoadのボトルネックになります。第2段階では、MultiLoadは、非常に大量のデータベース ディスク、CPU、およびメモリ リソースを使用します。実際、MultiLoad、FastLoad、およびFastExportジョブはリソースの消費が激しいため、データベースによってその同時実行数が制限されています。Teradata TPumpには、そのようなデータベースによって課せられる制限はありません。