バルクデータロードのトラブルシューティング¶
このトピックでは、バルクデータロードの問題をトラブルシューティングするための体系的なアプローチについて説明します。
このトピックの内容:
データロードの失敗¶
ステップ1: テーブルの COPY 履歴を表示する¶
テーブルのロードアクティビティ履歴をクエリします。詳細については、 COPY_HISTORY をご参照ください。 STATUS
列は、特定のファイルセットがロードされたか、部分的にロードされたか、ロードに失敗したかを示します。 FIRST_ERROR_MESSAGE
列は、試行が部分的にロードされたか失敗した場合の理由を示します。
ファイルのセットに複数の問題がある場合、 FIRST_ERROR_MESSAGE
列は最初に発生したエラーのみを示します。ファイル内のすべてのエラーを表示するには、手順として ステップ2: データのロードを検証する をご参照ください。
ステップ2: データのロードを検証する¶
VALIDATION_MODE コピーオプションは、ロードされるデータを検証し、指定された検証オプションに基づいて結果を返すように COPY ステートメントに指示します。このコピーオプションが指定されている場合、データはロードされません。コピーオプションの詳細については、 COPY INTO <テーブル> をご参照ください。
COPY ステートメントを VALIDATION_MODE コピーオプションが RETURN_ALL_ERRORS
に設定された状態で実行します。ステートメントで、ロードしようとしたファイルのセットを参照します。
次の例では、エラーを含む一連のファイルを検証します。エラーの分析を容易にするために、 COPY INTO <場所> ステートメントは問題のある記録をテキストファイルにアンロードして、元のデータファイルで分析および修正できるようにします。このステートメントは、 RESULT_SCAN テーブル関数をクエリして記録を取得します。 LAST_QUERY_ID 関数を使用して該当する記録を取得するには、このセクションのステートメントを連続して実行する必要があります。
COPY INTO mytable
FROM @mystage/myfile.csv.gz
VALIDATION_MODE=RETURN_ALL_ERRORS;
SET qid=last_query_id();
COPY INTO @mystage/errors/load_errors.txt FROM (SELECT rejected_record FROM TABLE(result_scan($qid)));
その他の問題¶
Error: Integration {0}
associated with the stage {1}
cannot be found¶
003139=SQL compilation error:\nIntegration ''{0}'' associated with the stage ''{1}'' cannot be found.
このエラーは、外部ステージと、ステージにリンクされているストレージ統合との関連付けが壊れている場合に発生する可能性があります。これは、ストレージ統合オブジェクトが再作成されたときに発生します( CREATE OR REPLACE STORAGE INTEGRATION を使用)。ステージは、ストレージ統合の名前ではなく、非表示の ID を使用してストレージ統合にリンクします。バックグラウンドでは、 CREATE OR REPLACE 構文はオブジェクトをドロップし、別の非表示の IDでオブジェクトを再作成します。
1つ以上のステージにリンクされた後にストレージ統合を再作成する必要がある場合は、 ALTER STAGE stage_name
SET STORAGE_INTEGRATION = storage_integration_name
を実行して、各ステージとストレージ統合間の関連付けを再確立する必要があります。ここで、
stage_name
は、ステージの名前です。storage_integration_name
は、ストレージ統合の名前です。
COPY_HISTORY ビューの LOAD_TIME 値より前の CURRENT_TIMESTAMP を使用して挿入されたロード時間¶
テーブル設計者は、記録がテーブルにロードされるときに、現在のタイムスタンプをデフォルト値として挿入するタイムスタンプ列を追加できます。目的は、各記録がテーブルにロードされた時間をキャプチャすることです。ただし、タイムスタンプは、 COPY_HISTORY関数 (Information Schema)または COPY_HISTORYビュー (Account Usage)によって返されるLOAD_TIME列の値よりも前です。その理由は、 CURRENT_TIMESTAMP は、記録がテーブルに挿入されたとき(つまり、ロード操作のトランザクションがコミットされたとき)ではなく、クラウドサービスでロード操作がコンパイルされたときに評価されるためです。
代わりに METADATA$START_SCAN_TIME を含めてクエリすることをお勧めします。これにより、記録のロードがより正確に表現されます。