Fehlerbehebung

Bei der Anwendung von BigQuery sind zwei Arten von Fehlern möglich: HTTP-Fehlercodes und Jobfehler. Jobfehler werden beim Aufruf von jobs.get im Objekt status angegeben.

Fehlertabelle

Die folgende Tabelle enthält Fehlercodes, die beim Stellen einer Anfrage an die BigQuery API zurückgegeben werden können. API-Antworten beinhalten einen HTTP-Fehlercode und ein Fehlerobjekt. Die Spalte "Fehlercode" in der Tabelle bezieht sich auf das Attribut reason im Fehlerobjekt.

Wenn Sie den Jobstatus mithilfe des bq-Befehlszeilentools prüfen, wird standardmäßig kein Fehlerobjekt zurückgegeben. Zur Anzeige des Objekts und des entsprechenden Attributs reason aus der nachfolgenden Tabelle verwenden Sie das Flag -- format=prettyjson. Beispiel: bq --format=prettyjson show -j <job id>

Wenn Sie einen HTTP-Antwortcode erhalten, der nicht in der folgenden Liste aufgeführt ist, deutet dies auf ein Problem hin oder auf ein gültiges Ergebnis der HTTP-Anfrage. Der Fehler 502 verweist z. B. auf ein Problem mit der Netzwerkverbindung. Eine vollständige Liste der HTTP-Antwortcodes finden Sie unter HTTP-Antwortcodes.

Fehlercode HTTP-Code Beschreibung Fehlerbehebung
accessDenied 403 Dieser Fehler wird bei dem Versuch zurückgegeben, auf Ressourcen wie Tabellen, Datasets oder Jobs zuzugreifen, für die keine Zugriffsberechtigung besteht. 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. bei einem Problem mit der Netzwerkverbindung oder wenn 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: Aufrufe mit den Methoden jobs.get und jobs.insert.

Aufrufe mit jobs.get

  • Wenn Sie beim Aufruf von jobs.get den Fehler 503 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.

Aufrufe mit jobs.insert

Wenn Sie beim Aufruf von jobs.insert diesen Fehler erhalten, ist offen, ob der Job erfolgreich war. Sie müssen den Job 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 Platform Console.
blocked 403 Dieser Fehler wird zurückgegeben, wenn BigQuery den Vorgang, den Sie ausführen möchten, vorübergehend auf die schwarze Liste 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. Außerdem wird er zurückgegeben, wenn für das Attribut writeDisposition eines Jobs der Wert WRITE_EMPTY festgelegt ist und die Zieltabelle, auf die mit dem Job zugegriffen wird, bereits vorhanden ist. Benennen Sie die Ressource, die erstellt werden soll, um oder ändern Sie den Wert writeDisposition im Job.
internalError 500 Dieser Fehler wird bei einem internen Fehler von BigQuery zurückgegeben. 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 demgegenüber 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.
notFound 404 Dieser Fehler wird zurückgegeben, wenn Sie eine nicht vorhandene Ressource angeben. Dies 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 6 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. Am Attribut message des Fehlerobjekts können Sie erkennen, welches Kontingent überschritten wurde. Wenn Sie ein BigQuery-Kontingent zurücksetzen oder erhöhen möchten, wenden Sie sich an den Support. Zur Änderung eines benutzerdefinierten Kontingents senden Sie eine entsprechende Anfrage über die Seite Google Cloud Platform Console. Wenn Sie diesen Fehler bei Verwendung der BigQuery-Sandbox erhalten, können Sie ein Upgrade ausführen.
rateLimitExceeded 403 Dieser Fehler wird zurückgegeben, wenn Ihr Projekt das Ratenlimit gleichzeitiger Anfragen oder das Limit für API-Anfragen überschreitet, weil in zu kurzer Zeit zu viele Anfragen gesendet wurden. Verringern Sie die Anfragerate.

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

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 dies durch COUNT(DISTINCT) ersetzen.
  • 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 in der Abfrage UNIQUE verwendet wird, können Sie stattdessen GROUP BY oder eine Fensterfunktion in einer Subselect-Anweisung nutzen.
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 sichergehen möchten, dass umfangreiche Ergebnisse keine Probleme verursachen, können Sie für das Attribut allowLargeResults den Wert true festlegen 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 verwaltetet 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.

Beispiel für eine Fehlerantwort

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

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 entweder zusammen mit dem Fehler "HTTP 400 Bad Request" oder mit dem Fehler "HTTP 401 Unauthorized" angezeigt. description_string ist ein durch die OAuth2-Spezifikation definierter Fehlercode. 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 es nur teilweise gelungen ist.

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 in dem Attribut insertErrors angegebenen Zeilen nicht eingefügt, während die Einfügung der übrigen Zeilen erfolgreich war. Das Attribut errors-Eigenschaft 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 möglicherweise 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 möglicherweise nicht sofort erkannt. Ebenso kann das Löschen und/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". Daher finden sich aktuelle Streamingdaten nicht in der Zieltabelle bzw. -ausgabe.

Nach oben

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...