Resolver problemas de consulta

Este documento tem como objetivo ajudar você a solucionar problemas comuns relacionados à execução de consultas, como identificar motivos para consultas lentas ou fornecer etapas de resolução para erros comuns retornados por consultas com falha.

Resolver problemas de consultas lentas

Ao resolver problemas de desempenho lento de consultas, considere as seguintes causas comuns:

  1. Verifique a página Google Cloud Status do serviço para saber sobre interrupções conhecidas do serviço do BigQuery que podem afetar o desempenho das consultas.

  2. Revise a linha do tempo do job para sua consulta na página de detalhes do job e veja quanto tempo levou cada etapa da consulta.

    • Se a maior parte do tempo decorrido for devido a tempos de criação longos, entre em contato com o Cloud Customer Care para receber ajuda.

    • Se a maior parte do tempo decorrido for devido a tempos de execução longos, revise os insights de performance da consulta. Os insights de performance de consultas podem informar se a consulta foi executada por mais tempo do que o tempo médio de execução e sugerir possíveis causas. As possíveis causas incluem disputa de slot de consulta ou uma cota de embaralhamento insuficiente. Para mais informações sobre cada problema de desempenho de consulta e possíveis soluções, consulte Interpretar insights de desempenho de consultas.

  3. Revise o campo finalExecutionDurationMs no JobStatistics do job de consulta. A consulta pode ter sido repetida. O campo finalExecutionDurationMs contém a duração em milissegundos da execução da tentativa final deste job.

  4. Revise os bytes processados na página de detalhes do job de consulta para verificar se eles estão acima do esperado. Para isso, compare o número de bytes processados pela consulta atual com outro job de consulta concluído em um período aceitável. Se houver uma grande discrepância de bytes processados entre as duas consultas, talvez a consulta tenha sido lenta devido a um grande volume de dados. Para informações sobre como otimizar suas consultas para processar grandes volumes de dados, consulte Otimizar a computação de consultas.

    Você também pode identificar consultas no seu projeto que processam uma grande quantidade de dados pesquisando as consultas mais caras usando a visualização INFORMATION_SCHEMA.JOBS.

Comparar uma execução lenta e rápida da mesma consulta

Se uma consulta que antes era executada rapidamente agora está lenta, examine a saída do objeto da API Job para identificar mudanças na execução.

Ocorrências em cache

Confirme se a execução rápida do job foi um ocorrência em cache observando o valor de cacheHit. Se o valor for true para a execução rápida da consulta, ela usou resultados armazenados em cache em vez de ser executada.

Se você espera que o job lento use resultados armazenados em cache, investigue por que a consulta não está mais usando resultados armazenados em cache. Se você não espera que a consulta recupere dados do cache, procure um exemplo de execução rápida que não tenha atingido o cache para a investigação.

Atrasos nas cotas

Para determinar se a lentidão foi causada por adiamentos de cota, verifique o campo quotaDeferments dos dois jobs. Compare os valores para determinar se o tempo de início da consulta mais lenta foi adiado por adiamentos de cota que não afetaram o job mais rápido.

Duração da execução

Para entender a diferença entre a duração da execução da última tentativa dos dois jobs, compare os valores do campo finalExecutionDurationMs.

Se os valores de finalExecutionDurationMs forem muito semelhantes, mas a diferença no tempo de execução real entre as duas consultas, calculada como startTime - endTime, for muito maior, isso significa que pode ter havido uma nova tentativa de execução de consulta interna para o job lento devido a um possível problema temporário. Se você notar esse padrão de diferença repetidamente, entre em contato com o Cloud Customer Care para receber ajuda.

Bytes processados

Revise os bytes processados na página de detalhes do job de consulta ou consulte o totalBytesProcessed em JobStatistics para verificar se ele está mais alto do que o esperado. Se houver uma grande discrepância de bytes processados entre as duas consultas, a consulta poderá ser lenta devido a uma mudança no volume de dados processados. Para informações sobre como otimizar consultas para processar grandes volumes de dados, consulte Otimizar a computação de consultas. Os seguintes motivos podem causar um aumento no número de bytes processados por uma consulta:

  • O tamanho das tabelas referenciadas pela consulta aumentou.
  • A consulta agora está lendo uma partição maior da tabela.
  • A consulta faz referência a uma visualização cuja definição mudou.

Tabelas referenciadas

Verifique se as consultas leem as mesmas tabelas analisando a saída do campo referencedTables em JobStatistics2. As diferenças nas tabelas referenciadas podem ser explicadas pelo seguinte:

  • A consulta SQL foi modificada para ler tabelas diferentes. Compare o texto da consulta para confirmar.
  • A definição da visualização mudou entre as execuções da consulta. Verifique as definições das visualizações referenciadas nesta consulta e atualize-as, se necessário.

As diferenças nas tabelas referenciadas podem explicar as mudanças em totalBytesProcessed.

Uso de visualizações materializadas

Se a consulta fizer referência a alguma visualização materializada, as diferenças de performance podem ser causadas pela escolha ou rejeição de visualizações materializadas durante a execução da consulta. Inspecione MaterializedViewStatistics para entender se alguma visualização materializada usada na consulta rápida foi rejeitada na consulta lenta. Confira os campos chosen e rejectedReason no objeto MaterializedView.

Estatísticas de armazenamento em cache de metadados

Para consultas que envolvem tabelas do BigLake do Amazon S3 ou do Cloud Storage com o armazenamento em cache de metadados ativado, compare a saída de MetadataCacheStatistics para verificar se há uma diferença no uso do cache de metadados entre a consulta lenta e a rápida e os motivos correspondentes. Por exemplo, o cache de metadados pode estar fora da janela maxStaleness da tabela.

Comparar estatísticas do BigQuery BI Engine

Se a consulta usar o BigQuery BI Engine, analise a saída de BiEngineStatistics para determinar se os mesmos modos de aceleração foram aplicados às consultas lenta e rápida. Consulte o campo BiEngineReason para entender o motivo de alto nível da aceleração parcial ou da ausência de aceleração, como falta de memória, ausência de uma reserva ou entrada muito grande.

Analisar diferenças nos insights de desempenho da consulta

Compare os insights de performance de consulta de cada uma das consultas analisando o gráfico de execução no console do Google Cloud ou o objeto StagePerformanceStandaloneInsight para entender os seguintes problemas possíveis:

Preste atenção aos insights fornecidos para o job lento e às diferenças entre os insights produzidos para o job rápido. Assim, você identifica mudanças de estágio que afetam o desempenho.

Uma análise mais completa dos metadados de execução do job exige a análise das etapas únicas da execução da consulta comparando os objetos ExplainQueryStage dos dois jobs.

Para começar, consulte as métricas Wait ms e Shuffle output bytes descritas na seção Interpretar informações da fase de consulta.

Avisos de recursos da visualização INFORMATION_SCHEMA.JOBS

Consulte o campo query_info.resource_warning da INFORMATION_SCHEMA.JOBS visualização para saber se há uma diferença nos avisos analisados pelo BigQuery em relação aos recursos usados.

Análise de estatísticas de carga de trabalho

Os recursos de slots disponíveis e a contenção de slots podem afetar o tempo de execução da consulta. As seções a seguir ajudam você a entender o uso e a disponibilidade de slots para uma execução específica de uma consulta.

Média de slots por segundo

Para calcular o número médio de slots usados por milissegundo pela consulta, divida o valor de slot-milissegundos do job, totalSlotMs de JobStatistics2, pela duração em milissegundos da execução da última tentativa desse job, finalExecutionDurationMs de JobStatistics.

Também é possível calcular o número médio de slots por milissegundo usado por um job consultando a visualização INFORMATION_SCHEMA.JOBS.

Um job que realiza uma quantidade semelhante de trabalho com um número maior de slots médios por segundo é concluído mais rápido. Uma média menor de uso de slots por segundo pode ser causada pelo seguinte:

  1. Não havia outros recursos disponíveis devido a uma disputa entre diferentes jobs. A reserva estava no limite.
  2. O job não solicitou mais slots durante grande parte da execução. Por exemplo, isso pode acontecer quando há um desvio de dados.

Modelos de gerenciamento de carga de trabalho e tamanho da reserva

Se você usa o modelo de faturamento sob demanda, o número de slots que podem ser usados por projeto é limitado. Seu projeto também pode ter menos slots disponíveis se houver uma grande quantidade de contenção de capacidade sob demanda em um local específico.

O modelo baseado em capacidade é mais previsível e permite especificar um número garantido de slots de valor de referência.

Considere essas diferenças ao comparar uma execução de consulta usando sob demanda com uma execução de consulta que usa uma reserva.

Usar uma reserva é recomendado para ter um desempenho de execução de consultas estável e previsível. Para mais informações sobre as diferenças entre cargas de trabalho sob demanda e baseadas em capacidade, consulte Introdução ao gerenciamento de cargas de trabalho.

Simultaneidade de jobs

A simultaneidade de jobs representa a disputa entre jobs por recursos de slot durante a execução da consulta. Uma simultaneidade maior geralmente causa uma execução mais lenta porque o job tem acesso a menos slots.

Você pode consultar a visualização INFORMATION_SCHEMA.JOBS para encontrar o número médio de jobs simultâneos que estão sendo executados ao mesmo tempo que uma consulta específica em um projeto.

Se houver mais de um projeto atribuído a uma reserva, modifique a consulta para usar JOBS_BY_ORGANIZATION em vez de JOBS_BY_PROJECT e receber dados precisos no nível da reserva.

Uma concorrência média maior durante a execução lenta em comparação com a rápida é um fator que contribui para a lentidão geral.

Reduza a simultaneidade no projeto ou na reserva distribuindo consultas que usam muitos recursos ao longo do tempo em uma reserva ou projeto ou em diferentes reservas ou projetos.

Outra solução é comprar uma reserva ou aumentar o tamanho de uma reserva atual. Considere permitir que a reserva use slots inativos.

Para entender quantos slots adicionar, leia sobre estimar os requisitos de capacidade do slot.

Os jobs executados em reservas com mais de um projeto atribuído podem ter resultados diferentes de atribuição de slots com a mesma simultaneidade média de jobs, dependendo do projeto que os está executando. Leia sobre o agendamento justo para saber mais.

Utilização de reservas

Os gráficos de recursos do administrador e o Cloud Monitoring do BigQuery podem ser usados para monitorar a utilização da reserva. Para mais informações, consulte Monitore as reservas do BigQuery.

Para entender se um job solicitou mais slots, consulte a métrica de unidades executáveis estimadas, que é estimatedRunnableUnits da resposta da API Job ou period_estimated_runnable_units na visualização INFORMATION_SCHEMA.JOBS_TIMELINE. Se o valor dessa métrica for maior que zero, o job poderia ter se beneficiado de mais slots naquele momento. Para estimar a porcentagem do tempo de execução do job em que ele teria se beneficiado de mais slots, execute a seguinte consulta na visualização 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;
 O resultado será semelhante ao seguinte: 
+---------------------------------+
|   execution_duration_percentage |
+---------------------------------+
|                            96.7 |
+---------------------------------+

Uma porcentagem baixa significa que a disponibilidade de recursos do slot não é um fator importante para a lentidão da consulta nesse cenário.

Se a porcentagem for alta e a reserva não tiver sido totalmente utilizada durante esse período, entre em contato com o atendimento ao cliente do Cloud para investigar.

Se a reserva foi totalmente utilizada durante a execução lenta do job e a porcentagem for alta, o job foi limitado em recursos. Considere reduzir a simultaneidade, aumentar o tamanho da reserva, permitir que ela use slots ociosos ou comprar uma reserva se o job foi executado sob demanda.

Metadados do job e descobertas da análise de carga de trabalho inconclusivos

Se você ainda não conseguir encontrar o motivo para explicar o desempenho mais lento do que o esperado, entre em contato com o Cloud Customer Care para receber ajuda.

Resolução de esquema Avro

String de erro: Cannot skip stream

Esse erro pode ocorrer ao carregar vários arquivos Avro com esquemas diferentes, resultando em um problema de resolução de esquema e fazendo com que o job de importação falhe em um arquivo aleatório.

Para resolver esse erro, verifique se o último arquivo alfabético do job de carregamento contém o superconjunto (união) dos esquemas diferentes. Esse é um requisito baseado em como o Avro processa a resolução de esquemas.

Consultas simultâneas em conflito

String de erro: Concurrent jobs in the same session are not allowed

Esse erro pode ocorrer quando várias consultas são executadas simultaneamente em uma sessão, o que não é permitido. Veja as limitações da sessão.

Instruções DML conflitantes

String de erro: Could not serialize access to table due to concurrent update

Esse erro pode ocorrer ao modificar instruções de linguagem de manipulação de dados (DML) em execução simultânea na mesma tabela em conflito, ou quando a tabela é truncada durante uma instrução DML mutável. Para mais informações, consulte Conflitos de instruções DML.

Para resolver esse erro, execute operações DML que afetam uma única tabela, de maneira que não se sobreponham.

Subconsultas correlacionadas

String de erro: Correlated subqueries that reference other tables are not supported unless they can be de-correlated

Esse erro pode ocorrer quando a consulta contém uma subconsulta que faz referência a uma coluna de fora dela, chamada de coluna de correlação. A subconsulta correlacionada é avaliada usando uma estratégia de execução aninhada ineficiente, em que a subconsulta é avaliada para cada linha da consulta externa que produz as colunas de correlação. Às vezes, o BigQuery pode reescrever internamente consultas com subconsultas correlacionadas para que elas sejam executadas com mais eficiência. O erro de subconsultas correlacionadas ocorre quando o BigQuery não consegue otimizar a consulta de maneira suficiente.

Para resolver esse erro, tente o seguinte:

  • Remova todas as cláusulas ORDER BY, LIMIT, EXISTS, NOT EXISTS ou IN da subconsulta.
  • Use uma consulta de várias instruções para criar uma tabela temporária a ser referenciada na sua subconsulta.
  • Reescreva a consulta para usar um CROSS JOIN.

Permissões de controle de acesso insuficientes no nível da coluna

String de erro: Requires fineGrainedGet permission on the read columns to execute the DML statements

Esse erro ocorre quando você tenta uma instrução DML DELETE, UPDATE ou MERGE sem ter a permissão de leitor de controle refinado nas colunas verificadas que usam o controle de acesso no nível da coluna para restringir esse tipo de acesso. Para mais informações, consulte Impacto nas gravações com controle de acesso no nível da coluna.

Credenciais inválidas para consultas programadas

Strings de erro:

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

Esse erro pode ocorrer quando uma consulta programada falha devido a credenciais desatualizadas, principalmente ao consultar dados do Google Drive.

Para corrigir esse erro, siga estas etapas:

Credenciais de conta de serviço inválidas

String de erro: HttpError 403 when requesting returned: The caller does not have permission

Esse erro pode aparecer quando você tenta configurar uma consulta programada com uma conta de serviço. Para resolver esse erro, consulte as etapas de solução de problemas em Problemas de autorização e permissão.

Hora inválida do snapshot

String de erro: Invalid snapshot time

Esse erro pode ocorrer ao tentar consultar dados históricos que estão fora da janela de viagem no tempo para o conjunto de dados. Para solucionar esse erro, mude a consulta para acessar dados históricos na janela de viagem no tempo do conjunto de dados.

Esse erro também pode aparecer se uma das tabelas usadas na consulta for descartada e recriada depois que a consulta for iniciada. Verifique se há uma consulta programada ou um aplicativo que execute essa operação que foi executada ao mesmo tempo que a consulta com falha. Se houver, tente mover o processo que executa a operação de soltar e recriar para ser executado em um horário que não entre em conflito com as consultas que leem essa tabela.

O job já existe

String de erro: Already Exists: Job <job name>

Esse erro pode ocorrer em jobs de consulta que precisam avaliar matrizes grandes. Assim, a criação de um job de consulta leva mais tempo que a média. Por exemplo, uma consulta com uma cláusula WHERE como WHERE column IN (<2000+ elements array>).

Para corrigir esse erro, siga estas etapas:

Esse erro também pode ocorrer quando você define manualmente um ID de job, mas o job não retorna sucesso dentro de um período de tempo limite. Nesse caso, adicione um gerenciador de exceções para verificar se o job existe. Em caso afirmativo, você pode extrair os resultados da consulta do job.

Job não localizado

String de erro: Job not found

Esse erro pode ocorrer em resposta a uma chamada getQueryResults, em que nenhum valor é especificado para o campo location. Se esse for o caso, tente ligar novamente e forneça um valor location.

Para mais informações, consulte Evitar várias avaliações das mesmas expressões de tabela comum (CTEs).

Local não encontrado

String de erro: Dataset [project_id]:[dataset_id] was not found in location [region]

Esse erro é retornado quando você se refere a um recurso de conjunto de dados que não existe ou quando o local na solicitação não corresponde ao local do conjunto de dados.

Para resolver esse problema, especifique o local do conjunto de dados na consulta ou confirme se ele está disponível no mesmo local.

A consulta excede o limite de tempo de execução

String de erro: Query fails due to reaching the execution time limit

Se a consulta estiver atingindo o limite de tempo de execução da consulta, verifique a duração das execuções anteriores consultando a visualização INFORMATION_SCHEMA.JOBS com uma consulta semelhante ao seguinte exemplo:

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

Se as execuções anteriores da consulta tiverem demorado muito menos tempo, use os insights de desempenho da consulta para determinar e resolver o problema.

A resposta da consulta é muito grande

String de erro: responseTooLarge

Este erro ocorre quando os resultados da consulta são maiores do que o tamanho máximo da resposta.

Para resolver esse erro, siga as orientações fornecidas para a mensagem de erro responseTooLarge.

A reserva não foi encontrada ou está sem slots

String de erro: Cannot run query: project does not have the reservation in the data region or no slots are configured

Esse erro ocorre quando a reserva atribuída ao projeto na região da consulta não tem slots atribuídos. Você pode adicionar slots à reserva, permitir que ela use slots inativos, usar uma reserva diferente ou remover a atribuição e executar a consulta sob demanda.

Tabela não encontrada

String de erro: Not found: Table [project_id]:[dataset].[table_name] was not found in location [region]

Esse erro ocorre quando uma tabela na sua consulta não pode ser encontrada no conjunto de dados ou na região especificada. Para resolver esse erro, faça o seguinte:

  • Verifique se a consulta contém o projeto, o conjunto de dados e o nome da tabela corretos.
  • Verifique se a tabela existe na região em que você executou a consulta.
  • Verifique se a tabela não foi descartada e recriada durante a execução do job. Caso contrário, a propagação incompleta de metadados pode causar esse erro.

Muitas instruções DML

String de erro: Too many DML statements outstanding against <table-name>, limit is 20

Esse erro ocorre quando você excede o limite de 20 instruções DML no status PENDING em uma fila para uma única tabela. Esse erro geralmente ocorre quando você envia jobs DML em uma única tabela mais rapidamente do que o BigQuery pode processar.

Uma solução possível é agrupar várias operações DML menores em jobs maiores, mas com menos jobs, por exemplo, agrupando atualizações e inserções. Quando você agrupa jobs menores em jobs maiores, o custo para executá-los é amortizado e a execução é mais rápida. A consolidação de instruções DML que afetam os mesmos dados geralmente melhora a eficiência dos jobs DML e tem menor probabilidade de exceder o limite de cota de tamanho de fila. Para mais informações sobre como otimizar suas operações DML, consulte Evitar instruções DML que atualizam ou inserem linhas individuais.

Outras soluções para melhorar a eficiência da DML podem ser particionar ou agrupar as tabelas. Para saber mais, consulte Práticas recomendadas.

Transação cancelada devido a uma atualização simultânea

String de erro: Transaction is aborted due to concurrent update against table [table_name]

Esse erro pode ocorrer quando duas instruções DML mutáveis tentam atualizar simultaneamente a mesma tabela. Por exemplo, suponha que você inicie uma transação em uma sessão que contenha uma instrução DML mutante seguida de um erro. Se não houver um gerenciador de exceções, o BigQuery vai reverter automaticamente a transação quando a sessão terminar, o que leva até 24 horas. Durante esse período, outras tentativas de executar uma instrução DML mutante na tabela vão falhar.

Para resolver esse erro, liste suas sessões ativas e verifique se alguma delas contém um job de consulta com o status ERROR que executou uma instrução DML mutante na tabela. Em seguida, encerre essa sessão.

O usuário não tem permissão

Strings de erro:

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

Esses erros podem ocorrer quando você executa uma consulta sem a permissão bigquery.jobs.create no projeto em que está executando a consulta, independentemente das suas permissões no projeto que contém os dados.

Você também pode receber esses erros se sua conta de serviço, usuário ou grupo não tiver a permissão bigquery.tables.getData em todas as tabelas e visualizações referenciadas pela consulta. Para mais informações sobre as permissões necessárias para executar uma consulta, consulte Funções necessárias.

Esses erros também podem ocorrer se a tabela não existir na região consultada, como asia-south1. Para verificar a região, examine o local do conjunto de dados.

Ao corrigir esses erros, considere o seguinte:

  • Contas de serviço: as contas de serviço precisam ter a permissão bigquery.jobs.create no projeto em que são executadas e a permissão bigquery.tables.getData em todas as tabelas e visualizações referenciadas pela consulta.

  • Papéis personalizados: os papéis personalizados do IAM precisam ter a permissão bigquery.jobs.create explicitamente incluída no papel relevante e a permissão bigquery.tables.getData em todas as tabelas e visualizações referenciadas pela consulta.

  • Conjuntos de dados compartilhados: ao trabalhar com conjuntos de dados compartilhados em um projeto separado, talvez você ainda precise da permissão bigquery.jobs.create no projeto para executar consultas ou jobs nesse conjunto de dados.

Para conceder permissão de acesso a uma tabela ou visualização, consulte Conceder acesso a uma tabela ou visualização.

Problemas com recursos excedidos

Os seguintes problemas ocorrem quando o BigQuery não tem recursos suficientes para concluir sua consulta.

A consulta excede os recursos da CPU

String de erro: Query exceeded resource limits

Ele ocorre quando as consultas on demand usam muita CPU em relação à quantidade de dados verificados. Para informações sobre como resolver esses problemas, consulte Resolver problemas de recursos excedidos.

A consulta excede os recursos de memória

String de erro: Resources exceeded during query execution: The query could not be executed in the allotted memory

Para instruções SELECT, esse erro ocorre quando a consulta usa muitos recursos. Para corrigir esse erro, consulte Resolver problemas de recursos excedidos.

Sem espaço na pilha

String de erro: Out of stack space due to deeply nested query expression during query resolution.

Esse erro pode ocorrer quando uma consulta contém muitas chamadas de função aninhadas. Às vezes, partes de uma consulta são convertidas em chamadas de função durante a análise. Por exemplo, uma expressão com operadores de concatenação repetidos, como A || B || C || ..., se torna CONCAT(A, CONCAT(B, CONCAT(C, ...))).

Para corrigir esse erro, reescreva a consulta para reduzir a quantidade de aninhamento.

Recursos excedidos durante a execução da consulta

String de erro: 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.

Isso pode acontecer com consultas ORDER BY ... LIMIT ... OFFSET .... Devido a detalhes de implementação, a classificação pode ocorrer em uma única unidade de computação, que pode ficar sem memória se precisar processar muitas linhas antes da aplicação de LIMIT e OFFSET, principalmente com um OFFSET grande.

Para corrigir esse erro, evite valores grandes de OFFSET em consultas ORDER BY ... LIMIT. Como alternativa, use a função de janela escalonável ROW_NUMBER() para atribuir classificações com base na ordem escolhida e filtre essas classificações em uma cláusula WHERE. Exemplo:

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

A consulta excede os recursos de embaralhamento

String de erro: Resources exceeded during query execution: Your project or organization exceeded the maximum disk and memory limit available for shuffle operations

Esse erro ocorre quando uma consulta não pode acessar recursos suficientes do embaralhamento.

Para solucionar esse erro, provisione mais slots ou reduza a quantidade de dados processados pela consulta. Para mais informações sobre como fazer isso, consulte Cota de embaralhamento insuficiente.

Para mais informações sobre como resolver esses problemas, consulte Resolver problemas de recursos excedidos.

A consulta é muito complexa

String de erro: Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex

Esse erro ocorre quando uma consulta é muito complexa. As principais causas de complexidade são:

  • Cláusulas WITH que estão muito aninhadas ou são usadas de forma repetida.
  • Visualizações muito aninhadas ou usadas de forma repetida.
  • Uso repetido do operador UNION ALL.

Para resolver esse erro, tente as seguintes opções:

  • Divida a consulta em várias consultas e use a linguagem processual para executar essas consultas em uma sequência, com estado compartilhado.
  • Use tabelas temporárias em vez de cláusulas WITH.
  • Reescreva sua consulta para reduzir o número de objetos referenciados e comparações.

É possível monitorar de maneira proativa as consultas que estão se aproximando do limite de complexidade usando o campo query_info.resource_warning na visualização INFORMATION_SCHEMA.JOBS. O exemplo a seguir retorna consultas com alto uso de recursos nos últimos três dias:

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

Para mais informações sobre como resolver esses problemas, consulte Resolver problemas de recursos excedidos.

Resolver problemas de recursos excedidos

Para jobs de consulta:

Para otimizar suas consultas, siga estas etapas:

  • Tente remover uma cláusula ORDER BY.
  • Se a consulta usa JOIN, verifique se a tabela maior está à esquerda da cláusula. Além disso, verifique se os dados não contêm chaves de junção duplicadas.
  • Se a consulta usa FLATTEN, determine se ele é necessário no caso de uso específico. Para mais informações, consulte dados aninhados e repetidos.
  • Se a consulta usa EXACT_COUNT_DISTINCT, considere usar COUNT(DISTINCT).
  • Se a consulta usa COUNT(DISTINCT <value>, <n>) com um grande valor <n>, use GROUP BY em vez disso. Veja mais informações em COUNT(DISTINCT).
  • Se a consulta usa UNIQUE, utilize GROUP BY em vez disso, ou use a função de janela dentro de uma subseleção.
  • Se a consulta materializar muitas linhas usando uma cláusula LIMIT, considere filtrar em outra coluna, por exemplo, ROW_NUMBER(), ou remover a cláusula LIMIT completamente para permitir o carregamento em paralelo de gravação.
  • Se a consulta usou visualizações profundamente aninhadas e uma cláusula WITH, isso pode causar um crescimento exponencial na complexidade, o que causará o atingimento dos limites.
  • Use tabelas temporárias em vez de cláusulas WITH. Uma cláusula WITH pode precisar ser recalculada várias vezes, o que pode tornar a consulta complexa e, portanto, lenta. Manter os resultados intermediários em tabelas temporárias reduz a complexidade.
  • Evite usar consultas UNION ALL.
  • Se a consulta usar MATCH_RECOGNIZE, modifique a cláusula PARTITION BY para reduzir o tamanho das partições ou adicione uma cláusula PARTITION BY se ela não existir.

Para saber mais, acesse os recursos a seguir:

Para jobs de carregamento:

Se você estiver carregando arquivos Avro ou Parquet, reduza o tamanho da linha. Verifique se há restrições de tamanho específicas para o formato do arquivo que você está carregando:

Se você receber esse erro ao carregar arquivos ORC, entre em contato com o suporte.

Para a API Storage:

String de erro: Stream memory usage exceeded

Durante uma chamada ReadRows da API Storage Read, alguns streams com alto uso de memória podem receber um erro RESOURCE_EXHAUSTED com essa mensagem. Isso pode acontecer na leitura de tabelas largas ou com um esquema complexo. Como resolução, reduza o tamanho da linha de resultado selecionando menos colunas para ler (usando o parâmetro selected_fields) ou simplificando o esquema da tabela. ,

Resolver problemas de conectividade

As seções a seguir descrevem como resolver problemas de conectividade ao tentar interagir com o BigQuery:

Adicionar o DNS do Google à lista de permissões

Use a ferramenta Google IP Dig para resolver o endpoint DNS do BigQuery bigquery.googleapis.com em um único IP de registro "A". Verifique se o IP não está bloqueado nas configurações do firewall.

Em geral, recomendamos permitir os nomes do DNS do Google. Os intervalos de IP compartilhados nos arquivos https://www.gstatic.com/ipranges/goog.json e https://www.gstatic.com/ipranges/cloud.json mudam com frequência. Por isso, recomendamos adicionar à lista de permissões os nomes do DNS do Google. Confira uma lista de nomes de DNS comuns que recomendamos adicionar à lista de permissões:

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

Identificar o proxy ou firewall que está descartando pacotes

Para identificar todos os saltos de pacote entre o cliente e o Google Front End (GFE), execute um comando traceroute na máquina do cliente que possa destacar o servidor que está descartando pacotes direcionados ao GFE. Confira um exemplo de comando traceroute:

traceroute -T -p 443 bigquery.googleapis.com

Também é possível identificar os saltos de pacote para endereços IP específicos do GFE se o problema estiver relacionado a um endereço IP específico:

traceroute -T -p 443 142.250.178.138

Se houver um problema de tempo limite do lado do Google, você vai ver a solicitação chegar até o GFE.

Se os pacotes nunca chegarem ao GFE, entre em contato com o administrador da rede para resolver o problema.

Gerar um arquivo PCAP e analisar seu firewall ou proxy

Gere um arquivo de captura de pacote (PCAP) e analise-o para garantir que o firewall ou proxy não esteja filtrando pacotes para IPs do Google e permitindo que os pacotes cheguem ao GFE.

Confira um exemplo de comando que pode ser executado com a ferramenta tcpdump:

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

Configurar novas tentativas para problemas de conectividade intermitentes

Há situações em que os balanceadores de carga do GFE podem descartar conexões de um IP do cliente. Por exemplo, se ele detectar padrões de tráfego de DDoS ou se a instância do balanceador de carga estiver sendo reduzida, o que pode resultar na reciclagem do IP do endpoint. Se os balanceadores de carga do GFE descartarem a conexão, o cliente precisará capturar a solicitação com tempo esgotado e tentar de novo para o endpoint DNS. Não use o mesmo endereço IP até que a solicitação seja concluída, porque ele pode ter mudado.

Se você identificou um problema com tempos limite consistentes do lado do Google em que as novas tentativas não ajudam, entre em contato com o Cloud Customer Care e inclua um arquivo PCAP atualizado gerado pela execução de uma ferramenta de captura de pacotes, como o tcpdump.

A seguir