Vista TAREAS

La vista INFORMATION_SCHEMA.JOBS contiene metadatos casi en tiempo real sobre todos los trabajos de BigQuery del proyecto actual.

Rol necesario

Para obtener el permiso que necesitas para consultar la vista INFORMATION_SCHEMA.JOBS, pide a tu administrador que te asigne el rol de gestión de identidades y accesos Lector de recursos de BigQuery (roles/bigquery.resourceViewer) en tu proyecto. Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

Este rol predefinido contiene el permiso bigquery.jobs.listAll INFORMATION_SCHEMA.JOBS, que es necesario para consultar la vista bigquery.jobs.listAll INFORMATION_SCHEMA.JOBS.

También puedes obtener este permiso con roles personalizados u otros roles predefinidos.

Para obtener más información sobre los permisos de BigQuery, consulta Control de acceso con gestión de identidades y accesos.

Esquema

Los datos subyacentes se particionan por la columna creation_time y se agrupan en clústeres por project_id y user_email. La columna query_info contiene información adicional sobre los trabajos de consulta.

La vista INFORMATION_SCHEMA.JOBS tiene el siguiente esquema:

Nombre de la columna Data type (Dato) Valor
bi_engine_statistics RECORD Si el proyecto está configurado para usar BI Engine, este campo contiene BiEngineStatistics. De lo contrario, NULL.
cache_hit BOOLEAN Indica si los resultados de la consulta de este trabajo procedían de una caché. Si tienes un trabajo de instrucción de varias consultas, cache_hit de tu consulta principal es NULL.
creation_time TIMESTAMP (Columna de partición) Hora de creación de este trabajo. La partición se basa en la hora UTC de esta marca de tiempo.
destination_table RECORD Tabla de destino de los resultados (si corresponde).
end_time TIMESTAMP Hora de finalización de este trabajo, en milisegundos desde el inicio del registro de tiempo. Este campo representa la hora en la que el trabajo pasa al estado DONE.
error_result RECORD Detalles de los errores como objetos ErrorProto.
job_creation_reason.code STRING Especifica el motivo de alto nivel por el que se ha creado un trabajo.
Los valores posibles son:
  • REQUESTED: se ha solicitado la creación de un trabajo.
  • LONG_RUNNING: la solicitud de consulta se ha ejecutado más allá del tiempo de espera definido por el sistema especificado por el campo timeoutMs en QueryRequest. Por lo tanto, se consideró una operación de larga duración para la que se creó un trabajo.
  • LARGE_RESULTS: los resultados de la consulta no caben en la respuesta insertada.
  • OTHER: el sistema ha determinado que la consulta debe ejecutarse como un trabajo.
job_id STRING El ID del trabajo si se ha creado uno. De lo contrario, el ID de consulta de una consulta que usa el modo de creación de tareas opcional. Por ejemplo, bquxjob_1234.
job_stages RECORD Fases de la consulta de la tarea.

Nota: Los valores de esta columna están vacíos en las consultas que leen datos de tablas con políticas de acceso a nivel de fila. Para obtener más información, consulta las prácticas recomendadas para la seguridad a nivel de fila en BigQuery.

job_type STRING El tipo de trabajo. Puede ser QUERY, LOAD, EXTRACT, COPY o NULL. Un valor NULL indica un trabajo en segundo plano.
labels RECORD Matriz de etiquetas aplicadas al trabajo como pares clave-valor.
parent_job_id STRING ID del trabajo principal (si lo hay).
priority STRING La prioridad de este trabajo. Los valores válidos son INTERACTIVE y BATCH.
project_id STRING Columna de clustering: el ID del proyecto.
project_number INTEGER El número del proyecto.
query STRING Texto de la consulta de SQL. Solo la vista JOBS_BY_PROJECT tiene la columna de consulta.
referenced_tables RECORD Matriz de tablas a las que hace referencia la tarea. Solo se rellena en el caso de las consultas que no se han encontrado en la caché.
reservation_id STRING Nombre de la reserva principal asignada a este trabajo, con el formato RESERVATION_ADMIN_PROJECT:RESERVATION_LOCATION.RESERVATION_NAME.
En este resultado:
  • RESERVATION_ADMIN_PROJECT: el nombre del proyecto de Google Cloud que administra la reserva
  • RESERVATION_LOCATION: la ubicación de la reserva
  • RESERVATION_NAME: el nombre de la reserva
edition STRING Edición asociada a la reserva asignada a este trabajo. Para obtener más información sobre las ediciones, consulta Introducción a las ediciones de BigQuery.
session_info RECORD Detalles sobre la sesión en la que se ejecutó este trabajo, si la hubiera.
start_time TIMESTAMP Hora de inicio de este trabajo, en milisegundos desde la época. Este campo representa la hora en la que la tarea pasa del estado PENDING a RUNNING o DONE.
state STRING Estado de ejecución del trabajo. Los estados válidos son PENDING, RUNNING y DONE.
statement_type STRING El tipo de instrucción de consulta. Por ejemplo, DELETE, INSERT, SCRIPT, SELECT o UPDATE. Consulta QueryStatementType para ver una lista de valores válidos.
timeline RECORD Cronología de la consulta de la tarea. Contiene instantáneas de la ejecución de consultas.
total_bytes_billed INTEGER Si el proyecto está configurado para usar los precios bajo demanda, este campo contiene el total de bytes facturados por la tarea. Si el proyecto está configurado para usar precios de tarifa plana, no se te cobrarán los bytes y este campo solo tiene carácter informativo.

Nota: Los valores de esta columna están vacíos en las consultas que leen datos de tablas con políticas de acceso a nivel de fila. Para obtener más información, consulta las prácticas recomendadas para la seguridad a nivel de fila en BigQuery.

total_bytes_processed INTEGER

Total de bytes procesados por el trabajo.

Nota: Los valores de esta columna están vacíos en las consultas que leen datos de tablas con políticas de acceso a nivel de fila. Para obtener más información, consulta las prácticas recomendadas para la seguridad a nivel de fila en BigQuery.

total_modified_partitions INTEGER Número total de particiones que ha modificado la tarea. Este campo se rellena en los trabajos LOAD y QUERY.
total_slot_ms INTEGER Milisegundos de ranura de la tarea durante toda su duración en el estado RUNNING, incluidas las reintentos.
transaction_id STRING ID de la transacción en la que se ha ejecutado este trabajo (si la hay). Vista previa
user_email STRING Columna de clustering: dirección de correo o cuenta de servicio del usuario que ha ejecutado el trabajo.
query_info.resource_warning STRING El mensaje de advertencia que aparece si el uso de recursos durante el procesamiento de la consulta supera el umbral interno del sistema.
Si una tarea de consulta se completa correctamente, se rellena el campo resource_warning. Con resource_warning, obtienes puntos de datos adicionales para optimizar tus consultas y configurar la monitorización de las tendencias de rendimiento de un conjunto de consultas equivalente mediante query_hashes.
query_info.query_hashes.normalized_literals STRING Contiene el valor hash de la consulta. normalized_literals es un hash hexadecimal STRING que ignora los comentarios, los valores de los parámetros, las funciones definidas por el usuario y los literales. El valor hash será diferente si cambian las vistas subyacentes o si la consulta hace referencia implícitamente a columnas, como SELECT *, y el esquema de la tabla cambia.
Este campo aparece en las consultas de GoogleSQL que se han realizado correctamente y que no son aciertos de caché.
query_info.performance_insights RECORD Estadísticas de rendimiento de la tarea.
query_info.optimization_details STRUCT Las optimizaciones basadas en el historial del trabajo.
transferred_bytes INTEGER Total de bytes transferidos en consultas entre nubes, como las tareas de transferencia entre nubes de BigQuery Omni.
materialized_view_statistics RECORD Estadísticas de las vistas materializadas que se han tenido en cuenta en un trabajo de consulta. Vista previa
metadata_cache_statistics RECORD Estadísticas sobre el uso del índice de columnas de metadatos de las tablas a las que se hace referencia en un trabajo de consulta.
search_statistics RECORD Estadísticas de una consulta de búsqueda.
query_dialect STRING Este campo estará disponible en algún momento de mayo del 2025. El dialecto de consulta que se ha usado en la tarea. Los valores válidos son los siguientes:
  • GOOGLE_SQL: se ha solicitado que el trabajo use GoogleSQL.
  • LEGACY_SQL: se ha solicitado que el trabajo use Legacy SQL.
  • DEFAULT_LEGACY_SQL: no se ha especificado ningún dialecto de consulta en la solicitud de trabajo. BigQuery ha usado el valor predeterminado de LegacySQL.
  • DEFAULT_GOOGLE_SQL: no se ha especificado ningún dialecto de consulta en la solicitud de trabajo. BigQuery ha usado el valor predeterminado de GoogleSQL.

Este campo solo se rellena en las tareas de consulta. La selección predeterminada del dialecto de consulta se puede controlar mediante los ajustes de configuración.
continuous BOOLEAN Si el trabajo es una consulta continua.
continuous_query_info.output_watermark TIMESTAMP Representa el punto hasta el que la consulta continua ha procesado los datos correctamente.
vector_search_statistics RECORD Estadísticas de una consulta de búsqueda de vectores.

Cuando consulte INFORMATION_SCHEMA.JOBS para obtener un coste resumido de los trabajos de consulta, excluya el tipo de instrucción SCRIPT. De lo contrario, algunos valores podrían contabilizarse dos veces. La fila SCRIPT incluye valores de resumen de todos los trabajos secundarios que se han ejecutado como parte de este trabajo.

Tareas de consulta con varias instrucciones

Un trabajo de consulta con varias instrucciones es un trabajo de consulta que usa el lenguaje de procedimiento. Los trabajos de consulta con varias instrucciones suelen definir variables con DECLARE o tener instrucciones de control de flujo, como IF o WHILE. Cuando envías una consulta INFORMATION_SCHEMA.JOBS, es posible que tengas que distinguir entre una tarea de consulta con varias instrucciones y otras tareas. Un trabajo de consulta con varias instrucciones tiene las siguientes características:

  • statement_type = SCRIPT
  • reservation_id = NULL

Tareas secundarias

Cada uno de los trabajos secundarios de un trabajo de consulta con varias instrucciones tiene un parent_job_id que apunta al trabajo de consulta con varias instrucciones. Esto incluye los valores de resumen de todas las tareas secundarias que se han ejecutado como parte de esta tarea.

Si consultas INFORMATION_SCHEMA.JOBS para obtener un resumen del coste de las tareas de consulta, debes excluir el tipo de instrucción SCRIPT. De lo contrario, algunos valores, como total_slot_ms, podrían contabilizarse dos veces.

Conservación de datos

Esta vista contiene los trabajos que se están ejecutando y el historial de los últimos 180 días.

Ámbito y sintaxis

Las consultas en esta vista deben incluir un calificador de región. En la siguiente tabla se explica el ámbito de la región de esta vista:

Nombre de la vista Ámbito de los recursos Ámbito de la región
[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.JOBS[_BY_PROJECT] Nivel de proyecto REGION
Sustituye lo siguiente:
  • Opcional: PROJECT_ID: el ID de tu Google Cloud proyecto. Si no se especifica, se usa el proyecto predeterminado.
  • REGION: cualquier nombre de región del conjunto de datos. Por ejemplo, `region-us`.

Ejemplos

Para ejecutar la consulta en un proyecto que no sea el predeterminado, añade el ID del proyecto con el siguiente formato:

`PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS
Sustituye lo siguiente:

  • PROJECT_ID: el ID del proyecto.
  • REGION_NAME: la región de tu proyecto.

Por ejemplo, `myproject`.`region-us-central1`.INFORMATION_SCHEMA.JOBS.

Comparar el uso de tareas bajo demanda con los datos de facturación

En los proyectos que usan los precios bajo demanda, puedes usar la vista INFORMATION_SCHEMA.JOBS para consultar los cargos por computación durante un periodo determinado.

En los proyectos que usan la tarifa basada en la capacidad (slots), puedes usar el INFORMATION_SCHEMA.RESERVATIONS_TIMELINE para consultar los cargos de computación durante un periodo determinado.

La siguiente consulta genera agregaciones diarias estimadas de los TiBs facturados y los cargos resultantes. En la sección Limitaciones se explica cuándo es posible que estas estimaciones no coincidan con tu factura.

Solo en este ejemplo, se deben definir las siguientes variables adicionales. Puedes editarlos aquí para que te resulte más fácil usarlos.

  • START_DATE: la fecha más antigua para agregar datos (inclusive).
  • END_DATE: la fecha más reciente para agregar datos (inclusive).
  • PRICE_PER_TIB: el precio bajo demanda por TiB que se usa para las estimaciones de facturación.
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;

Limitaciones

  • BigQuery oculta algunas estadísticas de las consultas sobre tablas con seguridad a nivel de fila. La consulta proporcionada cuenta el número de trabajos afectados como jobs_using_row_level_security, pero no tiene acceso al uso facturable.

  • El precio de BigQuery ML para las consultas bajo demanda depende del tipo de modelo que se cree. INFORMATION_SCHEMA.JOBS no registra qué tipo de modelo se ha creado, por lo que la consulta proporcionada da por hecho que todas las instrucciones CREATE_MODEL han creado los tipos de modelo con la facturación más alta.

  • Los procedimientos de Apache Spark usan un modelo de precios similar, pero los cargos se registran como SKU de pago por uso de la edición Enterprise de BigQuery. INFORMATION_SCHEMA.JOBS registra este uso como total_bytes_billed, pero no puede determinar a qué SKU corresponde.

Calcular la utilización media de las ranuras

En el siguiente ejemplo se calcula la utilización media de las ranuras de todas las consultas de los últimos 7 días de un proyecto determinado. Ten en cuenta que este cálculo es más preciso en los proyectos que tienen un uso constante de las ranuras a lo largo de la semana. Si tu proyecto no tiene un uso de ranuras constante, este número puede ser inferior al esperado.

Para ejecutar la consulta, sigue estos pasos:

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();

El resultado es similar al siguiente:

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

Puedes consultar el uso de una reserva concreta con WHERE reservation_id = "…". Esto puede ser útil para determinar el porcentaje de uso de una reserva durante un periodo. En el caso de las tareas de secuencias de comandos, la tarea principal también informa del uso total de ranuras de sus tareas secundarias. Para evitar que se contabilicen dos veces, usa WHERE statement_type != "SCRIPT" para excluir el trabajo principal.

Si quieres consultar la utilización media de las ranuras de trabajos concretos, usa total_slot_ms / TIMESTAMP_DIFF(end_time, start_time, MILLISECOND).

Recuento de consultas activas recientes por prioridad de consulta

En el siguiente ejemplo se muestra el número de consultas agrupadas por prioridad (interactivas o por lotes) que se han iniciado en las últimas 7 horas:

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;

El resultado es similar al siguiente:

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

El campo priority indica si una consulta es INTERACTIVE o BATCH.

Ver el historial de tareas de carga

En el siguiente ejemplo se muestran todos los usuarios o cuentas de servicio que han enviado un trabajo de carga por lotes de un proyecto concreto. Como no se especifica ningún límite temporal, esta consulta analiza todo el historial disponible.

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

El resultado es similar al siguiente:

+--------------+
| user         |
+--------------+
| abc@xyz.com  |
| xyz@xyz.com  |
| bob@xyz.com  |
+--------------+

Obtener el número de tareas de carga para determinar la cuota de tareas diaria utilizada

En el siguiente ejemplo se devuelve el número de tareas por día, conjunto de datos y tabla para que pueda determinar qué parte de la cuota diaria de tareas se ha utilizado.

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;
Nota: Los nombres de las vistas `INFORMATION_SCHEMA` distinguen entre mayúsculas y minúsculas. El resultado es similar al siguiente:
+-------------+------------+-------------+----------+-----------------+
|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              |
+-------------+------------+-------------+----------+-----------------+

Obtener las últimas tareas fallidas

En el siguiente ejemplo se muestran los tres últimos trabajos fallidos:

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;

Los resultados deberían ser similares a los siguientes:

+------------+--------------------------+------------------+-------------------------------------+
| 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...|
+------------+--------------------------+------------------+-------------------------------------+

Consultar la lista de trabajos de larga duración

En el siguiente ejemplo se muestra la lista de tareas de larga duración que están en estado RUNNING o PENDING durante más de 30 minutos:

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;

El resultado es similar al siguiente:

+-----------+----------+---------+--------------------------------+--------------------------------+------------------+
| 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  |
+-----------+----------+---------+--------------------------------+--------------------------------+------------------+

Consultas que usan el modo de creación de tareas opcional

En el siguiente ejemplo se muestra una lista de consultas que se ejecutaron en el modo de creación de tareas opcional para las que BigQuery no creó tareas.

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;

Los resultados deberían tener este aspecto:

+-----------+
| job_id    |                                          |
+-----------+
| bquxjob_1 |
| bquxjob_2 |
| bquxjob_3 |
+-----------+

En el siguiente ejemplo se muestra información sobre una consulta que se ejecutó en el modo de creación de trabajos opcional y para la que BigQuery no creó ningún trabajo.

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

Nota: El campo job_id contiene el queryId de la consulta cuando no se ha creado ningún trabajo para esta consulta.

Los resultados deberían tener este aspecto:

+-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+
| 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                 |
+-----------+----------------+-------------+-----------+--------------------------+--------------------+---------------------+---------------+-------+----------------------+

En el siguiente ejemplo se muestra una lista de consultas que se ejecutaron en el modo de creación de tareas opcional para las que BigQuery creó tareas.

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

Los resultados deberían tener este aspecto:

+-----------+--------------------------+
| job_id    | job_creation_reason_code |
+-----------+--------------------------+
| bquxjob_1 | LARGE_RESULTS            |
| bquxjob_2 | LARGE_RESULTS            |
| bquxjob_3 | LARGE_RESULTS            |
+-----------+--------------------------+

Bytes procesados por identidad de usuario

En el siguiente ejemplo se muestra el total de bytes facturados por los trabajos de consulta por usuario:

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;

Nota: Consulta la advertencia de la columna total_bytes_billed en la documentación del esquema de las vistas JOBS.

Los resultados deberían tener este aspecto:

+---------------------+--------------+
| user_email          | bytes_billed |
+---------------------+--------------+
| bob@example.com     | 2847932416   |
| alice@example.com   | 1184890880   |
| charles@example.com | 10485760     |
+---------------------+--------------+

Desglose por horas de los bytes procesados

En el siguiente ejemplo se muestra el total de bytes facturados de los trabajos de consulta en intervalos horarios:

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;

El resultado es similar al siguiente:

+-------------------------+--------------+
| 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     |
+-------------------------+--------------+

Tareas de consulta por tabla

En el siguiente ejemplo se muestra cuántas veces se ha hecho referencia a cada tabla consultada en my_project en un trabajo de consulta:

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;

El resultado es similar al siguiente:

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

Número de tareas de consulta de SQL antiguo por proyecto

El campo "query_dialect" de INFORMATION_SCHEMA estará disponible en algún momento de mayo del 2025. En el siguiente ejemplo se muestra cuántos trabajos de consulta de SQL antiguo se ejecutan en proyectos.

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;

Número de particiones modificadas por tareas de consulta y carga por tabla

En el siguiente ejemplo se muestra el número de particiones modificadas por consultas con declaraciones de DML y tareas de carga por tabla. Ten en cuenta que esta consulta no muestra el total_modified_partitions de los trabajos de copia.

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

Número medio de ranuras por milisegundo que usa un trabajo.

En el siguiente ejemplo se muestra cómo calcular el número medio de ranuras que usa un trabajo durante la ejecución. Esto puede ser útil para solucionar problemas de consultas lentas y comparar la ejecución lenta de una consulta con la ejecución más rápida de la misma consulta. Comparar este valor con el tamaño total de la reserva y el número medio de trabajos simultáneos ejecutados en el proyecto o la reserva puede ayudarte a saber si varias consultas competían por los espacios al mismo tiempo durante la ejecución.

Un número medio de ranuras más alto significa que se asignan más recursos al trabajo, lo que suele dar como resultado una ejecución más rápida.

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'

Sustituye JOB_ID por la job_id que estés investigando.

El resultado será similar al siguiente:

+------------------+
| avg_slots_per_ms |
+------------------+
|             17.0 |
+------------------+

Consultas más caras por proyecto

En el siguiente ejemplo se muestran las consultas más caras de my_project por tiempo de uso de ranura:

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

También puede enumerar las consultas más caras por datos procesados con el siguiente ejemplo:

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

El resultado de cualquiera de los ejemplos es similar al siguiente:

+-----------+---------------------------------+-----------------------+---------------+
| 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        |
+-----------+---------------------------------+-----------------------+---------------+

Obtener detalles sobre una advertencia de recursos

Si aparece el mensaje de error Recursos superados, puedes consultar las consultas en un periodo determinado:

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;

Monitorizar las advertencias de recursos agrupadas por fecha

Si recibes el mensaje de error Recursos superados, puedes monitorizar el número total de advertencias de recursos agrupadas por fecha para saber si hay algún cambio en la carga de trabajo:

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;

Estimar el uso y el coste de las ranuras de las consultas

En el siguiente ejemplo se calcula el número medio y máximo de ranuras de cada trabajo mediante estimated_runnable_units.

El reservation_id es NULL si no tienes ninguna reserva.

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
  DATE(creation_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) AND CURRENT_DATE()
  AND project_id = 'my_project'
  AND (statement_type != 'SCRIPT' OR statement_type IS NULL)
GROUP BY 1,2,3,4,5,6,7,8,9,10
ORDER BY job_id;

El resultado, por ejemplo, es similar al siguiente:

+-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+
|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          | 1000                     |
| project1  | bquxjob2  | reservation2   | 2020-12-10    | 120                  | LOAD     | abc@example.com | 161480704          | 2890         | SELECT ... FROM dataset.table1 | 2779.1534          | 1000                     |
| project1  | bquxjob3  | reservation1   | 2020-12-10    | 120                  | LOAD     | abc@example.com | 161480704          | 2890         | SELECT ... FROM dataset.table1 | 1279.1534          | 998                     |
+-----------+-----------+----------------+---------------+----------------------+----------+-----------------+--------------------+--------------+--------------------------------+--------------------+--------------------------+

Ver estadísticas de rendimiento de las consultas

En el siguiente ejemplo, se devuelven todos los trabajos de consulta que tienen estadísticas de rendimiento de tu proyecto en los últimos 30 días, junto con una URL que enlaza al gráfico de ejecución de la consulta en la consola de Google Cloud .

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
  );

Ver tareas de actualización de metadatos

En el siguiente ejemplo se enumeran las tareas de actualización de metadatos de las últimas seis horas:

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;

Sustituye REGION_NAME por tu región.

Analizar el rendimiento a lo largo del tiempo de consultas idénticas

En el siguiente ejemplo se devuelven los 10 trabajos más lentos de los últimos 7 días que han ejecutado la misma consulta:

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;

Sustituye JOB_ID por cualquier job_id que haya ejecutado la consulta que estás analizando.

Los 5 trabajos que han analizado más bytes hoy

En el siguiente ejemplo se muestra cómo encontrar los cinco trabajos que han analizado la mayor cantidad de bytes en una organización durante el día actual. Puedes aplicar más filtros en statement_type para consultar información adicional, como cargas, exportaciones y consultas.

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;

El resultado es similar al siguiente:

+--------------+--------------+---------------------------+
| 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                 |
+--------------+--------------+---------------------------+

Ver tareas pendientes o en curso

SELECT
  job_id,
  creation_time,
  query
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_USER
WHERE
  state != 'DONE';

El resultado es similar al siguiente:

+--------------+---------------------------+---------------------------------+
| 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 |
+--------------+---------------------------+---------------------------------+

Ver las tareas con estadísticas de contención de slots

Para ver los trabajos con sus estadísticas de contención de ranuras, ejecuta la siguiente consulta:

SELECT
  job_id,
  creation_time,
  query_info.performance_insights,
FROM
  `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS j,
  UNNEST(query_info.performance_insights.stage_performance_standalone_insights) i
WHERE
  (j.statement_type != "SCRIPT" OR j.statement_type IS NULL)
  AND i IS NOT NULL
  AND i.slot_contention

El resultado muestra diferentes estadísticas de rendimiento sobre los trabajos, incluida la contención de ranuras:

+------------+-------------------------+-------------------------------------------------+----------------------------------------------------------------------------+
| job_id     | creation_time           | performance_insights.avg_previous_execution_ms  | performance_insightsstage_performance_standalone_insights.slot_contention  |
+------------+-------------------------+-------------------------------------------------+----------------------------------------------------------------------------+
| bquxjob_1  | 2025-08-08 00:00:00 UTC | null                                            | true                                                                       |
| bquxjob_2  | 2025-08-08 00:00:00 UTC | 42689                                           | true                                                                       |
| bquxjob_3  | 2025-08-08 00:00:00 UTC | 42896                                           | true                                                                       |
+------------+-------------------------+-------------------------------------------------+----------------------------------------------------------------------------+

Ver el número medio de tareas simultáneas que se ejecutan junto con una tarea concreta en el mismo proyecto

En el siguiente ejemplo se muestra cómo calcular el número medio de tareas que se ejecutan al mismo tiempo que una tarea de consulta específica en el mismo proyecto.

Este cálculo ayuda a determinar si un mayor número de trabajos simultáneos en el mismo proyecto ha provocado problemas de contención de ranuras. Recoge estos datos cuando tengas que solucionar problemas con consultas lentas o comparar ejecuciones de consultas lentas y rápidas.

Si se están ejecutando muchas más consultas simultáneas de lo esperado, comprueba si se han iniciado más trabajos, si han cambiado los datos consultados o ambas cosas.

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

Haz los cambios siguientes:

  • JOB_ID: el ID del trabajo de la consulta que está analizando

  • REGION_NAME: la región de tu proyecto

El resultado es similar al siguiente:

+-------------------------+
| average_concurrent_jobs |
+-------------------------+
|                     2.8 |
+-------------------------+

Obtener los bytes procesados por las tareas de exportación

En el siguiente ejemplo se calcula el valor de total_bytes_processed para los tipos de trabajo EXTRACT. Para obtener información sobre las cuotas de los trabajos de exportación, consulta el artículo Política de cuotas para trabajos de exportación. El total de bytes procesados se puede usar para monitorizar el uso agregado y verificar que las tareas de exportación no superen el límite de 50 TB al día:

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;

Obtener el uso de las tareas de copia

Para obtener información sobre los trabajos de copia, consulta Copiar una tabla. En el siguiente ejemplo se muestra el uso de los trabajos de copia:

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;

Obtener el uso de las tablas de BigLake para Apache Iceberg en la optimización del almacenamiento de BigQuery

En el siguiente ejemplo se muestra el uso de la tabla de Iceberg de BigLake en la optimización del almacenamiento de BigQuery.

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(%)";

Obtener el uso de la tabla Iceberg de BigLake en los metadatos de la tabla de exportación de BigQuery

En el siguiente ejemplo se muestra el uso de 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;

Coincidir con el comportamiento de uso de las ranuras de los gráficos de recursos administrativos

Para consultar el comportamiento de uso de los espacios publicitarios de forma similar a la información de los gráficos de recursos administrativos, consulta la vista INFORMATION_SCHEMA.JOBS_TIMELINE.