Résoudre les problèmes liés aux requêtes

Ce document est destiné à vous aider à résoudre les problèmes courants liés à l'exécution de requêtes, tels que l'identification des raisons de lenteur des requêtes ou la résolution des erreurs courantes renvoyées par les requêtes ayant échoué.

Résoudre les problèmes liés à la lenteur des requêtes

Pour résoudre les problèmes de lenteur des requêtes, procédez comme suit :

  • Consultez la page Google Cloud Service Health pour connaître les pannes de service BigQuery connues susceptibles d'avoir un impact sur les performances des requêtes.

  • Examinez la chronologie de la tâche de votre requête dans l'explorateur de tâches pour voir le temps nécessaire à l'exécution de chaque étape de la requête.

    • Si la majeure partie du temps écoulé est due à des temps de création longs, contactez Cloud Customer Care pour obtenir de l'aide.

    • Si la majeure partie du temps écoulé est due à des temps d'exécution longs, consultez vos informations sur les performances des requêtes. Les insights sur les performances des requêtes peuvent vous informer si l'exécution de votre requête a dépassé la durée d'exécution moyenne et suggérer les causes possibles. Les causes possibles incluent un conflit d'emplacements de requête ou un quota de brassage insuffisant. Pour en savoir plus sur chaque problème de performances des requêtes et les solutions possibles, consultez la page Interpréter les insights sur les performances des requêtes.

  • Examinez le champ finalExecutionDurationMs dans le type d'objet JobStatistics de votre job de requête. La requête a peut-être été relancée. Le champ finalExecutionDurationMs contient la durée en millisecondes de l'exécution de la dernière tentative de ce job.

  • Examinez la quantité d'octets traités sur la page des informations sur la tâche de requête pour voir si elle est plus élevée que prévu. Pour ce faire, comparez le nombre d'octets traités par la requête actuelle à un autre job de requête qui s'est terminé dans un délai acceptable. S'il existe un écart important entre les octets traités par les deux requêtes, il est possible que la requête ait été lente en raison d'un volume de données important. Pour en savoir plus sur l'optimisation de vos requêtes pour gérer de grands volumes de données, consultez Optimiser le calcul des requêtes.

    Vous pouvez également identifier les requêtes de votre projet qui traitent une grande quantité de données en recherchant les requêtes les plus coûteuses à l'aide de la vue INFORMATION_SCHEMA.JOBS.

  • Examinez l'utilisation de vos réservations et vérifiez s'il y a des conflits d'emplacements. Pour en savoir plus, consultez Analyse des statistiques de charge de travail.

  • Vérifiez les exécutions précédentes et récentes pour le même hachage de requête afin de voir si de nouveaux insights sur les performances des requêtes sont disponibles pour les jobs plus lents, comme un changement d'échelle d'entrée de données. Vous pouvez filtrer par hachage de requête dans l'explorateur de jobs d'administration.

Comparer une exécution lente et une exécution rapide de la même requête

Si une requête qui s'exécutait rapidement est désormais lente, examinez le résultat de l'objet API Job pour identifier les modifications apportées à son exécution.

Succès de cache

Vérifiez si l'exécution rapide du job était un succès de cache (hit) en consultant la valeur cacheHit. Si la valeur est true pour l'exécution rapide de la requête, cela signifie que la requête a utilisé des résultats mis en cache au lieu d'exécuter la requête.

Si vous vous attendez à ce que le job lent utilise des résultats mis en cache, recherchez pourquoi la requête n'utilise plus les résultats mis en cache. Si vous ne vous attendez pas à ce que la requête récupère des données du cache, recherchez un exemple d'exécution de requête rapide qui n'a pas atteint le cache pour l'investigation.

Délais de quota

Pour déterminer si le ralentissement est dû à des reports de quota, vérifiez le champ quotaDeferments pour les deux jobs. Comparez les valeurs pour déterminer si l'heure de début de la requête la plus lente a été retardée par des reports de quota qui n'ont pas affecté le job le plus rapide.

Durée de l'exécution

Pour comprendre la différence entre la durée d'exécution de la dernière tentative des deux jobs, comparez leurs valeurs pour le champ finalExecutionDurationMs.

Si les valeurs de finalExecutionDurationMs sont assez similaires, mais que la différence de temps d'exécution réel entre les deux requêtes, calculée comme startTime - endTime, est beaucoup plus importante, cela signifie qu'une nouvelle tentative d'exécution de requête interne a pu être effectuée pour le job lent en raison d'un éventuel problème temporaire. Si vous constatez ce schéma de différence à plusieurs reprises, contactez Cloud Customer Care pour obtenir de l'aide.

Octets traités

Examinez la quantité d'octets traités sur la page d'informations sur la tâche de requête ou consultez totalBytesProcessed dans JobStatistics pour voir si elle est plus élevée que prévu. S'il existe un écart important entre les octets traités par les deux requêtes, la requête peut être lente en raison d'une modification du volume de données traitées. Pour en savoir plus sur l'optimisation des requêtes afin de gérer de grands volumes de données, consultez Optimiser le calcul des requêtes. Les raisons suivantes peuvent entraîner une augmentation du nombre d'octets traités par une requête :

  • La taille des tables référencées par la requête a augmenté.
  • La requête lit désormais une partition plus grande de la table.
  • La requête fait référence à une vue dont la définition a changé.

Tables référencées

Vérifiez si les requêtes lisent les mêmes tables en analysant le résultat du champ referencedTables dans JobStatistics2. Les différences entre les tables référencées peuvent s'expliquer par les éléments suivants :

  • La requête SQL a été modifiée pour lire différentes tables. Comparez le texte de la requête pour le confirmer.
  • La définition de la vue a changé entre les exécutions de la requête. Vérifiez les définitions des vues référencées dans cette requête et mettez-les à jour si nécessaire.

Les différences entre les tables référencées peuvent expliquer les modifications de totalBytesProcessed.

Utilisation des vues matérialisées

Si la requête fait référence à des vues matérialisées, les différences de performances peuvent être dues au fait que les vues matérialisées sont choisies ou rejetées lors de l'exécution de la requête. Inspectez MaterializedViewStatistics pour savoir si des vues matérialisées utilisées dans la requête rapide ont été rejetées dans la requête lente. Examinez les champs chosen et rejectedReason dans l'objet MaterializedView.

Statistiques de mise en cache des métadonnées

Pour les requêtes impliquant des tables BigLake Amazon S3 ou des tables BigLake Cloud Storage avec la mise en cache des métadonnées activée, comparez le résultat de MetadataCacheStatistics pour vérifier s'il existe une différence d'utilisation du cache de métadonnées entre la requête lente et la requête rapide, et les raisons correspondantes. Par exemple, le cache de métadonnées peut se trouver en dehors de la fenêtre maxStaleness de la table.

Comparer les statistiques BigQuery BI Engine

Si la requête utilise BigQuery BI Engine, analysez le résultat de BiEngineStatistics pour déterminer si les mêmes modes d'accélération ont été appliqués à la requête lente et à la requête rapide. Examinez le champ BiEngineReason pour comprendre la raison générale de l'accélération partielle ou de l'absence d'accélération, par exemple une mémoire insuffisante, une réservation manquante ou une entrée trop volumineuse.

Examiner les différences dans les insights sur les performances des requêtes

Comparez les insights sur les performances des requêtes pour chacune des requêtes en consultant le graphique d'exécution dans la console Google Cloud ou l'objet StagePerformanceStandaloneInsight pour comprendre les problèmes potentiels suivants :

Prêtez attention aux insights fournis pour le job lent, ainsi qu'aux différences entre les insights générés pour le job rapide, afin d'identifier les changements d'étape qui affectent les performances.

Attribution de réservation

Vérifiez s'il existe des différences dans la réservation attribuée aux deux jobs. Une modification de réservation ou un passage d'une tarification à la demande à une réservation peut avoir un impact sur les performances. Pour en savoir plus, consultez Modèles de gestion des charges de travail et taille des réservations.

Une analyse plus approfondie des métadonnées d'exécution des jobs nécessite de passer par les différentes étapes de l'exécution de la requête en comparant les objets ExplainQueryStage des deux jobs.

Pour commencer, examinez les métriques Wait ms et Shuffle output bytes décrites dans la section Interpréter les informations sur les étapes de requête.

Avertissements de ressources de la vue INFORMATION_SCHEMA.JOBS

Interrogez le champ query_info.resource_warning de la vue INFORMATION_SCHEMA.JOBS pour voir s'il existe une différence dans les avertissements analysés par BigQuery concernant les ressources utilisées.

Analyse des statistiques de charge de travail

Les ressources d'emplacements disponibles et les conflits d'emplacements peuvent affecter le temps d'exécution des requêtes. Les sections suivantes vous aident à comprendre l'utilisation et la disponibilité des emplacements pour une exécution particulière d'une requête.

Nombre moyen d'emplacements par seconde

Pour calculer le nombre moyen d'emplacements utilisés par milliseconde par la requête, divisez la valeur d'emplacements-millisecondes du job, totalSlotMs de JobStatistics2, par la durée en millisecondes de l'exécution de la dernière tentative de ce job, finalExecutionDurationMs de JobStatistics.

Vous pouvez également calculer le nombre moyen d'emplacements par milliseconde utilisés par un job en interrogeant la vue INFORMATION_SCHEMA.JOBS.

Un job effectuant une quantité de travail similaire avec un plus grand nombre d'emplacements moyens par seconde se termine plus rapidement. Une utilisation moyenne des emplacements par seconde plus faible peut être due aux facteurs suivants :

  • Aucune ressource supplémentaire n'était disponible en raison d'un conflit de ressources entre différents jobs : la réservation était saturée.
  • Le job n'a pas demandé plus d'emplacements pendant une grande partie de l'exécution. Par exemple, cela peut se produire en cas de décalage des données.

Modèles de gestion des charges de travail et taille des réservations

Si vous utilisez le modèle de facturation à la demande, le nombre d'emplacements que vous pouvez utiliser par projet est limité. Votre projet peut également avoir moins d'emplacements disponibles s'il existe de nombreux conflits pour la capacité à la demande dans un emplacement spécifique.

Le modèle basé sur la capacité est plus prévisible et vous permet de spécifier un nombre confirmé d'emplacements de référence.

Tenez compte de ces différences lorsque vous comparez l'exécution d'une requête à la demande à l'exécution d'une requête qui utilise une réservation.

Il est recommandé d'utiliser une réservation pour obtenir des performances d'exécution des requêtes stables et prévisibles. Pour en savoir plus sur les différences entre les charges de travail à la demande et celles basées sur la capacité, consultez Présentation de la gestion des charges de travail.

Simultanéité des jobs

La simultanéité des jobs représente la concurrence entre les jobs pour les ressources d'emplacements lors de l'exécution de la requête. Une simultanéité des jobs plus élevée entraîne généralement une exécution plus lente des jobs, car le job a accès à moins d'emplacements.

Vous pouvez interroger la vue INFORMATION_SCHEMA.JOBS pour trouver le nombre moyen de jobs simultanés qui s'exécutent en même temps qu'une requête particulière dans un projet.

Si plusieurs projets sont attribués à une réservation, modifiez la requête pour utiliser JOBS_BY_ORGANIZATION au lieu de JOBS_BY_PROJECT afin d'obtenir des données précises au niveau de la réservation.

Une simultanéité moyenne plus élevée lors de l'exécution lente du job par rapport au job rapide est un facteur contribuant à la lenteur globale.

Envisagez de réduire la simultanéité au sein du projet ou de la réservation en répartissant les requêtes utilisant les ressources de manière intensive, au fil du temps dans une réservation ou un projet, ou sur des réservations ou des projets différents.

Une autre solution consiste à acheter une réservation ou à augmenter la taille d'une réservation existante. Envisagez d'autoriser la réservation à utiliser des emplacements inactifs.

Pour savoir combien d'emplacements ajouter, consultez Estimer les exigences relatives à la capacité d'emplacements.

Les jobs exécutés dans des réservations auxquelles plusieurs projets sont attribués peuvent obtenir des résultats d'attribution d'emplacements différents avec la même simultanéité moyenne des jobs, selon le projet qui les exécute. Consultez la section sur la planification équitable pour en savoir plus.

Utilisation des réservations

Les graphiques de ressources d'administration et BigQuery Cloud Monitoring peuvent être utilisés pour surveiller l'utilisation des réservations. Pour en savoir plus, consultez Surveiller les réservations BigQuery.

Pour savoir si un job a demandé des emplacements supplémentaires, consultez la métrique des unités exécutables estimées, qui est estimatedRunnableUnits dans la réponse de l'API Job ou period_estimated_runnable_units dans la vue INFORMATION_SCHEMA.JOBS_TIMELINE. Si la valeur de cette métrique est supérieure à 0, le job aurait pu bénéficier d'emplacements supplémentaires à ce moment-là. Pour estimer le pourcentage de temps d'exécution du job pendant lequel le job aurait bénéficié d'emplacements supplémentaires, exécutez la requête suivante sur la vue INFORMATION_SCHEMA.JOBS_TIMELINE :

SELECT
  ROUND(COUNTIF(period_estimated_runnable_units > 0) / COUNT(*) * 100, 1) AS execution_duration_percentage
FROM `myproject`.`region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
WHERE job_id = 'my_job_id'
GROUP BY job_id;
 Le résultat ressemble à ce qui suit : 
+---------------------------------+
|   execution_duration_percentage |
+---------------------------------+
|                            96.7 |
+---------------------------------+

Un faible pourcentage signifie que la disponibilité des ressources d'emplacement n'est pas un facteur majeur de la lenteur des requêtes dans ce scénario.

Si le pourcentage est élevé et que la réservation n'a pas été entièrement utilisée pendant cette période, contactez Cloud Customer Care pour examiner le problème.

Si la réservation a été entièrement utilisée pendant l'exécution lente du job et que le pourcentage est élevé, le job était limité en ressources. Envisagez de réduire la simultanéité, d'augmenter la taille de la réservation, d'autoriser la réservation à utiliser des emplacements inactifs ou d'acheter une réservation si le job a été exécuté à la demande.

Les résultats de l'analyse des métadonnées du job et de la charge de travail ne sont pas concluants

Si vous ne parvenez toujours pas à trouver la raison pour laquelle les performances des requêtes sont plus lentes que prévu, contactez Cloud Customer Care pour obtenir de l'aide.

Résoudre les problèmes liés aux requêtes à l'aide de Gemini Cloud Assist

Pour utiliser Gemini Cloud Assist afin de résoudre un échec de requête ou un problème de performances, procédez comme suit :

  1. Dans la console Google Cloud , accédez à la page BigQuery.

    Accéder à BigQuery

  2. Dans la barre d'outils Google Cloud , cliquez sur Ouvrir ou fermer le chat Gemini Cloud Assist spark.

  3. Dans le panneau Cloud Assist, saisissez un prompt incluant l'ID du job pour examiner son exécution, ses métriques de performances ou les raisons de son échec. Exemple :

    • Pourquoi JOB_ID a-t-il échoué ?
    • Pourquoi ce job prend-il autant de temps ? JOB_ID
    • Résume les performances de mon job au cours des dernières 24 heures.

Résoudre les problèmes d'échec de requête à l'aide de gcpdiag

gcpdiag est un outil Open Source. Il ne s'agit pas d'un produit Google Cloud officiellement pris en charge. Vous pouvez utiliser l'outil gcpdiag pour vous aider à identifier et à résoudre les problèmes liés au projet Google Cloud. Pour plus d'informations, consultez le projet gcpdiag sur GitHub.

L'outil gcpdiag vous aide à analyser les requêtes BigQuery ayant échoué pour déterminer s'il existe une cause racine connue et une solution pour l'échec spécifique.

Exécuter la commande gcpdiag

Vous pouvez exécuter la commande gcpdiag à partir de la Google Cloud CLI :

ConsoleGoogle Cloud

  1. Terminez l'exécution, puis copiez la commande suivante. 
    2. gcpdiag runbook bigquery/failed-query \
   --parameter project_id=PROJECT_ID \
   --parameter bigquery_job_region=JOB_REGION \
   --parameter bigquery_job_id=JOB_ID \
   --parameter bigquery_skip_permission_check=SKIP_PERMISSION_CHECK
  2. Ouvrez la console Google Cloud et activez Cloud Shell.
    3. Ouvrir la console Cloud
  3. Collez la commande copiée.
  4. Exécutez la commande gcpdiag, qui télécharge l'image Docker gcpdiag, puis effectue des vérifications de diagnostic. Le cas échéant, suivez les instructions de sortie pour corriger les échecs de vérification.

Docker

Vous pouvez exécuter gcpdiag à l'aide d'un wrapper qui démarre gcpdiag dans un conteneur Docker. Docker ou Podman doivent être installés.

  1. Copiez et exécutez la commande suivante sur votre station de travail locale.
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Exécutez la commande gcpdiag. 
    ./gcpdiag runbook bigquery/failed-query \
   --parameter project_id=PROJECT_ID \
   --parameter bigquery_job_region=JOB_REGION \
   --parameter bigquery_job_id=JOB_ID \
   --parameter bigquery_skip_permission_check=SKIP_PERMISSION_CHECK

Affichez les paramètres disponibles pour ce runbook.

Remplacez les éléments suivants :

  • PROJECT_ID : ID du projet contenant la ressource.
  • JOB_REGION : région dans laquelle le job BigQuery a été exécuté.
  • JOB_ID : identifiant de la tâche BigQuery.
  • SKIP_PERMISSION_CHECK (facultatif) : définissez ce paramètre sur True si vous souhaitez ignorer la vérification des autorisations pertinentes et accélérer l'exécution du runbook (la valeur par défaut est False).

Options utiles :

Pour obtenir la liste et la description de toutes les options de l'outil gcpdiag, consultez les instructions d'utilisation de gcpdiag.

Résolution de schéma Avro

Chaîne d'erreur : Cannot skip stream

Cette erreur peut se produire lors du chargement de plusieurs fichiers Avro avec différents schémas, ce qui entraîne un problème de résolution du schéma et l'échec de la tâche d'importation dans un fichier aléatoire.

Pour résoudre cette erreur, assurez-vous que le dernier fichier alphabétique du job de chargement contient le sur-ensemble (union) des différents schémas. Il s'agit d'une exigence basée sur la manière dont Avro gère la résolution de schéma.

Requêtes simultanées en conflit

Chaîne d'erreur : Concurrent jobs in the same session are not allowed

Cette erreur peut se produire lorsque plusieurs requêtes s'exécutent simultanément dans une session, ce qui n'est pas accepté. Référez-vous aux limites de session.

Instructions LMD en conflit

Chaîne d'erreur : Could not serialize access to table due to concurrent update

Cette erreur se produit lorsque des instructions LMD (langage de manipulation de données) en mutation simultanées (UPDATE, DELETE ou MERGE) tentent de modifier simultanément des données dans la même partition de table, ou lorsque la table est tronquée pendant l'exécution d'une instruction LMD.

BigQuery permet l'exécution simultanée d'instructions LMD en mutation sur la même table, à condition qu'elles modifient des partitions différentes. Toutefois, si deux jobs tentent de modifier la même partition, le premier job à valider réussit, et les jobs suivants échouent avec cette erreur.

Pour résoudre cette erreur, essayez les options suivantes :

  • Relancer le job en échec : si le conflit a été causé par un chevauchement temporaire avec un autre job, relancez la requête une fois le job en conflit terminé.
  • Identifier et coordonner les jobs en conflit : exécutez la requête de diagnostic de la section suivante pour identifier le job en conflit, puis coordonnez les planifications afin que les opérations LMD en mutation sur la même partition ne s'exécutent pas en même temps.
  • Partitionnez vos tables : si des jobs LMD simultanés mettent à jour différents segments de données, partitionnez votre table par date ou par plage d'entiers. Les instructions LMD en mutation simultanées réussissent sans conflit si elles modifient des partitions différentes.
  • Opérations LMD par lot : combinez plusieurs opérations UPDATE ou DELETE individuelles en une seule instruction MERGE ou un seul job par lot pour réduire la simultanéité et la surcharge de commit. Pour en savoir plus, consultez la section Bonnes pratiques.

Identifier le job en conflit

Pour identifier la tâche qui mettait à jour la table simultanément lorsque l'erreur s'est produite, exécutez une requête sur la vue INFORMATION_SCHEMA.JOBS :

SELECT
  job_id,
  query,
  start_time,
  end_time
FROM
  `region-REGION`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time BETWEEN
    TIMESTAMP_SUB(TIMESTAMP 'FAILED_JOB_START_TIME', INTERVAL 1 DAY)
    AND TIMESTAMP 'FAILED_JOB_END_TIME'
  AND destination_table.table_id = 'TABLE_NAME'
  AND destination_table.dataset_id = 'DATASET_NAME'
  AND statement_type IN ('UPDATE', 'DELETE', 'MERGE')
  AND start_time <= 'FAILED_JOB_END_TIME'
  AND (end_time >= 'FAILED_JOB_START_TIME' OR end_time IS NULL)
ORDER BY
  start_time;

Remplacez les éléments suivants :

  • REGION : nom de la région où se trouve votre ensemble de données, par exemple us.
  • FAILED_JOB_START_TIME : code temporel du début du job ayant échoué (par exemple, 2026-09-01 09:55:00 UTC).
  • FAILED_JOB_END_TIME : code temporel de la fin du job ayant échoué (par exemple, 2026-09-01 10:00:00 UTC).
  • TABLE_NAME : nom de la table que l'instruction LMD ayant échoué a tenté de mettre à jour.
  • DATASET_NAME : nom de l'ensemble de données contenant la table.

Si la requête ne renvoie aucun job initié par l'utilisateur en conflit, le conflit peut avoir été causé par une autre opération en arrière-plan, telle que l'expiration de la partition.

Autres causes de conflits de mises à jour simultanées

  • Expiration de partition : les tâches système en arrière-plan qui font expirer des partitions peuvent entrer en conflit avec une instruction LMD si elles modifient la même partition pendant l'exécution du job. Si vous utilisez l'expiration des partitions, planifiez les jobs LMD en dehors des périodes d'expiration des partitions.
  • Transactions multi-instructions : lorsqu'une transaction multi-instructions modifie une table, elle bloque toutes les autres instructions LMD simultanées sur cette table jusqu'à ce que la transaction soit terminée.
  • Instructions LMD n'affectant aucune ligne : une instruction UPDATE, DELETE ou MERGE acquiert des verrous sur les partitions ciblées et peut provoquer des conflits de sérialisation même si aucune ligne ne correspond aux conditions de filtre.

Pour en savoir plus, consultez la section Conflits d'instructions LMD.

Sous-requêtes corrélées

Chaîne d'erreur : Correlated subqueries that reference other tables are not supported unless they can be de-correlated

Cela peut se produire lorsque votre requête contient une sous-requête qui référence une colonne extérieure à cette sous-requête, appelée colonne de corrélation. La sous-requête corrélée est évaluée à l'aide d'une stratégie d'exécution imbriquée inefficace, dans laquelle la sous-requête est évaluée pour chaque ligne de la requête externe générant les colonnes de corrélation. Parfois, BigQuery peut réécrire en interne les requêtes avec des sous-requêtes corrélées afin qu'elles s'exécutent plus efficacement. L'erreur de sous-requêtes corrélée se produit lorsque BigQuery ne peut pas optimiser suffisamment la requête.

Pour résoudre cette erreur, essayez les options suivantes :

  • Supprimez toutes les clauses ORDER BY, LIMIT, EXISTS, NOT EXISTS ou IN de votre sous-requête.
  • Utilisez une requête à plusieurs instructions pour créer une table temporaire à référencer dans votre sous-requête.
  • Réécrivez votre requête pour utiliser une CROSS JOIN à la place.

Autorisations de contrôle des accès insuffisantes au niveau des colonnes

Chaînes d'erreur :

  • Access denied: Requires fineGrainedGet permission on the read columns to execute the DML statements
  • `Accès refusé : l'utilisateur n'est pas autorisé à accéder au tag avec stratégie projects/PROJECT_ID/locations/LOCATION/taxonomies/TAXONOMY_ID/policyTags/POLICY_TAG_ID sur la colonne PROJECT_ID.DATASET.TABLE.COLUMN.'

Ces erreurs se produisent lorsque vous tentez d'exécuter une requête SQL ou une instruction LMD DELETE, UPDATE ou MERGE sans disposer du rôle Lecteur détaillé sur les colonnes qui utilisent le contrôle des accès au niveau des colonnes. Ce rôle est attribué aux comptes principaux lors de la configuration d'un tag avec stratégie. Pour en savoir plus, consultez Impact sur les opérations d'écriture avec le contrôle des accès au niveau des colonnes.

Pour contourner ce problème, modifiez la requête afin d'exclure les colonnes comportant des tags avec stratégie, ou attribuez le rôle Lecteur détaillé à l'utilisateur. Ce rôle est attribué aux comptes principaux lors de la configuration d'un tag avec stratégie. Pour en savoir plus, consultez Mettre à jour les autorisations sur les tags avec stratégie.

Résoudre les problèmes liés aux requêtes programmées

Les problèmes suivants peuvent survenir lors de la configuration ou de l'exécution d'une requête programmée.

Une requête planifiée déclenche des exécutions en double

Une requête programmée peut être déclenchée plusieurs fois à l'heure programmée. Ce comportement est plus susceptible de se produire pour les requêtes planifiées exactement à l'heure (par exemple, 09:00). Cela peut entraîner des résultats inattendus, tels que des données en double si la requête effectue des opérations INSERT.

Pour réduire le risque d'exécutions en double, planifiez vos requêtes à une heure décalée, par exemple quelques minutes avant ou après l'heure (par exemple, 08:58 ou 09:03). Pour en savoir plus, consultez Planifier des requêtes.

Identifiants non valides pour les requêtes programmées

Chaînes d'erreur :

  • Error code: INVALID_USERID
  • Error code 5: Authentication failure: User Id not found
  • PERMISSION_DENIED: BigQuery: Permission denied while getting Drive credentials

Cette erreur peut se produire lorsqu'une requête programmée échoue en raison d'identifiants obsolètes, en particulier lors de l'interrogation de données Google Drive.

Pour résoudre cette erreur, procédez comme suit :

Identifiants du compte de service non valides

Chaîne d'erreur : HttpError 403 when requesting returned: The caller does not have permission

Cette erreur peut se produire lorsque vous tentez de configurer une requête programmée avec un compte de service. Pour résoudre cette erreur, consultez la procédure de dépannage dans Problèmes d'autorisation.

Heure d'instantané non valide

Chaîne d'erreur : Invalid snapshot time

Cette erreur peut se produire lorsque vous essayez d'interroger des données historiques en dehors de la fenêtre de fonctionnalité temporelle de l'ensemble de données. Pour résoudre cette erreur, modifiez la requête d'accès aux données historiques afin de l'inclure dans la fenêtre de fonctionnalité temporelle de l'ensemble de données.

Cette erreur peut également se produire si l'une des tables utilisées dans la requête est supprimée puis recréée après le démarrage de la requête. Vérifiez si une requête planifiée ou une application effectuent cette opération en même temps que la requête ayant échoué. Le cas échéant, essayez de déplacer le processus qui effectue l'opération de suppression et de recréation à une heure qui n'entre pas en conflit avec les requêtes qui lisent cette table.

La tâche existe déjà

Chaîne d'erreur : Already Exists: Job <job name>

Cette erreur peut se produire pour les tâches de requête qui doivent évaluer des tableaux volumineux, de telle sorte que la création de la tâche de requête prend plus de temps que la moyenne. Par exemple, une requête avec une clause WHERE telle que WHERE column IN (<2000+ elements array>).

Pour résoudre cette erreur, procédez comme suit :

Cette erreur peut également se produire lorsque vous définissez manuellement un ID de job, mais que le job ne renvoie pas de résultat positif dans un délai imparti. Dans ce cas, vous pouvez ajouter un gestionnaire d'exceptions pour vérifier si le job existe. Si c'est le cas, vous pouvez extraire les résultats de la requête du job.

Job introuvable

Chaîne d'erreur : Job not found

Cette erreur peut se produire en réponse à un appel getQueryResults dans lequel aucune valeur n'est spécifiée pour le champ location. Dans ce cas, réessayez l'appel et fournissez une valeur location.

Pour en savoir plus, consultez la page Évitez plusieurs évaluations des mêmes expressions de table courantes (CTE).

Position introuvable

Chaîne d'erreur : Dataset [project_id]:[dataset_id] was not found in location [region]

Cette erreur apparaît lorsque vous faites référence à une ressource d'ensemble de données qui n'existe pas ou lorsque l'emplacement dans la requête ne correspond pas à l'emplacement de l'ensemble de données.

Pour résoudre ce problème, spécifiez l'emplacement de l'ensemble de données dans la requête ou vérifiez que l'ensemble de données est disponible au même emplacement.

La requête dépasse le délai d'exécution

Chaîne d'erreur : Query fails due to reaching the execution time limit

Si votre requête atteint le Délai d'exécution de la requête, vérifiez la durée des précédentes exécutions de la requête en interrogeant la vue INFORMATION_SCHEMA.JOBS avec une requête semblable à l'exemple suivant :

SELECT TIMESTAMP_DIFF(end_time, start_time, SECOND) AS runtime_in_seconds
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE statement_type = 'QUERY'
AND query = "my query string";

Si les exécutions précédentes de la requête ont pris beaucoup moins de temps, utilisez les insights sur les performances des requêtes pour déterminer et résoudre le problème sous-jacent.

La requête dépasse la limite maximale d'octets facturés

Chaîne d'erreur : Query exceeded limit for bytes billed: LIMIT_BYTES. REQUIRED_BYTES or higher required.

Cette erreur HTTP 400 Bad Request (reason: bytesBilledLimitExceeded) se produit lorsque l'estimation avant exécution du nombre d'octets à facturer pour une requête (REQUIRED_BYTES) dépasse la limite d'octets configurée dans maximumBytesBilled (LIMIT_BYTES). BigQuery fait échouer le job avant l'exécution et ne facture pas la requête.

Étant donné que la tarification à la demande applique un minimum de 10 Mo (10,485,760 octets) par table référencée et que l'estimation avant exécution pour les tables groupées calcule une limite supérieure pour toutes les partitions correspondantes avant l'élagage du cluster, REQUIRED_BYTES peut être supérieur au nombre réel d'octets analysés lors de l'exécution de la requête.

Pour résoudre ce problème, effectuez l'une des opérations suivantes :

  • Prévisualisez l'estimation du nombre d'octets avec un dry run. Effectuez une simulation (bq query --dry_run dans la CLI bq ou configuration.dryRun = true dans l'API) ou vérifiez l'outil de validation des requêtes dans la console Google Cloud pour inspecter totalBytesProcessed avant d'exécuter la requête.
  • Optimisez la requête pour analyser moins d'octets. Sélectionnez uniquement les colonnes dont votre requête a besoin au lieu d'exécuter SELECT *, et filtrez sur les colonnes partitionnées afin que BigQuery puisse élaguer les partitions lors de l'estimation de pré-exécution. Le filtrage sur les colonnes en cluster réduit le nombre d'octets réellement facturés lors de l'exécution de la requête, mais ne réduit pas l'estimation de la limite supérieure avant l'exécution vérifiée par rapport à maximumBytesBilled. Pour en savoir plus, consultez Réduire la quantité de données traitées.
  • Augmentez la limite maximumBytesBilled. Définissez la limite d'octets maximumBytesBilled sur une valeur supérieure ou égale à la valeur REQUIRED_BYTES indiquée dans le message d'erreur à l'aide de l'option Nombre maximal d'octets facturés (sous Paramètres de requête > Options avancées) dans la console Google Cloud , de l'option --maximum_bytes_billed dans la CLI bq ou de la propriété de configuration de job configuration.query.maximumBytesBilled dans l'API.

La réponse à la requête est trop volumineuse

Chaîne d'erreur : responseTooLarge

Cette erreur se produit lorsque les résultats de la requête dépassent la taille de réponse maximale ou lorsqu'une seule ligne dépasse la limite de taille de ligne de l'API REST.

Certaines requêtes s'exécutent en plusieurs étapes. Cette erreur se produit lorsqu'une étape renvoie une taille de réponse trop importante, même si le résultat final est inférieur au maximum. Cette erreur se produit généralement lorsque les requêtes utilisent une clause ORDER BY. Il peut parfois être utile de supprimer la clause ORDER BY ou d'ajouter une clause LIMIT. Pour assurer l'affichage des résultats de taille volumineuse, spécifiez une table de destination dans la configuration de votre job. Pour les requêtes ancien SQL, vous devez également définir la propriété configuration.query.allowLargeResults sur true. Pour plus d'informations, consultez la section Écrire des résultats de requête volumineux.

Limite de taille de réponse sur une seule ligne dépassée

Chaînes d'erreur :

  • Response too large to return. Message before conversion exceeds max row limit, limit: LIMIT actual: ACTUAL
  • Response too large to return. single row too big to return due to byte limit, actual: ACTUAL limit: LIMIT

Cette erreur HTTP 403 Forbidden (reason: responseTooLarge) se produit lorsque vous lisez des résultats de requête ou des lignes de table à l'aide des méthodes de l'API REST jobs.getQueryResults ou tabledata.list (y compris l'affichage des résultats dans la console Google Cloud ou l'outil de ligne de commande bq), et qu'une seule ligne sérialisée non imbriquée dépasse la taille de ligne maximale acceptée par le point de terminaison de pagination REST (20 Mo pour jobs.getQueryResults ou 100 Mo pour tabledata.list). Cela se produit généralement sur les tables avec des schémas larges, des champs ARRAY ou STRUCT répétés profondément imbriqués, ou des valeurs STRING ou BYTES volumineuses.

Pour lire des lignes qui dépassent les limites de taille de ligne de l'API REST, effectuez l'une des opérations suivantes :

  • Utilisez l'API BigQuery Storage Read. Lisez la table ou la table de destination de la requête temporaire à l'aide de l'API Storage Read, qui diffuse les données au format binaire Apache Arrow ou Avro et accepte les lectures à haut débit de structures de lignes volumineuses et complexes.
  • Exportez la table vers Cloud Storage. Exportez les résultats de la table ou de la requête vers Cloud Storage à l'aide d'une instruction EXPORT DATA ou d'un job d'extraction (par exemple, au format Avro, Parquet ou JSON), puis lisez les fichiers exportés depuis Cloud Storage.
  • Projetez ou agrégez moins de colonnes. Au lieu d'exécuter SELECT *, sélectionnez uniquement les colonnes ou sous-champs spécifiques requis par votre application, ou annulez l'imbrication des tableaux répétés dans votre requête afin que les lignes de sortie individuelles restent sous la limite de taille.

Un paramètre obligatoire est manquant

Chaîne d'erreur : Required parameter is missing: PARAMETER_NAME

Cette erreur HTTP 400 Bad Request (reason: required) est une erreur de validation d'API avant l'exécution qui se produit lorsqu'un champ obligatoire dans une charge utile ou une URL de requête API n'est pas fourni, ou lorsqu'une propriété obligatoire sur un objet de configuration de bibliothèque cliente est null ou None.

Pour résoudre cette erreur, procédez comme suit :

  • Consultez la documentation de référence de l'API REST. Inspectez le PARAMETER_NAME dans le message d'erreur, puis examinez le corps de la requête et les paramètres de requête requis pour la méthode dans la documentation de référence de l'API REST BigQuery afin de vous assurer que votre code renseigne tous les champs obligatoires.
  • Vérifiez les paramètres de la bibliothèque cliente. Si vous utilisez une bibliothèque cliente BigQuery (telle que la bibliothèque cliente Java ou Python), consultez la documentation de la bibliothèque cliente pour connaître les paramètres requis de la méthode que vous appelez.
  • Inspectez l'objet de configuration avant d'appeler l'API. Utilisez un débogueur ou une instruction de journalisation pour inspecter l'objet de configuration de la tâche ou de la requête juste avant l'exécution de l'appel d'API, et recherchez les valeurs None ou null attribuées aux propriétés requises telles que destinationTable.

Réservation introuvable ou emplacements manquants

Chaîne d'erreur : Cannot run query: project does not have the reservation in the data region or no slots are configured

Cette erreur se produit lorsqu'aucun emplacement n'est attribué à la réservation attribuée au projet dans la région de la requête. Vous pouvez ajouter des emplacements à la réservation, autoriser la réservation à utiliser des emplacements inactifs, utiliser une autre réservation ou supprimer l'attribution et exécuter la requête à la demande.

Table introuvable

Chaîne d'erreur : Not found: Table [project_id]:[dataset].[table_name] was not found in location [region]

Cette erreur se produit lorsqu'une table de votre requête est introuvable dans l'ensemble de données ou la région que vous avez spécifiés. Pour résoudre cette erreur, procédez comme suit :

  • Vérifiez que votre requête contient les noms corrects du projet, de l'ensemble de données et de la table.
  • Vérifiez que la table existe dans la région où vous avez exécuté la requête.
  • Assurez-vous que la table n'a pas été supprimée et recréée pendant l'exécution du job. Sinon, une propagation incomplète des métadonnées peut provoquer cette erreur.

Trop d'instructions LMD

Chaîne d'erreur : Too many DML statements outstanding against <table-name>, limit is 20

Cette erreur se produit lorsque vous dépassez la limite de 20 instructions LMD en mutation à l'état PENDING dans une file d'attente pour une seule table. Cette erreur se produit généralement lorsque vous envoyez des jobs LMD sur une seule table plus rapidement que ce que BigQuery peut traiter.

Pour vérifier les jobs à l'état PENDING qui remplissent la file d'attente, ainsi que les jobs RUNNING qui pourraient les empêcher d'être retirés de la file d'attente, interrogez la vue INFORMATION_SCHEMA.JOBS :

SELECT
  project_id,
  job_id,
  creation_time,
  user_email,
  statement_type,
  state
FROM
  `region-us`.INFORMATION_SCHEMA.JOBS
WHERE
  statement_type IN ('UPDATE', 'DELETE', 'MERGE')
  AND state IN ('RUNNING', 'PENDING')
ORDER BY
  creation_time DESC;

Une solution possible consiste à regrouper plusieurs opérations LMD plus petites dans des jobs plus volumineux, mais moins nombreux. Par exemple, en regroupant les mises à jour et les insertions. Lorsque vous regroupez des jobs plus petites en plus grandes, le coût d'exécution des jobs les plus importants est amorti et l'exécution est plus rapide. Le regroupement des instructions LMD qui affectent les mêmes données améliore généralement l'efficacité des jobs LMD et est moins susceptible de dépasser la limite de quota de la file d'attente. Pour plus d'informations sur l'optimisation de vos opérations LMD, consultez la section Éviter les instructions LMD qui mettent à jour ou insèrent des lignes simples.

D'autres solutions permettant d'améliorer l'efficacité de vos instructions LMD peuvent consister à partitionner ou à mettre en cluster vos tables. Pour en savoir plus, consultez la section Bonnes pratiques.

Erreur 403 : quota dépassé

Chaîne d'erreur : 403 Quota exceeded: Your table exceeded quota for total number of DML jobs writing to a table, pending + running.

Cette erreur se produit lorsque le nombre total de jobs LMD (INSERT, UPDATE, DELETE et MERGE) écrivant dans une seule table (dans les états PENDING et RUNNING) dépasse le quota de simultanéité de la table.

Alors que l'erreur limit is 20 limite spécifiquement la file d'attente PENDING pour les instructions LMD en mutation (UPDATE, DELETE et MERGE), cette erreur 403 Quota exceeded s'applique au total combiné de tous les jobs LMD (INSERT plus LMD en mutation) écrivant simultanément dans une table. Étant donné que le LMD de mutation est déjà limité par sa limite de file d'attente de 20 jobs, cette erreur de quota 403 se produit le plus souvent lorsque vous envoyez trop de requêtes INSERT simultanées sur une seule table. Pour résoudre cette erreur, procédez comme suit :

  • Augmenter les emplacements de réservation : augmentez le nombre d'emplacements dans votre réservation pour accélérer l'exécution des jobs et réduire la simultanéité des jobs. Cela réduit le nombre de jobs en attente dans la file d'attente et permet d'éviter d'atteindre la limite.
  • Optimisez l'orchestration des workflows : limitez le nombre de tâches LMD simultanées dans votre outil d'orchestration pour éviter de dépasser les limites de simultanéité au niveau de la table (y compris les requêtes INSERT à haute fréquence ciblant la même table).
  • Opérations LMD par lot : combinez plusieurs instructions LMD plus petites en un nombre réduit d'instructions plus volumineuses afin de réduire le nombre total de jobs mis en file d'attente pour la table.

Transaction annulée en raison d'une mise à jour simultanée

Chaîne d'erreur : Transaction is aborted due to concurrent update against table [table_name]

Cette erreur peut se produire lorsque deux instructions LMD impliquant une mutation tentent de mettre à jour simultanément la même table. Par exemple, supposons que vous démarriez une transaction dans une session contenant une instruction LMD de mutation suivie d'une erreur. S'il n'y a pas de gestionnaire d'exceptions, BigQuery annule automatiquement la transaction à la fin de la session, ce qui peut prendre jusqu'à 24 heures. Pendant ce temps, les autres tentatives d'exécution d'une instruction LMD en mutation sur la table échouent.

Pour résoudre cette erreur, listez vos sessions actives et vérifiez si l'une d'elles contient un job de requête avec l'état ERROR qui a exécuté une instruction LMD de mutation sur la table. Ensuite, mettez fin à cette session.

Erreur 412 : Le job fait référence à une table qui appartient à un ensemble de données de basculement

Chaîne d'erreur : Error 412: The job references a table that belongs to a failover dataset in the ... region (PROJECT_ID:DATASET_ID). However, only jobs that run on a reservation with the "ENTERPRISE_PLUS" edition can modify or write to failover datasets. Please also make sure that the job that is writing to the failover dataset is running in the current primary location.

Cela signifie que le job n'a pas été exécuté avec une édition BigQuery Enterprise Plus ou qu'il a été exécuté dans une région autre que l'emplacement principal de l'ensemble de données de basculement. Pour en savoir plus, consultez Reprise après sinistre gérée.

Erreur lors du chargement de la vue lors de l'utilisation des résultats mis en cache

Chaîne d'erreur : BigQuery data export: There was an error loading this view. IAM setPolicy failed for Dataset <PROJECT_ID>. One or more users named in the policy do not belong to a permitted customer.

Cette erreur indique que vos ID client Google Workspace n'ont pas été autorisés à accéder à la contrainte de règle d'administration. Pour en savoir plus sur l'utilisation de la contrainte iam.allowedPolicyMemberDomains, consultez Utiliser la contrainte iam.allowedPolicyMemberDomains pour mettre en œuvre le partage restreint au domaine.

Erreurs de l'ancien SQL

Les erreurs suivantes peuvent se produire lors de l'utilisation de l'ancien SQL.

Cannot be queried with legacy SQL

Chaîne d'erreur : cannot be queried with legacy SQL. Please consider switching to standard SQL

Cette erreur peut se produire dans l'un des deux scénarios suivants :

  • La requête a été écrite en SQL standard, mais l'option permettant d'utiliser explicitement l'ancien SQL a été provisionnée. Veillez à exécuter votre requête en SQL standard en suivant la documentation publique, par exemple en fournissant --use_legacy_sql=false à l'aide de l'outil de ligne de commande bq.

  • Vous essayez d'interroger une table avec un classement à l'aide de l'ancien SQL, ce qui n'est pas possible.

Impossible d'interroger les tables avec des colonnes renommées à l'aide de l'ancien SQL

Chaîne d'erreur : Table project:dataset.table with renamed columns cannot be queried with legacy SQL. Please consider switching to standard SQL or dropping column my_column

Cette erreur se produit si vous interrogez une table avec une colonne renommée à l'aide de l'ancien SQL. Utilisez plutôt le SQL standard.

L'utilisateur ne dispose pas de l'autorisation requise

Chaînes d'erreur :

  • Access Denied: Project [project_id]: User does not have bigquery.jobs.create permission in project [project_id].
  • User does not have permission to query table project-id:dataset.table.
  • Access Denied: User does not have permission to query table or perhaps it does not exist.

Ces erreurs peuvent se produire lorsque vous exécutez une requête sans l'autorisation bigquery.jobs.create sur le projet à partir duquel vous exécutez la requête, quelles que soient vos autorisations sur le projet contenant les données.

Vous pouvez également recevoir ces erreurs si votre compte de service, votre utilisateur ou votre groupe ne dispose pas de l'autorisation bigquery.tables.getData sur toutes les tables et vues auxquelles votre requête fait référence. Pour en savoir plus sur les autorisations requises pour exécuter une requête, consultez Rôles requis.

Ces erreurs peuvent également se produire si la table n'existe pas dans la région interrogée, par exemple asia-south1. Vous pouvez vérifier la région en examinant l'emplacement de l'ensemble de données.

Lorsque vous corrigez ces erreurs, tenez compte des points suivants :

  • Comptes de service : les comptes de service doivent disposer de l'autorisation bigquery.jobs.create sur le projet à partir duquel ils s'exécutent, ainsi que de l'autorisation bigquery.tables.getData sur toutes les tables et vues référencées par la requête.

  • Rôles personnalisés : l'autorisation bigquery.jobs.create doit être explicitement incluse dans le rôle concerné pour les rôles IAM personnalisés, et ils doivent disposer de l'autorisation bigquery.tables.getData sur toutes les tables et vues référencées par la requête.

  • Ensembles de données partagés : lorsque vous travaillez avec des ensembles de données partagés dans un projet distinct, il se peut que vous ayez tout de même besoin de l'autorisation bigquery.jobs.create dans le projet pour exécuter des requêtes ou des jobs dans cet ensemble de données.

Pour autoriser l'accès à une table ou à une vue, consultez Autoriser l'accès à une table ou à une vue.

Autorisation bigquery.reservations.use refusée pour la réservation

Chaîne d'erreur :

  • Access Denied: Reservation projects/project/locations/region/reservations/reservation_name: Permission bigquery.reservations.use denied on reservation projects/project/locations/region/reservations/reservation_name (or it may not exist)

Cette erreur se produit lorsqu'une requête est attribuée pour s'exécuter dans une réservation spécifique à l'aide de l'instruction SET @@reservation et que l'autorisation bigquery.reservations.use est manquante pour l'utilisateur ou le compte de service. Vous pouvez inspecter l'échec dans Cloud Logging ou sur la page des jobs BigQuery pour identifier le compte principal qui a tenté d'effectuer cette opération.

Autres erreurs Access Denied

Chaînes d'erreur :

  • Access Denied: Dataset project_id:dataset_id: Permission bigquery.datasets.get denied on dataset project_id:dataset_id (or it may not exist).
  • Access Denied: Dataset project_id:dataset_id: Permission bigquery.datasets.update denied on dataset project_id:dataset_id (or it may not exist).
  • Access Denied: BigQuery BigQuery: User does not have permission to access data protected by policy tag

Pour résoudre les erreurs Access Denied générales dans BigQuery, utilisez Policy Analyzer pour déterminer l'accès d'un compte principal à une ressource.

Dans Policy Analyzer, indiquez la ressource BigQuery à laquelle vous essayez d'accéder (par exemple, //bigquery.googleapis.com/projects/YOUR_PROJECT/datasets/YOUR_DATASET/tables/YOUR_TABLE) et l'adresse e-mail de l'utilisateur ou du compte de service qui reçoit l'erreur Access Denied en tant que compte principal. L'analyse affiche les autorisations du compte principal sur la ressource, que vous pouvez comparer aux autorisations manquantes dans le message d'erreur.

Le chiffrement de destination n'est pas compatible avec les scripts

Chaîne d'erreur : configuration.query.destinationEncryptionConfiguration cannot be set for scripts

Cette erreur se produit lorsque vous tentez de définir la configuration de chiffrement de destination pour un job de script BigQuery, ce qui n'est pas possible.

Accès refusé par une règle d'administration

Chaîne d'erreur : IAM setPolicy failed for Dataset DATASET: Operation denied by org policy on resource.

Cette erreur se produit lorsqu'une règle d'administration empêche le compte principal d'interroger une ressource BigQuery. Le service de règles d'administration vous permet d'appliquer des contraintes sur les ressources compatibles dans toute votre hiérarchie d'organisation.

Si le principal doit avoir accès à la ressource, vous devez utiliser les outils de dépannage VPC disponibles pour diagnostiquer le problème lié à votre règle d'administration.

Problèmes liés à un dépassement de ressources

Les problèmes suivants se produisent lorsque BigQuery ne dispose pas de ressources suffisantes pour traiter votre requête.

La requête dépasse les ressources du processeur

Chaîne d'erreur : Query exceeded resource limits. This query used CPU_SECONDS_USED CPU seconds but would charge only ANALYSIS_MEGABYTES_BILLEDM Analysis bytes. This exceeds the ratio supported by the on-demand pricing model. Please consider moving this workload to a capacity-based pricing model, which does not have this limit. CPU_SECONDS_USED CPU seconds were used, and this query must use less than CPU_SECONDS_LIMIT CPU seconds.

Cette erreur (billingTierLimitExceeded) se produit lorsqu'une requête utilisant la tarification à la demande dépasse la limite d'utilisation maximale du processeur par données analysées d'environ 256 secondes de processeur par Mio de données analysées. Cela se produit lorsqu'une requête à la demande effectue des opérations gourmandes en ressources processeur (telles que des opérations CROSS JOIN sans contrainte, des conditions de jointure inexactes, des expressions régulières complexes, des fonctions de fenêtre analytique non partitionnées ou des fonctions JavaScript définies par l'utilisateur lourdes en calculs) sur une quantité relativement faible de données analysées.

Pour résoudre cette erreur, effectuez l'une des opérations suivantes :

La requête dépasse les ressources mémoire

Chaîne d'erreur : Resources exceeded during query execution: The query could not be executed in the allotted memory

Pour les instructions SELECT, cette erreur se produit lorsque la requête utilise trop de ressources. Pour résoudre cette erreur, consultez la section Résoudre les problèmes liés au dépassement de ressources.

Espace de pile insuffisant

Chaîne d'erreur : Out of stack space due to deeply nested query expression during query resolution.

Cette erreur peut se produire lorsqu'une requête contient trop d'appels de fonction imbriqués. Parfois, des parties d'une requête sont traduites en appels de fonction lors de l'analyse. Par exemple, une expression avec des opérateurs de concaténation répétés, comme A || B || C || ..., devient CONCAT(A, CONCAT(B, CONCAT(C, ...))).

Pour résoudre cette erreur, réécrivez votre requête afin de réduire le niveau d'imbrication.

Ressources dépassées lors de l'exécution de la requête

Chaîne d'erreur : Resources exceeded during query execution: The query could not be executed in the allotted memory. Peak usage: [percentage]% of limit. Top memory consumer(s): ORDER BY operations.

Cela peut se produire avec les requêtes ORDER BY ... LIMIT ... OFFSET .... En raison de détails d'implémentation, le tri peut se produire sur une seule unité de calcul, qui peut manquer de mémoire si elle doit traiter trop de lignes avant l'application de LIMIT et OFFSET, en particulier avec un OFFSET volumineux.

Pour résoudre cette erreur, évitez les valeurs OFFSET élevées dans les requêtes ORDER BY ... LIMIT. Vous pouvez également utiliser la fonction de fenêtrage évolutive ROW_NUMBER() pour attribuer des rangs en fonction de l'ordre choisi, puis filtrer ces rangs dans une clause WHERE. Exemple :

SELECT ...
FROM (
  SELECT ROW_NUMBER() OVER (ORDER BY ...) AS rn
  FROM ...
)
WHERE rn > @start_index AND rn <= @page_size + @start_index  -- note that row_number() starts with 1

Nœud de calcul TensorFlow à court de mémoire

Chaîne d'erreur : Resources exceeded during query execution: TensorFlow worker out of memory.

Les modèles qui dépassent la limite de mémoire (généralement 250 Mo), en particulier lorsqu'ils utilisent des fonctions gourmandes en ressources comme ML.EXPLAIN_PREDICT, peuvent déclencher cette erreur.

Pour résoudre cette erreur, procédez comme suit :

  1. Utiliser les modèles distants de Gemini Enterprise Agent Platform : pour les modèles qui dépassent les limites de mémoire, déployez votre modèle sur Agent Platform en suivant les étapes du SDK Vertex AI pour Python pour déployer un modèle, puis accédez-y à l'aide de modèles distants. Cela permet de décharger les exigences de mémoire sur l'infrastructure dédiée d'Agent Platform.

  2. Optimiser le modèle : réduisez l'empreinte RAM du modèle en simplifiant l'architecture, en quantifiant ou en élaguant.

  3. Utilisez des fonctions moins intensives : si l'erreur se produit lors d'un appel ML.EXPLAIN_PREDICT, essayez d'exécuter le job avec ML.PREDICT pour déterminer si le modèle peut s'exécuter sans la surcharge supplémentaire des fonctionnalités d'explicabilité.

  4. Analysez la taille des données d'entrée : des lignes individuelles volumineuses peuvent contribuer à l'épuisement de la mémoire. Vérifiez la taille de vos plus grandes lignes à l'aide de la commande suivante : 

    SELECT BYTE_LENGTH(TO_JSON_STRING(t)) AS row_size
FROM your_table AS t
ORDER BY row_size DESC
LIMIT 10

La requête dépasse les ressources de brassage

Chaîne d'erreur : Resources exceeded during query execution: Your project or organization exceeded the maximum disk and memory limit available for shuffle operations

Cette erreur se produit lorsqu'une requête ne peut pas accéder à suffisamment de ressources de brassage.

Pour résoudre cette erreur, provisionnez plus d'emplacements ou réduisez la quantité de données traitée par la requête. Pour en savoir plus, consultez la section Quota de brassage insuffisant.

Si vous utilisez le modèle de tarification à la demande, vous êtes limité à un maximum de 2 000 emplacements. Pour augmenter le nombre d'emplacements, vous devez passer à un modèle de tarification basé sur la capacité.

Pour en savoir plus sur la résolution de ces problèmes, consultez la section Résoudre les problèmes liés au dépassement de ressources.

Requête trop complexe

Chaîne d'erreur : Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex

Cette erreur se produit lorsqu'une requête est trop complexe. Les principales causes de la complexité sont les suivantes :

  • Clauses WITH profondément imbriquées ou utilisées à plusieurs reprises.
  • Vues profondément imbriquées ou utilisées à plusieurs reprises.
  • Utilisation répétée de l'opérateur UNION ALL.

Pour résoudre cette erreur, essayez les options suivantes :

  • Divisez la requête en plusieurs requêtes, puis utilisez un langage procédural pour exécuter ces requêtes en séquence, avec un état partagé.
  • Utilisez des tables temporaires au lieu des clauses WITH.
  • Réécrivez votre requête pour réduire le nombre d'objets référencés et de comparaisons.

Vous pouvez surveiller de manière proactive les requêtes qui approchent de la limite de complexité en utilisant le champ query_info.resource_warning dans la vue INFORMATION_SCHEMA.JOBS. L'exemple suivant renvoie les requêtes ayant entraîné une utilisation élevée des ressources au cours des trois derniers jours :

SELECT
  ANY_VALUE(query) AS query,
  MAX(query_info.resource_warning) AS resource_warning
FROM
  <your_project_id>.`region-us`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 DAY)
  AND query_info.resource_warning IS NOT NULL
GROUP BY
  query_info.query_hashes.normalized_literals
LIMIT
  1000

Pour en savoir plus sur la résolution de ces problèmes, consultez la section Résoudre les problèmes liés au dépassement de ressources.

Résoudre les problèmes liés au dépassement de ressources

Pour les tâches de requête :

Pour optimiser vos requêtes, procédez comme suit :

  • Essayez de retirer une clause ORDER BY.
  • Si la requête utilise JOIN, assurez-vous que la plus grande table se trouve à gauche de la clause. Assurez-vous également que vos données ne contiennent pas de clés de jointure en double.
  • Si la requête utilise FLATTEN, déterminez si elle est nécessaire pour ce cas d'utilisation. Pour en savoir plus, consultez la section sur les données imbriquées et répétées.
  • Si la requête utilise EXACT_COUNT_DISTINCT, pensez à utiliser plutôt COUNT(DISTINCT).
  • Si votre requête utilise COUNT(DISTINCT <value>, <n>) avec une valeur <n> élevée, pensez à utiliser GROUP BY à la place. Pour en savoir plus, consultez la section consacrée à COUNT(DISTINCT).
  • Si votre requête utilise UNIQUE, utilisez plutôt GROUP BY ou une fonction de fenêtre dans une instruction subselect.
  • Si votre requête matérialise plusieurs lignes à l'aide d'une clause LIMIT, envisagez de filtrer une autre colonne telle que ROW_NUMBER(), ou de supprimer complètement la clause LIMIT pour autoriser le chargement en parallèle des écritures.
  • Si votre requête utilise des vues profondément imbriquées et une clause WITH, cela peut entraîner une croissance exponentielle de complexité, atteignant ainsi les limites.
  • Utilisez des tables temporaires au lieu des clauses WITH. Une clause WITH peut devoir être recalculée plusieurs fois, ce qui peut compliquer la requête et la ralentir. La persistance des résultats intermédiaires dans les tables temporaires réduit la complexité.
  • Évitez d'utiliser des requêtes UNION ALL.
  • Si votre requête utilise MATCH_RECOGNIZE, modifiez la clause PARTITION BY pour réduire la taille des partitions, ou ajoutez une clause PARTITION BY si elle n'existe pas.

Pour en savoir plus, consultez les ressources suivantes :

Pour les tâches de chargement :

Si vous chargez des fichiers Avro ou Parquet, réduisez la taille des lignes dans les fichiers. Recherchez les restrictions de taille spécifiques au format de fichier que vous chargez :

Si cette erreur se produit lors du chargement des fichiers ORC, contactez l'assistance.

Pour l'API Storage :

Chaîne d'erreur : Stream memory usage exceeded

Lors d'un appel ReadRows à l'API Storage Read, certains flux avec une utilisation élevée de mémoire peuvent obtenir une erreur RESOURCE_EXHAUSTED avec ce message. Cela peut se produire lors de la lecture de tables volumineuses ou de tables avec un schéma complexe. Pour résoudre le problème, réduisez la taille des lignes de résultat en sélectionnant moins de colonnes à lire (à l'aide du paramètre selected_fields), ou en simplifiant le schéma de la table.

Résoudre les problèmes de connectivité

Les sections suivantes expliquent comment résoudre les problèmes de connectivité lorsque vous essayez d'interagir avec BigQuery :

Ajouter le DNS Google à la liste d'autorisation

Utilisez l'outil Google IP Dig pour résoudre le point de terminaison DNS BigQuery bigquery.googleapis.com en une seule adresse IP d'enregistrement "A". Assurez-vous que cette adresse IP n'est pas bloquée dans les paramètres de votre pare-feu.

En général, nous vous recommandons d'ajouter les noms DNS Google à la liste d'autorisation. Les plages d'adresses IP partagées dans les fichiers https://www.gstatic.com/ipranges/goog.json et https://www.gstatic.com/ipranges/cloud.json changent souvent. Nous vous recommandons donc d'ajouter les noms DNS Google à la liste d'autorisation. Voici une liste de noms DNS courants que nous vous recommandons d'ajouter à la liste d'autorisation :

  • *.1e100.net
  • *.google.com
  • *.gstatic.com
  • *.googleapis.com
  • *.googleusercontent.com
  • *.appspot.com
  • *.gvt1.com

Identifier le proxy ou le pare-feu qui supprime les paquets

Pour identifier tous les sauts de paquets entre le client et le Google Front End (GFE), exécutez une commande traceroute sur votre machine cliente. Elle peut mettre en évidence le serveur qui supprime les paquets dirigés vers le GFE. Voici un exemple de commande traceroute :

traceroute -T -p 443 bigquery.googleapis.com

Il est également possible d'identifier les sauts de paquets pour des adresses IP GFE spécifiques si le problème est lié à une adresse IP particulière :

traceroute -T -p 443 142.250.178.138

En cas de problème de délai avant expiration côté Google, vous verrez que la requête parvient jusqu'au GFE.

Si vous constatez que les paquets n'atteignent jamais le GFE, contactez votre administrateur réseau pour résoudre ce problème.

Générer un fichier PCAP et analyser votre pare-feu ou votre proxy

Générez un fichier de capture de paquets (PCAP) et analysez-le pour vous assurer que le pare-feu ou le proxy ne filtre pas les paquets vers les adresses IP Google et qu'il autorise les paquets à atteindre le GFE.

Voici un exemple de commande pouvant être exécutée avec l'outil tcpdump :

tcpdump -s 0 -w debug.pcap -K -n host bigquery.googleapis.com

Configurer des nouvelles tentatives pour les problèmes de connectivité intermittents

Dans certains cas, les équilibreurs de charge GFE peuvent interrompre les connexions d'une adresse IP cliente. Par exemple, s'ils détectent des modèles de trafic DDoS ou si l'instance d'équilibreur de charge est réduite, ce qui peut entraîner le recyclage de l'adresse IP du point de terminaison. Si les équilibreurs de charge GFE interrompent la connexion, le client doit intercepter la requête ayant expiré et la renvoyer au point de terminaison DNS. Assurez-vous de ne pas utiliser la même adresse IP tant que la requête n'a pas abouti, car l'adresse IP peut avoir changé.

Si vous avez identifié un problème de délais d'expiration constants côté Google pour lesquels les nouvelles tentatives ne sont d'aucune aide, contactez Cloud Customer Care et veillez à inclure un nouveau fichier PCAP généré en exécutant un outil de capture de paquets tel que tcpdump.

Étapes suivantes