Ansicht JOBS

Die Ansicht INFORMATION_SCHEMA.JOBS enthält Metadaten nahezu in Echtzeit zu allen BigQuery-Jobs im aktuellen Projekt.

Hinweis :Die Ansichtsnamen INFORMATION_SCHEMA.JOBS und INFORMATION_SCHEMA.JOBS_BY_PROJECT sind Synonyme und können austauschbar verwendet werden.

Erforderliche Rolle

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle BigQuery-Ressourcenbetrachter (roles/bigquery.resourceViewer) für Ihr Projekt zuzuweisen. Diese Rolle enthält die Berechtigung, die Sie zum Abfragen der Ansicht INFORMATION_SCHEMA.JOBS benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierte Rolle enthält die Berechtigung bigquery.jobs.listAll, die zum Abfragen der INFORMATION_SCHEMA.JOBS-Ansicht erforderlich ist.

Sie können diese Berechtigung auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Weitere Informationen zu BigQuery-Berechtigungen finden Sie unter Zugriffssteuerung mit IAM.

Schema

Die zugrunde liegenden Daten werden nach der Spalte creation_time partitioniert und nach project_id und user_email geclustert. Die query_info-Spalte enthält zusätzliche Informationen zu Ihren Abfragejobs.

Die Ansicht INFORMATION_SCHEMA.JOBS hat das folgende Schema:

Spaltenname	Datentyp	Wert
bi_engine_statistics	RECORD	Wenn das Projekt für die Verwendung der BI Engine-SQL-Schnittstelle konfiguriert ist, dann enthält dieses Feld BiEngineStatistics. Andernfalls NULL.
cache_hit	BOOLEAN	Ob die Abfrageergebnisse dieses Jobs aus einem Cache stammen. Wenn Sie einen Abfragejob mit mehreren Anweisungen haben, ist cache_hit für Ihre übergeordnete Abfrage NULL.
creation_time	TIMESTAMP	(Partitionierungsspalte) Erstellungszeit dieses Jobs. Die Partitionierung basiert auf der UTC-Zeit dieses Zeitstempels.
destination_table	RECORD	Zieltabelle für etwaige Ergebnisse.
end_time	TIMESTAMP	Die Endzeit dieses Jobs in Millisekunden seit der Epoche. Dieses Feld gibt den Zeitpunkt an, zu dem der Job in den Status DONE wechselt.
error_result	RECORD	Details zu Fehlern als Objekte vom Typ ErrorProto.
job_creation_reason.code	STRING	Gibt den allgemeinen Grund an, warum ein Job erstellt wurde. Folgende Werte sind möglich: REQUESTED: Die Erstellung eines Jobs wurde angefordert. LONG_RUNNING: Die Abfrageanfrage hat länger als das systemdefinierte Zeitlimit gedauert, das im Feld „timeoutMs“ in der QueryRequest angegeben ist. Daher wurde er als lang andauernder Vorgang betrachtet, für den ein Job erstellt wurde. LARGE_RESULTS: Die Ergebnisse der Abfrage passen nicht in die Inline-Antwort. OTHER: Das System hat festgestellt, dass die Abfrage als Job ausgeführt werden muss.
job_id	STRING	Die ID des Jobs, falls ein Job erstellt wurde. Andernfalls die Abfrage-ID einer Abfrage, die den Modus für kurze Abfragen verwendet. Beispiel: bquxjob_1234.
job_stages	RECORD	Abfragephasen des Jobs. Hinweis: Die Werte dieser Spalte sind leer, wenn Sie Abfragen aus Tabellen mit Zugriffsrichtlinien auf Zeilenebene durchgeführt haben. Weitere Informationen finden Sie unter Best Practices für die Sicherheit auf Zeilenebene in BigQuery.
job_type	STRING	Typ des Jobs. Kann QUERY, LOAD, EXTRACT, COPY oder NULL sein. Ein NULL-Wert gibt einen internen Job an, z. B. die Auswertung einer Anweisung eines Skriptjobs oder die Aktualisierung einer materialisierten Ansicht.
labels	RECORD	Array aus Labels, die als Schlüssel/Wert-Paare auf den Job angewendet werden.
parent_job_id	STRING	ID des übergeordneten Jobs, sofern vorhanden.
priority	STRING	Die Priorität dieses Jobs Zulässige Werte: INTERACTIVE und BATCH.
project_id	STRING	(Clustering-Spalte) Die ID des Projekts.
project_number	INTEGER	Die Nummer des Projekts.
query	STRING	SQL-Abfragetext. Nur die Ansicht JOBS_BY_PROJECT enthält die Abfragespalte.
referenced_tables	RECORD	Array von Tabellen, auf die der Job verweist. Wird nur für Abfragejobs ausgefüllt, die keine Cache-Treffer sind.
reservation_id	STRING	Name der primären Reservierung, die diesem Job zugewiesen ist, im Format RESERVATION_ADMIN_PROJECT:RESERVATION_LOCATION.RESERVATION_NAME. In dieser Ausgabe gilt: RESERVATION_ADMIN_PROJECT: Name des Google Cloud-Projekts, das die Reservierung verwaltet RESERVATION_LOCATION: der Standort der Reservierung RESERVATION_NAME: der Name der Reservierung
edition	STRING	Die mit der Reservierung verknüpfte Edition, die diesem Job zugewiesen ist. Weitere Informationen zu Editionen finden Sie unter Einführung in BigQuery-Editionen.
session_info	RECORD	Details zur Sitzung, in der dieser Job ausgeführt wurde, sofern vorhanden.
start_time	TIMESTAMP	Die Startzeit dieses Jobs in Millisekunden seit der Epoche. Dieses Feld gibt den Zeitpunkt an, zu dem der Job vom Status PENDING in RUNNING oder DONE wechselt.
state	STRING	Ausführungsstatus des Jobs. Gültige Statuswerte sind PENDING, RUNNING und DONE.
statement_type	STRING	Der Typ der Abfrageanweisung. Beispiel: DELETE, INSERT, SCRIPT, SELECT oder UPDATE. Eine Liste der gültigen Werte finden Sie unter QueryStatementType.
timeline	RECORD	Abfragezeitachse des Jobs. Enthält Snapshots der Abfrageausführung.
total_bytes_billed	INTEGER	Wenn das Projekt für die Verwendung von On-Demand-Preisen konfiguriert ist, enthält dieses Feld die Gesamtzahl der für den Job in Rechnung gestellten Byte. Wenn das Projekt für die Verwendung von Pauschalpreisen konfiguriert ist, werden Ihnen keine Byte in Rechnung gestellt. Dieses Feld dient nur zur Information. Hinweis: Die Werte dieser Spalte sind leer, wenn Sie Abfragen aus Tabellen mit Zugriffsrichtlinien auf Zeilenebene durchgeführt haben. Weitere Informationen finden Sie unter Best Practices für die Sicherheit auf Zeilenebene in BigQuery.
total_bytes_processed	INTEGER	Gesamtzahl der vom Job verarbeiteten Byte. Hinweis: Die Werte dieser Spalte sind leer, wenn Sie Abfragen aus Tabellen mit Zugriffsrichtlinien auf Zeilenebene durchgeführt haben. Weitere Informationen finden Sie unter Best Practices für die Sicherheit auf Zeilenebene in BigQuery.
total_modified_partitions	INTEGER	Gesamtzahl der Partitionen, die der Job geändert hat. Dieses Feld wird für LOAD- und QUERY-Jobs ausgefüllt.
total_slot_ms	INTEGER	Slotmillisekunden für den Job über seine gesamte Dauer im Status RUNNING, einschließlich Wiederholungen.
transaction_id	STRING	ID der Transaktion, in der dieser Job ausgeführt wurde (falls vorhanden). (Vorschau)
user_email	STRING	(Clustering-Spalte) E-Mail-Adresse oder Dienstkonto des Nutzers, der den Job ausgeführt hat.
query_info.resource_warning	STRING	Die Warnmeldung, die angezeigt wird, wenn die Ressourcennutzung während der Abfrageverarbeitung über dem internen Schwellenwert des Systems liegt. Bei einem erfolgreichen Abfragejob kann das resource_warning-Feld ausgefüllt sein. Mit resource_warning erhalten Sie zusätzliche Datenpunkte, um Ihre Abfragen zu optimieren und das Monitoring für Leistungstrends eines entsprechenden Abfragesatzes einzurichten. Verwenden Sie dazu query_hashes.
query_info.query_hashes.normalized_literals	STRING	Enthält die Hashes der Abfrage. normalized_literals ist ein hexadezimaler STRING-Hash, der Kommentare, Parameterwerte, UDFs und Literale ignoriert. Der Hashwert unterscheidet sich, wenn sich die zugrunde liegenden Ansichten ändern oder wenn die Abfrage implizit auf Spalten wie SELECT * verweist und sich das Tabellenschema ändert. Dieses Feld wird bei erfolgreichen GoogleSQL-Abfragen angezeigt, die keine Cache-Treffer sind.
query_info.performance_insights	RECORD	Leistungsstatistiken für den Job.
query_info.optimization_details	STRUCT	Die verlaufsbasierten Optimierungen für den Job.
transferred_bytes	INTEGER	Gesamtzahl der übertragenen Byte für cloudübergreifende Abfragen, wie die cloudübergreifenden BigQuery Omni-Übertragungsjobs.
materialized_view_statistics	RECORD	Statistiken von materialisierten Ansichten, die in einem Abfragejob berücksichtigt werden. (Vorschau)

Wenn Sie INFORMATION_SCHEMA.JOBS abfragen, um eine Zusammenfassung der Kosten für Abfragejobs zu erhalten, schließen Sie die Anweisung SCRIPT aus. Andernfalls könnten einige Werte zweimal gezählt werden. Die Zeile SCRIPT enthält zusammenfassende Werte für alle untergeordneten Jobs, die im Rahmen dieses Jobs ausgeführt wurden.

Jobs mit Abfragen mit mehreren Anweisungen

Ein Abfragejob mit mehreren Anweisungen ist ein Abfragejob, bei dem die prozedurale Sprache verwendet wird. Bei Abfragejobs mit mehreren Anweisungen werden Variablen häufig mit DECLARE definiert oder es gibt Ablaufsteuerungsanweisungen wie IF oder WHILE. Wenn Sie INFORMATION_SCHEMA.JOBS abfragen, müssen Sie möglicherweise den Unterschied zwischen einem Abfragejob mit mehreren Anweisungen und anderen Jobs erkennen. Ein Abfragejob mit mehreren Anweisungen hat folgende Merkmale:

• statement_type = SCRIPT
• reservation_id = NULL
• Untergeordnete Jobs Jeder untergeordnete Job eines Abfragejobs mit mehreren Anweisungen hat eine parent_job_id, die auf den Abfragejob mit mehreren Anweisungen selbst verweist. Dazu gehören zusammenfassende Werte für alle untergeordneten Jobs, die im Rahmen dieses Jobs ausgeführt wurden. Wenn Sie daher INFORMATION_SCHEMA.JOBS abfragen, um eine Zusammenfassung der Kosten für Abfragejobs zu erhalten, sollten Sie den Anweisungstyp SCRIPT ausschließen. Andernfalls könnten einige Werte wie total_slot_ms zweimal gezählt werden.

Datenaufbewahrung

Diese Ansicht enthält aktuell ausgeführte Jobs und den Jobverlauf der letzten 180 Tage.

Bereich und Syntax

Für Abfragen dieser Ansicht muss ein Regions-Qualifier verwendet werden. In der folgenden Tabelle wird der Regionsbereich für diese Ansicht erläutert:

Ansichtsname	Ressourcenbereich	Regionsbereich
[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.JOBS[_BY_PROJECT]	auf Projektebene	REGION

Ersetzen Sie Folgendes:

Optional: PROJECT_ID: die ID Ihres Google Cloud-Projekts. Wenn keine Angabe erfolgt, wird das Standardprojekt verwendet.

REGION: ist ein beliebiger Dataset-Regionsname. Beispiel: `region-us`

Hinweis: Zum Abfragen von INFORMATION_SCHEMA-Ansichten müssen Sie einen Regions-Qualifier verwenden. Der Ort der Abfrageausführung muss mit der Region der Ansicht INFORMATION_SCHEMA übereinstimmen.

Beispiele

Wenn Sie die Abfrage für ein anderes Projekt als Ihr Standardprojekt ausführen möchten, fügen Sie die Projekt-ID im folgenden Format hinzu:

`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS

Ersetzen Sie Folgendes:

• PROJECT_ID: die ID des Projekts.
• REGION_NAME: Region für Ihr Projekt

Beispiel: `myproject`.`region-us-central1`.INFORMATION_SCHEMA.JOBS.

On-Demand-Jobnutzung mit Abrechnungsdaten vergleichen

Bei Projekten mit On-Demand-Preisen können Sie in der Ansicht INFORMATION_SCHEMA.JOBS die berechneten Kosten für einen bestimmten Zeitraum prüfen.

Bei Projekten mit kapazitätsbasierten Preisen (Slots) können Sie mit INFORMATION_SCHEMA.RESERVATIONS_TIMELINE die Rechenkosten für einen bestimmten Zeitraum prüfen.

Die folgende Abfrage liefert geschätzte tägliche Summen Ihrer in Rechnung gestellten TiB und der daraus resultierenden Kosten. Im Abschnitt Einschränkungen wird erläutert, wann diese Schätzungen möglicherweise nicht mit Ihrer Rechnung übereinstimmen.

Nur für dieses Beispiel müssen die folgenden zusätzlichen Variablen festgelegt werden. Sie können sie hier bearbeiten.

• START_DATE: das früheste Datum für die Aggregation (einschließlich).
• END_DATE: das späteste Datum für die Aggregation (einschließlich).
• PRICE_PER_TIB: der On-Demand-Preis pro TiB, der für die Rechnungsschätzung verwendet wird.

CREATE TEMP FUNCTION isBillable(error_result ANY TYPE)
AS (
  -- You aren't charged for queries that return an error.
  error_result IS NULL
  -- However, canceling a running query might incur charges.
  OR error_result.reason = 'stopped'
);

-- BigQuery hides the number of bytes billed on all queries against tables with
-- row-level security.
CREATE TEMP FUNCTION isMaybeUsingRowLevelSecurity(
  job_type STRING, tib_billed FLOAT64, error_result ANY TYPE)
AS (
  job_type = 'QUERY'
  AND tib_billed IS NULL
  AND isBillable(error_result)
);

WITH
  query_params AS (
    SELECT
      date 'START_DATE' AS start_date,  -- inclusive
      date 'END_DATE' AS end_date,  -- inclusive
  ),
  usage_with_multiplier AS (
    SELECT
      job_type,
      error_result,
      creation_time,
      -- Jobs are billed by end_time in PST8PDT timezone, regardless of where
      -- the job ran.
      EXTRACT(date FROM end_time AT TIME ZONE 'PST8PDT') billing_date,
      total_bytes_billed / 1024 / 1024 / 1024 / 1024 total_tib_billed,
      CASE statement_type
        WHEN 'SCRIPT' THEN 0
        WHEN 'CREATE_MODEL' THEN 50 * PRICE_PER_TIB
        ELSE PRICE_PER_TIB
        END AS multiplier,
    FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
  )
SELECT
  billing_date,
  sum(total_tib_billed * multiplier) estimated_charge,
  sum(total_tib_billed) estimated_usage_in_tib,
  countif(isMaybeUsingRowLevelSecurity(job_type, total_tib_billed, error_result))
    AS jobs_using_row_level_security,
FROM usage_with_multiplier, query_params
WHERE
  1 = 1
  -- Filter by creation_time for partition pruning.
  AND date(creation_time) BETWEEN date_sub(start_date, INTERVAL 2 day) AND end_date
  AND billing_date BETWEEN start_date AND end_date
  AND isBillable(error_result)
GROUP BY billing_date
ORDER BY billing_date;

Beschränkungen

• In BigQuery werden einige Statistiken für Abfragen auf Tabellen mit Sicherheit auf Zeilenebene ausgeblendet. In der bereitgestellten Abfrage wird die Anzahl der betroffenen Jobs mit jobs_using_row_level_security angegeben, aber es ist kein Zugriff auf die abrechenbare Nutzung möglich.

• Die Preise für On-Demand-Abfragen mit BigQuery ML hängen vom Typ des erstellten Modells ab. INFORMATION_SCHEMA.JOBS verfolgt nicht, welcher Modelltyp erstellt wurde. Daher wird bei der angegebenen Abfrage davon ausgegangen, dass alle CREATE_MODEL-Anweisungen die Modelltypen mit höherer Abrechnung erstellt haben.

• Für Apache Spark-Prozeduren wird ein ähnliches Preismodell verwendet. Die Kosten werden jedoch als Pay-per-Use-SKU für die BigQuery Enterprise-Version ausgewiesen. INFORMATION_SCHEMA.JOBS erfasst diese Nutzung als total_bytes_billed, kann jedoch nicht ermitteln, für welche SKU die Nutzung steht.

Durchschnittliche Slot-Auslastung berechnen

Im folgenden Beispiel wird die durchschnittliche Slot-Auslastung für alle Abfragen in den letzten sieben Tagen für ein bestimmtes Projekt berechnet. Beachten Sie, dass diese Berechnung am besten für Projekte mit gleichbleibender Slot-Nutzung im Wochenverlauf funktioniert. Wenn Ihr Projekt keine konsistente Slot-Nutzung aufweist, ist diese Zahl möglicherweise niedriger als erwartet.

Das geht so:

SELECT
  SUM(total_slot_ms) / (1000 * 60 * 60 * 24 * 7) AS avg_slots
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  -- Filter by the partition column first to limit the amount of data scanned.
  -- Eight days allows for jobs created before the 7 day end_time filter.
  creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP()
  AND job_type = 'QUERY'
  AND statement_type != 'SCRIPT'
  AND end_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP();

Hinweis: Bei Ansichtsnamen vom Typ INFORMATION_SCHEMA wird zwischen Groß- und Kleinschreibung unterschieden.

Das Ergebnis sieht etwa so aus:

+------------+
| avg_slots  |
+------------+
| 3879.1534  |
+------------+

Sie können die Nutzung einer bestimmten Reservierung mit WHERE reservation_id = "…" prüfen. Dies kann hilfreich sein, um die prozentuale Nutzung einer Reservierung über einen bestimmten Zeitraum zu ermitteln. Bei Skriptjobs meldet der übergeordnete Job auch die gesamte Slot-Nutzung seiner untergeordneten Jobs. Verwenden Sie zur Vermeidung einer doppelten Zählung WHERE statement_type != "SCRIPT", um den übergeordneten Job auszuschließen.

Wenn Sie stattdessen die durchschnittliche Slot-Auslastung für einzelne Jobs prüfen möchten, verwenden Sie total_slot_ms / TIMESTAMP_DIFF(end_time, start_time, MILLISECOND).

Zuletzt aktive Abfragen nach Abfragepriorität zählen

Im folgenden Beispiel sehen Sie die Anzahl der Abfragen, die in den letzten 7 Stunden gestartet wurden, nach Priorität (interaktiv oder Batch) gruppiert:

SELECT
  priority,
  COUNT(*) active_jobs
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 hour)
  AND job_type = 'QUERY'
GROUP BY priority;

Das Ergebnis sieht etwa so aus:

+-------------+-------------+
| priority    | active_jobs |
+-------------+-------------+
| INTERACTIVE |           2 |
| BATCH       |           3 |
+-------------+-------------+

Das Feld priority gibt an, ob eine Abfrage INTERACTIVE oder BATCH ist.

Ladejobverlauf ansehen

Im folgenden Beispiel werden alle Nutzer oder Dienstkonten aufgelistet, die einen Batch-Ladejob für ein bestimmtes Projekt gesendet haben. Da keine Zeitgrenze angegeben ist, durchsucht diese Abfrage den gesamten verfügbaren Verlauf.

SELECT
  user_email AS user,
  COUNT(*) num_jobs
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  job_type = 'LOAD'
GROUP BY
  user_email;

Hinweis: Bei Ansichtsnamen vom Typ INFORMATION_SCHEMA wird zwischen Groß- und Kleinschreibung unterschieden.

Das Ergebnis sieht etwa so aus:

+--------------+
| user         |
+--------------+
| [e-mail]  |
+--------------+
| [e-mail]  |
+--------------+

Anzahl der Ladejobs abrufen, um das verwendete tägliche Jobkontingent zu ermitteln

Im folgenden Beispiel wird die Anzahl der Jobs nach Tag, Dataset und Tabelle zurückgegeben, sodass Sie feststellen können, wie viel des täglichen Jobkontingents verwendet wird.

SELECT
    DATE(creation_time) as day,
    destination_table.project_id as project_id,
    destination_table.dataset_id as dataset_id,
    destination_table.table_id as table_id,
    COUNT(job_id) AS load_job_count
 FROM
   `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
 WHERE
    creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP()
    AND job_type = "LOAD"
GROUP BY
    day,
    project_id,
    dataset_id,
    table_id
ORDER BY
    day DESC;

Die letzten zehn fehlgeschlagenen Jobs abrufen

Im folgenden Beispiel werden die letzten zehn fehlgeschlagenen Jobs angezeigt:

SELECT
   job_id,
  creation_time,
  user_email,
   error_result
 FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY
WHERE
  error_result.reason != "Null"
ORDER BY
  creation_time DESC
LIMIT 10;

Die Antwort sollte in etwa so aussehen:

+---------------+--------------------------+------------------+-------------------------------------+
| job_id        | creation_time            | user_email       | error_result                        |
+---------------+--------------------------+------------------+-------------------------------------+
| examplejob_1  | 2020-10-10 00:00:00 UTC  | [e-mail]  | Column 'col1' has mismatched type...|
| examplejob_2  | 2020-10-11 00:00:00 UTC  | [e-mail]  | Column 'col1' has mismatched type...|
+---------------+--------------------------+------------------+-------------------------------------+

Liste mit lang andauernden Jobs abfragen

Das folgende Beispiel zeigt die Liste der lang andauernden Jobs, die länger als 30 Minuten den Status RUNNING oder PENDING haben:

SELECT
  job_id,
  job_type,
  state,
  creation_time,
  start_time,
  user_email
 FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
 WHERE
  state!="DONE" AND
  creation_time <= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 MINUTE)
ORDER BY
  creation_time ASC;

Das Ergebnis sieht etwa so aus:

+--------+----------+---------+--------------------------------+--------------------------------+------------------+
| job_id | job_type | state   | creation_time                  | start_time                     | user_email       |
+--------+----------+---------+--------------------------------+--------------------------------+------------------+
| job_1  | QUERY    | RUNNING | 2023-05-03 05:07:22.818000 UTC | 2023-05-03 05:07:22.905000 UTC | [e-mail]  |
| job_2  | QUERY    | PENDING | 2023-05-01 02:05:47.925000 UTC | 2023-05-01 02:05:47.998000 UTC | [e-mail]  |
+--------+----------+---------+--------------------------------+--------------------------------+------------------+

Abfragen, die den für kurze Abfragen optimierten Modus verwenden

Im folgenden Beispiel wird eine Liste von Abfragen angezeigt, die im optimierten Modus für kurze Abfragen ausgeführt wurden und für die BigQuery keine Jobs erstellt hat.

SELECT
 job_id,
FROM
 `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
 TIMESTAMP_TRUNC(creation_time, DAY) = '2024-06-12'
 AND job_creation_reason.code IS NULL
LIMIT 10;

Die Ergebnisse sollten so aussehen:

+------------------------------------------+
| job_id                                   |
+------------------------------------------+
| 2Lm09bHxDEsoVK8zwzWJomLHU_Ud%1910479b151 |
| j9_GVQf28jW2M1_RfTYGRPX1vq--!191047a135f | 
+------------------------------------------+

Das folgende Beispiel zeigt Informationen zu einer Abfrage, die im optimierten Modus für kurze Abfragen ausgeführt wurde und für die in BigQuery kein Job erstellt wurde.

SELECT
 job_id,
 statement_type,
 priority,
 cache_hit,
 job_creation_reason.code AS job_creation_reason_code,
 total_bytes_billed,
 total_bytes_processed,
 total_slot_ms,
 state,
 error_result.message AS error_result_message,
FROM
 `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
 TIMESTAMP_TRUNC(creation_time, DAY) = '2024-06-12'
 AND job_id = '2Lm09bHxDEsoVK8zwzWJomLHU_Ud%1910479b151' -- queryId

Hinweis: Das Feld job_id enthält die queryId der Abfrage, wenn für diese Abfrage kein Job erstellt wurde.

Die Ergebnisse sollten so aussehen:

+------------------------------------------+----------------+-------------+-----------+--------------------------+--------------------+-----------------------+---------------+-------+----------------------+
| job_id                                   | statement_type | priority    | cache_hit | job_creation_reason_code | total_bytes_billed | total_bytes_processed | total_slot_ms | state | error_result_message |
+------------------------------------------+----------------+-------------+-----------+--------------------------+--------------------+-----------------------+---------------+-------+----------------------+
| 2Lm09bHxDEsoVK8zwzWJomLHU_Ud%1910479b151 | SELECT         | INTERACTIVE | false     | null                     | 161480704          | 161164718             | 3106          | DONE  | null                 |
+------------------------------------------+----------------+-------------+-----------+--------------------------+--------------------+-----------------------+---------------+-------+----------------------+

Das folgende Beispiel zeigt eine Liste von Abfragen, die im optimierten Modus für kurze Abfragen ausgeführt wurden und für die BigQuery Jobs erstellt hat.

SELECT
 job_id,
 job_creation_reason.code AS job_creation_reason_code
FROM
 `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
 TIMESTAMP_TRUNC(creation_time, DAY) = '2024-06-12'
 AND job_creation_reason.code IS NOT NULL
 AND job_creation_reason.code != 'REQUESTED'
LIMIT
 10

Die Ergebnisse sollten so aussehen:

+----------------------------------+--------------------------+
| job_id                           | job_creation_reason_code |
+----------------------------------+--------------------------+
| job_LxOEwrJEffcOfjK7GBwWjO3RroOI | LARGE_RESULTS            |
+----------------------------------+--------------------------+

Verarbeitete Byte pro Nutzeridentität

Das folgende Beispiel zeigt die Gesamtzahl der Byte, die für Abfragejobs pro Nutzer in Rechnung gestellt werden:

SELECT
  user_email,
  SUM(total_bytes_billed) AS bytes_billed
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  job_type = 'QUERY'
  AND statement_type != 'SCRIPT'
GROUP BY
  user_email;

Hinweis: Weitere Informationen finden Sie in der Schemadokumentation für die Spalte total_bytes_billed in den JOBS-Ansichten.

Die Ergebnisse sollten so aussehen:

+---------------------+--------------+
| user_email          | bytes_billed |
+---------------------+--------------+
| [e-mail]     | 2847932416   |
| [e-mail]   | 1184890880   |
| [e-mail] | 10485760     |
+---------------------+--------------+

Stündliche Aufschlüsselung der verarbeiteten Byte

Das folgende Beispiel zeigt die Gesamtzahl der für Abfragejobs in Rechnung gestellten Byte in stündlichen Intervallen.

SELECT
  TIMESTAMP_TRUNC(end_time, HOUR) AS time_window,
  SUM(total_bytes_billed) AS bytes_billed
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  job_type = 'QUERY'
  AND statement_type != 'SCRIPT'
GROUP BY
  time_window
ORDER BY
  time_window DESC;

Das Ergebnis sieht etwa so aus:

+-------------------------+--------------+
| time_window             | bytes_billed |
+-------------------------+--------------+
| 2022-05-17 20:00:00 UTC | 1967128576   |
| 2022-05-10 21:00:00 UTC | 0            |
| 2022-04-15 20:00:00 UTC | 10485760     |
| 2022-04-15 17:00:00 UTC | 41943040     |
+-------------------------+--------------+

Abfragejobs pro Tabelle

Im folgenden Beispiel wird gezeigt, wie oft die einzelnen in my_project abgefragten Tabellen von einem Abfragejob referenziert wurden:

SELECT
  t.project_id,
  t.dataset_id,
  t.table_id,
  COUNT(*) AS num_references
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS, UNNEST(referenced_tables) AS t
GROUP BY
  t.project_id,
  t.dataset_id,
  t.table_id
ORDER BY
  num_references DESC;

Das Ergebnis sieht etwa so aus:

+------------+------------+----------+----------------+
| project_id | dataset_id | table_id | num_references |
+------------+------------+----------+----------------+
| my_project | dataset1   | orders   | 58             |
| my_project | dataset1   | products | 40             |
| my_project | dataset2   | sales    | 30             |
| other_proj | dataset1   | accounts | 12             |
+------------+------------+----------+----------------+

Anzahl der geänderten Partitionen pro Tabelle durch Abfrage- und Ladejobs

Im folgenden Beispiel sehen Sie die Anzahl der Partitionen, die durch Abfragen mit DML-Anweisungen und Ladejobs pro Tabelle geändert wurden. Beachten Sie, dass in dieser Abfrage die total_modified_partitions für Kopierjobs nicht angezeigt wird.

SELECT
  destination_table.table_id,
  SUM(total_modified_partitions) AS total_modified_partitions
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  DATE(creation_time, "America/Los_Angeles") = CURRENT_DATE()
GROUP BY
  table_id
ORDER BY
  total_modified_partitions DESC

Die teuersten Abfragen nach Projekt

Im folgenden Beispiel werden die teuersten Abfragen in my_project nach Slot-Nutzungszeit aufgelistet:

SELECT
 job_id,
 query,
 user_email,
 total_slot_ms
FROM `my_project`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE EXTRACT(DATE FROM  creation_time) = current_date()
ORDER BY total_slot_ms DESC
LIMIT 4

Mit dem folgenden Beispiel können Sie auch die teuersten Abfragen nach Daten auflisten:

SELECT
 job_id,
 query,
 user_email,
 total_bytes_processed
FROM `my_project`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE EXTRACT(DATE FROM  creation_time) = current_date()
ORDER BY total_bytes_processed DESC
LIMIT 4

Das Ergebnis für jedes der Beispiele sieht in etwa so aus:

+--------------+---------------------------------+-----------------------+---------------+
| job_id       | query                           | user_email            | total_slot_ms |
+--------------+---------------------------------+--------------------------+------------+
| examplejob_1 | SELECT ... FROM dataset.table1  | [e-mail]       | 80,000        |
| examplejob_2 | SELECT ... FROM dataset.table2  | [e-mail]     | 78,000        |
| examplejob_3 | SELECT ... FROM dataset.table3  | [e-mail]   | 75,000        |
| examplejob_4 | SELECT ... FROM dataset.table4  | [e-mail]      | 72,000        |
+--------------+---------------------------------+-----------------------+---------------+

Details zu einer Ressourcenwarnung abrufen

Wenn Sie die Fehlermeldung Ressourcen überschritten erhalten, können Sie sich in einem Zeitfenster über die Abfragen informieren:

SELECT
  query,
  query_info.resource_warning
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
 creation_time BETWEEN TIMESTAMP("2022-12-01")
 AND TIMESTAMP("2022-12-08")
 AND query_info.resource_warning IS NOT NULL
LIMIT 50;

Ressourcenwarnungen nach Datum gruppiert

Wenn Sie die Fehlermeldung Ressourcen überschritten erhalten, können Sie die Gesamtzahl der nach Ressourcen gruppierten Ressourcenwarnungen überwachen, um festzustellen, ob es Änderungen an der Arbeitslast gab:

WITH resource_warnings AS (
  SELECT
    EXTRACT(DATE FROM creation_time) AS creation_date
  FROM
    `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
  WHERE
    creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY)
    AND query_info.resource_warning IS NOT NULL
)
SELECT
  creation_date,
  COUNT(1) AS warning_counts
FROM
  resource_warnings
GROUP BY creation_date
ORDER BY creation_date DESC;

Slot-Nutzung und Kosten für Abfragen schätzen

Im folgenden Beispiel werden die durchschnittlichen Slots und maximalen Slots für jeden Job mithilfe von estimated_runnable_units berechnet.

Die reservation_id ist NULL, wenn Sie keine Reservierungen haben.

SELECT
  project_id,
  job_id,
  reservation_id,
  EXTRACT(DATE FROM creation_time) AS creation_date,
  TIMESTAMP_DIFF(end_time, start_time, SECOND) AS job_duration_seconds,
  job_type,
  user_email,
  total_bytes_billed,

  -- Average slot utilization per job is calculated by dividing total_slot_ms by the millisecond duration of the job

  SAFE_DIVIDE(job.total_slot_ms,(TIMESTAMP_DIFF(job.end_time, job.start_time, MILLISECOND))) AS job_avg_slots,
  query,

  -- Determine the max number of slots used at ANY stage in the query.
  -- The average slots might be 55. But a single stage might spike to 2000 slots.
  -- This is important to know when estimating number of slots to purchase.

  MAX(SAFE_DIVIDE(unnest_job_stages.slot_ms,unnest_job_stages.end_ms - unnest_job_stages.start_ms)) AS jobstage_max_slots,

  -- Check if there's a job that requests more units of works (slots). If so you need more slots.
  -- estimated_runnable_units = Units of work that can be scheduled immediately.
  -- Providing additional slots for these units of work accelerates the query,
  -- if no other query in the reservation needs additional slots.

  MAX(unnest_timeline.estimated_runnable_units) AS estimated_runnable_units
FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS AS job
  CROSS JOIN UNNEST(job_stages) as unnest_job_stages
  CROSS JOIN UNNEST(timeline) AS unnest_timeline
WHERE project_id = 'my_project'
  AND statement_type != 'SCRIPT'
  AND DATE(creation_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) AND CURRENT_DATE()
GROUP BY 1,2,3,4,5,6,7,8,9,10
ORDER BY job_id;

Leistungsstatistiken für Abfragen aufrufen

Im folgenden Beispiel werden alle Abfragejobs zurückgegeben, die in den letzten 30 Tagen Leistungsinformationen aus Ihrem Projekt erhalten haben, sowie eine URL, die auf das Diagramm zur Abfrageausführung in der Google Cloud Console verweist.

SELECT
  `bigquery-public-data`.persistent_udfs.job_url(
    project_id || ':us.' || job_id) AS job_url,
  query_info.performance_insights
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  DATE(creation_time) >= CURRENT_DATE - 30 -- scan 30 days of query history
  AND job_type = 'QUERY'
  AND state = 'DONE'
  AND error_result IS NULL
  AND statement_type != 'SCRIPT'
  AND EXISTS ( -- Only include queries which had performance insights
    SELECT 1
    FROM UNNEST(
      query_info.performance_insights.stage_performance_standalone_insights
    )
    WHERE slot_contention OR insufficient_shuffle_quota
    UNION ALL
    SELECT 1
    FROM UNNEST(
      query_info.performance_insights.stage_performance_change_insights
    )
    WHERE input_data_change.records_read_diff_percentage IS NOT NULL
  );

Metadaten-Aktualisierungsjobs ansehen

Im folgenden Beispiel werden die Metadaten-Aktualisierungsjobs aufgelistet:

SELECT
 *
FROM
 `region-aws-us-east-1.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE
 job_id LIKE '%metadata_cache_refresh%'
 AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time desc
LIMIT 10;

Leistung für identische Abfragen im Zeitverlauf analysieren

Im folgenden Beispiel werden die zehn langsamsten Jobs der letzten sieben Tage zurückgegeben, für die dieselbe Abfrage ausgeführt wurde:

DECLARE querytext STRING DEFAULT(
  SELECT query
  FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
  WHERE job_id = 'JOB_ID'
  LIMIT 1
);

SELECT
  start_time,
  end_time,
  project_id,
  job_id,
  TIMESTAMP_DIFF(end_time, start_time, SECOND) AS run_secs,
  total_bytes_processed / POW(1024, 3) AS total_gigabytes_processed,
  query
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
WHERE
  query = querytext
  AND total_bytes_processed > 0
  AND creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY 5 DESC
LIMIT 10;

Ersetzen Sie JOB_ID durch eine beliebige job_id, mit der die zu analysierende Abfrage ausgeführt wurde.

Slot-Nutzungsverhalten mit Admin-Ressourcendiagrammen abgleichen

Fragen Sie die Ansicht INFORMATION_SCHEMA.JOBS_TIMELINE ab, um das Slot-Nutzungsverhalten zu untersuchen, das den Informationen in Admin-Ressourcendiagrammen ähnelt.