Fehlerbehebung bei Abfrageproblemen

Dieses Dokument soll Ihnen bei der Behebung häufiger Probleme bei der Ausführung von Abfragen helfen. Sie können z. B. Gründe für langsame Abfragen ermitteln oder Schritte zur Lösung häufig auftretender Fehler bereitstellen, die von fehlgeschlagenen Abfragen zurückgegeben werden.

Fehlerbehebung bei langsamen Abfragen

Bei der Fehlerbehebung bei langsamer Abfrageleistung sollten Sie die folgenden häufigen Ursachen berücksichtigen:

  1. Prüfen Sie die Seite Google Cloud Service Health auf bekannte BigQuery-Dienstausfälle, die sich auf die Abfrageleistung auswirken können.

  2. In der Jobzeitachse für Ihre Abfrage auf der Seite der Jobdetails können Sie sehen, wie lange die Ausführung der einzelnen Phasen der Abfrage dauert.

    • Wenn die meiste verstrichene Zeit auf lange Erstellungszeiten zurückzuführen ist, wenden Sie sich an Cloud Customer Care.

    • Wenn die meiste verstrichene Zeit auf lange Ausführungszeiten zurückzuführen ist, sehen Sie sich die Statistiken zur Abfrageleistung an. Statistiken zur Abfrageleistung können Sie darüber informieren, ob Ihre Abfrage länger als die durchschnittliche Ausführungszeit gedauert hat, und mögliche Ursachen angeben. Mögliche Gründe sind beispielsweise Konflikte bei Abfrage-Slots oder ein unzureichendes Shuffle-Kontingent. Weitere Informationen zu den einzelnen mit Abfragen verbundenen Leistungsproblemen und zu möglichen Lösungen finden Sie unter Statistiken zur Abfrageleistung interpretieren.

  3. Sehen Sie sich das Feld finalExecutionDurationMs in der JobStatistics für Ihren Abfragejob an. Die Anfrage wurde möglicherweise wiederholt. Das Feld finalExecutionDurationMs enthält die Dauer der Ausführung des letzten Versuchs dieses Jobs in Millisekunden.

  4. Prüfen Sie die verarbeiteten Byte auf der Seite mit den Abfragejobdetails, um festzustellen, ob die Anzahl höher ist als erwartet. Dazu können Sie die Anzahl der von der aktuellen Abfrage verarbeiteten Bytes mit einer anderen Abfrage vergleichen, die in einer akzeptablen Zeit abgeschlossen wurde. Wenn es eine große Diskrepanz zwischen den verarbeiteten Bytezahlen der beiden Abfragen gibt, war die Abfrage möglicherweise aufgrund eines großen Datenvolumens langsam. Informationen zum Optimieren von Abfragen für die Verarbeitung großer Datenmengen finden Sie unter Abfrageberechnung optimieren.

    Sie können auch Abfragen in Projekten identifizieren, die große Datenmengen verarbeiten. Suchen Sie dazu mit der INFORMATION_SCHEMA.JOBS-Ansicht nach den teuersten Abfragen.

Langsame und schnelle Ausführung derselben Abfrage vergleichen

Wenn eine Abfrage, die zuvor schnell ausgeführt wurde, jetzt langsam ausgeführt wird, sehen Sie sich die Ausgabe des Job API-Objekts an, um Änderungen bei der Ausführung zu erkennen.

Cache-Treffer

Prüfen Sie anhand des Werts cacheHit, ob die schnelle Ausführung des Jobs ein Cache-Treffer war. Wenn der Wert true für die schnelle Ausführung der Abfrage ist, wurden zwischengespeicherte Ergebnisse verwendet, anstatt die Abfrage auszuführen.

Wenn Sie erwarten, dass für den langsamen Job im Cache gespeicherte Ergebnisse verwendet werden, untersuchen Sie, warum für die Abfrage keine im Cache gespeicherten Ergebnisse mehr verwendet werden. Wenn Sie nicht erwarten, dass die Abfrage Daten aus dem Cache abruft, suchen Sie nach einem Beispiel für eine schnelle Abfrageausführung, bei der der Cache nicht verwendet wurde.

Kontingentverzögerungen

Wenn Sie feststellen möchten, ob die Verlangsamung durch Quota-Aufschübe verursacht wurde, prüfen Sie das Feld quotaDeferments für beide Jobs. Vergleichen Sie die Werte, um festzustellen, ob die Startzeit der langsameren Abfrage durch Kontingentaufschübe verzögert wurde, die sich nicht auf den schnelleren Job ausgewirkt haben.

Dauer der Ausführung

Wenn Sie die Ausführungsdauer des letzten Versuchs beider Jobs vergleichen möchten, sehen Sie sich die Werte für das Feld finalExecutionDurationMs an.

Wenn die Werte für finalExecutionDurationMs sehr ähnlich sind, die Differenz der tatsächlichen Ausführungszeit zwischen den beiden Abfragen, berechnet als startTime - endTime, jedoch viel größer ist, kann es sein, dass für den langsamen Job aufgrund eines möglichen vorübergehenden Problems ein interner Wiederholungsversuch für die Ausführung der Abfrage stattgefunden hat. Wenn dieses Muster wiederholt auftritt, wenden Sie sich an Cloud Customer Care.

Verarbeitete Byte

Prüfen Sie die verarbeiteten Byte auf der Seite mit den Abfragejobdetails oder sehen Sie sich die totalBytesProcessed aus JobStatistics an, um festzustellen, ob die Anzahl höher ist als erwartet. Wenn es eine große Diskrepanz bei den verarbeiteten Bytes zwischen den beiden Abfragen gibt, kann die Abfrage aufgrund einer Änderung des Volumens der verarbeiteten Daten langsam sein. Informationen zum Optimieren von Abfragen für die Verarbeitung großer Datenmengen finden Sie unter Abfrageberechnung optimieren. Die folgenden Gründe können zu einer Erhöhung der Anzahl der von einer Abfrage verarbeiteten Byte führen:

  • Die Größe der Tabellen, auf die sich die Abfrage bezieht, hat zugenommen.
  • Die Abfrage liest jetzt eine größere Partition der Tabelle.
  • Die Abfrage verweist auf eine Ansicht, deren Definition sich geändert hat.

Referenzierte Tabellen

Prüfen Sie, ob die Abfragen dieselben Tabellen lesen, indem Sie die Ausgabe des Felds referencedTables in JobStatistics2 analysieren. Die Unterschiede in den referenzierten Tabellen lassen sich durch Folgendes erklären:

  • Die SQL-Abfrage wurde so geändert, dass sie andere Tabellen liest. Vergleichen Sie den Abfragetext, um dies zu bestätigen.
  • Die Ansichtsdefinition hat sich zwischen den Ausführungen der Abfrage geändert. Prüfen Sie die Definitionen der in dieser Abfrage referenzierten Ansichten und aktualisieren Sie sie bei Bedarf.

Unterschiede in den referenzierten Tabellen könnten Änderungen bei totalBytesProcessed erklären.

Nutzung von materialisierten Ansichten

Wenn in der Abfrage auf materialisierte Ansichten verwiesen wird, können Leistungsunterschiede dadurch entstehen, dass materialisierte Ansichten während der Abfrageausführung ausgewählt oder abgelehnt werden. Prüfen Sie MaterializedViewStatistics, um festzustellen, ob in der langsamen Abfrage materialisierte Ansichten abgelehnt wurden, die in der schnellen Abfrage verwendet wurden. Sehen Sie sich die Felder chosen und rejectedReason im MaterializedView-Objekt an.

Statistiken zum Caching von Metadaten

Vergleichen Sie bei Abfragen, die Amazon S3 BigLake-Tabellen oder Cloud Storage BigLake-Tabellen mit aktiviertem Metadaten-Caching umfassen, die Ausgabe von MetadataCacheStatistics, um zu prüfen, ob es einen Unterschied bei der Verwendung des Metadaten-Cache zwischen der langsamen und der schnellen Abfrage gibt, und um die entsprechenden Gründe zu ermitteln. Der Metadatencache befindet sich beispielsweise möglicherweise außerhalb des maxStaleness-Fensters der Tabelle.

BigQuery BI Engine-Statistiken vergleichen

Wenn für die Abfrage BigQuery BI Engine verwendet wird, analysieren Sie die Ausgabe von BiEngineStatistics, um festzustellen, ob dieselben Beschleunigungsmodi auf die langsame und die schnelle Abfrage angewendet wurden. Im Feld BiEngineReason sehen Sie den allgemeinen Grund für die teilweise oder gar nicht erfolgte Beschleunigung, z. B. nicht genügend Arbeitsspeicher, fehlende Reservierung oder zu große Eingabe.

Unterschiede bei Statistiken zur Abfrageleistung prüfen

Vergleichen Sie die Informationen zur Abfrageleistung für die einzelnen Abfragen, indem Sie sich das Ausführungsdiagramm in der Google Cloud -Konsole oder das StagePerformanceStandaloneInsight-Objekt ansehen, um die folgenden möglichen Probleme zu ermitteln:

Achten Sie sowohl auf die Erkenntnisse für den langsamen Job als auch auf die Unterschiede zwischen den Erkenntnissen für den schnellen Job, um Phasenänderungen zu erkennen, die sich auf die Leistung auswirken.

Für eine gründlichere Analyse der Metadaten zur Jobausführung müssen die einzelnen Phasen der Abfrageausführung durchlaufen werden, indem die ExplainQueryStage-Objekte für die beiden Jobs verglichen werden.

Sehen Sie sich zuerst die Messwerte Wait ms und Shuffle output bytes an, die im Abschnitt Informationen zur Abfragephase interpretieren beschrieben werden.

Ressourcenwarnungen in der Ansicht „INFORMATION_SCHEMA.JOBS“

Fragen Sie das Feld query_info.resource_warning der INFORMATION_SCHEMA.JOBS-Ansicht ab, um zu sehen, ob es einen Unterschied bei den von BigQuery analysierten Warnungen in Bezug auf die verwendeten Ressourcen gibt.

Analyse von Arbeitslaststatistiken

Die verfügbaren Slot-Ressourcen und Slot-Konflikte können sich auf die Ausführungszeit von Abfragen auswirken. In den folgenden Abschnitten erfahren Sie mehr über die Slot-Nutzung und ‑Verfügbarkeit für einen bestimmten Lauf einer Abfrage.

Durchschnittliche Slots pro Sekunde

Um die durchschnittliche Anzahl der von der Abfrage pro Millisekunde verwendeten Slots zu berechnen, teilen Sie den Slot-Millisekunden-Wert für den Job, totalSlotMs aus JobStatistics2, durch die Dauer in Millisekunden der Ausführung des letzten Versuchs dieses Jobs, finalExecutionDurationMs aus JobStatistics.

Sie können auch die durchschnittliche Anzahl der Slots pro Millisekunde, die von einem Job verwendet werden, berechnen, indem Sie die Ansicht INFORMATION_SCHEMA.JOBS abfragen.

Ein Job, bei dem eine ähnliche Menge an Arbeit mit einer größeren Anzahl von durchschnittlichen Slots pro Sekunde ausgeführt wird, wird schneller abgeschlossen. Eine niedrigere durchschnittliche Slot-Nutzung pro Sekunde kann folgende Ursachen haben:

  1. Aufgrund eines Ressourcenkonflikts zwischen verschiedenen Jobs waren keine zusätzlichen Ressourcen verfügbar – die Reservierung war ausgeschöpft.
  2. Für den Job wurden während eines Großteils der Ausführung keine weiteren Slots angefordert. Das kann beispielsweise bei einer Datenabweichung der Fall sein.

Modelle für die Arbeitslastverwaltung und Reservierungsgröße

Wenn Sie das On-Demand-Abrechnungsmodell verwenden, ist die Anzahl der Slots, die Sie pro Projekt nutzen können, begrenzt. Möglicherweise sind auch weniger Slots für Ihr Projekt verfügbar, wenn an einem bestimmten Standort ein hohes Konfliktpotenzial für On-Demand-Kapazität besteht.

Das kapazitätsbasierte Modell ist besser vorhersagbar und Sie können eine garantierte Anzahl von Referenz-Slots angeben.

Berücksichtigen Sie diese Unterschiede, wenn Sie die Ausführung einer On-Demand-Abfrage mit der Ausführung einer Abfrage mit einer Reservierung vergleichen.

Die Verwendung einer Reservierung wird empfohlen, um eine stabile, vorhersehbare Leistung bei der Ausführung von Abfragen zu erzielen. Weitere Informationen zu den Unterschieden zwischen On-Demand- und kapazitätsbasierten Arbeitslasten finden Sie unter Einführung in die Arbeitslastverwaltung.

Jobnebenläufigkeit

Die Jobnebenläufigkeit gibt an, wie Jobs während der Abfrageausführung um Slotressourcen konkurrieren. Eine höhere Job-Concurrency führt in der Regel zu einer langsameren Jobausführung, da der Job auf weniger Slots zugreifen kann.

Sie können die Ansicht INFORMATION_SCHEMA.JOBS abfragen, um die durchschnittliche Anzahl gleichzeitiger Jobs zu ermitteln, die gleichzeitig mit einer bestimmten Abfrage in einem Projekt ausgeführt werden.

Wenn einer Reservierung mehrere Projekte zugewiesen sind, ändern Sie die Abfrage so, dass JOBS_BY_ORGANIZATION anstelle von JOBS_BY_PROJECT verwendet wird, um genaue Daten auf Reservierungsebene zu erhalten.

Eine höhere durchschnittliche Parallelität während der langsamen Ausführung des Jobs im Vergleich zum schnellen Job trägt zur allgemeinen Langsamkeit bei.

Sie können die Parallelität im Projekt oder in der Reservierung reduzieren, indem Sie ressourcenintensive Abfragen über einen längeren Zeitraum innerhalb einer Reservierung oder eines Projekts oder über verschiedene Reservierungen oder Projekte hinweg verteilen.

Eine weitere Lösung besteht darin, eine Reservierung zu erwerben oder die Größe einer vorhandenen Reservierung zu erhöhen. Erwägen Sie, der Reservierung die Verwendung inaktiver Slots zu erlauben.

Informationen dazu, wie viele Slots Sie hinzufügen sollten, finden Sie unter Anforderungen an die Slotkapazität schätzen.

Bei Jobs, die in Reservierungen mit mehr als einem zugewiesenen Projekt ausgeführt werden, kann es bei gleicher durchschnittlicher Jobnebenläufigkeit zu unterschiedlichen Ergebnissen bei der Slotzuweisung kommen, je nachdem, in welchem Projekt sie ausgeführt werden. Weitere Informationen zur fairen Planung

Reservierungsauslastung

Die Reservierungsauslastung kann mit Admin-Ressourcendiagrammen und BigQuery Cloud Monitoring überwacht werden. Weitere Informationen finden Sie unter BigQuery Reservations überwachen.

Ob für einen Job zusätzliche Slots angefordert wurden, können Sie anhand der Messwert „Geschätzte ausführbare Einheiten“ erkennen, der in der Job API-Antwort estimatedRunnableUnits oder in der INFORMATION_SCHEMA.JOBS_TIMELINE-Ansicht als period_estimated_runnable_units angegeben ist. Wenn der Wert für diesen Messwert größer als 0 ist, hätte der Job zu diesem Zeitpunkt von zusätzlichen Slots profitieren können. Wenn Sie den Prozentsatz der Jobausführungszeit schätzen möchten, in der der Job von zusätzlichen Slots profitiert hätte, führen Sie die folgende Abfrage für die INFORMATION_SCHEMA.JOBS_TIMELINE-Ansicht aus:

SELECT
  ROUND(COUNTIF(period_estimated_runnable_units > 0) / COUNT(*) * 100, 1) AS execution_duration_percentage
FROM `myproject`.`region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
WHERE job_id = 'my_job_id'
GROUP BY job_id;
 Das Ergebnis sieht etwa so aus: 
+---------------------------------+
|   execution_duration_percentage |
+---------------------------------+
|                            96.7 |
+---------------------------------+

Ein niedriger Prozentsatz bedeutet, dass die Verfügbarkeit von Slot-Ressourcen in diesem Szenario nicht wesentlich zur Langsamkeit der Abfrage beiträgt.

Wenn der Prozentsatz hoch ist und die Reservierung in diesem Zeitraum nicht vollständig genutzt wurde, wenden Sie sich an den Cloud-Kundenservice, um das Problem zu untersuchen.

Wenn die Reservierung während der langsamen Jobausführung vollständig genutzt wurde und der Prozentsatz hoch ist, war der Job ressourcenbeschränkt. Sie können die Anzahl der gleichzeitig ausgeführten Jobs reduzieren, die Reservierungsgröße erhöhen, der Reservierung erlauben, inaktive Slots zu verwenden, oder eine Reservierung erwerben, wenn der Job On-Demand ausgeführt wurde.

Jobmetadaten und Ergebnisse der Arbeitslastanalyse nicht schlüssig

Wenn Sie den Grund für eine unerwartet langsame Abfrageleistung nun immer noch nicht identifiziert haben, wenden Sie sich an Cloud Customer Care.

Avro-Schemaauflösung

Fehlerstring: Cannot skip stream

Dieser Fehler kann auftreten, wenn mehrere Avro-Dateien mit unterschiedlichen Schemas geladen werden. Dies führt zu einem Problem mit der Schemaauflösung und dazu, dass der Importjob bei einer zufälligen Datei fehlschlägt.

Achten Sie darauf, dass die letzte alphabetische Datei im Ladevorgang die Obermenge (Vereinigung) der unterschiedlichen Schemas enthält, um diesen Fehler zu beheben. Diese Anforderung basiert darauf, wie mit Avro die Schemaauflösung verarbeitet wird.

In Konflikt stehende gleichzeitige Abfragen

Fehlerstring: Concurrent jobs in the same session are not allowed

Dieser Fehler kann auftreten, wenn mehrere Abfragen gleichzeitig in einer Sitzung ausgeführt werden, was nicht unterstützt wird. Siehe Sitzungseinschränkungen

In Konflikt stehende DML-Anweisungen

Fehlerstring: Could not serialize access to table due to concurrent update

Dieser Fehler kann auftreten, wenn mutierende DML-Anweisungen (Data Manipulation Language, Datenbearbeitungssprache), die gleichzeitig in derselben Tabelle ausgeführt werden, miteinander in Konflikt stehen oder wenn die Tabelle während einer mutierenden DML-Anweisung abgeschnitten wird. Weitere Informationen finden Sie unter Konflikte mit DML-Anweisungen.

Zur Behebung dieses Fehlers führen Sie DML-Vorgänge, die eine einzelne Tabelle betreffen, so aus, dass sie sich nicht überschneiden.

Korrelierte Unterabfragen

Fehlerstring: Correlated subqueries that reference other tables are not supported unless they can be de-correlated

Dieser Fehler kann auftreten, wenn Ihre Abfrage eine Unterabfrage enthält, die auf eine Spalte von außerhalb dieser Unterabfrage verweist. Diese wird als Korrelationsspalte bezeichnet. Die korrelierte Unterabfrage wird mithilfe einer ineffizienten, verschachtelten Ausführungsstrategie ausgewertet, bei der die Unterabfrage für jede Zeile aus der äußeren Abfrage ausgewertet wird, die die Korrelationsspalten erzeugt. Manchmal kann BigQuery Abfragen mit korrelierten Unterabfragen intern neu schreiben, damit sie effizienter ausgeführt werden. Der Fehler bei korrelierten Unterabfragen tritt auf, wenn BigQuery die Abfrage nicht ausreichend optimieren kann.

Versuchen Sie Folgendes, um diesen Fehler zu beheben:

  • Entfernen Sie alle ORDER BY-, LIMIT-, EXISTS-, NOT EXISTS- und IN-Klauseln aus der Unterabfrage.
  • Verwenden Sie eine Abfrage mit mehreren Anweisungen, um eine temporäre Tabelle zu erstellen, auf die in Ihrer Unterabfrage verwiesen werden soll.
  • Schreiben Sie Ihre Abfrage so um, dass stattdessen CROSS JOIN verwendet wird.

Unzureichende Berechtigungen für die Zugriffssteuerung auf Spaltenebene

Fehlerstring: Requires fineGrainedGet permission on the read columns to execute the DML statements

Dieser Fehler tritt auf, wenn Sie die DML-Anweisung DELETE, UPDATE oder MERGE ausführen, ohne die Berechtigung "Detaillierter Lesezugriff" für die gescannten Spalten zu haben, die Zugriffssteuerung auf Spaltenebene verwenden, um den Zugriff auf Spaltenebene einzuschränken. Weitere Informationen finden Sie unter Auswirkungen auf Schreibvorgänge mit Zugriffssteuerung auf Spaltenebene.

Ungültige Anmeldedaten für geplante Abfragen

Fehlerstrings:

  • Error code: INVALID_USERID
  • Error code 5: Authentication failure: User Id not found
  • PERMISSION_DENIED: BigQuery: Permission denied while getting Drive credentials

Dieser Fehler kann auftreten, wenn eine geplante Abfrage aufgrund veralteter Anmeldedaten fehlschlägt, insbesondere bei der Abfrage von Google Drive-Daten.

So beheben Sie diesen Fehler:

Ungültige Anmeldedaten für das Dienstkonto

Error string: HttpError 403 when requesting returned: The caller does not have permission

Dieser Fehler kann auftreten, wenn Sie versuchen, eine geplante Abfrage mit einem Dienstkonto einzurichten. Informationen zur Behebung dieses Fehlers finden Sie in den Schritten zur Fehlerbehebung unter Probleme mit Autorisierung und Berechtigungen.

Ungültige Snapshot-Zeit

Fehlerstring: Invalid snapshot time

Dieser Fehler kann auftreten, wenn versucht wird, Verlaufsdaten außerhalb des Zeitreisefensters für das Dataset abzufragen. Um diesen Fehler zu beheben, ändern Sie die Abfrage, um innerhalb des Zeitreisefensters des Datasets auf Verlaufsdaten zuzugreifen.

Dieser Fehler kann auch auftreten, wenn eine der in der Abfrage verwendeten Tabellen gelöscht und nach dem Start der Abfrage neu erstellt wird. Prüfen Sie, ob es eine geplante Abfrage oder Anwendung gibt, die diesen Vorgang ausführt und zur gleichen Zeit wie die fehlgeschlagene Abfrage lief. Wenn dies der Fall ist, versuchen Sie, den Vorgang, der das Löschen und die Neuerstellung durchführt, so zu verschieben, dass er zu einer Zeit läuft, die nicht mit Abfragen kollidiert, die diese Tabelle lesen.

Job ist bereits vorhanden

Fehlerstring: Already Exists: Job <job name>

Dieser Fehler kann bei Abfragejobs auftreten, die große Arrays auswerten müssen, sodass das Erstellen eines Abfragejobs länger als der Durchschnitt dauert. Beispiel: Eine Abfrage mit einer WHERE-Anweisung wie WHERE column IN (<2000+ elements array>).

So beheben Sie diesen Fehler:

Dieser Fehler kann auch auftreten, wenn Sie eine Job-ID manuell festlegen, der Job aber nicht innerhalb eines Zeitlimits erfolgreich abgeschlossen wird. In diesem Fall können Sie einen Ausnahmehandler hinzufügen, um zu prüfen, ob der Job vorhanden ist. Wenn dies der Fall ist, können Sie die Abfrageergebnisse aus dem Job abrufen.

Job nicht gefunden

Fehlerstring: Job not found

Dieser Fehler kann als Antwort auf einen getQueryResults-Aufruf auftreten, bei dem für das Feld location kein Wert angegeben ist. Wiederholen Sie in diesem Fall den Aufruf und geben Sie einen location-Wert an.

Weitere Informationen finden Sie unter Mehrere Auswertungen derselben allgemeinen Tabellenausdrücke (Common Table Expressions, CTEs) vermeiden.

Standort nicht gefunden

Fehlerstring: Dataset [project_id]:[dataset_id] was not found in location [region]

Dieser Fehler wird zurückgegeben, wenn Sie auf ein nicht vorhandenes Dataset verweisen oder wenn der Standort in der Anfrage nicht mit dem Standort des Datasets übereinstimmt.

Um dieses Problem zu beheben, geben Sie den Speicherort des Datasets in der Abfrage an oder bestätigen Sie, dass das Dataset am selben Speicherort verfügbar ist.

Abfrage überschreitet das Ausführungszeitlimit

Fehlerstring: Query fails due to reaching the execution time limit

Wenn Ihre Abfrage das Zeitlimit für die Ausführung der Abfrage überschreitet, überprüfen Sie die Ausführungszeit früherer Ausführungen der Abfrage, indem Sie die Ansicht INFORMATION_SCHEMA.JOBS mit einer Abfrage ähnlich dem folgenden Beispiel abfragen:

SELECT TIMESTAMP_DIFF(end_time, start_time, SECOND) AS runtime_in_seconds
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE statement_type = 'QUERY'
AND query = "my query string";

Wenn vorherige Ausführungen der Abfrage erheblich weniger Zeit in Anspruch genommen haben, können Sie mit den Statistiken zur Abfrageleistung das zugrunde liegende Problem ermitteln und beheben.

Die Abfrageantwort ist zu groß

Fehlerstring: responseTooLarge

Dieser Fehler tritt auf, wenn die Ergebnisse Ihrer Abfrage die maximale Antwortgröße überschreiten.

Folgen Sie der Anleitung für die Fehlermeldung responseTooLarge, um diesen Fehler zu beheben.

Reservierung nicht gefunden oder es fehlen Slots

Fehlerstring: Cannot run query: project does not have the reservation in the data region or no slots are configured

Dieser Fehler tritt auf, wenn der Reservierung, die dem Projekt in der Region der Abfrage zugewiesen ist, keine Slots zugewiesen sind. Sie können der Reservierung entweder Slots hinzufügen, der Reservierung erlauben, inaktive Slots zu verwenden, eine andere Reservierung verwenden oder die Zuweisung entfernen und die Abfrage bei Bedarf ausführen.

Tabelle nicht gefunden

Fehlerstring: Not found: Table [project_id]:[dataset].[table_name] was not found in location [region]

Dieser Fehler tritt auf, wenn eine Tabelle in Ihrer Abfrage im angegebenen Dataset oder in der angegebenen Region nicht gefunden werden kann. So beheben Sie diesen Fehler:

  • Prüfen Sie, ob Ihre Abfrage den richtigen Projekt-, Dataset- und Tabellennamen enthält.
  • Prüfen Sie, ob die Tabelle in der Region vorhanden ist, in der Sie die Abfrage ausgeführt haben.
  • Prüfen Sie, ob die Tabelle während der Ausführung des Jobs gelöscht und neu erstellt wurde. Andernfalls kann dieser Fehler durch eine unvollständige Übertragung von Metadaten verursacht werden.

Zu viele DML-Anweisungen

Fehlerstring: Too many DML statements outstanding against <table-name>, limit is 20

Dieser Fehler tritt auf, wenn Sie das Limit von 20 DML-Anweisungen im Status PENDING in einer Warteschlange für eine einzelne Tabelle überschreiten. Dieser Fehler tritt in der Regel auf, wenn Sie DML-Jobs für eine einzelne Tabelle schneller senden, als BigQuery sie verarbeiten kann.

Eine mögliche Lösung besteht darin, mehrere kleinere DML-Vorgänge in größeren, aber weniger Jobs zu gruppieren, z. B. durch Batching von Aktualisierungen und Einfügungen. Wenn Sie kleinere Jobs zu größeren Jobs gruppieren, sind die Kosten für die Ausführung der größeren Jobs amortisiert und die Ausführung erfolgt schneller. Durch die Konsolidierung von DML-Anweisungen, die dieselben Daten betreffen, wird im Allgemeinen die Effizienz von DML-Jobs verbessert und die Wahrscheinlichkeit geringer, dass das Kontingentlimit für Warteschlangengrößen überschritten wird. Weitere Informationen zum Optimieren Ihrer DML-Vorgänge finden Sie unter DML-Anweisungen, die einzelne Zeilen aktualisieren oder einfügen.

Weitere Lösungen zur Verbesserung der DML-Effizienz können die Partitionierung oder das Clustern Ihrer Tabellen sein. Weitere Informationen finden Sie in den Best Practices.

Transaktion aufgrund von gleichzeitiger Aktualisierung abgebrochen

Fehlerstring: Transaction is aborted due to concurrent update against table [table_name]

Dieser Fehler kann auftreten, wenn zwei verschiedene mutierende DML-Anweisungen (Data Manipulation Language, Datenbearbeitungssprache) versuchen, dieselbe Tabelle gleichzeitig zu aktualisieren. Angenommen, Sie starten eine Transaktion in einer Sitzung, die eine mutierende DML-Anweisung gefolgt von einem Fehler enthält. Wenn kein Ausnahme-Handler vorhanden ist, führt BigQuery automatisch ein Rollback der Transaktion durch, wenn die Sitzung endet. Das kann bis zu 24 Stunden dauern. Während dieser Zeit schlagen andere Versuche fehl, eine mutierende DML-Anweisung für die Tabelle auszuführen.

Zur Behebung dieses Fehlers listen Sie Ihre aktiven Sitzungen auf und prüfen Sie, ob eine davon einen Abfragejob mit dem Status ERROR enthält, in dem eine mutierende DML-Anweisung für die Tabelle ausgeführt wurde. Beenden Sie dann diese Sitzung.

Nutzer hat keine Berechtigung

Fehlerstrings:

  • Access Denied: Project [project_id]: User does not have bigquery.jobs.create permission in project [project_id].
  • User does not have permission to query table project-id:dataset.table.
  • Access Denied: User does not have permission to query table or perhaps it does not exist.

Diese Fehler können auftreten, wenn Sie eine Abfrage ohne die Berechtigung bigquery.jobs.create für das Projekt ausführen, in dem die Abfrage ausgeführt wird, unabhängig von Ihren Berechtigungen für das Projekt, das die Daten enthält.

Diese Fehler können auch auftreten, wenn Ihr Dienstkonto, Nutzer oder Ihre Gruppe nicht die Berechtigung bigquery.tables.getData für alle Tabellen und Ansichten hat, auf die in Ihrer Abfrage verwiesen wird. Weitere Informationen zu den Berechtigungen, die zum Ausführen einer Abfrage erforderlich sind, finden Sie unter Erforderliche Rollen.

Diese Fehler können auch auftreten, wenn die Tabelle in der abgefragten Region nicht vorhanden ist, z. B. asia-south1. Sie können die Region überprüfen, indem Sie sich den Dataset-Speicherort ansehen.

Beachten Sie beim Beheben dieser Fehler Folgendes:

  • Dienstkonten: Dienstkonten müssen die Berechtigung bigquery.jobs.create für das Projekt haben, aus dem sie ausgeführt werden, und die Berechtigung bigquery.tables.getData für alle Tabellen und Ansichten, auf die in der Abfrage verwiesen wird.

  • Benutzerdefinierte Rollen: Benutzerdefinierte IAM-Rollen müssen die Berechtigung bigquery.jobs.create enthalten, die explizit in der entsprechenden Rolle enthalten ist. Außerdem müssen sie die Berechtigung bigquery.tables.getData für alle Tabellen und Ansichten haben, auf die in der Abfrage verwiesen wird.

  • Freigegebene Datasets: Wenn Sie mit freigegebenen Datasets in einem separaten Projekt arbeiten, benötigen Sie möglicherweise weiterhin die Berechtigung bigquery.jobs.create im Projekt, um Abfragen oder Jobs in diesem Dataset auszuführen.

Informationen zum Erteilen der Berechtigung für den Zugriff auf eine Tabelle oder Ansicht finden Sie unter Zugriff auf eine Tabelle oder Ansicht gewähren.

Probleme mit überschrittener Ressourcen

Die folgenden Probleme treten auf, wenn BigQuery nicht genügend Ressourcen hat, um Ihre Abfrage abzuschließen.

Abfrage überschreitet CPU-Ressourcen

Fehlerstring: Query exceeded resource limits

Dieser Fehler tritt auf, wenn On-Demand-Abfragen zu viel CPU im Vergleich zur Menge der gescannten Daten verbrauchen. Informationen zum Beheben dieser Probleme finden Sie unter Fehlerbehebung bei Ressourcenüberschreitungen.

Abfrage überschreitet Speicherressourcen

Fehlerstring: Resources exceeded during query execution: The query could not be executed in the allotted memory

Bei SELECT-Anweisungen tritt dieser Fehler auf, wenn die Abfrage zu viele Ressourcen verwendet. Informationen zum Beheben dieses Fehlers finden Sie unter Fehlerbehebung bei Ressourcenüberschreitungen.

Nicht genügend Stapelspeicher

Fehlerstring: Out of stack space due to deeply nested query expression during query resolution.

Dieser Fehler kann auftreten, wenn eine Abfrage zu viele verschachtelte Funktionsaufrufe enthält. Manchmal werden Teile einer Abfrage während des Parsens in Funktionsaufrufe übersetzt. Ein Ausdruck mit wiederholten Verkettungsoperatoren, z. B. A || B || C || ..., wird zu CONCAT(A, CONCAT(B, CONCAT(C, ...))).

Schreiben Sie die Abfrage um, um die Anzahl der Verschachtelungen zu reduzieren.

Ressourcen wurden während der Abfrageausführung überschritten

Fehlerstring: Resources exceeded during query execution: The query could not be executed in the allotted memory. Peak usage: [percentage]% of limit. Top memory consumer(s): ORDER BY operations.

Das kann bei ORDER BY ... LIMIT ... OFFSET ...-Anfragen passieren. Aufgrund von Implementierungsdetails kann die Sortierung auf einer einzelnen Recheneinheit erfolgen. Wenn zu viele Zeilen verarbeitet werden müssen, bevor LIMIT und OFFSET angewendet werden, kann der Arbeitsspeicher ausgehen, insbesondere bei einem großen OFFSET.

Um diesen Fehler zu beheben, sollten Sie große OFFSET-Werte in ORDER BY-…-LIMIT-Abfragen vermeiden. Alternativ können Sie die skalierbare Fensterfunktion ROW_NUMBER() verwenden, um Ränge basierend auf der ausgewählten Reihenfolge zuzuweisen, und diese Ränge dann in einer WHERE-Klausel filtern. Beispiel:

SELECT ...
FROM (
  SELECT ROW_NUMBER() OVER (ORDER BY ...) AS rn
  FROM ...
)
WHERE rn > @start_index AND rn <= @page_size + @start_index  -- note that row_number() starts with 1

Abfrage überschreitet Shuffle-Ressourcen

Fehlerstring: Resources exceeded during query execution: Your project or organization exceeded the maximum disk and memory limit available for shuffle operations

Dieser Fehler tritt auf, wenn eine Abfrage nicht auf genügend Shuffle-Ressourcen zugreifen kann.

Stellen Sie mehr Slots bereit oder reduzieren Sie die von der Abfrage verarbeitete Datenmenge, um diesen Fehler zu beheben. Weitere Informationen dazu finden Sie unter Unzureichendes Shuffle-Kontingent.

Weitere Informationen zur Behebung dieser Probleme finden Sie unter Fehlerbehebung bei Ressourcenüberschreitungen.

Abfrage ist zu komplex

Fehlerstring: Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex

Dieser Fehler tritt auf, wenn eine Abfrage zu komplex ist. Die Hauptursachen für Komplexität sind:

  • WITH-Klauseln, die tief verschachtelt sind oder wiederholt verwendet werden.
  • Tief verschachtelte oder wiederholt verwendete Ansichten.
  • Wiederholte Verwendung des UNION ALL-Operators.

Versuchen Sie Folgendes, um diesen Fehler zu beheben:

  • Teilen Sie die Abfrage in mehrere Abfragen auf und verwenden Sie dann eine prozedurale Sprache, um diese Abfragen in einer Sequenz mit gemeinsamem Zustand auszuführen.
  • Verwenden Sie temporäre Tabellen anstelle von WITH-Klauseln.
  • Schreiben Sie Ihre Abfrage um, um die Anzahl der referenzierten Objekte und Vergleiche zu reduzieren.

Sie können Abfragen, die sich dem Komplexitätslimit nähern, proaktiv mithilfe des Felds query_info.resource_warning in der Ansicht INFORMATION_SCHEMA.JOBS überwachen. Im folgenden Beispiel werden Abfragen mit hoher Ressourcennutzung für die letzten drei Tage zurückgegeben:

SELECT
  ANY_VALUE(query) AS query,
  MAX(query_info.resource_warning) AS resource_warning
FROM
  <your_project_id>.`region-us`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 DAY)
  AND query_info.resource_warning IS NOT NULL
GROUP BY
  query_info.query_hashes.normalized_literals
LIMIT
  1000

Weitere Informationen zur Behebung dieser Probleme finden Sie unter Fehlerbehebung bei Ressourcenüberschreitungen.

Fehlerbehebung bei Ressourcenüberschreitung

Für Abfragejobs:

So optimieren Sie Ihre Anfragen:

  • 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. Achten Sie außerdem darauf, dass Ihre Daten keine doppelten Join-Schlüssel enthalten.
  • 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.
  • Wenn in Ihrer Abfrage tief verschachtelte Ansichten und eine WITH-Klausel verwendet wurden, kann dies zu einem exponentiellen Anstieg der Komplexität führen, wodurch die Grenzwerte erreicht werden.
  • Verwenden Sie temporäre Tabellen anstelle von WITH-Klauseln. Eine WITH-Klausel muss möglicherweise mehrmals neu berechnet werden, was die Abfrage komplex und daher langsam machen kann. Wenn Sie Zwischenergebnisse stattdessen in temporären Tabellen speichern, wird die Komplexität reduziert.
  • Vermeiden Sie die Verwendung von UNION ALL-Abfragen.
  • Wenn in der Abfrage MATCH_RECOGNIZE verwendet wird, ändern Sie die PARTITION BY-Klausel, um die Größe der Partitionen zu verringern, oder fügen Sie eine PARTITION BY-Klausel hinzu, falls keine vorhanden ist.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Für Ladejobs:

Wenn Sie Avro- oder Parquet-Dateien laden, reduzieren Sie die Zeilengröße in den Dateien. Überprüfen Sie die Größe des geladenen Dateiformats auf bestimmte Größenbeschränkungen:

Wenn dieser Fehler beim Laden von ORC-Dateien auftritt, wenden Sie sich an den Support.

Für die Storage API:

Fehlerstring: Stream memory usage exceeded

Während eines ReadRows-Aufrufs der Storage Read API erhalten einige Streams mit hoher Arbeitsspeichernutzung möglicherweise den Fehler RESOURCE_EXHAUSTED mit dieser Meldung. Dies kann vorkommen, wenn aus breiten Tabellen oder Tabellen mit einem komplexen Schema gelesen wird. Reduzieren Sie zur Lösung die Größe der Ergebniszeile, indem Sie mit dem Parameter selected_fields weniger zu lesende Spalten auswählen oder das Tabellenschema vereinfachen.

Verbindungsprobleme beheben

In den folgenden Abschnitten wird beschrieben, wie Sie Verbindungsprobleme bei der Interaktion mit BigQuery beheben können:

Google DNS auf die Zulassungsliste setzen

Verwenden Sie das Google IP Dig-Tool, um den BigQuery-DNS-Endpunkt bigquery.googleapis.com in eine einzelne „A“-Eintrag-IP aufzulösen. Prüfen Sie, ob diese IP-Adresse in Ihren Firewalleinstellungen blockiert ist.

Im Allgemeinen empfehlen wir, Google-DNS-Namen auf die Zulassungsliste zu setzen. Die in den Dateien https://www.gstatic.com/ipranges/goog.json und https://www.gstatic.com/ipranges/cloud.json angegebenen IP-Bereiche ändern sich häufig. Daher empfehlen wir, stattdessen Google-DNS-Namen auf die Zulassungsliste zu setzen. Hier ist eine Liste der gängigen DNS-Namen, die wir empfehlen, der Zulassungsliste hinzuzufügen:

  • *.1e100.net
  • *.google.com
  • *.gstatic.com
  • *.googleapis.com
  • *.googleusercontent.com
  • *.appspot.com
  • *.gvt1.com

Proxy oder Firewall identifizieren, die Pakete verwerfen

Um alle Paket-Hops zwischen dem Client und dem Google Front End (GFE) zu ermitteln, führen Sie auf Ihrem Clientcomputer den Befehl traceroute aus. So können Sie den Server ermitteln, der Pakete verwirft, die an das GFE gerichtet sind. Hier ist ein Beispiel für einen traceroute-Befehl:

traceroute -T -p 443 bigquery.googleapis.com

Es ist auch möglich, Paket-Hops für bestimmte GFE-IP-Adressen zu identifizieren, wenn das Problem mit einer bestimmten IP-Adresse zusammenhängt:

traceroute -T -p 443 142.250.178.138

Wenn es ein Timeout-Problem auf Google-Seite gibt, wird die Anfrage bis zum GFE weitergeleitet.

Wenn Sie feststellen, dass die Pakete die GFE nie erreichen, wenden Sie sich an Ihren Netzwerkadministrator, um das Problem zu beheben.

PCAP-Datei erstellen und Firewall oder Proxy analysieren

Erstelle eine PCAP-Datei (Packet Capture) und analysiere sie, um sicherzustellen, dass die Firewall oder der Proxy keine Pakete an Google-IPs herausfiltert und Pakete die GFE erreichen können.

Hier ist ein Beispielbefehl, der mit dem Tool tcpdump ausgeführt werden kann:

tcpdump -s 0 -w debug.pcap -K -n host bigquery.googleapis.com

Wiederholungsversuche für zeitweilige Verbindungsprobleme einrichten

Es gibt Situationen, in denen GFE-Load-Balancer Verbindungen von einer Client-IP-Adresse trennen können, z. B. wenn DDOS-Trafficmuster erkannt werden oder die Load-Balancer-Instanz skaliert wird, was dazu führen kann, dass die Endpunkt-IP-Adresse wiederverwendet wird. Wenn die GFE-Load-Balancer die Verbindung trennen, muss der Client die Zeitüberschreitung der Anfrage abfangen und die Anfrage an den DNS-Endpunkt wiederholen. Verwenden Sie nicht dieselbe IP-Adresse, bis die Anfrage erfolgreich ist, da sich die IP-Adresse möglicherweise geändert hat.

Wenn Sie ein Problem mit konsistenten Google-seitigen Zeitüberschreitungen festgestellt haben, bei denen Wiederholungsversuche nicht helfen, wenden Sie sich an Cloud Customer Care und fügen Sie eine neue PCAP-Datei bei, die durch Ausführen eines Tools zur Paketerfassung wie tcpdump generiert wurde.

Nächste Schritte