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

So beheben Sie Probleme mit langsamer Abfrageleistung:

• Prüfen Sie die Seite Cloud de Confiance by S3NS Service Health auf bekannte BigQuery-Dienstausfälle, die sich auf die Abfrageleistung auswirken können.

• In der Jobzeitachse für Ihre Abfrage im Job-Explorer 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 Ursachen sind 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.

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

• Prüfen Sie die verarbeiteten Byte auf der Seite mit den Abfragejobdetails, um festzustellen, ob die Anzahl höher ist als erwartet. Vergleichen Sie dazu die Anzahl der von der aktuellen Abfrage verarbeiteten Byte mit einem anderen Abfragejob, der in einer akzeptablen Zeit abgeschlossen wurde. Wenn es eine große Abweichung bei den verarbeiteten Byte zwischen den beiden Abfragen gibt, war die Abfrage möglicherweise aufgrund eines großen Datenvolumens langsam. Informationen zum Optimieren von Abfragen für große 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.

• Prüfen Sie die Reservierungsnutzung und ob Slot-Konflikte vorliegen. Weitere Informationen finden Sie unter Analyse der Arbeitslaststatistiken.

• Prüfen Sie frühere und aktuelle Ausführungen für denselben Abfrage-Hash, um festzustellen, ob neue Statistiken zur Abfrageleistung für die langsameren Jobs verfügbar sind, z. B. eine Änderung der Dateneingabeskalierung. Sie können im Explorer für administrative Jobs nach Abfrage-Hash filtern.

Langsame und schnelle Ausführung derselben Abfrage vergleichen

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

Cache-Treffer

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

Wenn Sie erwarten, dass der langsame Job im Cache gespeicherte Ergebnisse verwendet, untersuchen Sie, warum die Abfrage keine im Cache gespeicherten Ergebnisse mehr verwendet. 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 Kontingentverschiebungen verursacht wurde, prüfen Sie das Feld quotaDeferments für beide Jobs. Vergleichen Sie die Werte, um festzustellen, ob der Beginn der langsameren Abfrage durch Kontingentverzögerungen verzögert wurde, die sich nicht auf den schnelleren Job ausgewirkt haben.

Dauer der Ausführung

Wenn Sie den Unterschied zwischen der Ausführungsdauer des letzten Versuchs beider Jobs verstehen möchten, vergleichen Sie die Werte für das Feld finalExecutionDurationMs.

Wenn die Werte für finalExecutionDurationMs sehr ähnlich sind, aber der Unterschied bei der Ausführungszeit zwischen den beiden Abfragen, berechnet als startTime - endTime, viel größer ist, bedeutet dies, dass es möglicherweise einen internen Wiederholungsversuch der Abfrageausführung für den langsamen Job aufgrund eines möglichen vorübergehenden Problems gab. Wenn Sie dieses Abweichungsmuster wiederholt sehen, 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 totalBytesProcessed aus JobStatistics an, um festzustellen, ob die Anzahl höher ist als erwartet. Wenn es eine große Diskrepanz bei den verarbeiteten Byte zwischen den beiden Abfragen gibt, ist die Abfrage möglicherweise aufgrund einer Änderung des verarbeiteten Datenvolumens langsam. Informationen zum Optimieren von Abfragen für große 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 in der Abfrage verwiesen wird, 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. Unterschiede in den referenzierten Tabellen können folgende Ursachen haben:

• Die SQL-Abfrage wurde so geändert, dass andere Tabellen gelesen werden. 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 Ansichten, auf die in dieser Abfrage verwiesen wird, und aktualisieren Sie sie bei Bedarf.

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

Nutzung von materialisierten Ansichten

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

Statistiken zum Metadaten-Caching

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

BigQuery BI Engine-Statistiken vergleichen

Wenn die Abfrage BigQuery BI Engine verwendet, analysieren Sie die Ausgabe von BiEngineStatistics, um festzustellen, ob dieselben Beschleunigungsmodi sowohl auf die langsame als auch auf die schnelle Abfrage angewendet wurden. Sehen Sie sich das Feld BiEngineReason an, um den allgemeinen Grund für die teilweise oder fehlende Beschleunigung zu erfahren, z. B. unzureichender Arbeitsspeicher, fehlende Reservierung oder zu große Eingabe.

Unterschiede bei Statistiken zur Abfrageleistung prüfen

Vergleichen Sie die Statistiken zur Abfrageleistung für jede der Abfragen, indem Sie sich das Ausführungsdiagramm in der Cloud de Confiance Console oder das Objekt StagePerformanceStandaloneInsight ansehen, um die folgenden möglichen Probleme zu verstehen:

• Slot-Konflikt (slotContention)
• Joins mit hoher Kardinalität (highCardinalityJoins)
• Unzureichendes Shuffle-Kontingent (insufficientShuffleQuota)
• Datenverzerrung (partitionSkew)

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

Reservierungszuweisung

Prüfen Sie, ob es Unterschiede bei der Reservierung gibt, die den beiden Jobs zugewiesen ist. Eine Änderung der Reservierung oder ein Wechsel von On-Demand zu einer Reservierung kann sich auf die Leistung auswirken. Weitere Informationen finden Sie unter Arbeitslastverwaltungsmodelle und Reservierungsgröße.

Für eine gründlichere Analyse der Metadaten zur Jobausführung müssen Sie die einzelnen Phasen der Abfrageausführung durchgehen und die ExplainQueryStage-Objekte für die beiden Jobs vergleichen.

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

Ressourcenwarnungen aus der Ansicht INFORMATION_SCHEMA.JOBS

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

Analyse von Arbeitslaststatistiken

Verfügbare 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 eine bestimmte Ausführung einer Abfrage.

Durchschnittliche Slots pro Sekunde

Wenn Sie die durchschnittliche Anzahl der von der Abfrage pro Millisekunde verwendeten Slots berechnen möchten, 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 von Slots pro Millisekunde berechnen, die von einem Job verwendet werden, indem Sie die Ansicht INFORMATION_SCHEMA.JOBS abfragen.

Ein Job, der eine ähnliche Menge an Arbeit mit einer größeren Menge an durchschnittlichen Slots pro Sekunde ausführt, wird schneller abgeschlossen. Eine niedrigere durchschnittliche Slotnutzung pro Sekunde kann folgende Ursachen haben:

• Aufgrund eines Ressourcenkonflikts zwischen verschiedenen Jobs waren keine zusätzlichen Ressourcen verfügbar. Die Reservierung war ausgeschöpft.
• Der Job hat während eines großen Teils der Ausführung keine weiteren Slots angefordert. Dies kann beispielsweise bei einer Datenverzerrung 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 verwenden können, begrenzt. Darüber hinaus stehen für Ihr Projekt möglicherweise weniger Slots zur Verfügung, wenn an einem bestimmten Standort ein hohes Konfliktpotenzial für On-Demand-Kapazität besteht.

Das kapazitätsbasierte Modell ist besser vorhersehbar und ermöglicht es Ihnen, eine bestätigte Anzahl von Baseline-Slots anzugeben.

Berücksichtigen Sie diese Unterschiede, wenn Sie eine Abfrageausführung mit On-Demand-Slots mit einer Abfrageausführung mit einer Reservierung vergleichen.

Die Verwendung einer Reservierung wird empfohlen, um eine stabile, vorhersehbare Abfrageausführungsleistung 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 Job-Nebenläufigkeit stellt die Konkurrenz zwischen Jobs um Slot-Ressourcen während der Abfrageausführung dar. Eine höhere Job-Nebenläufigkeit führt in der Regel zu einer langsameren Jobausführung, da der Job Zugriff auf weniger Slots hat.

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 mehr als ein Projekt zugewiesen ist, ä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 Nebenläufigkeit während der langsamen Jobausführung im Vergleich zum schnellen Job trägt zur allgemeinen Langsamkeit bei.

Sie können die Nebenläufigkeit innerhalb des Projekts oder der Reservierung reduzieren, indem Sie ressourcenintensive Abfragen entweder über die Zeit innerhalb einer Reservierung oder eines Projekts oder über verschiedene Reservierungen oder Projekte verteilen.

Eine andere Lösung besteht darin, eine Reservierung zu erwerben oder die Größe einer vorhandenen Reservierung zu erhöhen. Erwägen Sie, für die Reservierung die Verwendung inaktiver Slots zuzulassen.

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, können je nach Projekt, in dem sie ausgeführt werden, unterschiedliche Slot-Zuweisungsergebnisse bei gleicher durchschnittlicher Job-Nebenläufigkeit auftreten. Unter Fair Scheduling erfahren Sie mehr zu diesem Thema.

Reservierungsauslastung

Administratoren-Ressourcendiagramme und BigQuery Cloud Monitoring können verwendet werden, um die Reservierungsauslastung zu überwachen. Weitere Informationen finden Sie unter BigQuery Reservations überwachen.

Wenn Sie wissen möchten, ob für einen Job zusätzliche Slots angefordert wurden, sehen Sie sich den Messwert für die geschätzten ausführbaren Einheiten an. Dies ist estimatedRunnableUnits aus der Job API-Antwort oder period_estimated_runnable_units in der Ansicht INFORMATION_SCHEMA.JOBS_TIMELINE. 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. Führen Sie die folgende Abfrage für die Ansicht INFORMATION_SCHEMA.JOBS_TIMELINE aus, um den Prozentsatz der Jobausführungszeit zu schätzen, in dem der Job von zusätzlichen Slots profitiert hätte:

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;

+---------------------------------+
|   execution_duration_percentage |
+---------------------------------+
|                            96.7 |
+---------------------------------+

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

Wenn der Prozentsatz hoch ist und die Reservierung in dieser Zeit nicht vollständig genutzt wurde, wenden Sie sich an Cloud Customer Care, um das Problem zu untersuchen.

Wenn die Reservierung während der langsamen Jobausführung vollständig ausgelastet war und der Prozentsatz hoch ist, waren die Ressourcen für den Job eingeschränkt. Sie können die Nebenläufigkeit reduzieren, die Reservierungsgröße erhöhen, die Verwendung inaktiver Slots für die Reservierung zulassen oder eine Reservierung erwerben, wenn der Job On-Demand ausgeführt wurde.

Jobmetadaten und Ergebnisse der Arbeitslastanalyse nicht eindeutig

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

Fehlerbehebung bei Abfragen mit Gemini Cloud Assist

So verwenden Sie Gemini Cloud Assist, um einen Abfragefehler oder ein Leistungsproblem zu beheben:

1. Rufen Sie in der Cloud de Confiance Console die Seite BigQuery auf.

   BigQuery aufrufen

2. Klicken Sie in der Cloud de Confiance Symbolleiste auf spark Gemini Cloud Assist-Chat öffnen oder schließen.

3. Geben Sie im Bereich Cloud Assist einen Prompt ein, der die Job-ID enthält, um die Ausführung, die Leistungsmesswerte oder die Fehlerursachen zu untersuchen. Beispiel:

   • Warum ist JOB_ID fehlgeschlagen?
   • Warum dauert dieser Job so lange? JOB_ID
   • Fasse meine Arbeitsleistung der letzten 24 Stunden zusammen.

Fehlerbehebung bei Abfragefehlern mit gcpdiag

gcpdiag ist ein Open-Source-Tool. Es ist kein offiziell unterstütztes Cloud de Confiance by S3NS -Produkt. Mit dem Tool gcpdiag können Sie Probleme mit Cloud de Confiance by S3NS-Projekten identifizieren und beheben. Weitere Informationen finden Sie im gcpdiag-Projekt auf GitHub.

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.

Um diesen Fehler zu beheben, muss die letzte alphabetische Datei im Ladejob die Obermenge (Vereinigung) der unterschiedlichen Schemas enthalten. 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 tritt auf, wenn gleichzeitige mutierende DML-Anweisungen (Datenbearbeitungssprache) (UPDATE, DELETE oder MERGE) versuchen, Daten in derselben Tabellenpartition gleichzeitig zu ändern, oder wenn die Tabelle abgeschnitten wird, während eine DML-Anweisung ausgeführt wird.

In BigQuery können gleichzeitige mutierende DML-Anweisungen in derselben Tabelle ausgeführt werden, solange sie unterschiedliche Partitionen ändern. Wenn jedoch zwei Jobs versuchen, dieselbe Partition zu ändern, ist der erste Job, der einen Commit ausführt, erfolgreich und nachfolgende Jobs schlagen mit diesem Fehler fehl.

Versuchen Sie Folgendes, um diesen Fehler zu beheben:

• Fehlgeschlagenen Job wiederholen: Wenn der Konflikt durch eine vorübergehende Überschneidung mit einem anderen Job verursacht wurde, wiederholen Sie die Abfrage, nachdem der in Konflikt stehende Job abgeschlossen wurde.
• Konflikte zwischen Jobs identifizieren und koordinieren: Führen Sie die Diagnoseabfrage im folgenden Abschnitt aus, um den konkurrierenden Job zu identifizieren. Koordinieren Sie dann die Zeitpläne, damit mutierende DML-Vorgänge auf derselben Partition nicht gleichzeitig ausgeführt werden.
• Tabellen partitionieren: Wenn gleichzeitige DML-Jobs verschiedene Datensegmente aktualisieren, partitionieren Sie Ihre Tabelle nach Datum oder Ganzzahlbereich. Gleichzeitige mutierende DML-Anweisungen sind ohne Konflikte erfolgreich, wenn sie unterschiedliche Partitionen ändern.
• DML-Vorgänge im Batch verarbeiten: Kombinieren Sie mehrere einzelne UPDATE- oder DELETE-Vorgänge in einer einzigen MERGE-Anweisung oder einem Batchjob, um die Nebenläufigkeit und den Commit-Overhead zu reduzieren. Weitere Informationen finden Sie in den Best Practices.

Konfliktverursachenden Job identifizieren

Wenn Sie herausfinden möchten, welcher Job die Tabelle gleichzeitig aktualisiert hat, als der Fehler aufgetreten ist, führen Sie eine Abfrage für die Ansicht INFORMATION_SCHEMA.JOBS aus:

SELECT
  job_id,
  query,
  start_time,
  end_time
FROM
  `region-REGION`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time BETWEEN
    TIMESTAMP_SUB(TIMESTAMP 'FAILED_JOB_START_TIME', INTERVAL 1 DAY)
    AND TIMESTAMP 'FAILED_JOB_END_TIME'
  AND destination_table.table_id = 'TABLE_NAME'
  AND destination_table.dataset_id = 'DATASET_NAME'
  AND statement_type IN ('UPDATE', 'DELETE', 'MERGE')
  AND start_time <= 'FAILED_JOB_END_TIME'
  AND (end_time >= 'FAILED_JOB_START_TIME' OR end_time IS NULL)
ORDER BY
  start_time;

Ersetzen Sie Folgendes:

• REGION: der Regionsname, in dem sich Ihr Dataset befindet, z. B. us.
• FAILED_JOB_START_TIME: der Zeitstempel, der angibt, wann der fehlgeschlagene Job gestartet wurde, z. B. 2026-09-01 09:55:00 UTC.
• FAILED_JOB_END_TIME: der Zeitstempel, der angibt, wann der fehlgeschlagene Job beendet wurde, z. B. 2026-09-01 10:00:00 UTC.
• TABLE_NAME: der Name der Tabelle, die mit der fehlgeschlagenen DML-Anweisung aktualisiert werden sollte.
• DATASET_NAME: der Name des Datasets, das die Tabelle enthält.

Wenn die Abfrage keine in Konflikt stehenden, vom Nutzer initiierten Jobs zurückgibt, wurde der Konflikt möglicherweise durch einen anderen Hintergrundvorgang verursacht, z. B. durch den Ablauf einer Partition.

Andere Ursachen für Konflikte bei gleichzeitigen Updates

• Partitionsablauf: Hintergrundsystemaufgaben, die Partitionen ablaufen lassen, können mit einer DML-Anweisung in Konflikt stehen, wenn sie während der Jobausführung dieselbe Partition ändern. Wenn Sie den Partitionsablauf verwenden, planen Sie DML-Jobs außerhalb der Zeiten, in denen Partitionen ablaufen.
• Transaktionen mit mehreren Anweisungen: Wenn eine Transaktion mit mehreren Anweisungen eine Tabelle mutiert, werden alle anderen gleichzeitigen DML-Anweisungen für diese Tabelle blockiert, bis die Transaktion abgeschlossen ist.
• DML-Anweisungen, die sich auf null Zeilen auswirken: Eine UPDATE-, DELETE- oder MERGE-Anweisung erwirbt Sperren für Zielpartitionen und kann Serialisierungskonflikte verursachen, auch wenn keine Zeilen den Filterbedingungen entsprechen.

Weitere Informationen finden Sie unter Konflikte mit DML-Anweisungen.

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

Fehlerstrings:

• Access denied: Requires fineGrainedGet permission on the read columns to execute the DML statements
• `Access denied: User does not have permission to access policy tag projects/PROJECT_ID/locations/LOCATION/taxonomies/TAXONOMY_ID/policyTags/POLICY_TAG_ID on column PROJECT_ID.DATASET.TABLE.COLUMN.'

Diese Fehler treten auf, wenn Sie versuchen, eine SQL-Abfrage oder eine DML-Anweisung DELETE, UPDATE oder MERGE auszuführen, ohne dass Ihnen die Rolle Detaillierter Lesezugriff für die Spalten zugewiesen wurde, die die Zugriffssteuerung auf Spaltenebene verwenden. Diese Rolle wird Hauptkonten im Rahmen der Konfiguration eines Richtlinien-Tags zugewiesen. Weitere Informationen finden Sie unter Auswirkungen auf Schreibvorgänge mit Zugriffssteuerung auf Spaltenebene.

Um dieses Problem zu umgehen, ändern Sie die Abfrage so, dass Spalten mit Richtlinien-Tags ausgeschlossen werden, oder weisen Sie dem Nutzer die Rolle Detaillierter Lesezugriff zu. Diese Rolle wird Hauptkonten im Rahmen der Konfiguration eines Richtlinien-Tags zugewiesen. Weitere Informationen finden Sie unter Berechtigungen für Richtlinien-Tags aktualisieren.

Fehlerbehebung bei geplanten Abfragen

Die folgenden Probleme können während der Konfiguration oder Ausführung geplanter Abfragen auftreten.

Geplante Abfrage löst doppelte Ausführungen aus

Eine geplante Abfrage kann zum geplanten Zeitpunkt mehrmals ausgelöst werden. Dieses Verhalten tritt eher bei Abfragen auf, die genau zur vollen Stunde geplant sind (z. B. 09:00 Uhr). Dies kann zu unerwarteten Ergebnissen führen, z. B. zu doppelten Daten, wenn die Abfrage INSERT-Vorgänge ausführt.

Um das Risiko doppelter Ausführungen zu minimieren, sollten Sie Ihre Abfragen zu einer Zeit planen, die nicht zur vollen Stunde liegt, z. B. einige Minuten vor oder nach der vollen Stunde (z. B. 08:58 oder 09:03). Weitere Informationen finden Sie unter Abfragen planen.

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:

• Achten Sie darauf, dass Sie den BigQuery Data Transfer Service aktiviert haben. Dies ist eine Voraussetzung für die Verwendung geplanter Abfragen.
• Aktualisieren Sie die Anmeldedaten für die geplante Abfrage.

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:

• Erlauben Sie BigQuery, einen zufälligen jobId-Wert zu generieren, anstatt einen anzugeben.
• Verwenden Sie eine parametrisierte Abfrage, um das Array zu laden.

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 Ausnahme-Handler hinzufügen, um zu prüfen, ob der Job vorhanden ist. Wenn ja, 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 eine nicht vorhandene Dataset-Ressource angeben oder wenn der Standort in der Anfrage nicht mit dem Standort des Datasets übereinstimmt.

Geben Sie zur Behebung dieses Problems den Standort des Datasets in der Abfrage an oder prüfen Sie, ob das Dataset am selben Standort 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.

Abfrage überschreitet das Limit für maximal berechnete Byte

Fehlerstring: Query exceeded limit for bytes billed: LIMIT_BYTES. REQUIRED_BYTES or higher required.

Dieser HTTP-400 Bad Request-Fehler (reason: bytesBilledLimitExceeded) tritt auf, wenn die Schätzung der abzurechnenden Byte für eine Abfrage vor der Ausführung (REQUIRED_BYTES) das in maximumBytesBilled (LIMIT_BYTES) konfigurierte Byte-Limit überschreitet. BigQuery bricht den Job vor der Ausführung ab und berechnet die Abfrage nicht.

Da bei On-Demand-Preisen ein Minimum von 10 MB (10,485,760 Byte) pro referenzierter Tabelle erzwungen wird und bei der Schätzung vor der Ausführung für geclusterte Tabellen eine Obergrenze für alle übereinstimmenden Partitionen berechnet wird, bevor das Cluster-Pruning erfolgt, kann REQUIRED_BYTES höher sein als die tatsächlichen Byte, die beim Ausführen der Abfrage gescannt werden.

Führen Sie einen der folgenden Schritte aus, um das Problem zu lösen:

• Geschätzte Byte mit einem Probelauf ansehen Führen Sie einen Probelauf (bq query --dry_run in der bq-Befehlszeile oder configuration.dryRun = true in der API) aus oder prüfen Sie die Abfragevalidierung in der Cloud de Confiance Console, um totalBytesProcessed vor dem Ausführen der Abfrage zu prüfen.
• Optimieren Sie die Abfrage, um weniger Byte zu scannen. Wählen Sie nur die Spalten aus, die für Ihre Abfrage erforderlich sind, anstatt SELECT * auszuführen, und filtern Sie nach partitionierten Spalten, damit BigQuery Partitionen während der Schätzung vor der Ausführung bereinigen kann. Durch das Filtern nach geclusterten Spalten werden die tatsächlich abgerechneten Byte bei der Ausführung der Abfrage reduziert. Die vor der Ausführung geschätzte Obergrenze, die mit maximumBytesBilled verglichen wird, wird jedoch nicht reduziert. Weitere Informationen finden Sie unter Datenverarbeitung reduzieren.
• Erhöhen Sie das Limit für maximumBytesBilled. Legen Sie das Byte-Limit maximumBytesBilled auf einen Wert fest, der mindestens dem in der Fehlermeldung angegebenen Wert REQUIRED_BYTES entspricht. Verwenden Sie dazu Maximal abgerechnete Byte (unter Abfrageeinstellungen > Erweiterte Optionen) in der Cloud de Confiance -Konsole, das Flag --maximum_bytes_billed in der bq-Befehlszeile oder das Jobkonfigurationsattribut configuration.query.maximumBytesBilled in der API.

Die Abfrageantwort ist zu groß

Fehlerstring: responseTooLarge

Dieser Fehler tritt auf, wenn die Ergebnisse Ihrer Abfrage die maximale Antwortgröße überschreiten oder wenn eine einzelne Zeile das Zeilengrößenlimit der REST API überschreitet.

Einige Abfragen werden in mehreren Phasen ausgeführt. Dieser Fehler tritt auf, wenn eine Phase eine zu große Antwortgröße zurückgibt, auch wenn das Endergebnis kleiner als das Maximum ist. Dieser Fehler tritt häufig auf, wenn Abfragen eine ORDER BY-Klausel verwenden. Manchmal lässt sich das Problem durch Entfernen der ORDER BY-Klausel oder durch Hinzufügen einer LIMIT-Klausel beheben. Damit große Ergebnisse keine Probleme verursachen, geben Sie in der Jobkonfiguration eine Zieltabelle an. Bei Legacy-SQL-Abfragen müssen Sie außerdem das Attribut configuration.query.allowLargeResults auf true festlegen. Weitere Informationen finden Sie unter Große Abfrageergebnisse schreiben.

Größenbeschränkung für einzeilige Antworten überschritten

Fehlerstrings:

• Response too large to return. Message before conversion exceeds max row limit, limit: LIMIT actual: ACTUAL
• Response too large to return. single row too big to return due to byte limit, actual: ACTUAL limit: LIMIT

Dieser HTTP-403 Forbidden-Fehler (reason: responseTooLarge) tritt auf, wenn Sie Abfrageergebnisse oder Tabellenzeilen mit den REST API-Methoden jobs.getQueryResults oder tabledata.list lesen (einschließlich der Anzeige von Ergebnissen in der Cloud de Confiance Console oder im bq-Befehlszeilentool) und eine einzelne nicht verschachtelte, serialisierte Zeile die maximale Zeilengröße überschreitet, die vom REST-Paginierungsendpunkt unterstützt wird (20 MB für jobs.getQueryResults oder 100 MB für tabledata.list). Dies geschieht häufig bei Tabellen mit breiten Schemas, tief verschachtelten wiederholten ARRAY- oder STRUCT-Feldern oder großen STRING- oder BYTES-Werten.

Wenn Sie Zeilen lesen möchten, die die Größenbeschränkungen der REST API überschreiten, haben Sie folgende Möglichkeiten:

• BigQuery Storage Read API verwenden Lesen Sie die Tabelle oder die temporäre Abfragezieltabelle mit der Storage Read API, die Daten im binären Apache Arrow- oder Avro-Format streamt und Lesevorgänge mit hohem Durchsatz für große und komplexe Zeilenstrukturen unterstützt.
• Exportieren Sie die Tabelle nach Cloud Storage. Exportieren Sie die Tabelle oder die Abfrageergebnisse mit einer EXPORT DATA-Anweisung oder einem Extraktionsjob (z. B. im Avro-, Parquet- oder JSON-Format) nach Cloud Storage und lesen Sie die exportierten Dateien aus Cloud Storage.
• Projizieren oder aggregieren Sie weniger Spalten. Anstatt SELECT * auszuführen, wählen Sie nur die spezifischen Spalten oder Unterfelder aus, die für Ihre Anwendung erforderlich sind, oder heben Sie die Verschachtelung wiederholter Arrays in Ihrer Abfrage auf, damit die einzelnen Ausgabezeilen unter dem Größenlimit bleiben.

Erforderlicher Parameter fehlt

Fehlerstring: Required parameter is missing: PARAMETER_NAME

Dieser HTTP-400 Bad Request-Fehler (reason: required) ist ein API-Validierungsfehler vor der Ausführung, der auftritt, wenn ein erforderliches Feld in einer API-Anfragenutzlast oder URL nicht angegeben ist oder wenn ein erforderliches Attribut für ein Konfigurationsobjekt der Clientbibliothek null oder None ist.

So beheben Sie diesen Fehler:

• Sehen Sie sich die REST API-Referenz an. Prüfen Sie den PARAMETER_NAME in der Fehlermeldung und die erforderlichen Anfrage- und Suchparameter für die Methode in der BigQuery REST API-Referenz, um sicherzustellen, dass Ihr Code alle erforderlichen Felder ausfüllt.
• Parameter der Clientbibliothek prüfen Wenn Sie eine BigQuery-Clientbibliothek (z. B. die Java- oder Python-Clientbibliothek) verwenden, finden Sie in der Dokumentation zur Clientbibliothek die erforderlichen Parameter für die Methode, die Sie aufrufen.
• Prüfen Sie das Konfigurationsobjekt, bevor Sie die API aufrufen. Verwenden Sie einen Debugger oder ein Logbericht, um das Job- oder Anfragekonfigurationsobjekt unmittelbar vor der Ausführung des API-Aufrufs zu prüfen. Suchen Sie nach None- oder null-Werten, die erforderlichen Attributen wie destinationTable zugewiesen sind.

Reservierung nicht gefunden oder Slots fehlen

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, die Reservierung inaktive Slots verwenden lassen, eine andere Reservierung verwenden oder die Zuweisung entfernen und die Abfrage on demand 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 nicht im angegebenen Dataset oder in der angegebenen Region 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.
• Achten Sie darauf, dass die Tabelle während der Ausführung des Jobs nicht gelöscht und neu erstellt wurde. Andernfalls kann dieser Fehler durch eine unvollständige Metadatenweitergabe 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 mutierenden DML-Anweisungen im Status PENDING in einer Warteschlange für eine einzelne Tabelle überschreiten. Dieser Fehler tritt normalerweise auf, wenn Sie DML-Jobs für eine einzelne Tabelle schneller senden, als BigQuery sie verarbeiten kann.

Wenn Sie die Jobs mit dem Status PENDING prüfen möchten, die die Warteschlange füllen, sowie die Jobs mit dem Status RUNNING, die möglicherweise verhindern, dass sie aus der Warteschlange entfernt werden, fragen Sie die Ansicht INFORMATION_SCHEMA.JOBS ab:

SELECT
  project_id,
  job_id,
  creation_time,
  user_email,
  statement_type,
  state
FROM
  `region-us`.INFORMATION_SCHEMA.JOBS
WHERE
  statement_type IN ('UPDATE', 'DELETE', 'MERGE')
  AND state IN ('RUNNING', 'PENDING')
ORDER BY
  creation_time DESC;

Eine mögliche Lösung besteht darin, mehrere kleinere DML-Vorgänge in größeren, aber weniger Jobs zu gruppieren, z. B. durch Batch-Updates 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.

Fehler 403: Kontingent überschritten

Fehlerstring: 403 Quota exceeded: Your table exceeded quota for total number of DML jobs writing to a table, pending + running.

Dieser Fehler tritt auf, wenn die Gesamtzahl der DML-Jobs (INSERT, UPDATE, DELETE und MERGE), die in eine einzelne Tabelle schreiben, sowohl im Status PENDING als auch im Status RUNNING das Nebenläufigkeitskontingent der Tabelle überschreitet.

Während der Fehler limit is 20 die Warteschlange PENDING für mutierende DML-Anweisungen (UPDATE, DELETE und MERGE) einschränkt, gilt der Fehler 403 Quota exceeded für die Gesamtzahl aller DML-Jobs (INSERT plus mutierende DML), die gleichzeitig in eine Tabelle schreiben. Da mutierende DML bereits durch das Warteschlangenlimit von 20 Jobs begrenzt ist, tritt dieser 403-Kontingentfehler am häufigsten auf, wenn Sie zu viele gleichzeitige INSERT-Abfragen für eine einzelne Tabelle senden. So beheben Sie diesen Fehler:

• Reservierungsslots erhöhen: Erhöhen Sie die Anzahl der Slots in Ihrer Reservierung, damit Jobs schneller abgeschlossen werden und die Job-Nebenläufigkeit reduziert wird. Dadurch wird die Anzahl der ausstehenden Jobs in der Warteschlange reduziert und das Limit wird nicht erreicht.
• Workflow-Orchestrierung optimieren: Begrenzen Sie die Anzahl gleichzeitiger DML-Aufgaben in Ihrem Orchestrierungstool, um zu vermeiden, dass die Parallelitätslimits auf Tabellenebene überschritten werden (einschließlich hochfrequenter INSERT-Abfragen, die auf dieselbe Tabelle abzielen).
• DML-Vorgänge im Batch verarbeiten: Kombinieren Sie mehrere kleinere DML-Anweisungen zu weniger, größeren Anweisungen, um die Gesamtzahl der Jobs in der Warteschlange für die Tabelle zu reduzieren.

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 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. Dies kann bis zu 24 Stunden dauern. Während dieser Zeit schlagen andere Versuche, eine mutierende DML-Anweisung für die Tabelle auszuführen, fehl.

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, der eine mutierende DML-Anweisung für die Tabelle ausgeführt hat. Beenden Sie dann diese Sitzung.

Fehler 412: Der Job verweist auf eine Tabelle, die zu einem Failover-Dataset gehört

Fehlerstring: Error 412: The job references a table that belongs to a failover dataset in the ... region (PROJECT_ID:DATASET_ID). However, only jobs that run on a reservation with the "ENTERPRISE_PLUS" edition can modify or write to failover datasets. Please also make sure that the job that is writing to the failover dataset is running in the current primary location.

Das bedeutet, dass der Job entweder nicht unter einer BigQuery Enterprise Plus-Version ausgeführt wurde oder in einer anderen Region als dem primären Standort des Failover-Datasets ausgeführt wurde. Weitere Informationen finden Sie unter Verwaltete Notfallwiederherstellung.

Fehler beim Laden der Ansicht, wenn im Cache gespeicherte Ergebnisse verwendet werden

Fehlerstring: BigQuery data export: There was an error loading this view. IAM setPolicy failed for Dataset <PROJECT_ID>. One or more users named in the policy do not belong to a permitted customer.

Dieser Fehler weist darauf hin, dass Ihren Google Workspace-Kundennummern in der Einschränkung der Organisationsrichtlinie kein Zugriff gewährt wurde. Informationen zur Verwendung der Einschränkung iam.allowedPolicyMemberDomains finden Sie unter Einschränkung iam.allowedPolicyMemberDomains verwenden, um die domaineingeschränkte Freigabe zu implementieren.

Legacy-SQL-Fehler

Die folgenden Fehler können bei der Verwendung von Legacy-SQL auftreten.

Cannot be queried with legacy SQL

Fehlerstring: cannot be queried with legacy SQL. Please consider switching to standard SQL

Dieser Fehler kann in einem der folgenden Szenarien auftreten:

• Die Abfrage wurde in Standard-SQL geschrieben, aber die Option zur expliziten Verwendung von Legacy-SQL wurde bereitgestellt. Achten Sie darauf, dass Sie Ihre Abfrage mit Standard-SQL ausführen. Folgen Sie dazu der öffentlichen Dokumentation, indem Sie beispielsweise --use_legacy_sql=false mit dem bq-Befehlszeilentool angeben.

• Sie versuchen, eine Tabelle mit Sortierung mithilfe von Legacy-SQL abzufragen, was nicht unterstützt wird.

Tabellen mit umbenannten Spalten können nicht mit Legacy-SQL abgefragt werden.

Fehlerstring: Table project:dataset.table with renamed columns cannot be queried with legacy SQL. Please consider switching to standard SQL or dropping column my_column

Dieser Fehler tritt auf, wenn Sie eine Tabelle mit einer umbenannten Spalte mit Legacy-SQL abfragen. Verwenden Sie stattdessen Standard-SQL.

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 Sie die Abfrage ausführen, 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 Ihre Abfrage verweist. 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 anhand des Dataset-Standorts prüfen.

Beachten Sie beim Beheben dieser Fehler Folgendes:

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

• 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 die Abfrage verweist.

• 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 Gewähren von Zugriff auf eine Tabelle oder Ansicht finden Sie unter Zugriff auf eine Tabelle oder Ansicht gewähren.

Berechtigung bigquery.reservations.use für Reservierung verweigert

Fehlerstring:

• Access Denied: Reservation projects/project/locations/region/reservations/reservation_name: Permission bigquery.reservations.use denied on reservation projects/project/locations/region/reservations/reservation_name (or it may not exist)

Dieser Fehler tritt auf, wenn eine Abfrage mit der SET @@reservation-Anweisung einer bestimmten Reservierung zugewiesen wird und dem Nutzer oder Dienstkonto die Berechtigung bigquery.reservations.use fehlt. Sie können den Fehler in Cloud Logging oder auf der BigQuery-Jobseite prüfen, um festzustellen, welches Hauptkonto versucht hat, diesen Vorgang auszuführen.

Andere Access Denied-Fehler

Fehlerstrings:

• Access Denied: Dataset project_id:dataset_id: Permission bigquery.datasets.get denied on dataset project_id:dataset_id (or it may not exist).
• Access Denied: Dataset project_id:dataset_id: Permission bigquery.datasets.update denied on dataset project_id:dataset_id (or it may not exist).
• Access Denied: BigQuery BigQuery: User does not have permission to access data protected by policy tag

Wenn Sie allgemeine Access Denied-Fehler in BigQuery beheben möchten, verwenden Sie Policy Analyzer, um festzustellen, welchen Zugriff ein Hauptkonto auf eine Ressource hat.

Geben Sie in Policy Analyzer die BigQuery-Ressource an, auf die Sie zugreifen möchten (z. B. //bigquery.googleapis.com/projects/YOUR_PROJECT/datasets/YOUR_DATASET/tables/YOUR_TABLE), und die E-Mail-Adresse des Nutzers oder Dienstkontos, das den Fehler Access Denied als Hauptkonto erhält. Die Analyse zeigt die Berechtigungen des Hauptkontos für die Ressource, die Sie mit den fehlenden Berechtigungen in der Fehlermeldung vergleichen können.

Zielverschlüsselung wird für Skripts nicht unterstützt

Fehlerstring: configuration.query.destinationEncryptionConfiguration cannot be set for scripts

Dieser Fehler tritt auf, wenn versucht wird, die Zielverschlüsselungskonfiguration für einen BigQuery-Skriptjob festzulegen, was nicht unterstützt wird.

Zugriff durch Organisationsrichtlinie verweigert

Fehlerstring: IAM setPolicy failed for Dataset DATASET: Operation denied by org policy on resource.

Dieser Fehler tritt auf, wenn eine Organisationsrichtlinie verhindert, dass das Hauptkonto eine BigQuery-Ressource abfragt. Mit dem Organisationsrichtliniendienst können Sie Einschränkungen für unterstützte Ressourcen in der Organisationshierarchie erzwingen.

Wenn das Hauptkonto Zugriff auf die Ressource haben soll, müssen Sie die verfügbaren VPC-Fehlerbehebungstools verwenden, um das Problem mit Ihrer Organisationsrichtlinie zu diagnostizieren.

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. This query used CPU_SECONDS_USED CPU seconds but would charge only ANALYSIS_MEGABYTES_BILLEDM Analysis bytes. This exceeds the ratio supported by the on-demand pricing model. Please consider moving this workload to a capacity-based pricing model, which does not have this limit. CPU_SECONDS_USED CPU seconds were used, and this query must use less than CPU_SECONDS_LIMIT CPU seconds.

Dieser Fehler (billingTierLimitExceeded) tritt auf, wenn eine Abfrage mit On-Demand-Preisen das Limit für die maximale CPU-Nutzung pro gescannten Daten von etwa 256 CPU-Sekunden pro MiB gescannter Daten überschreitet. Dies geschieht, wenn eine On-Demand-Abfrage CPU-intensive Vorgänge wie uneingeschränkte CROSS JOIN-Vorgänge, ungenaue Join-Bedingungen, komplexe reguläre Ausdrücke, nicht partitionierte analytische Fensterfunktionen oder rechenintensive JavaScript-UDFs für eine relativ kleine Menge gescannter Daten ausführt.

Führen Sie einen der folgenden Schritte aus, um diesen Fehler zu beheben:

• Optimieren Sie die Abfrage. Refaktorieren Sie Ihr SQL, um den Rechenaufwand im Verhältnis zu den gescannten Daten zu reduzieren. Entfernen Sie dazu beispielsweise unbeabsichtigte kartesische Produkte (CROSS JOIN-Vorgänge ohne Filterung), ersetzen Sie ungenaue Join-Prädikate, vereinfachen Sie komplexe reguläre Ausdrücke, fügen Sie PARTITION BY-Klauseln zu Fensterfunktionen über große nicht partitionierte Fenster hinzu oder optimieren Sie JavaScript-UDFs. Weitere Informationen finden Sie unter Anti-SQL-Muster vermeiden, Einführung in die Optimierung der Abfrageleistung und Fehlerbehebung bei Ressourcenüberschreitungen.
• Zu kapazitätsbasierten Preisen wechseln Führen Sie die Arbeitslast mit kapazitätsbasierten Preisen (Slots) aus. Bei kapazitätsbasierten Preisen unterliegen Abfragen nicht dem On-Demand-Limit für das CPU-zu-Byte-Verhältnis.

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 Stapelspeicherplatz

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 beim Parsen in Funktionsaufrufe übersetzt. Beispiel: Ein Ausdruck mit wiederholten Verkettungsoperatoren wie A || B || C || ... wird zu CONCAT(A, CONCAT(B, CONCAT(C, ...))).

Schreiben Sie Ihre Abfrage um, um die Anzahl der Verschachtelungen zu reduzieren, um diesen Fehler zu beheben.

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.

Dies kann bei ORDER BY ... LIMIT ... OFFSET ...-Abfragen passieren. Aufgrund von Implementierungsdetails kann die Sortierung auf einer einzelnen Recheneinheit erfolgen, die möglicherweise nicht genügend Arbeitsspeicher hat, wenn sie zu viele Zeilen verarbeiten muss, bevor LIMIT und OFFSET angewendet werden, insbesondere bei einem großen OFFSET.

Vermeiden Sie große OFFSET-Werte in ORDER BY ... LIMIT-Abfragen, um diesen Fehler zu beheben. 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

TensorFlow-Worker hat keinen Arbeitsspeicher mehr

Fehlerstring: Resources exceeded during query execution: TensorFlow worker out of memory.

Modelle, die das Speicherlimit (normalerweise 250 MB) überschreiten, insbesondere bei Verwendung ressourcenintensiver Funktionen wie ML.EXPLAIN_PREDICT, können diesen Fehler auslösen.

So beheben Sie diesen Fehler:

1. Remote-Modelle der Gemini Enterprise Agent Platform verwenden: Wenn Modelle die Arbeitsspeicherlimits überschreiten, stellen Sie Ihr Modell auf der Agent Platform bereit. Folgen Sie dazu den Schritten im Vertex AI SDK für Python, um ein Modell bereitzustellen, und greifen Sie dann über Remote-Modelle darauf zu. Dadurch werden die Speicheranforderungen auf eine dedizierte Agent Platform-Infrastruktur ausgelagert.

2. Modell optimieren: Reduzieren Sie den RAM-Bedarf des Modells durch Vereinfachung der Architektur, Quantisierung oder Pruning.

3. Weniger rechenintensive Funktionen verwenden: Wenn der Fehler während eines ML.EXPLAIN_PREDICT-Aufrufs auftritt, versuchen Sie, den Job mit ML.PREDICT auszuführen, um festzustellen, ob das Modell ohne den zusätzlichen Aufwand von Erklärbarkeitsfunktionen ausgeführt werden kann.

4. Größe der Eingabedaten analysieren: Große einzelne Zeilen können dazu beitragen, dass der Arbeitsspeicher erschöpft ist. Prüfen Sie die Größe der größten Zeilen mit:

   SELECT BYTE_LENGTH(TO_JSON_STRING(t)) AS row_size
   FROM your_table AS t
   ORDER BY row_size DESC
   LIMIT 10

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.

Wenn Sie das On-Demand-Preismodell verwenden, sind Sie auf maximal 2.000 Slots beschränkt. Wenn Sie die Anzahl der Slots erhöhen möchten, müssen Sie zu einem kapazitätsbasierten Preismodell wechseln.

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 überwachen, indem Sie das Feld query_info.resource_warning in der Ansicht INFORMATION_SCHEMA.JOBS verwenden. 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 Abfragen:

• 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 für Ihre 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 Ihre Abfrage tief verschachtelte Ansichten und eine WITH-Klausel verwendet hat, kann dies zu einem exponentiellen Anstieg der Komplexität führen, wodurch die Limits 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 reduzieren, oder fügen Sie eine PARTITION BY-Klausel hinzu, falls keine vorhanden ist.

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Abfrageleistung optimieren
• Weitere Informationen zur Ressourcenwarnung
• Zustand, Ressourcennutzung und Jobs überwachen

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:

• Avro-Eingabedateianforderungen
• Anforderungen an Parquet-Eingabedateien

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“-Eintrags-IP aufzulösen. Achten Sie darauf, dass diese IP-Adresse in Ihren Firewall-Einstellungen nicht blockiert wird.

Im Allgemeinen empfehlen wir, Google-DNS-Namen auf die Zulassungsliste zu setzen. Die IP-Bereiche, die in den Dateien https://documentation.s3ns.fr/ipranges/goog.json und https://documentation.s3ns.fr/ipranges/cloud.json freigegeben sind, ändern sich häufig. Daher empfehlen wir, stattdessen Google-DNS-Namen auf die Zulassungsliste zu setzen. Hier ist eine Liste gängiger 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

Führen Sie auf Ihrem Clientcomputer einen traceroute-Befehl aus, um alle Pakethops zwischen dem Client und dem Google Front End (GFE) zu identifizieren. Dadurch kann der Server hervorgehoben werden, 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 ein Zeitüberschreitungsproblem auf Google-Seite vorliegt, wird die Anfrage bis zum GFE weitergeleitet.

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

PCAP-Datei generieren und Firewall oder Proxy analysieren

Erstellen Sie eine Paketerfassungsdatei (PCAP) und analysieren Sie sie, um sicherzustellen, dass die Firewall oder der Proxy keine Pakete an Google-IP-Adressen herausfiltert und Pakete das GFE erreichen können.

Hier ist ein Beispielbefehl, der mit dem tcpdump-Tool 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 verwerfen können, z. B. wenn DDoS-Trafficmuster erkannt werden oder wenn die Instanz mit Load Balancing herunterskaliert 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 Anfrage mit Zeitüberschreitung abfangen und die Anfrage an den DNS-Endpunkt wiederholen. Verwenden Sie dieselbe IP-Adresse erst, wenn die Anfrage erfolgreich war, da sich die IP-Adresse möglicherweise geändert hat.

Wenn Sie ein Problem mit konsistenten Zeitüberschreitungen auf Google-Seite festgestellt haben, bei denen Wiederholungsversuche nicht helfen, wenden Sie sich an Cloud Customer Care. Fügen Sie eine aktuelle PCAP-Datei hinzu, die mit einem Tool zur Paketerfassung wie tcpdump generiert wurde.

Nächste Schritte

• Statistiken zur Abfrageleistung abrufen.
• Weitere Informationen finden Sie unter Abfrageleistung verbessern.
• Prüfen Sie die Kontingente und Limits für Abfragen.
• Weitere Informationen zu anderen BigQuery-Fehlermeldungen