Fehlermeldungen
In diesem Dokument werden Fehlermeldungen beschrieben, die beim Arbeiten mit BigQuery auftreten können, einschließlich HTTP-Fehlercodes und vorgeschlagene Schritte zur Fehlerbehebung.
Weitere Informationen zu Abfragefehlern finden Sie unter Abfragefehler beheben.
Weitere Informationen zu Fehlern bei Streaming-Insert-Anweisungen finden Sie unter Fehlerbehebung bei Streaming-Insert-Anweisungen.
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 vonErrorProto
-Objekten enthält. - Ein
errorResults
-Objekt, das ein einzelnesErrorProto
-Objekt enthält.
Die Spalte Fehlermeldung 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 aufgeführt ist, deutet dies auf ein Problem oder ein erwartetes Ergebnis bezüglich 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 den Jobstatus mithilfe des bq-Befehlszeilentools prüfen, wird standardmäßig kein Fehlerobjekt 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>*
Wenn Sie das ausführliche Logging für das bq-Tool aufrufen möchten, verwenden Sie --apilog=stdout
. Weitere Informationen zur Fehlerbehebung für das bq-Tool finden Sie unter Fehlerbehebung.
Fehlermeldung | 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 und bitten Sie ihn um Zugriff auf die Ressource für den Nutzer, der durch den |
attributeError | 400 |
Dieser Fehler wird zurückgegeben, wenn es ein Problem mit dem Nutzercode gibt, bei dem ein bestimmtes Objektattribut aufgerufen wird, das nicht vorhanden ist. |
Prüfen Sie, ob das Objekt, mit dem Sie arbeiten, das Attribut hat, auf das Sie zugreifen möchten. Weitere Informationen zu diesem Fehler finden Sie unter AttributeError. |
backendError | 500, 503 oder 504 |
Dieser Fehler weist darauf hin, dass der Dienst derzeit nicht verfügbar ist. Dies kann aus verschiedenen vorübergehenden Gründen passieren, z. B.:
|
5xx-Fehler sind Probleme auf der Dienstseite, die der Client nicht beheben oder beeinflussen kann. Um die Auswirkungen von 5xx-Fehlern zu minimieren, müssen Sie Ihre Anfragen clientseitig mit abgeschnittenen exponentiellen Backoffs wiederholen. Weitere Informationen zum exponentiellen Backoff finden Sie unter Exponentieller Backoff. Es gibt jedoch zwei Sonderfälle für die Behebung dieses Fehlers:
Wenn die Wiederholungsversuche nicht erfolgreich sind und die Probleme weiterhin bestehen, können Sie die Rate der fehlgeschlagenen Anfragen berechnen und den Support kontaktieren. |
badRequest | 400 |
Der Fehler |
Wenn Sie herausfinden möchten, ob Daten für DML-Vorgänge für Tabellen verfügbar sind, sehen Sie in der Antwort |
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 |
Dieser Fehler tritt meist auf, wenn ein ineffizienter Cross Joins explizit oder implizit ausgeführt wird, 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 entweder die Abfrage optimieren oder das Preismodell kapazitätsbasiert (Slots) verwenden, um diesen Fehler zu beheben. Informationen zum Optimieren von Abfragen finden Sie unter SQL-Anti-Muster vermeiden. |
blockiert | 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. |
|
duplicate | 409 |
Dieser Fehler wird bei dem Versuch zurückgegeben, bereits vorhandene Jobs, Datasets oder Tabellen zu erstellen. Er wird außerdem zurückgegeben, wenn das Attribut |
Benennen Sie die Ressource, die Sie erstellen möchten, um oder ändern Sie den Wert |
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. Sie können auch versuchen, die Häufigkeit dieses Fehlers durch Reservierungen zu reduzieren. |
ungültig | 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 | 400 |
Dieser Fehler wird zurückgegeben, wenn Sie versuchen, eine ungültige Abfrage auszuführen. |
Prüfen Sie die Abfrage 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. |
jobBackendError | 400 |
Dieser Fehler wird zurückgegeben, wenn der Job erfolgreich erstellt wurde, aber mit einem internen Fehler fehlgeschlagen ist. Dieser Fehler kann in |
Wiederholen Sie den Job mit einem neuen |
jobInternalError | 400 |
Dieser Fehler wird zurückgegeben, wenn der Job erfolgreich erstellt wurde, aber mit einem internen Fehler fehlgeschlagen ist. Dieser Fehler kann in |
Wiederholen Sie den Job mit einem neuen |
jobRateLimitExceeded | 400 |
Dieser Fehler wird zurückgegeben, wenn der Job erfolgreich erstellt wurde, aber mit dem Fehler rateLimitExceeded fehlgeschlagen ist. Dieser Fehler kann in |
Verwenden Sie exponentiellen Backoff, um die Anfragerate zu reduzieren, und wiederholen Sie den Job dann mit einem neuen |
notFound | 404 |
Dieser Fehler wird zurückgegeben, wenn Sie eine nicht vorhandene Ressource angeben (ein Dataset, eine Tabelle oder ein Job) oder wenn der Standort in der Anfrage nicht mit dem Standort der Ressource übereinstimmt (z. B. dem Standort, an dem ein Job ausgeführt wird). Der Fehler kann auch auftreten, wenn Sie mit Tabelle-Decorators auf gelöschte Tabellen verweisen, an die kürzlich gestreamt wurde. |
Korrigieren Sie die Ressourcennamen, geben Sie den Standort korrekt an oder warten Sie nach dem Streaming mindestens sechs Stunden, bevor Sie eine gelöschte Tabelle abfragen. |
notImplemented | 501 |
Dieser Jobfehler wird zurückgegeben, wenn Sie versuchen, auf eine nicht implementierte Funktion zuzugreifen. |
|
proxyAuthenticationRequired | 407 |
Dieser Fehler wird zwischen der Clientumgebung und dem Proxyserver zurückgegeben, wenn die Anfrage keine gültigen Anmeldedaten für den Proxyserver enthält. Weitere Informationen finden Sie unter 407 Proxy Authentication Required. |
Die Fehlerbehebung ist spezifisch für Ihre Umgebung. Wenn Sie diesen Fehler bei der Arbeit in Java erhalten, müssen Sie darauf achten, dass Sie sowohl die Property |
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 |
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. |
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 Ihr Job zu viele Ressourcen beansprucht. |
Dieser Fehler wird zurückgegeben, wenn Ihr Job zu viele Ressourcen beansprucht. Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung bei Ressourcenfehlern aufgrund überschrittener Ressourcen. |
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 |
Manchmal lässt sich das Problem durch Hinzufügen einer |
Angehalten | 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. |
Zeitüberschreitung | 400 |
Der Job hat das Zeitlimit überschritten. |
Sie sollten die Menge der bei Ihrem Vorgang ausgeführten Arbeit reduzieren, damit sie innerhalb des festgelegten Limits ausgeführt werden kann. Weitere Informationen finden Sie unter Fehlerbehebung bei Kontingent- und Limitfehlern. |
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"
}
}
Rate der fehlgeschlagenen Anfragen und Betriebszeit berechnen
Die meisten 500- und 503-Fehler lassen sich durch Wiederholen des Vorgangs mit exponentiellem Backoff beheben. Wenn 500- und 503-Fehler weiterhin auftreten, können Sie die Gesamtrate fehlgeschlagener Anfragen und die entsprechende Betriebszeit berechnen, um sie mit dem BigQuery-Service Level Agreement (SLA) zu vergleichen und festzustellen, ob der Dienst wie erwartet funktioniert.
Um die Gesamtrate fehlgeschlagener Anfragen in den letzten 30 Tagen zu berechnen, teilen Sie die Anzahl der fehlgeschlagenen Anfragen für einen bestimmten API-Aufruf oder eine bestimmte Methode in den letzten 30 Tagen durch die Gesamtzahl der Anfragen für diesen API-Aufruf oder diese Methode in den letzten 30 Tagen. Multiplizieren Sie diesen Wert mit 100, um den durchschnittlichen Prozentsatz fehlgeschlagener Anfragen über 30 Tage zu erhalten.
Sie können beispielsweise Cloud Logging-Daten abfragen, um die Gesamtzahl der jobs.insert
-Anfragen und die Anzahl der fehlgeschlagenen jobs.insert
-Anfragen zu ermitteln und die Berechnung durchzuführen. Sie können die Werte für die Fehlerrate auch über das API-Dashboard oder mit dem Metrics Explorer in Cloud Monitoring abrufen. Diese Optionen enthalten keine Daten zu Netzwerk- oder Routingproblemen, die zwischen dem Client und BigQuery aufgetreten sind. Wir empfehlen daher, auch ein clientseitiges Protokollierungs- und Berichtssystem für genauere Berechnungen der Fehlerrate zu verwenden.
Ziehen Sie zuerst die Gesamtrate der fehlgeschlagenen Anfragen von 100% ab. Wenn dieser Wert größer oder gleich dem im BigQuery-SLA beschriebenen Wert ist, entspricht die Betriebszeit auch dem BigQuery-SLA. Wenn dieser Wert jedoch niedriger ist als der im SLA beschriebene Wert, berechnen Sie die Betriebszeit manuell.
Um die Betriebszeit zu berechnen, müssen Sie wissen, wie viele Minuten als Dienstausfallzeit gelten. Ein Dienstausfall ist ein Zeitraum von einer Minute mit einer Fehlerrate von mehr als 10 %, die gemäß den SLA-Definitionen berechnet wird. Um die Betriebszeit zu berechnen, ziehen Sie die Gesamtzahl der Minuten, in denen der Dienst ausgefallen ist, von der Gesamtzahl der Minuten der letzten 30 Tage ab. Teilen Sie die verbleibende Zeit durch die Gesamtzahl der Minuten der letzten 30 Tage und multiplizieren Sie diesen Wert mit 100, um den Prozentsatz der Betriebszeit über 30 Tage zu erhalten. Weitere Informationen zu den Definitionen und Berechnungen im Zusammenhang mit dem SLA finden Sie im BigQuery-Service Level Agreement (SLA).
Wenn Ihr monatlicher Uptime-Prozentsatz größer oder gleich dem im BigQuery-SLA beschriebenen Wert ist, wurde der Fehler höchstwahrscheinlich durch ein vorübergehendes Problem verursacht. Sie können es also weiterhin mit exponentiellem Backoff versuchen.
Wenn die Betriebszeit unter dem im SLA angegebenen Wert liegt, wenden Sie sich an den Support und geben Sie die beobachtete Gesamtrate der Fehler und die Berechnungen der Betriebszeit an.
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"}
Fehler ansehen
Mit dem Log-Explorer können Sie Authentifizierungsfehler für bestimmte Jobs, Nutzer oder andere Bereiche aufrufen. Im Folgenden finden Sie Beispiele für Log-Explorer-Filter, mit denen Sie Authentifizierungsfehler prüfen können:
Suchen Sie in den Audit-Logs zu Richtlinienverstößen nach fehlgeschlagenen Jobs mit Berechtigungsproblemen:
resource.type="bigquery_resource" protoPayload.status.message=~"Access Denied" logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access"
Ersetzen Sie
PROJECT_ID
durch die ID des Projekts, das die Ressource enthält.So suchen Sie nach einem bestimmten Nutzer oder Dienstkonto, das für die Authentifizierung verwendet wird:
resource.type="bigquery_resource" protoPayload.authenticationInfo.principalEmail="EMAIL"
Ersetzen Sie
EMAIL
durch die E-Mail-Adresse des Nutzers oder Dienstkontos.Suchen Sie in den Audit-Logs zur Administratoraktivität nach Änderungen an IAM-Richtlinien (Identity and Access Management):
protoPayload.methodName=~"SetIamPolicy" logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"
So suchen Sie in den Audit-Logs zum Datenzugriff nach Änderungen an einem bestimmten BigQuery-Dataset:
resource.type="bigquery_resource" protoPayload.resourceName="projects/PROJECT_ID/datasets/DATASET_ID" logName=projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
Ersetzen Sie
DATASET_ID
durch die ID des Datasets, das die Ressource enthält.
Fehlermeldungen zu Verbindungen
In der folgenden Tabelle sind Fehlermeldungen aufgeführt, die aufgrund von zeitweiligen Verbindungsproblemen angezeigt werden können, wenn Sie die Clientbibliotheken verwenden oder die BigQuery API über Ihren Code aufrufen:
Fehlermeldung | Clientbibliothek oder API | Fehlerbehebung |
---|---|---|
com.google.cloud.bigquery.BigQueryException: Read timed out | Java | Legen Sie einen höheren Zeitlimitwert fest. |
Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Connection reset at com.google.cloud.bigquery.spi.v2.HttpBigQueryRpc.translate(HttpBigQueryRpc.java:115) (Verbindung wurde geschlossen: javax.net.ssl.SSLException: java.net.SocketException: Verbindung zurückgesetzt unter com.google.cloud.bigquery.spi.v2.HttpBigQueryRpc.translate(HttpBigQueryRpc.java:115)) | Java | Implementieren Sie einen Wiederholungsmechanismus und legen Sie einen höheren Zeitlimitwert fest. |
javax.net.ssl.SSLHandshakeException: Remote-Host hat den Handshake terminiert | Java | Implementieren Sie einen Wiederholungsmechanismus und legen Sie einen höheren Zeitlimitwert fest. |
BrokenPipeError: [Errno 32] Broken pipe | Python | Implementieren Sie einen Wiederholungsmechanismus. Weitere Informationen zu diesem Fehler finden Sie unter BrokenPipeError. |
Verbindung abgebrochen. RemoteDisconnected('Remote end closed connection without response' | Python | Legen Sie einen höheren Zeitlimitwert fest. |
SSLEOFError (EOF occurred in violation of protocol) | Python | Dieser Fehler wird anstelle eines HTTP-Fehlers 413 (ENTITY_TOO_LARGE ) zurückgegeben. Reduzieren Sie die Größe der Anfrage. |
TaskCanceledException: Eine Aufgabe wurde abgebrochen | .NET-Bibliothek | Erhöhen Sie den Timeout-Wert auf der Clientseite. |
google.api_core.exceptions.PreconditionFailed: 412 PATCH | Python | Dieser Fehler wird zurückgegeben, wenn Sie versuchen, eine Tabellenressource mit einer HTTP-Anfrage zu aktualisieren. Achten Sie darauf, dass das ETag im HTTP-Header nicht veraltet ist. Bei Vorgängen auf Tabellen- oder Dataset-Ebene müssen Sie darauf achten, dass sich die Ressource seit der letzten Instanziierung nicht geändert hat. Erstellen Sie das Objekt bei Bedarf neu. |
Neue Verbindung konnte nicht hergestellt werden: [Errno 110] Zeitüberschreitung bei Verbindung | Clientbibliotheken | Dieser Fehler wird zurückgegeben, wenn bei der Übertragung oder dem Lesen von Daten aus BigQuery das Dateiende (End-of-File, EOF) erreicht wurde. Implementieren Sie einen Wiederholungsmechanismus und legen Sie einen höheren Zeitlimitwert fest. |
socks.ProxyConnectionError: Error connecting to HTTP proxy
|
Clientbibliotheken | Proxy-Status und ‑Einstellungen prüfen Implementieren Sie einen Wiederholungsmechanismus und legen Sie einen höheren Zeitlimitwert fest. |
Unerwartetes EOF oder 0 Byte vom Transportstream empfangen | Clientbibliotheken | Implementieren Sie einen Wiederholungsmechanismus und legen Sie einen höheren Zeitlimitwert fest. |
Google Cloud Console-Fehlermeldungen
In der folgenden Tabelle sind Fehlermeldungen aufgeführt, die in derGoogle Cloud Console auftreten können.
Fehlermeldung | Beschreibung | Fehlerbehebung |
---|---|---|
Unbekannte Fehlerantwort vom Server | Dieser Fehler tritt auf, wenn die Google 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. Deaktivieren Sie Ihre Browsererweiterungen, wenn Sie sich nicht im Inkognitomodus befinden. Prüfen Sie dann, ob das Problem dadurch behoben wird. |