Messages d'erreur

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 des erreurs

Le tableau suivant répertorie les codes d'erreur pouvant être renvoyés par BigQuery. Les réponses de l'API BigQuery incluent un code d'erreur HTTP et un objet d'erreur dans le corps de la réponse. La colonne "Code d'erreur" ci-dessous correspond à la propriété reason dans l'objet d'erreur. Ce tableau n'inclut pas toutes les erreurs HTTP possibles ou d'autres erreurs de mise en réseau. Par conséquent, ne partez pas du principe qu'un objet errors est présent dans chaque réponse d'erreur de BigQuery.

Vous pouvez également recevoir des erreurs ou des objets d'erreur différents si vous utilisez les bibliothèques clientes Cloud pour l'API BigQuery. Pour en savoir plus, consultez la page Bibliothèques clientes de l'API BigQuery.

Si vous recevez un code de réponse HTTP qui n'apparaît pas dans la liste ci-dessous, le code de réponse indique un problème ou un résultat attendu avec la requête HTTP. Les codes de réponse compris dans la plage 5xx indiquent une erreur côté serveur. Si vous recevez un code de réponse 5xx, réessayez la requête ultérieurement. Dans certains cas, un code de réponse 5xx peut être renvoyé par un serveur intermédiaire, tel qu'un proxy. Pour en savoir plus sur l'erreur, examinez le corps de la réponse et les en-têtes de réponse. Pour obtenir la liste complète des codes de réponse HTTP, consultez les codes de réponse HTTP.

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 correspondante dans le tableau ci-dessous, utilisez l'option -- format=prettyjson. Exemple : bq --format=prettyjson show -j <job id>

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, une table, une vue 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. Toutefois, il existe deux cas particuliers pour résoudre cette erreur : les appels jobs.get et les appels jobs.insert.

Appels jobs.get

  • Si vous avez reçu une erreur 503 lors de l'interrogation de jobs.get, patientez quelques secondes, puis relancez l'interrogation.
  • Si la tâche est terminée, mais contient un objet d'erreur contenant backendError, la tâche 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 jobs.insert

Si vous recevez cette erreur lors d'un appel jobs.insert, il est difficile de savoir si la tâche a réussi. Dans ce cas, il faut essayer de ré-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 Google Cloud Console.
blocked 403 Cette erreur apparaît lorsque BigQuery a temporairement mis sur liste de blocage 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à. L'erreur est également renvoyée lorsque la propriété de la tâche writeDisposition est définie sur WRITE_EMPTY et que la table de destination à laquelle la tâche est associée existe déjà. Renommez la ressource que vous essayez de créer ou modifiez la valeur writeDisposition dans la tâche.
internalError 500 Cette erreur apparaît lorsqu'une erreur interne se produit dans BigQuery. Retentez l'opération et si l'erreur persiste, contactez l'assistance ou envoyez un rapport de bug à l'aide de l'outil de suivi des problèmes 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 incorrectes renvoient une erreur invalidQuery.
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.
invalidUser 400 Cette erreur apparaît lorsque vous tentez de planifier une requête avec des identifiants utilisateur non valides. Actualisez les identifiants utilisateur, comme expliqué dans la page Planifier des requêtes.
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 reçu des données en flux continu. Corrigez les noms de ressources ou attendez au moins six heures après l'opération de flux continu 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 vous avez dépassé la version gratuite pour les requêtes. 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. Si cette erreur apparaît lorsque vous utilisez le bac à sable BigQuery, vous pouvez effectuer une mise à niveau.

Pour en savoir plus, consultez la page Résoudre les erreurs de quota BigQuery.

rateLimitExceeded 403 Cette erreur apparaît si le projet dépasse une limitation du débit à court terme en envoyant trop de requêtes trop rapidement. Vous pouvez par exemple consulter les limitations du débit pour les tâches de requête et les limitations du débit pour les requêtes d'API. Ralentissez la fréquence des demandes.

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

Pour en savoir plus, consultez la page Résoudre les erreurs de quota BigQuery.

resourceInUse 400 Cette erreur apparaît lorsque vous tentez 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 retirer 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 valeur <n> élevée, pensez à utiliser GROUP BY à la place. Pour en savoir plus, consultez la section sur COUNT(DISTINCT).
  • Si votre requête utilise UNIQUE, utilisez plutôt GROUP BY ou une fonction de fenêtre 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 envoie 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 assurer l'affichage des résultats de taille volumineuse, vous pouvez définir la propriété allowLargeResults sur true et spécifier la 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://bigquery.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 400 (Bad Request) ou d'une erreur 401 (Unauthorized). description_string est l'une des erreurs définies 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, vous devez examiner la propriété insertErrors de la réponse pour déterminer si les lignes ont bien été insérées, car il se peut que BigQuery n'ait réussi à insérer les lignes que partiellement.

Si la propriété insertErrors est 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éma sur certaines des lignes de 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 qui ne présentent pas une incompatibilité de schéma. Les lignes sans incompatibilité de schéma présentent une erreur lorsque la propriété reason est définie sur stopped, et peuvent être renvoyées telles quelles. Les lignes qui ont échoué incluent des informations détaillées sur l'incompatibilité du schéma.

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

Étant donné que l'API de 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 flux continu. La plupart du temps, 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 du schéma. La modification du schéma d'une table qui a récemment reçu des insertions en flux continu peut causer des réponses avec erreurs d'incompatibilité de schémas, car le système de flux continu peut ne pas relever immédiatement le changement de schéma.
  • Création/Suppression de table. Un flux continu dirigé vers une table qui n'existe pas renverra une variation de réponse notFound. La table créée dans la réponse peut ne pas être immédiatement reconnue par les insertions en flux continu suivantes. De même, supprimer 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. Les insertions en flux continu peuvent ne pas se trouver dans la nouvelle table.
  • Troncation de table. Le fait de tronquer les données d'une table (par exemple, à l'aide d'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 flux continu, 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 ce tampon, comme les tâches de copie de table et les méthodes d'API telles que tabledata.list. De ce fait, les données de flux continu récentes ne seront pas présentes dans la table ou la sortie de destination.

Haut de page