Résoudre les erreurs

Deux types d'erreurs peuvent apparaître lors de l'utilisation de BigQuery : codes d'erreur HTTP ou erreurs de tâche. Les erreurs de tâche sont représentées dans l'objet status lors de l'appel de jobs.get().

Tableau d'erreurs

Le tableau suivant répertorie les codes d'erreur pouvant apparaître lors des requêtes effectuées sur l'API BigQuery. Les réponses de l'API comprennent un code d'erreur HTTP et un objet d'erreur. La colonne "Code d'erreur" ci-dessous correspond à la propriété reason de l'objet d'erreur.

Si vous utilisez l'outil de ligne de commande bq pour vérifier l'état d'une tâche, l'objet d'erreur n'est pas renvoyé par défaut. Afin de visualiser l'objet et la propriété reason correspondant au tableau ci-dessous, utilisez l'indicateur -- format=prettyjson. Par exemple, bq --format=prettyjson show -j <job id>.

Si vous recevez un code de réponse HTTP qui n'apparaît pas dans la liste ci-dessous, il indique un problème ou un résultat attendu pour la requête HTTP. Par exemple, l'erreur 502 signifie qu'il y a un problème de connexion réseau. Pour obtenir la liste complète des codes de réponse HTTP, consultez la section Codes de réponse HTTP.

Code d'erreur Code HTTP Description Dépannage
accessDenied 403 Cette erreur apparaît lorsque vous essayez d'accéder à une ressource telle qu'un ensemble de données de table ou une tâche à laquelle vous n'avez pas accès. Cette erreur survient également lorsqu'on tente de modifier un objet en lecture seule. Contactez le propriétaire de la ressource et demandez l'accès à la ressource.
backendError 500 ou 503 Cette erreur apparaît en cas de panne temporaire du serveur, par exemple un problème de connexion réseau ou une surcharge du serveur. En général, il suffit d'attendre quelques secondes, puis de réessayer. Cependant, il existe deux cas particuliers pour résoudre cette erreur : appels de jobs.get et appels de jobs.insert.

Appels de jobs.get

  • Si vous avez reçu une erreur 503 lors de l'interrogation de jobs.get, attendez quelques secondes et relancez l'interrogation.
  • Si une tâche se termine, mais comprend un objet d'erreur contenant backendError, elle a échoué. Vous pouvez réessayer d'exécuter la tâche en toute sécurité, sans vous soucier de la cohérence des données.

Appels de jobs.insert

Si vous recevez cette erreur lors d'un appel de jobs.insert, il n'est pas possible de savoir clairement si la tâche a réussi. Dans ce cas, il faut essayer à nouveau d'exécuter la tâche.

billingNotEnabled 403 Cette erreur apparaît lorsque la facturation n'est pas activée pour le projet. Activez la facturation pour le projet dans la console Google Cloud Platform.
blocked 403 Cette erreur apparaît lorsque BigQuery a temporairement mis sur liste noire l'opération que vous avez tenté d'exécuter, généralement pour éviter une interruption du service. Cette erreur se produit rarement. Pour en savoir plus, veuillez contacter l'assistance.
duplicate 409 Cette erreur apparaît lorsqu'on essaye de créer une tâche, un ensemble de données ou une table qui existe déjà. Elle s'affiche également lorsque la propriété writeDisposition d'une tâche est définie sur WRITE_EMPTY et que la table de destination à laquelle la tâche doit accéder existe déjà. Renommez la ressource que vous essayez de créer ou modifiez la valeur writeDisposition de la tâche.
internalError 500 Cette erreur apparaît lorsqu'une erreur interne se produit dans BigQuery. Contactez l'assistance ou signalez un bug à l'aide de l'outil de suivi des problèmes de BigQuery.
invalid 400 Cette erreur apparaît en cas de saisie non valide autre qu'une requête non valide, par exemple des champs obligatoires non remplis ou un schéma de table non valide. Les requêtes non valides renvoient l'erreur invalidQuery à la place.
invalidQuery 400 Cette erreur apparaît lorsqu'on tente d'exécuter une requête non valide. Vérifiez l'absence d'erreurs de syntaxe dans la requête. La référence de requête contient des descriptions et des exemples de construction de requêtes valides.
notFound 404 Cette erreur apparaît lorsque vous faites référence à une ressource (un ensemble de données, une table ou une tâche) qui n'existe pas. Elle peut également survenir lorsque vous utilisez des décorateurs d'instantanés pour faire référence à des tables supprimées ayant récemment été la cible d'une diffusion en flux continu. Corrigez les noms de ressources ou attendez au moins 6 heures après la diffusion avant d'interroger une table supprimée.
notImplemented 501 Cette erreur de tâche apparaît lorsqu'on tente d'accéder à une fonctionnalité qui n'est pas implémentée. Pour en savoir plus, veuillez contacter l'assistance.
quotaExceeded 403 Cette erreur apparaît lorsque le projet dépasse un quota BigQuery ou un quota personnalisé, ou lorsque la facturation n'est pas configurée et que le forfait gratuit pour les requêtes est dépassé. Affichez la propriété message de l'objet d'erreur pour en savoir plus sur le quota dépassé. Pour réinitialiser ou augmenter un quota BigQuery, veuillez contacter l'assistance. Pour modifier un quota personnalisé, envoyez une demande depuis la page de la console Google Cloud Platform. Si cette erreur apparaît lorsque vous utilisez le bac à sable BigQuery, vous pouvez effectuer une mise à niveau.
rateLimitExceeded 403 Cette erreur apparaît si le projet dépasse le taux limite de requêtes simultanées ou le nombre limite de requêtes API en envoyant trop de requêtes, trop rapidement. Ralentissez la fréquence des demandes.

Si vous pensez que le projet n'a pas dépassé l'une de ces limites, veuillez contacter l'assistance.

resourceInUse 400 Cette erreur apparaît lorsqu'on tente de supprimer un ensemble de données contenant des tables ou de supprimer une tâche en cours d'exécution. Videz l'ensemble de données avant d'essayer de le supprimer ou attendez la fin d'une tâche avant de la supprimer.
resourcesExceeded 400 Cette erreur apparaît lorsque la requête utilise trop de ressources.
  • Essayez de diviser la requête en portions plus petites.
  • Essayez de supprimer une clause ORDER BY.
  • Si la requête utilise JOIN, assurez-vous que la plus grande table se trouve à gauche de la clause.
  • 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, envisagez de vous servir de COUNT(DISTINCT) à la place.
  • Si votre requête utilise COUNT(DISTINCT <value>, <n>) avec une grande valeur <n>, envisagez de vous servir de GROUP BY à la place. Pour en savoir plus, consultez la section sur COUNT(DISTINCT).
  • Si la requête utilise UNIQUE, envisagez de vous servir de GROUP BY à la place ou d'appliquer un fenêtrage dans une instruction subselect.
responseTooLarge 403 Cette erreur apparaît lorsque les résultats de la requête dépassent la taille de réponse maximale. Certaines requêtes s'exécutent en plusieurs étapes et cette erreur survient dès que l'une des étapes renvoie une réponse d'une taille trop élevée, même si le résultat final est inférieur au maximum. Cette erreur survient généralement dans les requêtes qui utilisent une clause ORDER BY. Il peut parfois être utile d'ajouter une clause LIMIT. Sinon, supprimez la clause ORDER BY. Pour garantir que les résultats volumineux pourront être affichés, vous pouvez définir la propriété allowLargeResults à la valeur true et désigner une table de destination.
stopped 200 Ce code d'état apparaît lorsqu'une tâche est annulée.
tableUnavailable 400 Certaines tables de BigQuery s'appuient sur des données gérées par d'autres équipes produit de Google. Cette erreur indique que l'une de ces tables est indisponible. Lorsque vous rencontrez ce message d'erreur, vous pouvez essayer de relancer la requête (voir les suggestions de dépannage de internalError) ou contacter l'équipe produit Google qui vous a donné accès à ses données.

Exemple de réponse d'erreur

GET https://www.googleapis.com/bigquery/v2/projects/12345/datasets/foo
Response:
[404]
{
  "error": {
  "errors": [
  {
    "domain": "global",
    "reason": "notFound",
    "message": "Not Found: Dataset myproject:foo"
  }],
  "code": 404,
  "message": "Not Found: Dataset myproject:foo"
  }
}

Erreurs d'authentification

Les erreurs émises par le système de génération de jetons OAuth renvoient l'objet JSON suivant, tel que défini par la spécification OAuth2.

{"error" : "description_string"}

L'erreur est accompagnée d'une erreur "HTTP 400 Bad Request" ou d'une erreur "HTTP 401 Unauthorized". description_string représente l'un des codes d'erreur définis par la spécification OAuth2. Exemple :

{"error":"invalid_client"}

Haut de page

Dépannage pour les insertions en flux continu

Les sections suivantes expliquent comment résoudre les erreurs qui surviennent lorsque vous insérez des données en flux continu dans BigQuery.

Codes de réponse HTTP d'échec

Si vous recevez un code de réponse HTTP d'échec, par exemple une erreur de réseau, il est impossible de savoir si l'insertion en flux continu a réussi. Si vous essayez simplement de renvoyer la requête, des lignes risquent d'apparaître en double dans votre table. Pour éviter les doublons dans la table, définissez la propriété insertId lors de l'envoi de la requête. BigQuery utilise la propriété insertId pour éliminer les doublons.

Si vous recevez une erreur d'autorisation, une erreur de nom de table non valide ou une erreur de quota dépassé, aucune ligne n'est insérée et l'intégralité de la requête échoue.

Codes de réponse HTTP de réussite

Même si vous recevez un code de réponse HTTP de réussite, il faut vérifier la propriété insertErrors de la réponse pour déterminer si les lignes ont été insérées correctement, car il est possible que BigQuery n'ait réussi que partiellement à les insérer.

Si la propriété insertErrors correspond à une liste vide, toutes les lignes ont été insérées correctement. Autrement, excepté en cas d'incompatibilité de schémas dans l'une des lignes, les lignes ont été insérées correctement, sauf celles indiquées dans la propriété insertErrors. La propriété errors contient des informations détaillées sur la raison de l'échec de chaque ligne n'ayant pas été insérée. La propriété index indique l'index de ligne de base 0 de la requête à laquelle renvoie l'erreur.

Si BigQuery rencontre une incompatibilité de schémas sur des lignes individuelles dans la requête, aucune des lignes n'est insérée et une entrée insertErrors est renvoyée pour chaque ligne, même celles n'ayant pas d'incompatibilité de schémas. Une erreur dont la propriété reason sera définie sur stopped sera attribuée aux lignes ne présentant pas d'incompatibilité de schémas et elles pourront être renvoyées telles quelles. Les lignes ayant échoué comprennent des informations détaillées sur l'incompatibilité de schémas.

Erreurs de métadonnées pour les insertions en flux continu

Étant donné que l'API de diffusion en flux continu de BigQuery est conçue pour des taux d'insertion élevés, les modifications apportées à l'exposition des métadonnées de la table sous-jacente finissent par être cohérentes, lors de l'interaction avec le système de diffusion en flux continu. Dans la plupart des cas, les modifications des métadonnées sont propagées en quelques minutes. Les réponses de l'API peuvent cependant refléter un état incohérent de la table pendant cette période.

Scénarios possibles :

  • Modifications de schéma : la modification du schéma d'une table qui a récemment reçu des insertions en flux continu peut renvoyer des erreurs d'incompatibilité de schémas, car le système de diffusion en flux continu peut ne pas relever immédiatement le changement de schéma.
  • Création/Suppression de table : la diffusion vers une table qui n'existe pas renverra une variation de réponse notFound. La création de la table dans la réponse peut ne pas être immédiatement reconnue par les insertions en flux continu suivantes. De même, supprimer et/ou recréer une table peut engendrer une période pendant laquelle les insertions en flux continu sont effectivement présentées à l'ancienne table et ne se trouveront pas dans la nouvelle.
  • Troncation de table : le fait de tronquer les données d'une table (par exemple, via une tâche de requête utilisant writeDisposition de WRITE_TRUNCATE) peut également entraîner la suppression des insertions suivantes pendant la période de cohérence.

Données manquantes ou non disponibles

Les insertions en flux continu résident temporairement dans le tampon de diffusion, qui présente des caractéristiques de disponibilité différentes de celles du stockage géré. Certaines opérations dans BigQuery n'interagissent pas avec le tampon de diffusion, comme les tâches de copie de table et les méthodes API, telles que tabledata.list. De ce fait, les données de diffusion récentes ne seront pas présentes dans la table ou la sortie de destination.

Haut de page

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Besoin d'aide ? Consultez notre page d'assistance.