Dépannage des chargements de données en lot¶

Étape 1 : affichage de l’historique COPY de la table¶

Interrogez l’historique des activités de chargement pour une table. Pour plus d’informations, voir COPY_HISTORY. La colonne STATUS indique si un ensemble particulier de fichiers a été chargé, partiellement chargé ou non. La colonne FIRST_ERROR_MESSAGE fournit une raison lorsqu’une tentative est partiellement chargée ou échouée.

Notez que si un ensemble de fichiers pose plusieurs problèmes, la colonne FIRST_ERROR_MESSAGE indique seulement la première erreur rencontrée. Pour afficher toutes les erreurs dans les fichiers, voir Étape 2 : validation du chargement de données pour obtenir les instructions.

Étape 2 : validation du chargement de données¶

L’option de copie VALIDATION_MODE commande une instruction COPY pour valider les données à charger et retourner les résultats en fonction de l’option de validation spécifiée. Aucune donnée n’est chargée lorsque cette option de copie est spécifiée. Pour plus d’informations sur l’option de copie, voir COPY INTO <table>.

Exécutez une instruction COPY avec l’option de copie VALIDATION_MODE définie sur RETURN_ALL_ERRORS. Dans l’instruction, faites référence à l’ensemble des fichiers que vous avez tenté de charger.

L’exemple suivant valide un ensemble de fichiers contenant des erreurs. Pour faciliter l’analyse des erreurs, une instruction COPY INTO <emplacement> décharge ensuite les enregistrements problématiques dans un fichier texte afin qu’ils puissent être analysés et corrigés dans les fichiers de données originaux. L’instruction interroge la fonction de table RESULT_SCAN pour récupérer les enregistrements. Notez que les instructions de cette section doivent être exécutées successivement afin de récupérer les enregistrements applicables à l’aide de la fonction 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)));

Erreur : l’intégration {0} associée à la zone de préparation {1} est introuvable¶

003139=SQL compilation error:\nIntegration ''{0}'' associated with the stage ''{1}'' cannot be found.

Cette erreur peut se produire lorsque l’association entre la zone de préparation externe et l’intégration de stockage liée à la zone de préparation a été rompue. Cela se produit lorsque l’objet d’intégration de stockage a été recréé (avec CREATE OR REPLACE STORAGE INTEGRATION). Une zone de préparation est liée à une intégration de stockage à l’aide d’un ID caché plutôt que le nom de l’intégration de stockage. En coulisse, la syntaxe CREATE OR REPLACE détruit l’objet et le recrée avec un ID caché différent.

Si vous devez recréer une intégration de stockage après qu’elle a été liée à une ou plusieurs zones de préparation, vous devez rétablir l’association entre chaque zone de préparation et l’intégration de stockage en exécutant ALTER STAGE stage_name SET STORAGE_INTEGRATION = storage_integration_name, où :

• stage_name est le nom de la zone de préparation.

• storage_integration_name est le nom de l’intégration de stockage.

Charger des horaires insérés en utilisant un CURRENT_TIMESTAMP antérieur aux valeurs LOAD_TIME dans la vueCOPY_HISTORY¶

Les concepteurs de tables peuvent ajouter une colonne d’horodatage qui insère l’horodatage actuel comme valeur par défaut lorsque des enregistrements sont chargés dans une table. L’objectif est de saisir l’heure à laquelle chaque enregistrement a été chargé dans la table ; toutefois, les horodatages sont antérieurs aux valeurs de la colonne LOAD_TIME renvoyées par la fonction COPY_HISTORY (Information Schema) ou la vue COPY_HISTORY (Account Usage). La raison en est que CURRENT_TIMESTAMP est évalué lorsque l’opération de chargement est compilée dans les services Cloud plutôt que lorsque l’enregistrement est inséré dans la table (c’est-à-dire lorsque la transaction pour l’opération de chargement est validée).

Il est recommandé d’inclure et de lancer la requête METADATA$START_SCAN_TIME à la place, car elle fournit une représentation plus précise du chargement de l’enregistrement.