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 von ErrorProto-Objekten enthält.
• Ein errorResults-Objekt, das ein einzelnes ErrorProto-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 in jeder Fehlerantwort von BigQuery ein Fehlerobjekt vorhanden ist. Außerdem erhalten Sie möglicherweise andere 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 wird der Antwortcode 5xx möglicherweise von einem Zwischenserver wie einem Proxy zurückgegeben. Prüfen Sie den Antworttext und die Antwortheader auf Details zum Fehler. 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>* Verwenden Sie --apilog=stdout, um das ausführliche Logging für das bq-Tool aufzurufen. Weitere Informationen zur Fehlerbehebung für das bq-Tool finden Sie unter Fehlerbehebung.

Fehlermeldung	HTTP-Code	Beschreibung	Fehlerbehebung
accessDenied	403	Dieser Fehler wird zurückgegeben, wenn Sie versuchen, auf eine Ressource wie ein Dataset, eine Tabelle, eine Ansicht oder einen Job 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 principalEmail-Wert im Audit-Log des Fehlers identifiziert wird.
attributeError	400	Dieser Fehler wird zurückgegeben, wenn ein Problem mit dem Nutzercode vorliegt, bei dem ein bestimmtes Objektattribut aufgerufen wird, aber 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, 502, 503 oder 504	Dieser Fehler weist darauf hin, dass der Dienst derzeit nicht verfügbar ist. Dies kann aufgrund einer Reihe von vorübergehenden Problemen passieren, darunter: Anstieg der Dienstnachfrage: Plötzliche Nachfragespitzen, z. B. zu Spitzenzeiten, können zu Lastabwürfen führen, um die Dienstqualität für alle BigQuery-Nutzer zu schützen. Damit das System nicht überlastet wird, kann BigQuery für einen kleinen Teil der Anfragen die Fehler 500 oder 503 zurückgeben. Netzwerkprobleme: Aufgrund der verteilten Natur von BigQuery werden Daten häufig zwischen verschiedenen Komponenten oder Maschinen im System übertragen. Verschiedene zeitweilige Probleme mit der Netzwerkverbindung können dazu führen, dass BigQuery einen 5xx-Fehler zurückgibt, einschließlich SSL-Handshake-Fehlern oder anderen Problemen mit der Netzwerkinfrastruktur zwischen dem Nutzer undGoogle Cloud. Ressourcenerschöpfung: BigQuery hat verschiedene interne Ressourcenlimits, um die Gesamtleistung des Dienstes zu schützen, damit ein einzelner Nutzer oder ein einzelner Job nicht zu viele Ressourcen verbraucht. BigQuery implementiert Lastabwurf, um die Erschöpfung von Ressourcen zu vermeiden. Backend-Fehler: In seltenen Fällen kann ein internes Problem in einer der BigQuery-Komponenten dazu führen, dass ein 500- oder 503-Fehler an den Client zurückgegeben wird.	5xx-Fehler sind dienstseitige Probleme, die der Client nicht beheben oder kontrollieren kann. Auf der Clientseite müssen Sie Ihre Anfragen mit abgeschnittenen exponentiellen Backoffs wiederholen, um die Auswirkungen von 5xx-Fehlern zu minimieren. Weitere Informationen zum exponentiellen Backoff finden Sie unter Exponentieller Backoff. Es gibt jedoch zwei Sonderfälle für die Fehlerbehebung dieses Fehlers: jobs.get- und jobs.insert-Aufrufe. jobs.get Anrufe Wenn Sie beim Abfragen von jobs.get den Fehler 503 erhalten haben, warten Sie einige Sekunden und fragen Sie dann noch einmal ab. Wenn der Job abgeschlossen wird, aber ein Fehlerobjekt mit backendError enthält, ist der Job fehlgeschlagen. Sie können den Job ohne Bedenken hinsichtlich der Datenkonsistenz wiederholen. jobs.insert-Aufrufe Wenn Sie diesen Fehler bei einem jobs.insert-Aufruf erhalten, ist unklar, ob der Job erfolgreich war. Sie müssen ihn dann noch einmal ausführen. Wenn die Wiederholungsversuche nicht erfolgreich sind und die Probleme weiterhin bestehen, können Sie die Rate der fehlgeschlagenen Anfragen berechnen und den Support kontaktieren. Wenn Sie außerdem feststellen, dass eine bestimmte Anfrage an BigQuery dauerhaft mit einem 5xx-Fehler fehlschlägt, auch wenn sie mit exponentiellem Backoff bei mehreren Workflow-Neustartversuchen wiederholt wird, sollten Sie dies an den Support eskalieren, um das Problem auf der BigQuery-Seite zu beheben, unabhängig von der insgesamt berechneten Fehlerrate. Achten Sie darauf, die Auswirkungen auf Ihr Unternehmen eindeutig zu kommunizieren, damit das Problem korrekt gesichtet werden kann.
badRequest	400	Der Fehler 'UPDATE or DELETE statement over table project.dataset.table would affect rows in the streaming buffer, which is not supported' kann auftreten, wenn einige kürzlich gestreamte Zeilen in einer Tabelle für DML-Vorgänge (DELETE,UPDATE, MERGE) möglicherweise nicht verfügbar sind, in der Regel ein paar Minuten, in seltenen Fällen jedoch bis zu 90 Minuten. Weitere Informationen finden Sie unter Streaming-Datenverfügbarkeit und DML-Einschränkungen.	Warten Sie einige Minuten und versuchen Sie es dann noch einmal oder filtern Sie die Anweisung so, dass nur ältere Daten außerhalb des Streaming-Zwischenspeichers verarbeitet werden. Wenn Sie herausfinden möchten, ob Daten für DML-Vorgänge in Tabellen verfügbar sind, sehen Sie in der tables.get-Antwort nach, ob der Abschnitt streamingBuffer vorhanden ist. Wenn der Abschnitt „streamingBuffer“ nicht vorhanden ist, sind Tabellendaten für DML-Vorgänge verfügbar. Sie können das Feld streamingBuffer.oldestEntryTime auch verwenden, um das Alter von Datensätzen im Streaming-Zwischenspeicher zu ermitteln. Alternativ können Sie Daten mit der BigQuery Storage Write API (gRPC) streamen, die diese Einschränkung nicht hat.
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. Dieser Fehler tritt auf, wenn On-Demand-Abfragen zu viel CPU im Vergleich zur Menge der gescannten Daten verbrauchen. Eine Anleitung zum Prüfen von Jobdetails finden Sie unter Jobs verwalten.	Dieser Fehler ist meist auf ineffiziente Cross Joins zurückzuführen, die entweder explizit oder implizit ausgeführt werden, z. B. 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.	Wenden Sie sich an den Support, um weitere Informationen zu erhalten.
duplicate	409	Dieser Fehler wird zurückgegeben, wenn Sie versuchen, einen Job, ein Dataset oder eine Tabelle zu erstellen, die bereits vorhanden sind. Der Fehler wird auch zurückgegeben, wenn das Attribut writeDisposition eines Jobs auf WRITE_EMPTY gesetzt ist und die Zieltabelle, auf die der Job zugreift, bereits vorhanden ist.	Benennen Sie die Ressource um, die Sie erstellen möchten, oder ändern Sie den Wert writeDisposition im Job. Weitere Informationen finden Sie unter Fehler „Job ist bereits vorhanden“ beheben.
internalError	500	Dieser Fehler wird zurückgegeben, wenn in BigQuery ein interner Fehler auftritt.	Warten Sie gemäß den Backoff-Anforderungen, die im BigQuery Service Level Agreement beschrieben sind, und versuchen Sie es dann noch einmal. Wenn der Fehler weiterhin auftritt, wenden Sie sich an den Support oder melden Sie einen Programmfehler über den BigQuery Issue Tracker. 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. Ungültige Abfragen geben einen invalidQuery-Fehler zurück.
invalidQuery	400	Dieser Fehler wird zurückgegeben, wenn Sie versuchen, eine ungültige Abfrage auszuführen.	Prüfen Sie Ihre 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 jobs.query oder jobs.getQueryResults angezeigt werden.	Wiederholen Sie den Job mit einem neuen jobId. Wenn der Fehler weiterhin auftritt, wenden Sie sich an den Support.
jobInternalError	400	Dieser Fehler wird zurückgegeben, wenn der Job erfolgreich erstellt wurde, aber mit einem internen Fehler fehlgeschlagen ist. Dieser Fehler kann in jobs.query oder jobs.getQueryResults angezeigt werden.	Wiederholen Sie den Job mit einem neuen jobId. Wenn der Fehler weiterhin auftritt, wenden Sie sich an den Support.
jobRateLimitExceeded	400	Dieser Fehler wird zurückgegeben, wenn der Job erfolgreich erstellt wurde, aber mit dem Fehler rateLimitExceeded fehlgeschlagen ist. Dieser Fehler kann in jobs.query oder jobs.getQueryResults angezeigt werden.	Verwenden Sie einen exponentiellen Backoff, um die Anforderungsrate zu reduzieren, und wiederholen Sie den Job dann mit einem neuen jobId.
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 ein Feature zuzugreifen, das nicht implementiert ist.	Wenden Sie sich an den Support, um weitere Informationen zu erhalten.
proxyAuthenticationRequired	407	Dieser Fehler wird zwischen der Clientumgebung und dem Proxyserver zurückgegeben, wenn die Anfrage keine gültigen Authentifizierungsdaten 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 mit Java erhalten, prüfen Sie, ob Sie die Attribute jdk.http.auth.tunneling.disabledSchemes= und jdk.http.auth.proxying.disabledSchemes= ohne Wert nach dem Gleichheitszeichen festgelegt haben.
quotaExceeded	403	Dieser Fehler wird zurückgegeben, wenn Ihr Projekt ein BigQuery-Kontingent oder ein benutzerdefiniertes Kontingent überschreitet oder wenn Sie die Abrechnung nicht eingerichtet haben und die kostenlose Stufe für Abfragen überschritten haben.	Weitere Informationen dazu, welches Kontingent überschritten wurde, finden Sie im Attribut message des Fehlerobjekts. 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 Seite Kontingente senden. Wenn Sie diesen Fehler bei Verwendung der BigQuery-Sandbox erhalten, können Sie ein Upgrade über die Sandbox ausführen. Weitere Informationen finden Sie unter BigQuery-Kontingentfehler beheben.
rateLimitExceeded	403, 429	Dieser Fehler wird zurückgegeben, wenn Ihr Projekt eine kurzfristige Ratenbegrenzung überschreitet, weil zu viele Anfragen zu schnell gesendet werden. Weitere Informationen finden Sie 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 zurückgegeben, wenn Sie versuchen, ein Dataset mit Tabellen oder einen derzeit ausgeführten Job zu löschen.	Leeren Sie das Dataset, bevor Sie versuchen, es zu löschen, oder warten Sie, bis ein Job abgeschlossen ist, bevor Sie es löschen.
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. Einige Abfragen werden in mehreren Phasen ausgeführt. Dieser Fehler wird zurückgegeben, wenn eine Phase eine zu große Antwortgröße zurückgibt, auch wenn das Endergebnis kleiner als das Maximum ist. Dieser Fehler wird häufig zurückgegeben, wenn Abfragen eine ORDER BY-Klausel verwenden.	Manchmal lässt sich das Problem durch Hinzufügen einer LIMIT-Klausel oder durch Entfernen der ORDER BY-Klausel beheben. Damit große Ergebnisse keine Probleme verursachen, setzen Sie das Attribut allowLargeResults auf true und geben Sie eine Zieltabelle an. Weitere Informationen finden Sie unter Große Abfrageergebnisse schreiben.
Angehalten	200	Dieser Statuscode wird zurückgegeben, wenn ein Job abgebrochen wird.
tableUnavailable	400	Bestimmte BigQuery-Tabellen basieren auf Daten, die von anderen Google-Produktteams verwaltet werden. Dieser Fehler weist darauf hin, dass eine dieser Tabellen nicht verfügbar ist.	Wenn diese Fehlermeldung angezeigt wird, können Sie die Anfrage noch einmal senden (siehe Vorschläge zur Fehlerbehebung für internalError) oder sich an das Google-Produktteam wenden, das Ihnen Zugriff auf seine Daten gewährt hat.
Zeitüberschreitung	400	Der Job hat das Zeitlimit überschritten.	Sie können den Arbeitsaufwand für den Vorgang reduzieren, damit er innerhalb des festgelegten Limits abgeschlossen 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 Verfügbarkeit berechnen

Die meisten 500- und 503-Fehler können durch einen Wiederholungsversuch mit exponentiellem Backoff behoben werden. Wenn die Fehler 500 und 503 weiterhin auftreten, können Sie die Gesamtrate der fehlgeschlagenen Anfragen und die entsprechende Verfügbarkeit berechnen und mit dem BigQuery Service Level Agreement (SLA) vergleichen, um festzustellen, ob der Dienst wie erwartet funktioniert.

Wenn Sie die Gesamtrate der fehlgeschlagenen Anfragen in den letzten 30 Tagen berechnen möchten, nehmen Sie die Anzahl der fehlgeschlagenen Anfragen für einen bestimmten API-Aufruf oder eine bestimmte Methode aus den letzten 30 Tagen und teilen Sie sie durch die Gesamtzahl der Anfragen für diesen API-Aufruf oder diese Methode aus den letzten 30 Tagen. Multiplizieren Sie diesen Wert mit 100, um den durchschnittlichen Prozentsatz der fehlgeschlagenen 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 erhalten und die Berechnung durchzuführen. Sie können die Fehlerratenwerte 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 auftreten. Daher empfehlen wir auch die Verwendung eines clientseitigen Logging- und Berichtssystems für genauere Berechnungen der Fehlerrate.

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 Verfügbarkeit auch dem BigQuery-SLA. Wenn dieser Wert jedoch kleiner als der im SLA beschriebene Wert ist, berechnen Sie die Verfügbarkeit manuell.

Um die Verfügbarkeit zu berechnen, müssen Sie die Anzahl der Minuten kennen, die als Dienstausfallzeit gelten. Dienstausfallzeit bedeutet ein Zeitraum von einer Minute mit einer Fehlerrate von mehr als 10 %, berechnet gemäß SLA-Definitionen. Zur Berechnung der Verfügbarkeit nehmen Sie die Gesamtminuten der letzten 30 Tage und ziehen die Gesamtminuten ab, in denen der Dienst nicht verfügbar war. Teilen Sie die verbleibende Zeit durch die Gesamtminuten 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 Verfügbarkeitsprozentsatz 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 Verfügbarkeit unter dem im SLA angegebenen Wert liegt, wenden Sie sich an den Support und teilen Sie die beobachtete Gesamtfehlerrate und die Verfügbarkeitsberechnungen mit.

Authentifizierungsfehler

Fehler, die vom OAuth-Tokengenerierungssystem ausgegeben werden, geben das folgende JSON-Objekt zurück, wie in der OAuth2-Spezifikation definiert.

{"error" : "_description_string_"}

Der Fehler wird entweder von einem HTTP-Fehler 400 (Ungültige Anfrage) oder einem HTTP-Fehler 401 (Nicht autorisiert) begleitet. _description_string_ ist einer der Fehlercodes, die in der OAuth 2.0-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.

• 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 für Administratoraktivitäten nach Änderungen an der Richtlinie für Identity and Access Management:

  protoPayload.methodName=~"SetIamPolicy"
  logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"
  

• 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 zur Verbindung

In der folgenden Tabelle sind Fehlermeldungen aufgeführt, die aufgrund von vorübergehenden Verbindungsproblemen auftreten 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)	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 Zeitlimitwert 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. Achten Sie bei Vorgängen auf Tabellen- oder Dataset-Ebene darauf, dass sich die Ressource seit der letzten Instanziierung nicht geändert hat, und erstellen Sie das Objekt bei Bedarf neu.
Failed to establish a new connection: [Errno 110] Connection timed out	Clientbibliotheken	Dieser Fehler wird zurückgegeben, wenn diese Anfrage beim Streamen oder Lesen von Daten aus BigQuery das Dateiende (EOF) erreicht hat. Implementieren Sie einen Wiederholungsmechanismus und legen Sie einen höheren Zeitlimitwert fest.
socks.ProxyConnectionError: Error connecting to HTTP proxy :8080: [Errno 110] Connection timed out	Clientbibliotheken	Fehlerbehebung bei Proxystatus und -einstellungen. 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 nicht im Inkognitomodus sind, und prüfen Sie, ob das Problem dadurch behoben wird.