Soluciona problemas de consultas

El objetivo de este documento es ayudarte a solucionar problemas habituales relacionados con la ejecución de consultas, como identificar los motivos de las consultas lentas o proporcionar pasos de resolución para los errores habituales que muestran las consultas con errores.

Soluciona problemas de consultas lentas

Para solucionar problemas de rendimiento de las consultas lentas, haz lo siguiente:

  • Consulta la página Google Cloud Service Health para ver si hay interrupciones conocidas del servicio de BigQuery que puedan afectar el rendimiento de las consultas.

  • Revisa el cronograma de trabajos para la consulta en el explorador de trabajos para ver cuánto tiempo tardó en ejecutarse cada etapa de la consulta.

    • Si la mayor parte del tiempo transcurrido se debió a tiempos de creación largos, comunícate con Atención al cliente de Cloud para obtener ayuda.

    • Si la mayor parte del tiempo transcurrido se debió a tiempos de ejecución largos, revisa las estadísticas de rendimiento de las consultas. Las estadísticas de rendimiento de las consultas pueden informarte si tu consulta se ejecutó más tiempo que el tiempo de ejecución promedio y sugerir posibles causas. Entre las posibles causas, se incluye la contención de ranuras de consultas o una cuota de Shuffle insuficiente. Para obtener más información sobre cada problema de rendimiento de las consultas y las posibles resoluciones, consulta Interpreta las estadísticas de rendimiento de las consultas.

  • Revisa el campo finalExecutionDurationMs en el tipo de objeto JobStatistics para tu trabajo de consulta. Es posible que se haya vuelto a intentar la consulta. El campo finalExecutionDurationMs contiene la duración en milisegundos de la ejecución del intento final de este trabajo.

  • Revisa los bytes procesados en la página de detalles del trabajo de consulta para ver si es mayor de lo esperado. Para ello, compara la cantidad de bytes que procesa la consulta actual con otro trabajo de consulta que se completó en un tiempo aceptable. Si hay una gran discrepancia de bytes procesados entre las dos consultas, es posible que la consulta haya sido lenta debido a un gran volumen de datos. Si deseas obtener información para optimizar tus consultas y controlar grandes volúmenes de datos, consulta Optimiza el procesamiento de las consultas.

    También puedes identificar las consultas de tu proyecto que procesan una gran cantidad de datos; para ello, busca las consultas más costosas con la vista INFORMATION_SCHEMA.JOBS.

  • Revisa el uso de tus reservas y verifica si hay contención de ranuras. Para obtener más información, consulta Análisis de estadísticas de cargas de trabajo.

  • Verifica las ejecuciones anteriores y recientes del mismo hash de consulta para ver si hay nuevas estadísticas de rendimiento de las consultas disponibles para los trabajos más lentos, como un cambio en la escala de entrada de datos. Puedes filtrar por hash de consulta en el explorador de trabajos administrativos.

Compara una ejecución lenta y una rápida de la misma consulta

Si una consulta que antes se ejecutaba con rapidez ahora se ejecuta con lentitud, examina el resultado del objeto de la API de Job para identificar los cambios en su ejecución.

Aciertos de caché

Confirma si la ejecución rápida del trabajo fue un acierto de caché mirando el valor cacheHit. Si el valor es true para la ejecución rápida de la consulta, esta usó resultados almacenados en caché en lugar de ejecutar la consulta.

Si esperas que el trabajo lento use resultados almacenados en caché, investiga por qué la consulta ya no usa resultados almacenados en caché. Si no esperas que la consulta recupere datos de la caché, busca un ejemplo de ejecución de consulta rápida que no haya alcanzado la caché para la investigación.

Demoras en las cuotas

Para determinar si la ralentización se debió a algún aplazamiento de cuota, verifica el campo quotaDeferments en ambos trabajos. Compara los valores para determinar si la hora de inicio de la consulta más lenta se retrasó debido a aplazamientos de cuota que no afectaron al trabajo más rápido.

Duración de la ejecución

Para comprender la diferencia entre la duración de la ejecución del último intento de ambos trabajos, compara sus valores para el campo finalExecutionDurationMs.

Si los valores de finalExecutionDurationMs son bastante similares, pero la diferencia en el tiempo de ejecución real entre las dos consultas, calculada como startTime - endTime, es mucho mayor, esto significa que podría haber habido un reintento de ejecución de consulta interno para el trabajo lento debido a un posible problema transitorio. Si ves este patrón de diferencia de forma reiterada, comunícate con Atención al cliente de Cloud para obtener ayuda.

Bytes procesados

Revisa los bytes procesados en la página de detalles del trabajo de consulta o consulta el totalBytesProcessed de JobStatistics para ver si es mayor de lo esperado. Si hay una gran discrepancia de bytes procesados entre las dos consultas, es posible que la consulta haya sido lenta debido a un cambio en el volumen de datos procesados. Si deseas obtener información para optimizar las consultas y controlar grandes volúmenes de datos, consulta Optimiza el procesamiento de las consultas. Los siguientes motivos pueden causar un aumento en la cantidad de bytes que procesa una consulta:

  • Aumentó el tamaño de las tablas a las que hace referencia la consulta.
  • La consulta ahora lee una partición más grande de la tabla.
  • La consulta hace referencia a una vista cuya definición cambió.

Tablas de referencia

Analiza el resultado del campo referencedTables en JobStatistics2 para verificar si las consultas leen las mismas tablas. Las diferencias en las tablas a las que se hace referencia se pueden explicar de la siguiente manera:

  • Se modificó la consulta en SQL para leer diferentes tablas. Compara el texto de la consulta para confirmarlo.
  • La definición de la vista cambió entre las ejecuciones de la consulta. Verifica las definiciones de las vistas a las que se hace referencia en esta consulta y actualízalas si es necesario.

Las diferencias en las tablas de referencia podrían explicar los cambios en totalBytesProcessed.

Uso de vistas materializadas

Si la consulta hace referencia a alguna vista materializada, las diferencias en el rendimiento pueden deberse a que se eligen o rechazan vistas materializadas durante la ejecución de la consulta. Inspecciona MaterializedViewStatistics para comprender si alguna vista materializada que se usó en la consulta rápida se rechazó en la consulta lenta. Observa los campos chosen y rejectedReason en el objeto MaterializedView.

Estadísticas de almacenamiento de metadatos en caché

En el caso de las consultas que involucran tablas de BigLake de Amazon S3 o tablas de BigLake de Cloud Storage con el almacenamiento en caché de metadatos habilitado, compara el resultado de MetadataCacheStatistics para verificar si hay una diferencia en el uso de la caché de metadatos entre la consulta lenta y la rápida, y los motivos correspondientes. Por ejemplo, la caché de metadatos podría estar fuera de la ventana maxStaleness de la tabla.

Compara las estadísticas de BigQuery BI Engine

Si la consulta usa BigQuery BI Engine, analiza el resultado de BiEngineStatistics para determinar si se aplicaron los mismos modos de aceleración a la consulta lenta y a la rápida. Consulta el campo BiEngineReason para comprender el motivo general de la aceleración parcial o la falta de aceleración, como la falta de memoria, la falta de una reserva o la entrada demasiado grande.

Revisa las diferencias en las estadísticas de rendimiento de las consultas

Compara las estadísticas de rendimiento de las consultas para cada una de las consultas con el gráfico de ejecución en la consola de Google Cloud o el objeto StagePerformanceStandaloneInsight para comprender los siguientes problemas posibles:

Presta atención a las estadísticas proporcionadas para el trabajo lento y las diferencias entre las estadísticas producidas para el trabajo rápido para identificar los cambios de etapa que afectan el rendimiento.

Asignación de reserva

Verifica si hay diferencias en la reserva asignada a los dos trabajos. Un cambio en la reserva o un cambio de según demanda a una reserva puede afectar el rendimiento. Para obtener más información, consulta Modelos de administración de cargas de trabajo y tamaño de la reserva.

Un análisis más exhaustivo de los metadatos de ejecución de trabajos requiere revisar las etapas individuales de la ejecución de consultas comparando los objetos ExplainQueryStage de los dos trabajos.

Para comenzar, consulta las métricas Wait ms y Shuffle output bytes que se describen en la sección Interpreta la información de la etapa de consulta.

Advertencias de recursos de la vista INFORMATION_SCHEMA.JOBS

Consulta el campo query_info.resource_warning de la vista INFORMATION_SCHEMA.JOBS para ver si hay una diferencia en las advertencias que analiza BigQuery en relación con los recursos usados.

Análisis de estadísticas de cargas de trabajo

Los recursos de ranuras disponibles y la contención de ranuras pueden afectar el tiempo de ejecución de las consultas. En las siguientes secciones, se explica el uso y la disponibilidad de las ranuras para una ejecución en particular de una consulta.

Promedio de ranuras por segundo

Para calcular la cantidad promedio de ranuras que usa la consulta por milisegundo, divide el valor de milisegundos de ranura del trabajo, totalSlotMs de JobStatistics2, por la duración en milisegundos de la ejecución del intento final de este trabajo, finalExecutionDurationMs de JobStatistics.

También puedes calcular la cantidad promedio de ranuras por milisegundo que usa un trabajo consultando la vista INFORMATION_SCHEMA.JOBS.

Un trabajo que realiza una cantidad similar de trabajo con una cantidad mayor de ranuras promedio por segundo se completa más rápido. Un uso promedio de ranuras por segundo más bajo puede deberse a lo siguiente:

  • No había recursos adicionales disponibles debido a una contención de recursos entre diferentes trabajos: la reserva se agotó.
  • El trabajo no solicitó más ranuras durante una gran parte de la ejecución. Por ejemplo, esto puede suceder cuando hay un sesgo de datos.

Modelos de administración de cargas de trabajo y tamaño de las reservas

Si usas el modelo de facturación a pedido, la cantidad de ranuras que puedes usar por proyecto es limitada. Es posible que, en ocasiones, tu proyecto también tenga menos ranuras disponibles si hay una competencia elevada por la capacidad a pedido en una ubicación específica.

El modelo basado en la capacidad es más predecible y te permite especificar una cantidad confirmada de ranuras de referencia.

Ten en cuenta estas diferencias cuando compares una ejecución de consulta que se ejecuta con el modelo a pedido con una ejecución de consulta que usa una reserva.

Se recomienda usar una reserva para tener un rendimiento de ejecución de consultas estable y predecible. Para obtener más información sobre las diferencias entre las cargas de trabajo según demanda y basadas en la capacidad, consulta Introducción a la administración de cargas de trabajo.

Simultaneidad de trabajos

La simultaneidad de trabajos representa la competencia entre trabajos por los recursos de ranuras durante la ejecución de la consulta. Por lo general, una mayor simultaneidad de trabajos hace que la ejecución de estos sea más lenta, ya que el trabajo tiene acceso a menos ranuras.

Puedes consultar la vista INFORMATION_SCHEMA.JOBS para encontrar la cantidad promedio de trabajos simultáneos que se ejecutan al mismo tiempo que una consulta en particular dentro de un proyecto.

Si hay más de un proyecto asignado a una reserva, modifica la consulta para usar JOBS_BY_ORGANIZATION en lugar de JOBS_BY_PROJECT y obtener datos precisos a nivel de la reserva.

Una simultaneidad promedio más alta durante la ejecución del trabajo lento en comparación con el trabajo rápido es un factor que contribuye a la lentitud general.

Considera reducir la simultaneidad dentro del proyecto o la reserva distribuyendo las consultas que requieren muchos recursos, ya sea a lo largo del tiempo dentro de una reserva o un proyecto, o en diferentes reservas o proyectos.

Otra solución es comprar una reserva o aumentar el tamaño de una reserva existente. Considera permitir que la reserva use ranuras inactivas.

Para comprender cuántas ranuras agregar, lee sobre cómo estimar los requisitos de capacidad de ranuras.

Los trabajos que se ejecutan en reservas con más de un proyecto asignado pueden experimentar diferentes resultados de asignación de ranuras con la misma simultaneidad promedio de trabajos, según el proyecto que los ejecute. Lee sobre la programación justa para obtener más información.

Uso de reservas

Los gráficos de recursos del administrador y Cloud Monitoring para BigQuery se pueden usar para supervisar el uso de las reservas. Para obtener más información, consulta Supervisa reservas de BigQuery.

Para comprender si un trabajo solicitó ranuras adicionales, consulta la métrica de unidades ejecutables estimadas, que es estimatedRunnableUnits de la respuesta de la API de Job, o period_estimated_runnable_units en la vista INFORMATION_SCHEMA.JOBS_TIMELINE. Si el valor de esta métrica es superior a 0, el trabajo podría haberse beneficiado de ranuras adicionales en ese momento. Para estimar el porcentaje del tiempo de ejecución del trabajo en el que el trabajo se habría beneficiado de ranuras adicionales, ejecuta la siguiente consulta en la vista INFORMATION_SCHEMA.JOBS_TIMELINE:

SELECT
  ROUND(COUNTIF(period_estimated_runnable_units > 0) / COUNT(*) * 100, 1) AS execution_duration_percentage
FROM `myproject`.`region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
WHERE job_id = 'my_job_id'
GROUP BY job_id;
 El resultado es similar al siguiente: 
+---------------------------------+
|   execution_duration_percentage |
+---------------------------------+
|                            96.7 |
+---------------------------------+

Un porcentaje bajo significa que la disponibilidad de recursos de ranura no es un factor principal en la lentitud de la consulta en esta situación.

Si el porcentaje es alto y la reserva no se usó por completo durante este tiempo, comunícate con Atención al cliente de Cloud para investigar.

Si la reserva se utilizó por completo durante la ejecución lenta del trabajo y el porcentaje es alto, el trabajo tuvo recursos limitados. Considera reducir la simultaneidad, aumentar el tamaño de la reserva, permitir que la reserva use ranuras inactivas o comprar una reserva si el trabajo se ejecutó a pedido.

Los resultados del análisis de los metadatos del trabajo y de la carga de trabajo no son concluyentes

Si aún no encuentras el motivo que explique el rendimiento de las consultas más lento de lo esperado, comunícate con Atención al cliente de Cloud para obtener ayuda.

Soluciona problemas de consultas con Gemini Cloud Assist

Para usar Gemini Cloud Assist como ayuda para solucionar problemas de rendimiento o de falla de una consulta, haz lo siguiente:

  1. En la consola de Google Cloud , ve a la página BigQuery.

    Ir a BigQuery

  2. En la barra de herramientas de Google Cloud , haz clic en spark Abrir o cerrar el chat de Gemini Cloud Assist.

  3. En el panel de Cloud Assist, ingresa una instrucción que incluya el ID del trabajo para investigar su ejecución, las métricas de rendimiento o los motivos de la falla. Por ejemplo:

    • ¿Por qué falló JOB_ID?
    • ¿Por qué este trabajo tarda tanto? JOB_ID
    • Resume mi rendimiento laboral de las últimas 24 horas.

Soluciona problemas de fallas de consultas con gcpdiag

gcpdiag es una herramienta de código abierto. No es un producto de Google Cloud compatible oficialmente. Puedes usar la herramienta gcpdiag para identificar y corregir problemas del proyecto de Google Cloud. Para obtener más información, consulta el proyecto en GitHub.

La herramienta gcpdiag te ayuda a analizar las consultas de BigQuery con errores para comprender si hay una causa raíz conocida y una mitigación para la falla específica.

Ejecuta el comando gcpdiag

Puedes ejecutar el comando gcpdiag desde Google Cloud CLI:

Consola deGoogle Cloud

  1. Completa y, luego, copia el siguiente comando. 
    2. gcpdiag runbook bigquery/failed-query \
   --parameter project_id=PROJECT_ID \
   --parameter bigquery_job_region=JOB_REGION \
   --parameter bigquery_job_id=JOB_ID \
   --parameter bigquery_skip_permission_check=SKIP_PERMISSION_CHECK
  2. Abre la consola de Google Cloud y activa Cloud Shell.
    3. Abre la consola de Cloud
  3. Pega el comando copiado.
  4. Ejecuta el comando gcpdiag, que descarga la imagen de Docker gcpdiag y, luego, realiza verificaciones de diagnóstico. Si corresponde, sigue las instrucciones de salida para corregir las verificaciones que fallaron.

Docker

Puedes ejecutar gcpdiag con un wrapper que inicie gcpdiag en un contenedor de Docker. Se debe instalar Docker o Podman.

  1. Copia y ejecuta el siguiente comando en tu estación de trabajo local. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Ejecuta el comando gcpdiag. 
    ./gcpdiag runbook bigquery/failed-query \
   --parameter project_id=PROJECT_ID \
   --parameter bigquery_job_region=JOB_REGION \
   --parameter bigquery_job_id=JOB_ID \
   --parameter bigquery_skip_permission_check=SKIP_PERMISSION_CHECK

Consulta los parámetros disponibles para este runbook.

Reemplaza lo siguiente:

  • PROJECT_ID: Es el ID del proyecto que contiene el recurso.
  • JOB_REGION: Es la región en la que se ejecutó el trabajo de BigQuery.
  • JOB_ID: Es el identificador del trabajo de BigQuery.
  • SKIP_PERMISSION_CHECK: (Opcional) Establece este valor en True si quieres omitir la verificación de permisos pertinente y acelerar la ejecución de la guía de runbook (el valor predeterminado es False).

Marcas útiles:

Para obtener una lista y una descripción de todas las marcas de la herramienta gcpdiag, consulta las instrucciones de uso de gcpdiag.

Resolución de esquema de Avro

Cadena del error: Cannot skip stream

Este error puede ocurrir cuando se cargan varios archivos de Avro con diferentes esquemas, lo que genera un problema de resolución del esquema y hace que el trabajo de importación falle en un archivo aleatorio.

Para abordar este error, asegúrate de que el último archivo alfabético en el trabajo de carga contenga el superconjunto (unión) de los esquemas diferentes. Este es un requisito basado en cómo Avro maneja la resolución de esquema.

Consultas simultáneas en conflicto

Cadena del error: Concurrent jobs in the same session are not allowed

Este error puede ocurrir cuando varias consultas se ejecutan de forma simultánea en una sesión, lo que no se admite. Consulta las limitaciones de sesión.

Sentencias DML en conflicto

Cadena del error: Could not serialize access to table due to concurrent update

Este error se produce cuando las declaraciones de lenguaje de manipulación de datos (DML) simultáneas (UPDATE, DELETE o MERGE) intentan modificar datos en la misma partición de tabla de forma simultánea o cuando la tabla se trunca mientras se ejecuta una sentencia DML.

BigQuery permite que las sentencias DML de mutación simultáneas se ejecuten en la misma tabla, siempre que modifiquen particiones diferentes. Sin embargo, si dos trabajos intentan modificar la misma partición, el primer trabajo que se confirma se ejecuta correctamente y los trabajos posteriores fallan con este error.

Para resolver este error, prueba lo siguiente:

  • Vuelve a intentar el trabajo con errores: Si el conflicto se debió a una superposición temporal con otro trabajo, vuelve a intentar la consulta después de que se complete el trabajo en conflicto.
  • Identifica y coordina los trabajos en conflicto: Ejecuta la consulta de diagnóstico en la siguiente sección para identificar el trabajo en conflicto y, luego, coordina los programas para que las operaciones de DML de mutación en la misma partición no se ejecuten al mismo tiempo.
  • Particiona tus tablas: Si los trabajos de DML simultáneos actualizan diferentes segmentos de datos, particiona tu tabla por fecha o rango de números enteros. Las sentencias DML de mutación simultáneas se ejecutan de forma correcta sin conflictos si modifican particiones diferentes.
  • Operaciones de DML por lotes: Combina varias operaciones UPDATE o DELETE individuales en una sola sentencia MERGE o un trabajo por lotes para reducir la simultaneidad y la sobrecarga de confirmación. Para obtener más información, consulta las Prácticas recomendadas.

Identifica el trabajo en conflicto

Para identificar qué trabajo actualizaba la tabla de forma simultánea cuando se produjo el error, ejecuta una consulta en la vista INFORMATION_SCHEMA.JOBS:

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

Reemplaza lo siguiente:

  • REGION: Es el nombre de la región en la que se encuentra el conjunto de datos, por ejemplo, us.
  • FAILED_JOB_START_TIME: Es la marca de tiempo en la que comenzó el trabajo con errores, por ejemplo, 2026-09-01 09:55:00 UTC.
  • FAILED_JOB_END_TIME: Es la marca de tiempo en la que finalizó el trabajo con errores, por ejemplo, 2026-09-01 10:00:00 UTC.
  • TABLE_NAME: Es el nombre de la tabla que la sentencia DML con errores intentó actualizar.
  • DATASET_NAME: Es el nombre del conjunto de datos que contiene la tabla.

Si la consulta no muestra trabajos iniciados por el usuario en conflicto, es posible que el conflicto se haya producido por otra operación en segundo plano, como el vencimiento de la partición.

Otras causas de conflictos de actualización simultánea

  • Vencimiento de la partición: Las tareas del sistema en segundo plano que vencen las particiones pueden entrar en conflicto con una declaración DML si modifican la misma partición durante la ejecución del trabajo. Si usas el vencimiento de particiones, programa los trabajos de DML fuera de los horarios en los que vencen las particiones.
  • Transacciones de varias sentencias: Cuando una transacción de varias sentencias muta una tabla, bloquea todas las demás sentencias DML simultáneas en esa tabla hasta que se completa la transacción.
  • Sentencias DML que afectan a cero filas: Una sentencia UPDATE, DELETE o MERGE adquiere bloqueos en las particiones de destino y puede causar conflictos de serialización, incluso si ninguna fila coincide con las condiciones del filtro.

Para obtener más información, consulta Conflictos de sentencias DML.

Subconsultas correlacionadas

Cadena del error: Correlated subqueries that reference other tables are not supported unless they can be de-correlated

Este error puede ocurrir cuando tu consulta contiene una subconsulta que hace referencia a una columna desde el exterior de esa subconsulta, llamada columna de correlación. La subconsulta correlacionada se evalúa con una estrategia de ejecución anidada y poco eficiente, en la que se evalúa la subconsulta para cada fila de la consulta externa que produce las columnas de correlación. A veces, BigQuery puede volver a escribir internamente las consultas con subconsultas correlacionadas para que se ejecuten de manera más eficiente. El error de subconsultas correlacionadas ocurre cuando BigQuery no puede optimizar la consulta de forma suficiente.

Para resolver este error, prueba lo siguiente:

  • Quita las cláusulas ORDER BY, LIMIT, EXISTS, NOT EXISTS o IN de la subconsulta.
  • Usa una consulta de varias instrucciones para crear una tabla temporal a la que hacer referencia en tu subconsulta.
  • Vuelve a escribir la consulta para usar CROSS JOIN en su lugar.

Permisos insuficientes de control de acceso a nivel de columna

Cadenas de error:

  • Access denied: Requires fineGrainedGet permission on the read columns to execute the DML statements
  • `Acceso denegado: El usuario no tiene permiso para acceder a la etiqueta de política projects/PROJECT_ID/locations/LOCATION/taxonomies/TAXONOMY_ID/policyTags/POLICY_TAG_ID en la columna PROJECT_ID.DATASET.TABLE.COLUMN.'

Estos errores se producen cuando intentas ejecutar una consulta en SQL o una declaración DELETE, UPDATE o MERGE de DML sin que se te otorgue el rol de lector detallado en las columnas que usan el control de acceso a nivel de columna. Este rol se asigna a las principales como parte de la configuración de una etiqueta de política. Para obtener más información, consulta Impacto en las operaciones de escritura del control de acceso a nivel de columna.

Para solucionar este problema, modifica la consulta para excluir las columnas con etiquetas de política u otorga el rol de lector detallado al usuario. Este rol se asigna a las principales como parte de la configuración de una etiqueta de política. Para obtener más información, consulta Actualiza los permisos en las etiquetas de política.

Soluciona problemas de consultas programadas

Los siguientes problemas pueden surgir durante la configuración o ejecución de la consulta programada.

La consulta programada activa ejecuciones duplicadas

Es posible que una consulta programada se active más de una vez a la hora programada. Es más probable que este comportamiento ocurra en las consultas programadas exactamente en la hora (como las 09:00). Esto puede generar resultados inesperados, como datos duplicados si la consulta realiza operaciones INSERT.

Para minimizar el riesgo de ejecuciones duplicadas, programa tus consultas en un horario que no sea en punto, como unos minutos antes o después de la hora (por ejemplo, 08:58 o 09:03). Para obtener más información, consulta Programa consultas.

Las credenciales no son válidas para las consultas programadas

Cadenas de error:

  • Error code: INVALID_USERID
  • Error code 5: Authentication failure: User Id not found
  • PERMISSION_DENIED: BigQuery: Permission denied while getting Drive credentials

Este error puede ocurrir cuando una consulta programada falla debido a credenciales desactualizadas, en especial cuando se consultan datos de Google Drive.

Para abordar este error, sigue estos pasos:

Las credenciales de la cuenta de servicio no son válidas.

Cadena del error: HttpError 403 when requesting returned: The caller does not have permission

Este error puede aparecer cuando intentas configurar una consulta programada con una cuenta de servicio. Para resolver este error, consulta los pasos para solucionar problemas en Problemas de autorización y permisos.

El tiempo de la instantánea no es válido

Cadena del error: Invalid snapshot time

Este error puede ocurrir cuando intentas consultar datos históricos que están fuera del período de viaje en el tiempo del conjunto de datos. Para abordar este error, cambia la consulta a fin de acceder a los datos históricos dentro del período de viaje en el tiempo del conjunto de datos.

Este error también puede aparecer si una de las tablas usadas en la consulta se descarta y se vuelve a crear después de que comienza la consulta. Verifica si hay una consulta programada o una aplicación que realice esta operación que se ejecutó al mismo tiempo que la consulta con errores. Si es así, intenta mover el proceso que realiza la operación de descarte y recreación para que se ejecute en un momento que no entre en conflicto con las consultas que leen esa tabla.

El trabajo ya existe

Cadena del error: Already Exists: Job <job name>

Este error puede ocurrir en los trabajos de consulta que deben evaluar arrays grandes, de modo que la creación de un trabajo de consulta tome más tiempo que el promedio. Por ejemplo, una consulta con una cláusula WHERE como WHERE column IN (<2000+ elements array>).

Para abordar este error, sigue estos pasos:

Este error también puede ocurrir cuando configuras manualmente un ID de trabajo, pero este no devuelve un resultado correcto dentro de un período de tiempo de espera. En este caso, puedes agregar un controlador de excepciones para verificar si el trabajo existe. Si es así, puedes extraer los resultados de la consulta del trabajo.

Trabajo no encontrado

Cadena del error: Job not found

Este error puede ocurrir en respuesta a una llamada getQueryResults, en la que no se especifica ningún valor para el campo location. Si ese es el caso, vuelve a intentar la llamada y proporciona un valor location.

Para obtener más información, consulta Evita varias evaluaciones de las mismas expresiones de tabla comunes (CTE).

No se encontró la ubicación

Cadena del error: Dataset [project_id]:[dataset_id] was not found in location [region]

Este error se muestra cuando haces referencia a un recurso de conjunto de datos que no existe o cuando la ubicación de la solicitud no coincide con la ubicación del conjunto de datos.

Para solucionar este problema, especifica la ubicación del conjunto de datos en la consulta o confirma que el conjunto de datos esté disponible en la misma ubicación.

La consulta excede el límite de tiempo de ejecución

Cadena del error: Query fails due to reaching the execution time limit

Si tu consulta llega al límite de tiempo de ejecución de la consulta, verifica el tiempo de ejecución de las ejecuciones anteriores de la consulta mediante una consulta a la vista INFORMATION_SCHEMA.JOBS con una consulta similar al siguiente ejemplo:

SELECT TIMESTAMP_DIFF(end_time, start_time, SECOND) AS runtime_in_seconds
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE statement_type = 'QUERY'
AND query = "my query string";

Si las ejecuciones anteriores de la consulta tomaron mucho menos tiempo, usa las estadísticas de rendimiento de las consultas para determinar y abordar el problema subyacente.

La consulta supera el límite máximo de bytes facturados

Cadena del error: Query exceeded limit for bytes billed: LIMIT_BYTES. REQUIRED_BYTES or higher required.

Este error de HTTP 400 Bad Request (reason: bytesBilledLimitExceeded) se produce cuando la estimación previa a la ejecución de los bytes que se facturarán por una consulta (REQUIRED_BYTES) supera el límite de bytes configurado en maximumBytesBilled (LIMIT_BYTES). BigQuery falla el trabajo antes de la ejecución y no cobra por la consulta.

Debido a que los precios según demanda aplican un mínimo de 10 MB (10,485,760 bytes) por tabla de referencia y la estimación previa a la ejecución para las tablas agrupadas calcula un límite superior en todas las particiones coincidentes antes de que se produzca la reducción del clúster, REQUIRED_BYTES puede ser mayor que los bytes reales analizados cuando se ejecuta la consulta.

Para solucionar este problema, realiza una de las siguientes acciones:

  • Obtén una vista previa de los bytes estimados con una ejecución de prueba. Ejecuta una ejecución de prueba (bq query --dry_run en la CLI de bq o configuration.dryRun = true en la API) o verifica el validador de consultas en la consola de Google Cloud para inspeccionar totalBytesProcessed antes de ejecutar la consulta.
  • Optimiza la consulta para analizar menos bytes. Selecciona solo las columnas que necesita tu consulta en lugar de ejecutar SELECT * y filtra las columnas particionadas para que BigQuery pueda reducir las particiones durante la estimación previa a la ejecución. Filtrar las columnas agrupadas en clústeres reduce los bytes reales facturados cuando se ejecuta la consulta, pero no reduce la estimación del límite superior previo a la ejecución que se verifica con maximumBytesBilled. Para obtener más información, consulta Reduce el procesamiento de datos.
  • Aumenta el límite de maximumBytesBilled. Establece el límite de bytes de maximumBytesBilled en un valor igual o superior al valor de REQUIRED_BYTES que se informa en el mensaje de error con la opción Cantidad máxima de bytes facturados (en Configuración de consultas > Opciones avanzadas) en la consola de Google Cloud , la marca --maximum_bytes_billed en la CLI de bq o la propiedad de configuración del trabajo configuration.query.maximumBytesBilled en la API.

La respuesta de la consulta es demasiado grande

Cadena del error: responseTooLarge

Este error ocurre cuando los resultados de tu consulta son más grandes que el tamaño máximo de respuesta o cuando una sola fila supera el límite de tamaño de fila de la API de REST.

Algunas consultas se ejecutan en varias etapas, y este error se produce cuando alguna etapa devuelve un tamaño de respuesta demasiado grande, incluso si el resultado final es menor que el máximo. Este error suele ocurrir cuando las consultas usan una cláusula ORDER BY. A veces, quitar la cláusula ORDER BY o agregar una cláusula LIMIT puede ayudar. Para garantizar que se puedan mostrar resultados grandes, especifica una tabla de destino en la configuración del trabajo. Para las consultas en SQL heredado, también debes establecer la propiedad configuration.query.allowLargeResults en true. Para obtener más información, consulta Escribe resultados de consultas grandes.

Se superó el límite de tamaño de la respuesta de una sola fila

Cadenas de error:

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

Este error de HTTP 403 Forbidden (reason: responseTooLarge) se produce cuando lees resultados de consultas o filas de tablas con los métodos de la API de REST jobs.getQueryResults o tabledata.list (incluida la visualización de resultados en la consola de Google Cloud o la herramienta de línea de comandos de bq), y una sola fila serializada no anidada supera el tamaño máximo de fila admitido por el extremo de paginación de REST (20 MB para jobs.getQueryResults o 100 MB para tabledata.list). Esto suele ocurrir en tablas con esquemas amplios, campos ARRAY o STRUCT repetidos y muy anidados, o valores STRING o BYTES grandes.

Para leer filas que superen los límites de tamaño de fila de la API de REST, realiza una de las siguientes acciones:

  • Usa la API de BigQuery Storage Read. Lee la tabla o la tabla de destino de la consulta temporal con la API de Storage Read, que transmite datos en formato binario de Apache Arrow o Avro, y admite lecturas de alta capacidad de procesamiento de estructuras de filas grandes y complejas.
  • Exporta la tabla a Cloud Storage. Exporta la tabla o los resultados de la consulta a Cloud Storage con una sentencia EXPORT DATA o un trabajo de extracción (por ejemplo, en formato Avro, Parquet o JSON) y lee los archivos exportados desde Cloud Storage.
  • Proyecta o agrega menos columnas. En lugar de ejecutar SELECT *, selecciona solo las columnas o los subcampos específicos que requiere tu aplicación o desanida los arrays repetidos en tu consulta para que las filas de salida individuales se mantengan por debajo del límite de tamaño.

Falta un parámetro obligatorio

Cadena del error: Required parameter is missing: PARAMETER_NAME

Este error de HTTP 400 Bad Request (reason: required) es un error de validación de la API previo a la ejecución que se produce cuando no se proporciona un campo obligatorio en una carga útil o URL de solicitud a la API, o cuando una propiedad obligatoria en un objeto de configuración de la biblioteca cliente es null o None.

Para resolver este error, haz lo siguiente:

  • Consulta la referencia de la API de REST. Inspecciona el PARAMETER_NAME en el mensaje de error y revisa el cuerpo de la solicitud y los parámetros de consulta obligatorios para el método en la referencia de la API de REST de BigQuery para asegurarte de que tu código complete todos los campos obligatorios.
  • Verifica los parámetros de la biblioteca cliente. Si usas una biblioteca cliente de BigQuery (como la biblioteca cliente de Java o Python), consulta la documentación de la biblioteca cliente para conocer los parámetros obligatorios del método al que llamas.
  • Inspecciona el objeto de configuración antes de llamar a la API. Usa un depurador o una instrucción de registro para inspeccionar el objeto de configuración del trabajo o de la solicitud justo antes de que se ejecute la llamada a la API y verifica si hay valores None o null asignados a las propiedades obligatorias, como destinationTable.

No se encontró la reserva o faltan ranuras

Cadena del error: Cannot run query: project does not have the reservation in the data region or no slots are configured

Este error se produce cuando la reserva asignada al proyecto en la región de la consulta tiene cero ranuras asignadas. Puedes agregar ranuras a la reserva, permitir que la reserva use ranuras inactivas, usar una reserva diferente o quitar la asignación y ejecutar la consulta según demanda.

No se encontró la tabla

Cadena del error: Not found: Table [project_id]:[dataset].[table_name] was not found in location [region]

Este error ocurre cuando no se puede encontrar una tabla de tu consulta en el conjunto de datos o la región que especificaste. Para resolver este error, haz lo siguiente:

  • Verifica que tu consulta contenga el nombre correcto del proyecto, del conjunto de datos y de la tabla.
  • Verifica que la tabla exista en la región en la que ejecutaste la consulta.
  • Asegúrate de que la tabla no se haya borrado ni vuelto a crear durante la ejecución del trabajo. De lo contrario, la propagación incompleta de metadatos puede causar este error.

Demasiadas sentencias DML

Cadena del error: Too many DML statements outstanding against <table-name>, limit is 20

Este error se produce cuando superas el límite de 20 sentencias DML de mutación en el estado PENDING en una cola para una sola tabla. Por lo general, este error ocurre cuando envías trabajos DML en una sola tabla más rápido de lo que puede procesar BigQuery.

Para verificar los trabajos en estado PENDING que llenan la cola junto con los trabajos RUNNING que podrían impedir que se quiten de la cola, consulta la vista INFORMATION_SCHEMA.JOBS:

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

Una solución posible es agrupar varias operaciones DML más pequeñas en trabajos más grandes, pero menos numerosos, por ejemplo, si agrupas en lotes las actualizaciones y las inserciones. Cuando agrupas trabajos más pequeños en trabajos más grandes, el costo de ejecutar los trabajos más grandes se amortiza y la ejecución es más rápida. Por lo general, la consolidación de sentencias DML que afectan a los mismos datos mejora la eficiencia de los trabajos DML y es menos probable que exceda el límite de cuota de tamaño de las colas. Para obtener más información acerca de cómo optimizar tus operaciones DML, consulta Evita sentencias DML que actualizan o insertan filas individuales.

Otras soluciones para mejorar la eficiencia del DML podrían ser particionar o agrupar en clústeres tus tablas. Para obtener más información, consulta las Prácticas recomendadas.

Error 403: Se superó la cuota

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

Este error se produce cuando la cantidad total de trabajos de DML (INSERT, UPDATE, DELETE y MERGE) que escriben en una sola tabla, en los estados PENDING y RUNNING, supera la cuota de simultaneidad de la tabla.

Mientras que el error limit is 20 restringe específicamente la cola PENDING para las sentencias DML de mutación (UPDATE, DELETE y MERGE), este error 403 Quota exceeded se aplica al total combinado de todos los trabajos de DML (INSERT más DML de mutación) que escriben en una tabla de forma simultánea. Debido a que el DML de mutación ya está limitado por su límite de cola de 20 trabajos, este error de cuota 403 ocurre con mayor frecuencia cuando envías demasiadas consultas INSERT simultáneas en una sola tabla. Para resolver este error, haz lo siguiente:

  • Aumenta las ranuras de reserva: Aumenta la cantidad de ranuras en tu reserva para ayudar a que los trabajos se completen más rápido y reducir la simultaneidad de los trabajos. Esto reduce la cantidad de trabajos pendientes en la cola y ayuda a evitar que se alcance el límite.
  • Optimiza la organización del flujo de trabajo: Limita la cantidad de tareas de DML simultáneas en tu herramienta de organización para evitar exceder los límites de simultaneidad a nivel de la tabla (incluidas las consultas INSERT de alta frecuencia orientadas a la misma tabla).
  • Operaciones DML por lotes: Combina varias sentencias DML más pequeñas en menos sentencias más grandes para reducir la cantidad total de trabajos en cola en la tabla.

Se anuló la transacción debido a una actualización simultánea

Cadena del error: Transaction is aborted due to concurrent update against table [table_name]

Este error puede ocurrir cuando dos sentencias DML de mutación diferentes intentan actualizar la misma tabla de forma simultánea. Por ejemplo, supongamos que inicias una transacción en una sesión que contiene una sentencia DML mutante seguida de un error. Si no hay un controlador de excepciones, BigQuery revierte automáticamente la transacción cuando finaliza la sesión, lo que tarda hasta 24 horas. Durante este período, fallarán otros intentos de ejecutar una declaración DML de mutación en la tabla.

Para abordar este error, enumera tus sesiones activas y verifica si alguna de ellas contiene un trabajo de consulta con el estado ERROR que ejecutó una declaración DML de mutación en la tabla. Luego, finaliza esa sesión.

Error 412: El trabajo hace referencia a una tabla que pertenece a un conjunto de datos de conmutación por error

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

Esto significa que el trabajo no se ejecutó con una edición de BigQuery Enterprise Plus o que se ejecutó en una región que no es la ubicación principal del conjunto de datos de conmutación por error. Consulta Recuperación ante desastres administrada para obtener más detalles.

Se produce un error cuando se carga la vista con resultados almacenados en caché

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

Este error indica que no se otorgó acceso a tus IDs de cliente de Google Workspace en la restricción de la política de la organización. Para obtener información sobre el uso de la restricción iam.allowedPolicyMemberDomains, consulta Usa la restricción iam.allowedPolicyMemberDomains para implementar el uso compartido restringido del dominio.

Errores de SQL heredado

Los siguientes errores pueden surgir cuando se usa SQL heredado.

Cannot be queried with legacy SQL

Cadena del error: cannot be queried with legacy SQL. Please consider switching to standard SQL

Este error puede ocurrir en una de las siguientes situaciones:

  • La consulta se escribió en SQL estándar, pero se aprovisionó la opción de usar SQL heredado de forma explícita. Asegúrate de ejecutar la consulta con SQL estándar siguiendo la documentación pública, por ejemplo, proporcionando --use_legacy_sql=false con la herramienta de línea de comandos de bq.

  • Intentas consultar una tabla con intercalación mediante SQL heredado, que no es compatible.

No se pueden consultar las tablas con columnas renombradas con SQL heredado

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

Este error se produce si consultas una tabla con una columna a la que se le cambió el nombre con SQL heredado. En su lugar, usa SQL estándar.

El usuario no tiene permiso

Cadenas de error:

  • Access Denied: Project [project_id]: User does not have bigquery.jobs.create permission in project [project_id].
  • User does not have permission to query table project-id:dataset.table.
  • Access Denied: User does not have permission to query table or perhaps it does not exist.

Estos errores pueden ocurrir cuando ejecutas una consulta sin el permiso bigquery.jobs.create en el proyecto en el que ejecutas la consulta, sin importar los permisos en el proyecto que contiene los datos.

También puedes recibir estos errores si tu cuenta de servicio, usuario o grupo no tiene el permiso bigquery.tables.getData en todas las tablas y vistas a las que hace referencia tu consulta. Para obtener más información sobre los permisos necesarios para ejecutar una consulta, consulta Roles necesarios.

Estos errores también pueden ocurrir si la tabla no existe en la región consultada, como asia-south1. Para verificar la región, examina la ubicación del conjunto de datos.

Cuando abordes estos errores, ten en cuenta lo siguiente:

  • Cuentas de servicio: Las cuentas de servicio deben tener el permiso bigquery.jobs.create en el proyecto desde el que se ejecutan y deben tener el permiso bigquery.tables.getData en todas las tablas y vistas a las que hace referencia la consulta.

  • Roles personalizados: Los roles personalizados de IAM deben tener el permiso bigquery.jobs.create incluido de forma explícita en el rol relevante y deben tener el permiso bigquery.tables.getData en todas las tablas y vistas a las que hace referencia la consulta.

  • Conjuntos de datos compartidos: Cuando trabajas con conjuntos de datos compartidos en un proyecto independiente, es posible que aún necesites el permiso bigquery.jobs.create en el proyecto para ejecutar consultas o trabajos en ese conjunto de datos.

Para otorgar permiso de acceso a una tabla o vista, consulta Otorga acceso a una tabla o vista.

Se denegó el permiso bigquery.reservations.use en la reserva

Cadena del error:

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

Este error se produce cuando se asigna una consulta para que se ejecute en una reserva específica con la sentencia SET @@reservation y a la cuenta de usuario o de servicio le falta el permiso bigquery.reservations.use. Puedes inspeccionar la falla en Cloud Logging o en la página de trabajos de BigQuery para identificar qué principal intentó realizar esta operación.

Otros errores de Access Denied

Cadenas de error:

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

Para solucionar problemas generales de Access Denied en BigQuery, usa el Analizador de políticas para determinar qué acceso tiene una principal a un recurso.

En el Analizador de políticas, proporciona el recurso de BigQuery al que intentas acceder (por ejemplo, //bigquery.googleapis.com/projects/YOUR_PROJECT/datasets/YOUR_DATASET/tables/YOUR_TABLE) y el correo electrónico del usuario o de la cuenta de servicio que recibe el error Access Denied como principal. En el análisis, se muestran los permisos de la principal en el recurso, que puedes comparar con los permisos faltantes en el mensaje de error.

No se admite la encriptación de destino para las secuencias de comandos

Cadena del error: configuration.query.destinationEncryptionConfiguration cannot be set for scripts

Este error se produce cuando se intenta establecer la configuración de encriptación de destino para un trabajo de secuencia de comandos de BigQuery, que no es compatible.

Se denegó el acceso por la política de la organización

Cadena del error: IAM setPolicy failed for Dataset DATASET: Operation denied by org policy on resource.

Este error ocurre cuando una política de la organización impide que el principal consulte un recurso de BigQuery. El Servicio de políticas de la organización te permite aplicar restricciones en los recursos compatibles de toda la jerarquía de la organización.

Si la principal debe tener acceso al recurso, deberás usar las herramientas de solución de problemas de VPC disponibles para diagnosticar el problema con la política de la organización.

Problemas de recursos excedidos

Los siguientes problemas se producen cuando BigQuery no tiene recursos suficientes para completar la consulta.

La consulta supera los recursos de CPU

Cadena del error: Query exceeded resource limits. This query used CPU_SECONDS_USED CPU seconds but would charge only ANALYSIS_MEGABYTES_BILLEDM Analysis bytes. This exceeds the ratio supported by the on-demand pricing model. Please consider moving this workload to a capacity-based pricing model, which does not have this limit. CPU_SECONDS_USED CPU seconds were used, and this query must use less than CPU_SECONDS_LIMIT CPU seconds.

Este error (billingTierLimitExceeded) se produce cuando una consulta que usa precios on-demand supera el límite máximo de uso de CPU por datos analizados de aproximadamente 256 segundos de CPU por MiB de datos analizados. Esto sucede cuando una consulta on demand realiza operaciones que requieren un uso intensivo de la CPU, como operaciones CROSS JOIN sin restricciones, condiciones de unión inexactas, expresiones regulares complejas, funciones de ventana analítica sin particiones o UDF de JavaScript con un uso intensivo de procesamiento, en una cantidad relativamente pequeña de datos analizados.

Para resolver este error, haz lo siguiente:

  • Optimiza la consulta. Refactoriza tu SQL para reducir la sobrecarga de procesamiento en relación con los datos analizados, por ejemplo, quitando productos cartesianos no deseados (operaciones CROSS JOIN sin filtrado), reemplazando predicados de unión inexactos, simplificando expresiones regulares complejas, agregando cláusulas PARTITION BY a funciones analíticas en ventanas grandes sin particiones o optimizando las UDF de JavaScript. Para obtener más información, consulta Evita patrones anti-SQL, Introducción a la optimización del rendimiento de las consultas y Soluciona problemas de recursos excedidos.
  • Cambia a los precios basados en la capacidad. Ejecuta la carga de trabajo con precios basados en la capacidad (ranuras). En los precios basados en la capacidad, las consultas no están sujetas al límite de proporción de CPU a bytes a pedido.

La consulta excede los recursos de memoria

Cadena del error: Resources exceeded during query execution: The query could not be executed in the allotted memory

En las sentencias SELECT, este error se produce cuando la consulta usa demasiados recursos. Para abordar este error, consulta Soluciona problemas de recursos excedidos.

No hay espacio en la pila

Cadena del error: Out of stack space due to deeply nested query expression during query resolution.

Este error puede ocurrir cuando una consulta contiene demasiadas llamadas a funciones anidadas. A veces, algunas partes de una consulta se traducen en llamadas a funciones durante el análisis. Por ejemplo, una expresión con operadores de concatenación repetidos, como A || B || C || ..., se convierte en CONCAT(A, CONCAT(B, CONCAT(C, ...))).

Para solucionar este error, vuelve a escribir la consulta para reducir la cantidad de anidamientos.

Se excedieron los recursos durante la ejecución de la consulta

Cadena del error: Resources exceeded during query execution: The query could not be executed in the allotted memory. Peak usage: [percentage]% of limit. Top memory consumer(s): ORDER BY operations.

Esto puede suceder con las consultas ORDER BY ... LIMIT ... OFFSET .... Debido a los detalles de implementación, la ordenación puede ocurrir en una sola unidad de procesamiento, que puede quedarse con memoria insuficiente si necesita procesar demasiadas filas antes de que se apliquen LIMIT y OFFSET, en especial con un OFFSET grande.

Para abordar este error, evita valores OFFSET grandes en las consultas ORDER BY … LIMIT. Como alternativa, usa la función analítica escalable ROW_NUMBER() para asignar clasificaciones según el orden elegido y, luego, filtra estas clasificaciones en una cláusula WHERE. Por ejemplo:

SELECT ...
FROM (
  SELECT ROW_NUMBER() OVER (ORDER BY ...) AS rn
  FROM ...
)
WHERE rn > @start_index AND rn <= @page_size + @start_index  -- note that row_number() starts with 1

El trabajador de TensorFlow se quedó sin memoria

Cadena del error: Resources exceeded during query execution: TensorFlow worker out of memory.

Los modelos que superan el límite de memoria (por lo general, 250 MB), en especial cuando se usan funciones que consumen muchos recursos, como ML.EXPLAIN_PREDICT, pueden activar este error.

Para resolver este error, haz lo siguiente:

  1. Usa modelos remotos de Gemini Enterprise Agent Platform: Para los modelos que superan los límites de memoria, implementa tu modelo en Agent Platform con los pasos del SDK de Vertex AI para Python para implementar un modelo y, luego, accede a él con modelos remotos. Esto descarga los requisitos de memoria en la infraestructura dedicada de la plataforma de agentes.

  2. Optimiza el modelo: Reduce el uso de RAM del modelo con la simplificación, la cuantización o la reducción de la arquitectura.

  3. Usa funciones menos intensivas: Si el error se produce durante una llamada a ML.EXPLAIN_PREDICT, intenta ejecutar el trabajo con ML.PREDICT para determinar si el modelo se puede ejecutar sin la sobrecarga adicional de las funciones de explicabilidad.

  4. Analiza el tamaño de los datos de entrada: Las filas individuales grandes pueden contribuir al agotamiento de la memoria. Verifica el tamaño de tus filas más grandes con lo siguiente: 

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

La consulta excede los recursos de Shuffle

Cadena del error: Resources exceeded during query execution: Your project or organization exceeded the maximum disk and memory limit available for shuffle operations

Este error ocurre cuando una consulta no puede acceder a suficientes recursos de Shuffle.

Para abordar este error, aprovisiona más ranuras o reduce la cantidad de datos que procesa la consulta. Para obtener más información sobre las formas de hacerlo, consulta Cuota de Shuffle insuficiente.

Si usas el modelo de precios a pedido, estás limitado a un máximo de 2,000 ranuras. Para aumentar la cantidad de ranuras, debes cambiar a un modelo de precios basado en la capacidad.

Si deseas obtener información adicional para resolver estos problemas, consulta Soluciona problemas de recursos excedidos.

La consulta es demasiado compleja

Cadena del error: Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex

Este error ocurre cuando una consulta es demasiado compleja. Las siguientes son las causas principales de la complejidad:

  • Cláusulas WITH que se anidan de forma profunda o se usan de forma repetida.
  • Vistas que se anidan de forma profunda o se usan de manera repetida.
  • Uso reiterado del operador UNION ALL.

Para resolver este error, prueba las siguientes opciones:

  • Divide la consulta en varias consultas y, luego, usa el lenguaje de procedimiento para ejecutar esas consultas en una secuencia con estado compartido.
  • Usa tablas temporales en lugar de cláusulas WITH.
  • Vuelve a escribir tu consulta para reducir la cantidad de objetos a los que se hace referencia y las comparaciones.

Puedes supervisar de forma proactiva las consultas que se acercan al límite de complejidad con el campo query_info.resource_warning en la vista INFORMATION_SCHEMA.JOBS. En el siguiente ejemplo, se muestran las consultas con un alto uso de recursos durante los últimos tres días:

SELECT
  ANY_VALUE(query) AS query,
  MAX(query_info.resource_warning) AS resource_warning
FROM
  <your_project_id>.`region-us`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 DAY)
  AND query_info.resource_warning IS NOT NULL
GROUP BY
  query_info.query_hashes.normalized_literals
LIMIT
  1000

Si deseas obtener información adicional para resolver estos problemas, consulta Soluciona problemas de recursos excedidos.

Soluciona problemas de recursos excedidos

Para los trabajos de consulta, haz lo siguiente:

Para optimizar tus consultas, prueba los siguientes pasos:

  • Intenta quitar una cláusula ORDER BY.
  • Si tu consulta usa JOIN, asegúrate de que la tabla más grande se encuentre en el lado izquierdo de la cláusula. También asegúrate de que tus datos no contengan claves de unión duplicadas.
  • Si tu consulta usa FLATTEN, determina si es necesario para tu caso práctico. A fin de obtener más información, consulta los datos anidados y repetidos.
  • Si tu consulta usa EXACT_COUNT_DISTINCT, considera reemplazar este valor por COUNT(DISTINCT).
  • Si tu consulta usa COUNT(DISTINCT <value>, <n>) con un valor <n> grande, considera usar GROUP BY en su lugar. Para obtener más información, consulta COUNT(DISTINCT):
  • Si tu consulta usa UNIQUE, considera usar GROUP BY en su lugar, o una función analítica dentro de una subselección.
  • Si tu consulta materializa muchas filas mediante una cláusula LIMIT, te recomendamos filtrar en otra columna, por ejemplo, ROW_NUMBER(), o quitar la cláusula LIMIT por completo para permitir la paralelización de escritura.
  • Si tu consulta usó vistas anidadas de manera profunda y una cláusula WITH, esto puede causar un crecimiento exponencial de la complejidad y, por lo tanto, alcanzar los límites.
  • Usa tablas temporales en lugar de cláusulas WITH. Es posible que una cláusula WITH deba volver a calcularse varias veces, lo que puede hacer que la consulta sea compleja y, por lo tanto, lenta. Conservar los resultados intermedios en tablas temporales reduce la complejidad.
  • Evita usar consultas UNION ALL.
  • Si tu consulta usa MATCH_RECOGNIZE, modifica la cláusula PARTITION BY para reducir el tamaño de las particiones o agrega una cláusula PARTITION BY si no existe una.

Para obtener más información, consulta los siguientes recursos:

Para los trabajos de carga, haz lo siguiente:

Si cargas archivos Avro o Parquet, reduce el tamaño de las filas en los archivos. Comprueba si hay restricciones de tamaño específicas para el formato de archivo que cargas:

Si recibes este error cuando cargas archivos ORC, comunícate con el equipo de asistencia.

Para la API de Storage:

Cadena del error: Stream memory usage exceeded

Durante una llamada ReadRows a la API de lectura de almacenamiento, algunas transmisiones con uso de memoria alto pueden recibir un error RESOURCE_EXHAUSTED con este mensaje. Esto puede suceder cuando se lee desde tablas anchas o con tablas con un esquema complejo. Como resolución, reduce el tamaño de la fila resultante. Para ello, selecciona menos columnas para leer (con el parámetro selected_fields) o simplifica el esquema de la tabla.

Soluciona problemas de conectividad

En las siguientes secciones, se describe cómo solucionar problemas de conectividad cuando intentas interactuar con BigQuery:

Agrega el DNS de Google a la lista de entidades permitidas

Usa la herramienta IP Dig de Google para resolver el extremo de DNS de BigQuery bigquery.googleapis.com en una sola IP de registro "A". Asegúrate de que esta IP no esté bloqueada en la configuración de tu firewall.

En general, recomendamos incluir en la lista de entidades permitidas los nombres de DNS de Google. Los rangos de IP que se comparten en los archivos https://www.gstatic.com/ipranges/goog.json y https://www.gstatic.com/ipranges/cloud.json cambian con frecuencia. Por lo tanto, recomendamos agregar los nombres de DNS de Google a la lista de entidades permitidas. Esta es una lista de nombres de DNS comunes que recomendamos agregar a la lista de entidades permitidas:

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

Identifica el proxy o el firewall que descarta paquetes

Para identificar todos los saltos de paquetes entre el cliente y Google Front End (GFE), ejecuta un comando traceroute en tu máquina cliente que podría destacar el servidor que descarta los paquetes dirigidos al GFE. Este es un comando traceroute de ejemplo:

traceroute -T -p 443 bigquery.googleapis.com

También es posible identificar los saltos de paquetes para direcciones IP de GFE específicas si el problema está relacionado con una dirección IP en particular:

traceroute -T -p 443 142.250.178.138

Si hay un problema de tiempo de espera del lado de Google, verás que la solicitud llega hasta el GFE.

Si ves que los paquetes nunca llegan al GFE, comunícate con tu administrador de red para resolver este problema.

Genera un archivo PCAP y analiza tu firewall o proxy

Genera un archivo de captura de paquetes (PCAP) y analízalo para asegurarte de que el firewall o el proxy no filtren los paquetes a las IPs de Google y permitan que los paquetes lleguen a GFE.

Este es un comando de ejemplo que se puede ejecutar con la herramienta tcpdump:

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

Configura reintentos para problemas de conectividad intermitentes

Hay situaciones en las que los balanceadores de cargas de GFE pueden descartar conexiones de una IP de cliente, por ejemplo, si detectan patrones de tráfico de DSD o si se reduce la escala verticalmente de la instancia del balanceador de cargas, lo que puede provocar que se recicle la IP del extremo. Si los balanceadores de cargas de GFE interrumpen la conexión, el cliente debe detectar la solicitud que agotó el tiempo de espera y volver a intentar la solicitud al extremo de DNS. Asegúrate de no usar la misma dirección IP hasta que la solicitud se realice correctamente, ya que es posible que la dirección IP haya cambiado.

Si identificaste un problema con tiempos de espera constantes del lado de Google en los que los reintentos no ayudan, comunícate con Atención al cliente de Cloud y asegúrate de incluir un archivo PCAP nuevo generado con una herramienta de captura de paquetes como tcpdump.

¿Qué sigue?