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

Berücksichtigen Sie bei der Fehlerbehebung bei langsamer Abfrageleistung die folgenden häufigen Ursachen:

  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 Ursachen sind Konflikte um Abfrageslots oder ein unzureichendes Zufallsmix-Kontingent. Weitere Informationen zu den einzelnen mit Abfragen verbundenen Leistungsproblemen und zu möglichen Lösungen finden Sie unter Statistiken zur Abfrageleistung interpretieren.

  3. 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 einem anderen Abfragejob vergleichen, der in einer akzeptablen Zeit abgeschlossen wurde. Wenn die Anzahl der verarbeiteten Bytes zwischen den beiden Abfragen stark abweicht, war die Abfrage möglicherweise aufgrund eines großen Datenvolumens langsam. Informationen zum Optimieren von Abfragen für große Datenmengen finden Sie unter Abfrageleistung 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.

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.

Um diesen Fehler zu beheben, muss die letzte Datei im Ladevorgang alphabetisch sortiert sein und die Übermenge (Union) 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 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 raw access permissions 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:

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 Speicherort in der Anfrage nicht mit dem Speicherort des Datasets übereinstimmt.

Geben Sie in der Abfrage den Speicherort des Datensatzes an oder prüfen Sie, ob der Datensatz 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.

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 einreichen, als BigQuery verarbeiten kann.

Eine mögliche Lösung besteht darin, mehrere kleinere DML-Vorgänge in größere, 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.

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.

Dieser Fehler tritt auf, 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. Außerdem benötigen Sie die Berechtigung bigquery.tables.getData für alle Tabellen und Ansichten, auf die Ihre Abfrage verweist.

Dieser Fehler kann auch auftreten, wenn die Tabelle in der abgefragten Region nicht vorhanden ist, z. B. asia-south1. Zum Abfragen von Ansichten benötigen Sie diese Berechtigung auch für alle zugrunde liegenden Tabellen und Ansichten. Weitere Informationen zu den erforderlichen Berechtigungen finden Sie unter Abfrage ausführen.

Beachten Sie Folgendes, wenn Sie diesen Fehler beheben:

  • Dienstkonten: Dienstkonten müssen die Berechtigung bigquery.jobs.create für das Projekt haben, aus dem sie ausgeführt werden.

  • Benutzerdefinierte Rollen: Benutzerdefinierte IAM-Rollen müssen die Berechtigung bigquery.jobs.create enthalten, die explizit in der entsprechenden Rolle enthalten ist.

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

So gewähren Sie Zugriff auf die Tabelle:

So gewähren Sie einem Prinzipal die Berechtigung zum Zugriff auf eine Tabelle:

  1. Rufen Sie die Seite BigQuery auf.

    BigQuery aufrufen

  2. Suchen Sie in Explorer die Tabelle, auf die Sie zugreifen möchten. Wählen Sie Aktionen anzeigen und dann Freigeben aus und klicken Sie dann auf Berechtigungen verwalten.

  3. Geben Sie unter Hauptkonten hinzufügen die Namen der Nutzer, Gruppen, Domains oder Dienstkonten ein, die Sie hinzufügen möchten.

  4. Wählen Sie unter Rollen zuweisen die Berechtigung bigquery.jobs.create aus. Alternativ können Sie die Rolle roles/bigquery.jobUser im Projekt zuweisen, aus dem die Abfrage erfolgt.

  5. Klicken Sie auf Speichern.

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.

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.

Mit dem Feld query_info.resource_warning in der Ansicht INFORMATION_SCHEMA.JOBS können Sie Abfragen proaktiv überwachen, die sich der Komplexitätsgrenze nähern. 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.
  • 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 Ihre Abfrage verschachtelte Ansichten und eine WITH-Klausel verwendet, kann dies zu einer exponentiellen Steigerung der Komplexität führen und die Limits erreichen.
  • Ersetzen Sie keine temporären Tabellen durch WITH-Klauseln. Die 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, lässt sich die Komplexität reduzieren.
  • Vermeiden Sie die Verwendung von UNION ALL-Abfragen.

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:

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. Achten Sie darauf, dass diese IP-Adresse nicht in Ihren Firewalleinstellungen blockiert ist.

Wir empfehlen generell, Google-DNS-Namen auf die Zulassungsliste zu setzen. Die IP-Bereiche, die in den Dateien https://www.gstatic.com/ipranges/goog.json und https://www.gstatic.com/ipranges/cloud.json enthalten sind, ändern sich häufig. Wir empfehlen daher, stattdessen Google-DNS-Namen auf die Zulassungsliste zu setzen. Hier ist eine Liste gängiger DNS-Namen, die Sie der Zulassungsliste hinzufügen sollten:

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

Proxy oder Firewall identifizieren, die Pakete ablehnen

Um alle Paket-Hops zwischen dem Client und dem Google Front End (GFE) zu ermitteln, führen Sie auf Ihrem Clientcomputer einen traceroute-Befehl aus. Dadurch wird der Server hervorgehoben, der Pakete an das GFE verwirft. 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 auf Google-Seite ein Zeitüberschreitungsproblem gibt, wird die Anfrage bis zum GFE weitergeleitet.

Wenn die Pakete die 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 Paket-Capture-Datei (PCAP) und analysieren Sie die Datei, um sicherzustellen, dass die Firewall oder der Proxy keine Pakete an Google-IP-Adressen herausfiltert und Pakete die GFE erreichen lassen.

Hier ist ein Beispiel für einen Befehl, der mit dem Tool tcpdump ausgeführt werden kann:

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

Wiederholungen für vorübergehende Verbindungsprobleme einrichten

Es gibt Situationen, in denen GFE-Load Balancer Verbindungen von einer Client-IP-Adresse unterbrechen. Das ist beispielsweise der Fall, wenn DDoS-Trafficmuster erkannt werden oder die Load Balancer-Instanz herunterskaliert wird, was dazu führen kann, dass die Endpunkt-IP 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 noch einmal wiederholen. Verwenden Sie nicht dieselbe IP-Adresse, bis die Anfrage erfolgreich war, da sich die IP-Adresse möglicherweise geändert hat.

Wenn Sie ein Problem mit regelmäßigen Zeitüberschreitungen auf Google-Seite festgestellt haben, bei dem Wiederholungen nicht helfen, wenden Sie sich an den Cloud-Kundenservice. Hängen Sie dabei eine neue PCAP-Datei an, die Sie mit einem Paketerfassungstool wie tcpdump erstellt haben.

Nächste Schritte