Ansicht JOBS
Die Ansicht INFORMATION_SCHEMA.JOBS
enthält Metadaten in nahezu Echtzeit zu allen BigQuery-Jobs im aktuellen Projekt.
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 von BI Engine konfiguriert ist, 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:
|
job_id |
STRING |
Die ID des Jobs, falls ein Job erstellt wurde. Andernfalls die Abfrage-ID einer Abfrage, die den optionalen Modus für die Joberstellung 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 Hintergrundjob an.
|
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:
|
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 ändert sich, wenn sich die zugrunde liegenden Ansichten ändern oder wenn in der Abfrage implizit auf Spalten wie SELECT * verwiesen wird 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) |
metadata_cache_statistics |
RECORD |
Statistiken zur Verwendung des Metadatenspaltenindex für Tabellen, auf die in einem Abfragejob verwiesen wird. |
search_statistics |
RECORD |
Statistiken für eine Suchanfrage. |
query_dialect |
STRING |
Dieses Feld wird voraussichtlich im Mai 2025 verfügbar sein.
Der für den Job verwendete Abfragedialekt. Gültige Werte sind:
Dieses Feld wird nur für Abfragejobs ausgefüllt. Die Standardauswahl des Abfragedialekts kann über die Konfigurationseinstellungen gesteuert werden. |
continuous |
BOOLEAN |
Gibt an, ob es sich bei dem Job um eine kontinuierliche Abfrage handelt. |
continuous_query_info.output_watermark |
TIMESTAMP |
Stellt den Punkt dar, bis zu dem die Continuous Query Daten erfolgreich verarbeitet hat. |
vector_search_statistics |
RECORD |
Statistiken für eine Vektorsuchanfrage. |
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.
Abfragejobs mit mehreren Anweisungen
Ein Abfragejob mit mehreren Anweisungen ist ein Abfragejob, in dem die prozedurale Sprache verwendet wird.
In Abfragejobs mit mehreren Anweisungen werden häufig Variablen mit DECLARE
definiert oder es sind Ablaufsteuerungsanweisungen wie IF
oder WHILE
enthalten. Wenn Sie INFORMATION_SCHEMA.JOBS
abfragen, müssen Sie möglicherweise den Unterschied zwischen einem Job für eine Abfrage mit mehreren Anweisungen und anderen Jobs erkennen. Ein Abfragejob mit mehreren Anweisungen hat die folgenden 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 INFORMATION_SCHEMA.JOBS
abfragen, um eine Zusammenfassung der Kosten für Abfragejobs zu erhalten, sollten Sie den Anweisungstyp SCRIPT
ausschließen. Andernfalls werden einige Werte wie total_slot_ms
möglicherweise zweimal gezählt.
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] |
Projektebene | REGION |
-
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`
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
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 die Ansicht INFORMATION_SCHEMA.JOBS
verwenden, um die Gebühren für die Rechenleistung in einem bestimmten Zeitraum zu prüfen.
Bei Projekten mit kapazitätsbasierten Preisen (Slots) können Sie die INFORMATION_SCHEMA.RESERVATIONS_TIMELINE
verwenden, um die Abrechnung für Rechenressourcen für einen bestimmten Zeitraum zu prüfen.
Die folgende Abfrage gibt die geschätzten täglichen Aggregate der abgerechneten TiB und die daraus resultierenden Gebühren zurück. Im Abschnitt Einschränkungen wird erläutert, wann diese Schätzungen möglicherweise nicht mit Ihrer Rechnung übereinstimmen.
Für dieses Beispiel müssen die folgenden zusätzlichen Variablen festgelegt werden. Sie können hier bearbeitet werden, um die Verwendung zu vereinfachen.
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 Rechnungsschätzungen 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
BigQuery blendet einige Statistiken aus für Abfragen von Tabellen mit Sicherheit auf Zeilenebene. Die angegebene Abfrage zählt die Anzahl der betroffenen Jobs als
jobs_using_row_level_security
, hat aber keinen Zugriff auf die abrechenbare Nutzung.Die Preise für BigQuery ML-On-Demand-Abfragen 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 Gebühren werden jedoch als BigQuery Enterprise-Edition-SKU mit nutzungsbasierter Abrechnung ausgewiesen. In
INFORMATION_SCHEMA.JOBS
wird diese Nutzung alstotal_bytes_billed
erfasst, aber es kann nicht ermittelt werden, 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();
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)
.
Anzahl der letzten aktiven Abfragen nach Abfragepriorität
Im folgenden Beispiel wird die Anzahl der Abfragen gruppiert nach Priorität (interaktiv oder Batch) angezeigt, die in den letzten 7 Stunden gestartet wurden:
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 Anfrage 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;
Das Ergebnis sieht etwa so aus:
+--------------+ | user | +--------------+ | abc@xyz.com | | xyz@xyz.com | | bob@xyz.com | +--------------+
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;
+-------------+------------+-------------+----------+-----------------+ |day | project_id | dataset_id | table_id | load_job_count | +-------------+------------+-------------+----------+-----------------+ | 2020-10-10 | my_project | dataset1 | orders | 58 | | 2020-10-10 | my_project | dataset1 | product | 20 | | 2020-10-10 | my_project | dataset1 | sales | 11 | +-------------+------------+-------------+----------+-----------------+
Die letzten fehlgeschlagenen Jobs abrufen
Im folgenden Beispiel werden die letzten drei fehlgeschlagenen Jobs angezeigt:
SELECT job_id, creation_time, user_email, error_result FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE error_result.reason != "Null" ORDER BY creation_time DESC LIMIT 3;
Die Antwort sollte in etwa so aussehen:
+------------+--------------------------+------------------+-------------------------------------+ | job_id | creation_time | user_email | error_result | +------------+--------------------------+------------------+-------------------------------------+ | bquxjob_1 | 2020-10-10 00:00:00 UTC | abc@example.com | Column 'col1' has mismatched type...| | bquxjob_2 | 2020-10-11 00:00:00 UTC | xyz@example.com | Column 'col1' has mismatched type...| | bquxjob_3 | 2020-10-11 00:00:00 UTC | bob@example.com | 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 | +--------+----------+---------+--------------------------------+--------------------------------+------------------+ | bquxjob_1 | QUERY | RUNNING | 2023-05-03 05:07:22.818000 UTC | 2023-05-03 05:07:22.905000 UTC | abc@example.com | | bquxjob_2 | QUERY | PENDING | 2023-05-01 02:05:47.925000 UTC | 2023-05-01 02:05:47.998000 UTC | xyz@example.com | | bquxjob_3 | QUERY | PENDING | 2023-05-01 02:05:47.925000 UTC | 2023-05-01 02:05:47.998000 UTC | abc@example.com | +--------+----------+---------+--------------------------------+--------------------------------+------------------+
Abfragen im Modus mit optionaler Joberstellung
Im folgenden Beispiel sehen Sie eine Liste von Abfragen, die im optionalen Modus für die Job-Erstellung 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 3;
Die Ergebnisse sollten so aussehen:
+-----------+ | job_id | | +-----------+ | bquxjob_1 | | bquxjob_2 | | bquxjob_3 | +-----------+
Das folgende Beispiel zeigt Informationen zu einer Abfrage, die im optionalen Job-Erstellungsmodus ausgeführt wurde und für die BigQuery keinen Job erstellt hat.
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 | +-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+ | bquxjob_1 | SELECT | INTERACTIVE | false | null | 161480704 | 161164718 | 3106 | DONE | null | +-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+
Im folgenden Beispiel sehen Sie eine Liste von Abfragen, die im optionalen Modus für die Job-Erstellung 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 3
Die Ergebnisse sollten so aussehen:
+-----------+--------------------------+ | job_id | job_creation_reason_code | +-----------+--------------------------+ | bquxjob_1 | LARGE_RESULTS | | bquxjob_2 | LARGE_RESULTS | | bquxjob_3 | 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: Lesen Sie die Einschränkungen für die Spalte total_bytes_billed
in der Schemadokumentation für die Ansichten JOBS
.
Die Ergebnisse sollten so aussehen:
+---------------------+--------------+ | user_email | bytes_billed | +---------------------+--------------+ | bob@example.com | 2847932416 | | alice@example.com | 1184890880 | | charles@example.com | 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 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 | | other_proj | dataset1 | accounts | 12 | +------------+------------+----------+----------------+
Anzahl der Legacy-SQL-Abfragejobs pro Projekt
Das Feld „query_dialect“ im INFORMATION_SCHEMA wird voraussichtlich im Mai 2025 verfügbar sein. Im folgenden Beispiel wird gezeigt, wie viele Legacy-SQL-Abfragejobs von Projekten ausgeführt werden.
SELECT project_id, -- Implicitly defaulted to LegacySQL since the query dialect was not specified -- in the request. COUNTIF(query_dialect = 'DEFAULT_LEGACY_SQL') AS default_legacysql_query_jobs, -- Explicitly requested LegacySQL. COUNTIF(query_dialect = 'LEGACY_SQL') AS legacysql_query_jobs, FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE query_dialect = 'DEFAULT_LEGACY_SQL' OR query_dialect = 'LEGACY_SQL' GROUP BY project_id ORDER BY default_legacysql_query_jobs DESC, legacysql_query_jobs DESC;
Anzahl der geänderten Partitionen pro Tabelle durch Abfrage- und Ladejobs
Im folgenden Beispiel sehen Sie die Anzahl der Partitionen, die von 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
Durchschnittliche Anzahl der Slots pro Millisekunde, die von einem Job verwendet werden
Im folgenden Beispiel wird berechnet, wie viele Slots ein Job während der Ausführung durchschnittlich verwendet. Das kann hilfreich sein, wenn Sie Probleme mit langsamen Abfragen beheben und eine langsame Ausführung einer Abfrage mit einer schnelleren Ausführung derselben Abfrage vergleichen möchten. Wenn Sie diesen Wert mit der Gesamtgröße der Reservierung und der durchschnittlichen Anzahl der gleichzeitig ausgeführten Jobs im Projekt oder in der Reservierung vergleichen, können Sie nachvollziehen, ob während der Ausführung mehrere Abfragen gleichzeitig um Slots konkurriert haben.
Eine höhere durchschnittliche Anzahl von Slots bedeutet, dass dem Job mehr Ressourcen zugewiesen werden, was in der Regel zu einer schnelleren Ausführung führt.
SELECT ROUND(SAFE_DIVIDE(total_slot_ms,TIMESTAMP_DIFF(end_time, start_time, MILLISECOND)), 1) as avg_slots_per_ms FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE job_id = 'JOB_ID'
Ersetzen Sie JOB_ID
durch das job_id
, das Sie untersuchen.
Das Ergebnis sieht etwa so aus:
+------------------+ | avg_slots_per_ms | +------------------+ | 17.0 | +------------------+
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 3
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 3
Das Ergebnis für jedes der Beispiele sieht in etwa so aus:
+-----------+---------------------------------+-----------------------+---------------+ | job_id | query | user_email | total_slot_ms | +-----------+---------------------------------+--------------------------+------------+ | bquxjob_1 | SELECT ... FROM dataset.table1 | bob@example.com | 80,000 | | bquxjob_2 | SELECT ... FROM dataset.table2 | alice@example.com | 78,000 | | bquxjob_3 | SELECT ... FROM dataset.table3 | charles@example.com | 75,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 3;
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' OR statement_type IS NULL) 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;
Das Ergebnis sieht etwa so aus:
+-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+ |project_id | job_id | reservation_id | creation_date | job_duration_seconds | job_type | user_email | total_bytes_billed | job_avg_slots| query | jobstage_max_slots | estimated_runnable_units | +-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+ | project1 | bquxjob1 | reservation1 | 2020-10-10 | 160 | LOAD | abc@example.com | 161480704 | 2890 | SELECT ... FROM dataset.table1 | 2779.1534 | 8293 | | project1 | bquxjob2 | reservation2 | 2020-12-10 | 120 | LOAD | abc@example.com | 161480704 | 2890 | SELECT ... FROM dataset.table1 | 2779.1534 | 8768 | | project1 | bquxjob3 | reservation1 | 2020-12-10 | 120 | LOAD | abc@example.com | 161480704 | 2890 | SELECT ... FROM dataset.table1 | 1279.1534 | 8738 | +-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+
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 der letzten sechs Stunden aufgelistet:
SELECT * FROM `region-REGION_NAME`.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;
Ersetzen Sie REGION_NAME durch Ihre Region.
Leistung für identische Abfragen im Zeitverlauf analysieren
Im folgenden Beispiel werden die zehn langsamsten Jobs der letzten sieben Tage zurückgegeben, die dieselbe Abfrage ausgeführt haben:
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 3;
Ersetzen Sie JOB_ID
durch ein beliebiges job_id
, das die analysierte Abfrage ausgeführt hat.
5 Jobs, die heute die meisten Byte gescannt haben
Das folgende Beispiel zeigt, wie Sie die fünf Jobs ermitteln, die in einer Organisation die meisten Byte für den aktuellen Tag gescannt haben. Sie können weiter nach statement_type
filtern, um zusätzliche Informationen wie Ladevorgänge, Exporte und Abfragen einzusehen.
SELECT job_id, user_email, total_bytes_billed FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION WHERE EXTRACT(DATE FROM creation_time) = current_date() ORDER BY total_bytes_billed DESC LIMIT 3;
Das Ergebnis sieht etwa so aus:
+--------------+--------------+---------------------------+ | job_id | user_email | total_bytes_billed | +--------------+--------------+---------------------------+ | bquxjob_1 | abc@xyz.com | 999999 | | bquxjob_2 | def@xyz.com | 888888 | | bquxjob_3 | ghi@xyz.com | 777777 | +--------------+--------------+---------------------------+
Ausstehende oder laufende Jobs ansehen
SELECT job_id, creation_time, query FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_USER WHERE state != 'DONE';
Das Ergebnis sieht etwa so aus:
+--------------+---------------------------+---------------------------------+ | job_id | creation_time | query | +--------------+---------------------------+---------------------------------+ | bquxjob_1 | 2019-10-10 00:00:00 UTC | SELECT ... FROM dataset.table1 | | bquxjob_2 | 2019-10-10 00:00:01 UTC | SELECT ... FROM dataset.table2 | | bquxjob_3 | 2019-10-10 00:00:02 UTC | SELECT ... FROM dataset.table3 | +--------------+---------------------------+---------------------------------+
Durchschnittliche Anzahl von gleichzeitig ausgeführten Jobs neben einem bestimmten Job im selben Projekt ansehen
Im folgenden Beispiel wird gezeigt, wie Sie die durchschnittliche Anzahl von Jobs berechnen, die gleichzeitig mit einem bestimmten Abfragejob im selben Projekt ausgeführt werden.
Mit dieser Berechnung lässt sich feststellen, ob eine erhöhte Anzahl gleichzeitiger Jobs im selben Projekt Probleme mit Slot-Konflikten verursacht hat. Diese Daten sind hilfreich, wenn Sie langsame Abfragen analysieren oder langsame und schnelle Abfrageausführungen vergleichen.
Wenn viel mehr gleichzeitige Abfragen ausgeführt werden als erwartet, prüfen Sie, ob mehr Jobs gestartet wurden, sich abgefragte Daten geändert haben oder beides.
WITH job_metadata AS ( SELECT creation_time, end_time, job_type FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE job_id = 'JOB_ID' -- If you know the date the job was created, add the following line to speed up the query by providing the date in UTC: -- AND DATE(creation_time) = 'YYYY-MM-DD' ), intervals AS ( SELECT TIMESTAMP_ADD(creation_time, INTERVAL (seconds_offset) SECOND) AS ts, job_type FROM job_metadata, UNNEST (GENERATE_ARRAY(0, IF(TIMESTAMP_DIFF(end_time, creation_time, SECOND) > 0, TIMESTAMP_DIFF(end_time, creation_time, SECOND), 1))) as seconds_offset ), concurrent_jobs AS ( SELECT int.ts, COUNT(*) as concurrent_jobs_count FROM intervals int JOIN `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT j ON int.ts BETWEEN j.creation_time and j.end_time WHERE job_id != 'JOB_ID' AND j.job_type = int.job_type GROUP BY int.ts) SELECT ROUND(AVG(concurrent_jobs_count),1) as average_concurrent_jobs FROM concurrent_jobs
Ersetzen Sie Folgendes:
JOB_ID
: die Job-ID der Abfrage, die Sie analysierenREGION_NAME
: Region für Ihr Projekt
Das Ergebnis sieht etwa so aus:
+-------------------------+ | average_concurrent_jobs | +-------------------------+ | 2.8 | +-------------------------+
Von Exportjobs verarbeitete Byte abrufen
Im folgenden Beispiel wird der Wert total_bytes_processed
für EXTRACT
-Jobtypen berechnet. Informationen zu Kontingenten für Exportjobs finden Sie unter Kontingentrichtlinie für Exportjobs.
Die insgesamt verarbeiteten Byte können verwendet werden, um die aggregierte Nutzung zu überwachen und sicherzustellen, dass Exportjobs unter dem Grenzwert von 50 TB pro Tag bleiben:
SELECT DATE(creation_time) as day, project_id as source_project_id, SUM(total_bytes_processed) AS total_bytes_processed FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP() AND job_type = "EXTRACT" GROUP BY day, source_project_id ORDER BY day DESC;
Kopierjobs abrufen
Weitere Informationen zu Kopierjobs finden Sie unter Tabelle kopieren. Das folgende Beispiel zeigt die Verwendung von Kopierjobs:
SELECT DATE(creation_time) as day, project_id as source_project_id, CONCAT(destination_table.project_id,":",destination_table.dataset_id,".",destination_table.table_id) as destination_table, COUNT(job_id) AS copy_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 = "COPY" GROUP BY day, source_project_id, destination_table ORDER BY day DESC;
Nutzung von BigLake-Tabellen für Apache Iceberg in der BigQuery-Speicheroptimierung abrufen
Im folgenden Beispiel wird die Verwendung von BigLake Iceberg-Tabellen zur Optimierung des BigQuery-Speichers veranschaulicht.
SELECT job_id, reservation_id, edition, total_slot_ms, total_bytes_processed, state FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR) AND user_email = "bigquery-adminbot@system.gserviceaccount.com" AND query LIKE "CALL BQ.OPTIMIZE_STORAGE(%)";
Nutzung von BigLake Iceberg-Tabellen in BigQuery-Exporttabellenmetadaten abrufen
Das folgende Beispiel zeigt die Verwendung von Iceberg EXPORT TABLE METADATA FROM
.
SELECT job_id, user_email, start_time, end_time, TIMESTAMP_DIFF(end_time, start_time, SECOND) AS duration_seconds, total_bytes_processed, reservation_id, CASE WHEN reservation_id IS NULL THEN 'PAYG (On-demand)' WHEN reservation_id != '' THEN 'Reservation' ELSE 'Unknown' END AS compute_type, query FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE job_type = 'QUERY' AND end_time IS NOT NULL -- Filter for queries containing the specified pattern (case-insensitive) AND REGEXP_CONTAINS(LOWER(query), r"export table metadata from") ORDER BY start_time DESC LIMIT 3;
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.