Compartilhar via

Troubleshoot tempdb errors on a dedicated SQL pool

  • Artigo

Aplica-se ao: Azure Synapse Analytics

Em um pool de SQL dedicado, o banco de dados tempdb é usado para tabelas temporárias e espaço intermediário para movimentações de dados (por exemplo: movimentações aleatórias, movimentações de corte), classificações, cargas, derramamentos de memória e outras operações. Além disso, uma transação não confirmada em uma sessão que interage com o banco de dados tempdb impedirá que o log libere todas as outras sessões, fazendo com que os arquivos de log sejam preenchidos. Como o banco de dados tempdb é um recurso compartilhado, o grande consumo do espaço tempdb pode fazer com que as consultas de outros usuários falhem e podem ser escalonadas para impedir que novas conexões sejam estabelecidas.

O que fazer se eu não conseguir me conectar ao pool de SQL dedicado?

Se você não tiver conexões existentes para identificar conexões ou consultas problemáticas, o único método para resolver a incapacidade de criar uma nova conexão é Pausar e Retomar ou Dimensionar o pool de SQL dedicado. Essa ação encerrará as transações do usuário que levaram a esse problema e recriará o banco de dados tempdb quando o serviço for reiniciado.

Observação: certifique-se de dar ao serviço tempo extra para desfazer todas as transações em execução, pois as operações de pausa e escala podem levar mais tempo do que o normal para serem concluídas nesse cenário.

Solucionar problemas de arquivos de dados tempdb completos

Etapa 1: Identificar a consulta que preenche o banco de dados tempdb

Certifique-se de identificar a consulta que preenche o banco de dados tempdb enquanto a consulta está sendo executada, a menos que você tenha implementado um componente de log em sua estrutura ETL ou auditoria de suas instruções de pool de SQL dedicadas. Na maioria dos casos, nem sempre, a consulta de execução mais longa executada durante o período em que o problema ocorreu é a causa dos erros de tempdb sem espaço. Execute a seguinte consulta para obter uma lista de consultas de longa duração:

SELECT TOP 5 *
FROM sys.dm_pdw_exec_requests
WHERE status = 'running'
ORDER BY total_elapsed_time desc;

Depois de ter uma consulta razoavelmente suspeita, tente uma das seguintes opções:

  • Mate a declaração.
  • Tente impedir que qualquer outra carga de trabalho consuma ainda mais o espaço tempdb para que o executor longo possa ser concluído.

Passo 2: Evite a recorrência

Depois de identificar e tomar medidas em relação à consulta responsável, considere implementar mitigações para evitar que o problema se repita. A tabela a seguir mostra mitigações para as causas mais comuns de erros de tempdb completo:

Motivo Descrição Mitigação
Plano ineficaz distribuído O plano distribuído gerado para uma determinada consulta pode introduzir inadvertidamente a movimentação de dados de alta frequência como resultado de estatísticas de tabela mal mantidas. Atualize as estatísticas das tabelas relevantes e certifique-se de que elas sejam mantidas regularmente.
Integridade fraca do CCI (Índice Columnstore Clusterizado) Ele consome o espaço tempdb devido a derramamentos de memória. Reconstrua os CCIs e certifique-se de que eles sejam mantidos em um cronograma regular.
Transações grandes Um grande volume de instruções or INSERT SELECT preenche o tempdb durante as operações de movimentação de CREATE TABLE AS SELECT (CTAS) dados. Divida sua instrução CTAS ou INSERT SELECT em várias transações menores.
Alocação de memória insuficiente Consultas com memória insuficiente alocada (por meio de classe de recurso ou grupo de carga de trabalho) podem se espalhar para o tempdb. Execute suas consultas com uma classe de recurso maior ou um grupo de carga de trabalho com mais recursos.
Consultas de tabela externa do usuário final As consultas em tabelas externas não são ideais para consultas de usuário final porque o mecanismo precisa ler o arquivo tempdb inteiro antes de processar os dados. Carregue os dados em uma tabela permanente e, em seguida, direcione as consultas do usuário para ela.
Recursos gerais insuficientes Você pode descobrir que seu pool de SQL dedicado está próximo de sua capacidade máxima de tempdb durante a alta atividade. Considere escalar verticalmente seu pool de SQL dedicado em combinação com qualquer uma das mitigações acima.

Solucionar problemas de arquivos de log de transações tempdb completos

O log de transações tempdb normalmente só é preenchido quando um cliente/usuário:

  • Abre uma transação explícita, mas nunca emite um COMMIT ou ROLLBACK.
  • Conjuntos IMPLICIT_TRANSACTION = ON (especialmente para clientes JDBC e ferramentas que usam recursos de AutoCommit).

Etapa 1: Identificar transações abertas

As conexões problemáticas podem ser de clientes que têm uma transação aberta, mas estão em um status "Ocioso". Execute a seguinte consulta para ajudar a identificar esse cenário:

SELECT *
FROM sys.dm_pdw_exec_sessions
WHERE is_transactional = 1
AND status = 'Idle';

Observação: nem todas as conexões retornadas como resultado dessa consulta são necessariamente problemáticas. Execute a consulta pelo menos duas vezes com mais de 15 minutos entre as execuções e veja quais conexões persistem nesse estado.

Etapa 2: mitigar e evitar o problema

Depois de identificar quais clientes estão mantendo transações abertas, trabalhe com os usuários para alterar um ou ambos:

  • Configuração do driver (por exemplo: configuração do JDBC AutoCommit como off, que define IMPLICIT_TRANSACTIONS = ON)
  • Comportamentos de consulta ad hoc (por exemplo: execução BEGIN TRAN incorreta sem/COMMITROLLBACK )

Como alternativa, você pode considerar a criação de um processo automatizado para detectar periodicamente esse cenário e eliminar quaisquer sessões potencialmente problemáticas.

Recursos