Fehlermeldungen

Auf dieser Seite werden verschiedene Fehlercodes und Fehlermeldungen beschrieben, die beim Arbeiten mit BigQuery auftreten können. Dazu gehören HTTP-Fehlercodes, Jobfehler und Google Cloud Console-Fehlermeldungen. Jobfehler werden beim Aufruf von jobs.get im Objekt status dargestellt.

Fehlertabelle

Antworten von der BigQuery API enthalten einen HTTP-Fehlercode und ein Fehlerobjekt im Antworttext. Ein Fehlerobjekt ist normalerweise eines der folgenden:

  • Ein errors-Objekt, das ein Array von ErrorProto-Objekten enthält.
  • Ein errorResults-Objekt, das ein einzelnes ErrorProto-Objekt enthält.

Die Spalte Fehlercode in der folgenden Tabelle wird dem Attribut reason in einem ErrorProto-Objekt zugeordnet.

Diese Tabelle enthält nicht alle möglichen HTTP-Fehler oder andere Netzwerkfehler. Gehen Sie daher nicht davon aus, dass ein Fehlerobjekt in jeder Fehlerantwort von BigQuery vorhanden ist. Darüber hinaus erhalten Sie möglicherweise verschiedene Fehler oder Fehlerobjekte, wenn Sie die Cloud-Clientbibliotheken für die BigQuery API verwenden. Weitere Informationen finden Sie unter BigQuery API-Clientbibliotheken.

Wenn Sie einen HTTP-Antwortcode erhalten, der nicht in der folgenden Tabelle erscheint, weist der Antwortcode auf ein Problem oder ein erwartetes Ergebnis mit der HTTP-Anfrage hin. Die Antwortcodes im Bereich 5xx zeigen einen serverseitigen Fehler an. Wenn Sie einen 5xx-Antwortcode erhalten, wiederholen Sie die Anfrage später. In einigen Fällen kann der Antwortcode 5xx von einem Zwischenserver wie einem Proxy zurückgegeben werden. Details zum Fehler finden Sie im Antworttext und in den Antwortheadern. Eine vollständige Liste der HTTP-Antwortcodes finden Sie unter HTTP-Antwortcodes.

Wenn Sie das bq-Befehlszeilentool zur Prüfung des Jobstatus verwenden, wird das Fehlerobjekt standardmäßig nicht zurückgegeben. Zur Anzeige des Fehlerobjekts und des entsprechenden reason-Attributs, das der folgenden Tabelle zugeordnet wird, verwenden Sie das Flag --format=prettyjson. Beispiel: bq --format=prettyjson show -j <job id>

Fehlercode HTTP-Code Beschreibung Fehlerbehebung
accessDenied 403 Dieser Fehler wird bei dem Versuch zurückgegeben, auf Ressourcen wie Datasets, Tabellen, Ansichten oder Jobs zuzugreifen, auf die Sie keinen Zugriff haben. Er wird außerdem zurückgegeben, wenn Sie versuchen, ein schreibgeschütztes Objekt zu ändern. Wenden Sie sich an den Ressourceninhaber zur Gewährung des Zugriffs auf die Ressource.
backendError 500 oder 503 Dieser Fehler wird bei einem vorübergehenden Serverausfall zurückgegeben, z. B. wenn es ein Problem mit der Netzwerkverbindung gibt oder der Server überlastet ist. Im Allgemeinen empfiehlt es sich, einige Sekunden zu warten und es dann noch einmal zu versuchen. Es gibt jedoch zwei Sonderfälle für die Behebung dieses Fehlers: jobs.get- und jobs.insert-Aufrufe.

jobs.get-Aufrufe

  • Wenn Sie beim Aufrufen von jobs.get einen 503-Fehler erhalten, warten Sie einige Sekunden und wiederholen Sie den Aufruf.
  • Wenn der Job abgeschlossen wird, aber ein Fehlerobjekt mit backendError zurückgibt, ist der Job fehlgeschlagen. Sie können dann den Job problemlos noch einmal ausführen, die Datenkonsistenz ist dadurch nicht gefährdet.

jobs.insert-Aufrufe

Wenn Sie diesen Fehler beim Ausführen eines jobs.insert-Aufrufs erhalten, ist unklar, ob der Job erfolgreich abgeschlossen wurde. Sie müssen ihn dann noch einmal ausführen.

billingNotEnabled 403 Dieser Fehler wird zurückgegeben, wenn die Abrechnung für das Projekt nicht aktiviert ist. Aktivieren Sie die Abrechnung für das Projekt in der Google Cloud Console.
billingTierLimitExceeded 400 Dieser Fehler wird zurückgegeben, wenn der Wert von statistics.query.billingTier für einen On-Demand-Job 100 überschreitet. Dies geschieht, wenn On-Demand-Abfragen zu viel CPU-Leistung relativ zur Menge der gescannten Daten verbrauchen. Eine Anleitung zum Prüfen von Jobstatistiken finden Sie unter Jobs verwalten. Dieser Fehler tritt meist auf, wenn ineffiziente Cross Joins explizit oder implizit ausgeführt werden, beispielsweise aufgrund einer ungenauen Join-Bedingung. Diese Abfragetypen sind aufgrund des hohen Ressourcenverbrauchs nicht für On-Demand-Preise geeignet und lassen sich im Allgemeinen nicht gut skalieren. Sie können die Abfrage entweder optimieren oder zu Pauschalpreisen wechseln, um diesen Fehler zu beheben. Informationen zum Optimieren von Abfragen finden Sie unter SQL-Anti-Muster vermeiden.
blocked 403 Dieser Fehler wird zurückgegeben, wenn BigQuery den Vorgang, den Sie ausführen möchten, vorübergehend auf die Ablehnungsliste gesetzt hat, meist mit dem Ziel, einen Dienstausfall zu verhindern. Dieser Fehler tritt sehr selten auf. Wenden Sie sich an den Support, um weitere Informationen zu erhalten.
duplicate 409 Dieser Fehler wird bei dem Versuch zurückgegeben, bereits vorhandene Jobs, Datasets oder Tabellen zu erstellen. Der Fehler wird auch zurückgegeben, wenn das Attribut writeDisposition eines Jobs auf WRITE_EMPTY gesetzt und die Zieltabelle, auf die der Job zugreift, bereits vorhanden ist. Benennen Sie die Ressource, die Sie erstellen möchten, um oder ändern Sie den Wert writeDisposition im Job.
internalError 500 Dieser Fehler wird bei einem internen Fehler von BigQuery zurückgegeben. Warten Sie entsprechend den Backoff-Anforderungen im BigQuery-Service Level Agreement und führen Sie den Vorgang dann noch einmal aus. Wenn der Fehler weiterhin auftritt, wenden Sie sich an den Support oder melden Sie einen Programmfehler über die BigQuery-Problemverfolgung.
invalid 400 Dieser Fehler wird zurückgegeben, wenn die Eingabe nicht wegen einer fehlerhaften Abfrage ungültig ist, sondern z. B. wegen nicht ausgefüllter Pflichtfelder oder wegen eines ungültigen Tabellenschemas. Bei ungültigen Abfragen wird der Fehler invalidQuery zurückgegeben.
invalidQuery 400 Dieser Fehler wird zurückgegeben, wenn Sie versuchen, eine ungültige Abfrage auszuführen. Prüfen Sie die Abfrage noch einmal auf Syntaxfehler. Die Funktionsreferenz für Abfragen enthält Erläuterungen und Beispiele zur Erstellung gültiger Abfragen.
invalidUser 400 Dieser Fehler wird zurückgegeben, wenn Sie versuchen, eine Abfrage mit ungültigen Nutzeranmeldedaten zu planen. Aktualisieren Sie die Nutzeranmeldedaten, wie unter Abfragen planen erläutert.
notFound 404 Dieser Fehler wird zurückgegeben, wenn Sie eine nicht vorhandene Ressource angeben. Das kann ein Dataset, eine Tabelle oder ein Job sein. Der Fehler kann auch auftreten, wenn Sie mit Snapshot-Decorators auf gelöschte Tabellen verweisen, an die kürzlich gestreamt wurde. Korrigieren Sie die Ressourcennamen oder warten Sie nach dem Streaming mindestens sechs Stunden, bevor Sie eine gelöschte Tabelle noch einmal abfragen.
notImplemented 501 Dieser Jobfehler wird zurückgegeben, wenn Sie versuchen, auf eine nicht implementierte Funktion zuzugreifen. Wenden Sie sich an den Support, um weitere Informationen zu erhalten.
quotaExceeded 403 Dieser Fehler wird zurückgegeben, wenn Ihr Projekt ein BigQuery-Kontingent oder ein benutzerdefiniertes Kontingent überschreitet oder wenn Sie keine Abrechnung eingerichtet haben und das kostenlose Kontingent für Abfragen überschreiten. Informationen dazu, welches Kontingent überschritten wurde, sind über das Attribut message des Fehlerobjekts verfügbar. Wenn Sie ein BigQuery-Kontingent zurücksetzen oder erhöhen möchten, wenden Sie sich an den Support. Zum Ändern eines benutzerdefinierten Kontingents können Sie eine Anfrage über die Google Cloud Console-Seite senden. Wenn Sie diesen Fehler bei Verwendung der BigQuery-Sandbox erhalten, können Sie ein Upgrade ausführen.

Weitere Informationen finden Sie unter BigQuery-Kontingentfehler beheben.

rateLimitExceeded 403 Dieser Fehler wird zurückgegeben, wenn Ihr Projekt eine kurzfristige Ratenbegrenzung überschreitet, weil zu viele Anfragen zu schnell gesendet werden. Informationen hierzu finden Sie beispielsweise unter Ratenbegrenzungen für Abfragejobs und Ratenbegrenzungen für API-Anfragen. Verringern Sie die Anfragerate.

Wenn Sie der Meinung sind, dass Ihr Projekt keines dieser Limits überschritten hat, wenden Sie sich an den Support.

Weitere Informationen finden Sie unter BigQuery-Kontingentfehler beheben.

resourceInUse 400 Dieser Fehler wird bei dem Versuch zurückgegeben, ein Dataset mit Tabellen oder einen gerade ausgeführten Job zu löschen. Entfernen Sie vor dem Löschen die Tabellen aus dem Dataset bzw. warten Sie, bis der entsprechende Job abgeschlossen wurde.
resourcesExceeded 400 Dieser Fehler wird zurückgegeben, wenn Ihre Abfrage zu viele Ressourcen beansprucht.
  • Versuchen Sie, die Abfrage aufzuteilen.
  • Versuchen Sie, eine ORDER BY-Klausel zu entfernen.
  • Wenn in der Abfrage JOIN verwendet wird, muss sich die größere Tabelle auf der linken Seite der Klausel befinden.
  • Wenn in der Abfrage FLATTEN verwendet wird, prüfen Sie, ob dies für Ihren Anwendungsfall wirklich erforderlich ist. Weitere Informationen finden Sie unter Verschachtelte und wiederkehrende Daten.
  • Wenn in der Abfrage EXACT_COUNT_DISTINCT verwendet wird, können Sie stattdessen COUNT(DISTINCT) nutzen.
  • Wenn in der Abfrage COUNT(DISTINCT <value>, <n>) mit einem hohen Wert für <n> verwendet wird, können Sie stattdessen GROUP BY nutzen. Weitere Informationen finden Sie unter COUNT(DISTINCT).
  • Wenn für Ihre Abfrage UNIQUE verwendet wird, können Sie stattdessen GROUP BY oder eine Fensterfunktion in einer Subselect-Anweisung nutzen.
  • Wenn in der Abfrage viele Zeilen mithilfe einer LIMIT-Klausel materialisiert werden, können Sie beispielsweise nach einer anderen Spalte filtern, z. B. ROW_NUMBER(), oder die Klausel LIMIT ganz entfernen, um die Schreibparallelisierung zu ermöglichen.
responseTooLarge 403 Dieser Fehler wird zurückgegeben, wenn die Ergebnisse Ihrer Abfrage die maximale Antwortgröße überschreiten. Manche Abfragen werden in mehreren Schritten ausgeführt. Dieser Fehler wird zurückgegeben, wenn die Antwort bei einem einzelnen Schritt zu groß ist, auch wenn das Endergebnis unterhalb des Maximums liegt. Dieser Fehler tritt oft auf, wenn in Abfragen eine ORDER BY-Klausel verwendet wird. Manchmal lässt sich das Problem durch Hinzufügen einer LIMIT-Klausel oder durch Entfernen der ORDER BY-Klausel beheben. Wenn Sie möchten, dass große Ergebnisse keine Probleme verursachen, können Sie das Attribut allowLargeResults auf true setzen und eine Zieltabelle angeben.
stopped 200 Dieser Statuscode wird zurückgegeben, wenn ein Job abgebrochen wird.
tableUnavailable 400 Für bestimmte BigQuery-Tabellen werden Daten benötigt, die von anderen Google-Produktteams verwaltet werden. Dieser Fehler gibt an, dass eine dieser Tabellen nicht verfügbar ist. Wenn diese Fehlermeldung auftritt, können Sie die Anfrage noch einmal ausführen (siehe Vorschläge zur Fehlerbehebung für internalError) oder Sie wenden sich an das Google-Produktteam, das Ihnen Zugriff auf seine Daten gewährt hat.
timeout 400 Zeitüberschreitung beim Job Sie sollten die Menge der bei Ihrem Vorgang ausgeführten Arbeit reduzieren, damit sie innerhalb des festgelegten Limits ausgeführt werden kann. Mehr dazu unter Kontingente und Einschränkungen.

Beispiel für eine Fehlerantwort

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"
  }
}

Authentifizierungsfehler

Bei Fehlern, die vom System zur Generierung von OAuth-Tokens ausgegeben werden, wird gemäß der Definition der OAuth2-Spezifikation das folgende JSON-Objekt zurückgegeben:

{"error" : "description_string"}

Der Fehler wird zusammen mit einem "HTTP 400 Bad Request"-Fehler oder einem "HTTP 401 Unauthorized"-Fehler angezeigt. description_string ist einer der Fehlercodes, die in der OAuth2-Spezifikation definiert sind. Beispiel:

{"error":"invalid_client"}

Nach oben

Fehlerbehebung bei Streaming-Insert-Anweisungen

In den folgenden Abschnitten wird die Fehlerbehebung beim Streamen von Daten in BigQuery erörtert.

HTTP-Fehlerantwortcodes

Wenn Sie einen HTTP-Fehlerantwortcode erhalten, z. B. bezüglich eines Netzwerkfehlers, lässt sich nicht feststellen, ob die Streaming-Insert-Anweisung erfolgreich war. Wenn Sie die Anfrage einfach noch einmal senden, könnte eine Tabellenzeile doppelt auftreten. Um eine Duplizierung in Ihrer Tabelle zu verhindern, legen Sie beim Senden der Anfrage das Attribut insertId fest. BigQuery verwendet das Attribut insertId zur Deduplizierung.

Wenn Sie einen Berechtigungsfehler oder einen Fehler bezüglich eines ungültigen Tabellennamens oder eines überschrittenen Kontingents erhalten, werden keine Zeilen eingefügt und die gesamte Anfrage schlägt fehl.

HTTP-Erfolgsantwortcodes

Selbst wenn Sie einen HTTP-Erfolgsantwortcode erhalten, müssen Sie anhand des Attributs insertErrors der Antwort prüfen, ob die Zeileneinfügungen durch BigQuery erfolgreich waren. Es kann nämlich sein, dass sie nur teilweise gelungen sind.

Wenn das Attribut insertErrors eine leere Liste ist, wurden alle Zeilen erfolgreich eingefügt. Andernfalls (außer im Fall eines Schemakonflikts in einigen der Zeilen) wurden die im Attribut insertErrors angegebenen Zeilen nicht eingefügt, während die Einfügung der übrigen Zeilen erfolgreich war. Das Attribut errors enthält detaillierte Informationen darüber, warum die entsprechenden Zeilen nicht eingefügt werden konnten. Das Attribut index gibt den 0-basierten Zeilenindex der Anfrage an, auf die sich der Fehler bezieht.

Wenn BigQuery bei einzelnen Zeilen der Anfrage auf einen Schemakonflikt stößt, wird keine der Zeilen eingefügt und für jede Zeile wird ein insertErrors-Eintrag zurückgegeben, selbst für Zeilen ohne Schemakonflikt. Für Zeilen ohne Schemakonflikt wird ein Fehler angegeben, bei dem das Attribut reason auf stopped gesetzt ist. Diese Zeilen können unverändert noch einmal gesendet werden. Fehlgeschlagene Zeilen enthalten detaillierte Informationen zum Schemakonflikt.

Metadatenfehler bei Streaming-Insert-Anweisungen

Da die Streaming-API von BigQuery auf hohe Einfügungsraten ausgelegt ist, sind Änderungen an den zugrunde liegenden Tabellenmetadaten beim Interagieren mit dem Streamingsystem letztendlich konsistent. In den meisten Fällen werden Metadatenänderungen innerhalb von Minuten wirksam. In diesem Zeitraum kann es jedoch vorkommen, dass API-Antworten den uneinheitlichen Zustand der Tabelle widerspiegeln.

Hier einige Szenarien:

  • Schemaänderungen Das Ändern des Schemas einer Tabelle, die kürzlich Streaming-Insert-Anweisungen erhalten hat, kann zu Schemakonfliktfehlern führen, da das Streamingsystem die Schemaänderung unter Umständen nicht sofort übernimmt.
  • Erstellen/Löschen einer Tabelle Beim Streamen an eine nicht vorhandene Tabelle wird eine Variante der notFound-Antwort zurückgegeben. Wenn Sie daraufhin die Tabelle erstellen, wird diese von nachfolgenden Streaming-Insert-Anweisungen unter Umständen nicht sofort erkannt. Ebenso kann das Löschen oder erneute Erstellen einer Tabelle dazu führen, dass für einen bestimmten Zeitraum Streaming-Insert-Anweisungen an die alte Tabelle gesendet werden und in der neu erstellten Tabelle nicht vorhanden sind.
  • Tabellenkürzung: Das Verkürzen der Daten einer Tabelle (z. B. mithilfe eines Abfragejobs, der für das Attribut "writeDisposition" den Wert "WRITE_TRUNCATE" verwendet) kann in gleicher Weise dazu führen, dass nachfolgende Insert-Anweisungen während des Konsistenzzeitraums entfernt werden.

Fehlende bzw. nicht verfügbare Daten

Streaming-Insert-Anweisungen werden vorübergehend im Streamingpuffer abgelegt, der andere Verfügbarkeitsmerkmale als ein verwalteter Speicher aufweist. Bestimmte BigQuery-Vorgänge erfordern keine Interaktion mit dem Streamingpuffer, z. B. Tabellenkopierjobs und API-Methoden wie tabledata.list. Aktuelle Streamingdaten sind nicht in der Zieltabelle oder -ausgabe enthalten.

Nach oben

Fehlermeldungen in der Cloud Console

In der folgenden Tabelle sind Fehlermeldungen aufgeführt, die in der Cloud Console auftreten können.

Fehlermeldung Beschreibung Fehlerbehebung
Unbekannte Fehlerantwort vom Server Dieser Fehler tritt auf, wenn die Cloud Console einen unbekannten Fehler vom Server empfängt. z. B. wenn Sie auf ein Dataset oder einen anderen Linktyp klicken und die Seite nicht angezeigt werden kann. Wechseln Sie in den Inkognitomodus oder den privaten Modus des Browsers und wiederholen Sie die Aktion, die zum Fehler geführt hat. Wenn im Inkognitomodus kein Fehler auftritt, ist der Fehler möglicherweise auf eine Browsererweiterung, z. B. einen Werbeblocker, zurückzuführen sein. Versuchen Sie, entsprechende Browsererweiterungen zu deaktivieren, wenn Sie sich nicht im Inkognitomodus befinden. Prüfen Sie dann, ob das Problem dadurch behoben wird.

Nach oben